Add context to accessible names for datetime range field inputs

Worth mentioning that in HTML5 browsers there is usually some indication on what goes in there. This is Chrome on OSX:

We also have invisible labels on each input element.

There is a related issue about the input format help text (it's on the timestamp widget), but I can't find it right now.

As a bug report this is eligible for 8.4.x releases.

Would it work if we just add a placeholder in the form 'dd-mm-yyyy' and '--:--:--' to these form elements? This would add a fallback for browser who don't add a placeholder themselves.

We could do this in processDatetime, where the title is set as well:

<?php
'title' => t('Date (e.g. @format)', ['@format' => static::formatExample($date_format)]),
?>

However, the formatExample callback returns an example in the form 'Date (e.g. 2017-09-29)', so we might want to add an extra helper function like formatExample (formatPlaceholder?) that will return 'yyyy-mm-dd' based on 'Y-m-d'?

Placeholder are often a problem for both blind and low vision users. Plus, once you click on them they go away. Having a description (visible or not) that is semantically linked with the label with something like aria-describedby would be best.

Is this still an issue?

Hi larowlan, Yes this is my fresh install of drupal 10 dev.

I've added tags to this to make sure it's grouped together for the #Usability team to decide what should be done. [2897397]

As it is presently there is a visually hidden label for both the date and time fields, and the inputs themselves use the correct html input types to allow the browser to handle the rendering of the individual field types natively. So I'd say it's less of an issue than it was, although whether that meets accessibility and usability targets would require input from those stakeholders

Note:
The Datetime range field can be added in Drupal 11 core via the Datetime Range module. Ensure that this has been enabled from ‘Extend’. Add a Date and Time field, then select ‘Date range’

The issue appears to be visually fixed as of Drupal 11, with placeholder values placed within the date and time fields. Both prefilled placeholder values and help text are customisable via 'Manage Fields'.

However, accessibility testing is still required to ensure that relevant fields can easily read by assistive software.

Solution by @jeantttttt and @r.imassi

Helped by @xjm and @quietone

Thanks @jeantttttt and @r.imassi!

Based on #25 and #26, I think we can rescope this issue to just do accessibility testing to ensure the hidden labels in #25 are sufficient for screen reader and similar usecases.

If it passes accessibility testing, this issue can be marked "Closed (duplicate)" (if we happen to find the issue that originally improved this) or "Closed (outdated)" otherwise.

If it's not sufficiently accessible, then we should rescope this to be about adding the needed ARIA functionality.

Tagging for accessibility review of the current state in HEAD.

Using the ANDI toolbar tool I can confirm it does have a label. Will ping the accessibility guys

tl;dr: Research in progress.

I just checked on main in Edge with VoiceOver. My observation is that the fields do have accessible names, as mentioned in #28.

However, it's not apparent whether the fields are the "Start Date" and "Start Time" as opposed to the "End Date" and "End Time".

So, my first impression is that now there is a different bug. Attached video shows this behavior.

The text "Start date" and "End date" are inside h4 elements, which creates another problem that may be contributing to this (the text isn't automatically included into the field names). That particular issue is probably covered by #3587677: heading-order: Ensure the order of headings is semantically correct, b/c my guess is that they all use datetime-wrapper.html.twig.

Seem what we could do here is change to start and end time?

re: @kentr voiceover announces in the the summary for the date range field that the date range field first has the date and time for the start date and then the date and time for the end date. but within the date time field steppers you not necessarily have the situational awareness in the aural interface if you are in the fields for the start or end time.

in general it has to be noted that browsers improved the support for the date and time fields significantly since 2017 when this issue was created. so the status quo is quite good.

in regard to the point @kentr raised in #29 i'Ve quickly recorded three short videos to illustrate that each browser employs a different value for an empty field. Chrome based browsers, edge in my case. use odd values (edge.mp4), while firefox uses "NaN" (firefox.mp4), and safari uses just "0" (safari.mp4).

It has to be noted that the color contrast the placeholder text uses in firefox and edge has a high enough contrast, but in safari the contrast is too light (i just used a color picker and i get ~2.13:1 for #b0b1bb against #ffffff - ideally the contrast should be at least 4.5:1).

Then there are two mostly ux related problems.

You know that the date and time field are required, it gets properly announced and communicated. The only problem is it is not clear if you have to enter values to the second. Personally, by reflex, i tend to only enter hours and minutes, and then assume that the value provided by the placeholder is being used without any entry. so entering 12:12 as the start time i would expect that 12:12:00 PM is being used based on the default placeholder values, but as you can see and hear the validation fails (safari_date_entry.mp4 - the video also illustrates the entire interaction with the date range field in safari and voice over, but i suppose that detail is out of the scope for this issue)

the other detail is in regard of labeling, by accident we've discussed the following issue #3023777: datetime_range fields have confusing options for date type setting during the last ux meeting on friday. on the field settings page for the date range field you have the options "All day" and "Date only" aside "daten and time"- on the node edit form the user has no way to distinguish if the field at hand is a "all day" field or "date only" field. it might be good if the editor entering knows which option was used and in consequence also knows what the difference between those to options actually is.

p.s. there is one detail i wanted to test but i am blanking where to change that setting, or at this point i am even uncertain if it is possible at all. is it possible to change the timeformat that is used on node edit forms? at the moment the entry into the date range field is in the 12h format. but you are only able to choose a time format on the "manage display" page for the field, but not on "manage form display".

I reviewed the Date and Time label behavior, and the same implementation exists in previous Drupal versions, including 8.x, 9.x, and 10.x.

No need to added the label text on the Time field.

The issue appears to be visually resolved in Drupal 11, as placeholder values are now displayed inside the date and time fields.

Therefore, we updated the field label to “Date + Time” from the Manage Fields configuration for better clarity.

Attached screenshot for reference.

That wasn't really what this issue was referring to and kinda bypassed all that was discussed before.

@rkoller thanks for the write up, some of those seem like their own issue but would you say though that it's properly labeled?

re #34: first in regard to the question if the date and time fields are properly labeled.

Sighted users are provided with the general context (start date and end date) by the field labels, while the details are conveyed via the placeholder text. Problem here, the information communicated via the placeholder text might be not accessible for everyone in every situation due to the lack of color contrast. Therefore people with visual impairments might run into barriers same as people without any visual impairment under certain conditions like bright day light.
Another detail to denote in the context of labeling that I've just noticed while writing up this summary. The iconography on the date and time fields shown in the "user interface changes" section in the issue summary doesn't apply to every browser. For Blink based browsers date and time fields have an icon but they have no AM/PM stepper, for Gecko based browsers date fields have an icon while time fields have no icon and they have a AM/PM stepper, while Webkit based browsers have no icons at all on date nor time field, but they have a AM/PM stepper. And it has to be noted that the Iconography provides visual cues only to sighted users.

Screenreader users might have problems depending on the browser they are using, a detail @kentR reminded me to. In Safari, when you tab through a form, and you get to the date field for the start date of a datetime range you get an announcement with a summary of the entire range, the steps itself are provided without any context afterwards (see safari_date_entry.mp4). In Firefox and Edge that summary is entirely missing, you only have the steps without any context when you tab through the form.

I've discussed the scope for this issue and which of the raised points should be moved to followups with @kentr via Slack - we've agreed on the following suggestion:

The only problem that should be fixed within the scope of this issue is a detail @kentr came up with. Currently the label on the stepper is

• Date
• Time
• Date
• Time

but it would be possible to change the visually-hidden label to

• Start date
• Start time
• End date
• End time

That way it would be ensured that the context is conveyed in the aural interface for every step. The rest of the following points should be moved to dedicated followup issues from our point of view:

1. Strictly speaking a high enough color contrast is mandatory that everyone is able to read the placeholder text, but there are two reasons why it is probably the better choice to move solving that problem to a followup. First, date and time fields don't support the placeholder pseudoelement, that is why the styling might be a bit more "hackish" and not that easy and quickly to accomplish. Second, making the styling of placeholder text consistent across browser shouldn't be exclusive to date and time fields but should be done for the themes in core consistently.
2. It would be good if empty values would be announced consistently across screenreaders. It would be nice to solve that inconsistency already in the scope of the current issue, but due to the fact it is most likely not that easy to accomplish it is probably the better choice to move the issue to a followup so the current issue isn't hold back - the labeling is more pressing to get solved.
3. In regard to the US centric date format (month day, Europe for example uses day month), time format (12h, Europe for example uses 24h), and delimiter (/, Europe for example uses . ) i've found an already existing but postponed issue: #169187: Easier date-time format setting . I've added a proposed resolution that would also solve the remaining problems for this issue here.

Thanks @rkoller this looks good. Would be nice to resolve this issue.

This seems like a good approach.

Thanks @rkoller for posting the discussion summary.

Removing Needs accessibility review based on input from the accessibility folks.

Updated the IS and attached a more complete video with sound of VoiceOver in Edge while moving through the Form controls rotor menu with the arrow key.

Ready for some thoughts

thank you for working on this! ive quickly checked out MR15802... ive tested on macos with latest safari, firefox, and edge in combination with voiceover.

sounds like only in edge the visually hidden labels are announced for every step (edge.mp4). in firefox (firefox.mp4) and safari (safari.mp4) that labeling for the steppers is not announced. and only in safari you have that summary at the beginning when the focus steps into the date range field and onto the start date field. neither edge nor firefox do have that kind of summary. and it has also be noted that the datefields behave differently interaction wise across browsers in regard to keyboard interaction. in particular edge stands out since only the first stepper is within the tab order the other steps have to be reached via the arrow key, an behavior unavailable for safari and chrome.

and seeing and hearing the differing behavior in between browsers with voiceover, i think it would be necessary to also test in more screenreaders aside voiceover. there might be more "surprises"

Looks like the proposed resolution didn't work as expected.

Putting at Needs work just to save other people from reviewing further until we figure out what's next.

I also had the thought of replacing the two h4 elements with two fieldset elements.

Seems like that would especially make sense to me when there is both a date and a time field, because fieldset is meant to group multiple controls. Not sure how it would be when there is only one field in each.

This would probably require template changes, though. It might also require CSS changes, because the nested fieldsets might not look great.

Another thing that came up in a discussion with @rkoller is that Adrian Roselli prefers plain text fields for known dates and says <input type="date"> is a problem for voice users.

Adrian also references this Graham Armfield post which says:

Is there enough support for input type="date" to make it safe to use as part of an accessible website, or web based application?
While some browsers have pretty good support for input type=”date”, including our accessibility requirements, our answer, sadly, has to be… “No”.

The Graham Armfield post is from 2019, so some of it may be out of date. Also, some of his points are related to HTML5 validation.

I later found out that the GOV.UK Design System also prefers text fields for memorable / known dates.

I'm mentioning this because I'm not convinced that all of the other problems that @rkoller found with these native fields are solvable, such as the color contrast of the placeholder text and the order of the day & month components based on locale.

So, I'm wondering if the fix for this issue lies in replacing these native date & time fields with something more accessible, starting by offering an option of multiple plain text fields for the cases where a date picker isn't required.

@rkoller said he would inquire with the UX people whether there are also general UX problems with these native fields (separate from the accessibility issues).