Won't fix Date field accessible name is overridden by the help text

[36degrees]

Affected version

v2.2.4

Form controls that ask for dates (with data-xf-init="date-input") generally seem to be associated with their labels correctly, but the use of aria-label on the form controls (to provide the 'Use the arrow keys to pick a date' help text) overrides the label – the accessible name for these controls ends up as just 'Use the arrow keys to pick a date' and the context of what the field is for is lost.

It would be more appropriate to make this help text part of the accessible description (for example using aria-describedby)

 

[Mike]

So this is actually coming directly from Pikaday, which is the library we use for the date picker. You can see it on their demo: https://pikaday.com/

There does appear to be an open issue about some regressions in their accessibilty:

Screen reader experience is broken · Issue #776 · Pikaday/Pikaday

Hi, While doing an accessibility audit we found an issue with how Voiceover reads through the datepicker. Keyboard navigation works perfectly and Voiceover starts to read the Use the arrow keys to ...

github.com

Though interestingly I haven't seen anything mentioned about this particular issue. I agree that using aria-label for this doesn't seem ideal, though it doesn't look like there's a way to prevent it (short of changes to the library directly). Given the potential other issues presented by the linked issue, that may really be a comparatively minor issue.

 

[36degrees]

Given the potential other issues presented by the linked issue, that may really be a comparatively minor issue.

I broadly agree, but (thankfully!) users can still input a date into the text box directly, ignoring the date picker entirely. So, even if other accessibility issues prevent them being able to use the date picker they could still fill it in, except for the fact that the overwritten label means they may not know what the field is for.

 

[Chris D]

In a future version of XF, (XF 2.3) we will no longer have a reliance on Pikaday in favour of using native HTML5 inputs for date, datetime-local and time.

It doesn't look like there are any accessibility improvements forthcoming in Pikaday.

The accessibility support of the native date input varies from browser to browser but is pretty good in both Firefox, Edge, and Chrome as far as I can determine. I haven't tested Android or iOS. Safari on macOS with VoiceOver seems a little patchy but the support for this element is fairly recent so the hope is that they will make accessibility improvements as time goes on.

As we're not planning to continue to use Pikaday is an acceptable workaround for now simply removing the problematic aria-label entirely? They will lose that instruction entirely but the proper form label will no longer be overwritten. Is that preferable?

 

[Chris D]

As mentioned previously, XF 2.3 uses native date/time inputs so this bug is no longer valid. But please do open a new report if you find any specific accessibility issues with the new approach that need some attention.