Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG][Accessibility]: Date Picker Component #103

Open
lewisdorigo opened this issue Jul 24, 2024 · 6 comments
Open

[BUG][Accessibility]: Date Picker Component #103

lewisdorigo opened this issue Jul 24, 2024 · 6 comments

Comments

@lewisdorigo
Copy link

lewisdorigo commented Jul 24, 2024

Description of the issue

After an accessibility audit on the Social Security Scotland Digital Portal, a few issues were raised with the Date Picker component supplied by the Design System.

Screen reader users aren't informed when the calendar is navigated.

When using the next/previous month and year buttons, user is not informed of the new month/year being displayed.

It was recommended that the .ds_datepicker__dialog__title element be given aria-live="polite".

Screenshot showing the date picker header.

aria-selected="true" is not supported on <button> elements

The currently selected month has the aria-selected="true" attribute, however this attribute is not actually supported on <button> elements. This means that screen reader users are not informed when they are on the currently selected date.

The WAI Date Picker Dialog uses a <table role="grid"> which additionally marks each <td> as being interact-able, and the <td> here supports aria-selected.

Alternatively aria-pressed may be more appropriate to use

Screenshot showing the date picker component with the currently selected date

Current date does not use aria-current

The current date is visually shown to clients, however this isn't highlighted to assistive technologies. This should have the aria-current="date" attribute, which would inform screen reader users that it is the current date.

@jsutcliffe
Copy link
Member

Thank you Lewis. Fixes for these should go into the next DS release.

@jamiegaskell
Copy link

jamiegaskell commented Jul 25, 2024

Just to add to this, aria-description may not be widely supported. According to https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-description, it's still in the W3C Editor's Draft for ARIA 1.3. Having said that, it appears to work with Jaws on Edge, Windows Narrator and TalkBack. That's all I've been able to test it on though.

@matthewford
Copy link

Just to add to this, I couldn't get keyboard navigation to work in Safari.

@jsutcliffe
Copy link
Member

Hi @matthewford, can you be more specific? E.g. what keyboard interactions are failing, what version of Safari are you using?

@matthewford
Copy link

Hi @matthewford, can you be more specific? E.g. what keyboard interactions are failing, what version of Safari are you using?

I'm trying to open the calendar widget - which works in Chrome but doesn't work in Safari 17.6 (a college also reported it is not working on their Safari, which might have been a different version).

@jsutcliffe
Copy link
Member

Ah, I see -- that's actually just default Safari behaviour. Tabbing in Safari does not tab through every interactive element as you might expect from other browsers, but only tabs through text fields and pop-up menus.

You can press option-tab to tab into other types of element, or you can set an option in Safari preferences to make the tab key behave similarly to how it works in other browsers (Preferences -> Advanced -> Press Tab to highlight each option on a web page).

Since that is something that is controlled by a user's preferences it is not appropriate for us to try to force that behaviour at all times.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants