USWDS- Date Picker: Improve screen reader keyboard navigation #5374
Conversation
There was a problem hiding this comment.
This is a huge improvement in keyboard/arrow key functionality.
In JAWS I'm able to easily navigate to different dates using the up and down arrow keys. The screen reader announcements are clear and easy to follow.
The only issue in NVDA is that I hear "application: table" announced before it tells me what date/cell I'm on. The arrow keys work. It's just annoying to hear that after every single change in focus.
|
@amycole501 Thanks for your review! Do you think that the NVDA "application: table" should hold back this change? Or do you think we should move forward with this improvement? |
|
The improvement is such that I think the minor announcement hiccup shouldn't hold up the change. The extra wording doesn't hinder usability so much as it makes it unnecessarily verbose. The important thing is that the person can use a keyboard to choose a date using the arrow keys. We can keep the "application table" issue in the backlog to fix in the future. |
|
@amycole501 That's a great idea, I'll add an issue to the backlog. Would you mind Clicking the "Add Review" button at the top and leave a comment with the "Approved" radio button selected so github shows your approval? |
There was a problem hiding this comment.
@mahoneycm, could you help me better understand what role="application" is doing here? I don't see any effect (positive or negative) in the VoiceOver experience. Is it necessary for JAWS and/or NVDA?
I tested with VoiceOver in Chrome, Safari, and Firefox. I also tested with VoiceOver Gestures in iOS Safari. I noticed only one minor VoiceOver regression from develop when using left/right swipe (See note about left and right swipe in touch interaction below).
I also saw some improvements, like being able to use table controls (VO + up/down arrow) to move up and down in Firefox, whereas up/down navigation was not possible before (See note about Up arrow/Down arrow below).
I did find a few gaps in the VoiceOver keyboard and touch experience. Most of these are likely out of scope on this issue, but I wanted to log these issues while I was testing in there to see if any of it makes sense to fix here. The items of concern are flagged in the list below. I figure we can make new issues from the description here if we don't want to tackle them now:
-
Screen reader readout matches
develop -
Screen reader readout is intuitive and make sense
- Here is a visual of the readouts for each item. This example shows VoiceOver readout Chrome, but the other browsers provide similar readouts with just some small formatting differences. The readout seemed intuitive to me.
⚠️ It would probably be good to change the the “Click to select year” language to be more inclusive of other navigation methods.
-
Date picker keyboard navigation with screen reader is intuitive
-
Tab/Shift+Tab: Moves through navigation items above the calendar (Navigate back one year, navigate back one month, etc) then moves to the selected date. -
Up arrow/Down arrow:⚠️ When VoiceOver is turned on in Chrome and Safari, the up and down arrows stop working as expected after using theTabkey anywhere in the component. (This matches the behavior indevelopand also occurs in your div-based demo)- Note: This issue does NOT happen when using
VO+Up/down arrow(This is an improvement overdevelop)
- Note: This issue does NOT happen when using
⚠️ When VoiceOver is turned on in Firefox, the up and down arrows close the dialog when VoiceOver is turned on (This matches the behavior indevelopand also occurs in your div-based demo)- Note: This issue does NOT happen when using
VO+Up/down arrow(This is an improvement overdevelop)
- Note: This issue does NOT happen when using
-
Left arrow/Right arrow: Moves the date value forward or backward by one day. -
Page up/Page down(Simulated in MacOS withFn+Up arroworFn+Down arrow): Moves focus to the same date on the previous/next month -
Enterwhen date is in focus : Adds the selected date to the input field
-
-
Date picker can be navigated easily with touch navigation
⚠️ The initial readout provides keyboard instructions instead of touch instructions- Left and right swipe in iOS: Moves to the next/previous date
- Behavior works as expected
⚠️ Note: in iOS with VoiceOver gestures, the readout now includes the abbreviations for the day of the week before the date “Th - sept 28”, “Fr - sept 29”. It is not immediately clear what these letters mean (”Thursday” and “Friday”) and it would be better if they were not read out. (This issue does not happen indevelop)
- Up and down swipe in iOS with VO Gestures:
-
⚠️ This does not work. Reads out “Heading not found” and does not move focus.
-
⚠️ I could not discover an easy way to navigate into the top navigation bar (could only swipe left/right).- 💡 It would be great if the text input for date picker opened the number keypad. Right now it opens the standard alpha keypad.
-
Navigation between months is possible without leaving the calendar table
- When VoiceOver is turned on in Chrome and Safari, using the up/down/left/right arrows will successfuly move to the previous/next month once focus is on the first/last of the month. (This matches the behavior in
develop) ⚠️ When VoiceOver is turned on in Firefox and VoiceOver Gestures is turned on in iOS Safari, you cannot move to another month with the left/right arrows. You must use the top navigation to move to next/previous month. (This matches the behavior indevelop)
- When VoiceOver is turned on in Chrome and Safari, using the up/down/left/right arrows will successfuly move to the previous/next month once focus is on the first/last of the month. (This matches the behavior in
Update
I opened the following issues to address the pre-existing touch and keyboard interaction concerns:
|
Also, a small note but can you add more detail to the summary in the PR description? |
More inclusive language@amyleadem I like the idea of using this PR to update the "Click to" language to something more inclusive! @amycole501 What do you think of Amy's comment?
Are you aware of better language we can use for actionable items? |
|
Hey there @amyleadem ! Thanks for the detailed review! role="application"From mdn:
This solution was based on the accessible screen reader offered by Deque University as well as this fix implemented by the Carbon design system My understanding is that this captures keyboard inputs better and allows us to define how the interactions should be handled, which we were already doing in the JS for the component. The change was necessary for JAWS and NVDA to navigate the date picker components intuitively. Before, pressing left or right would read out the next character of the date string instead of moving to the next date. I adjusted the summary description to capture this better! Inclusive languageI flagged Amy C in a separate comment to continue this discussion with less clutter 👍 Navigation after tabbingI noticed the same behavior after using This behavior is also present on the Deque University example I used as a reference for our solution. Since the behavior exists on Touch NavigationThis may be unintended side effects of using Do you notice similar interactions on the Deque University example? We might be able to resolve this by defining swipe behaviors similarly to how we’re defining keypresses Alternatively, maybe we can apply the role based on the device? How do we feel about solutions like that? Do you think that this should be a blocker for the PR? Or should we ticket this out in a new issue and continue there? |
|
@mahoneycm the easiest thing to do is just say "Select year" since everyone is selecting no matter the method. I found this resource helpful https://arthalearning.com/accessible-and-inclusive-language-in-elearning/ |
|
|
@amycole501 @amyleadem "Click to" language has been eradicated! |
There was a problem hiding this comment.
This is looking good on Safari/VoiceOver, @mahoneycm. There is one tiny regression in touch navigation but I think it is safe to move that to a follow-on issue. I’ve added details below.
- No behavioral regressions from
developwhen navigating by keyboard in Safari/VoiceOver- One small improvement in keyboard navigation is the ability to navigate up and down in the calendar with
VO+up/down arrow. Indeveloptheup/down arrowscaused various issues across browsers. (More details in [this comment])(#5374 (review))
- One small improvement in keyboard navigation is the ability to navigate up and down in the calendar with
- No behavioral regressions from
developwhen navigating by touch in iOS Safari/VoiceOver Gestures- One small change with touch navigation readout in Safari/VoiceOver Gestures. Moving from one date to the next, the readout now includes the abbreviations for the day of the week before the date. For example,. “Th - sept 28”, “Fr - sept 29”. This adds a bit of confusion. I’ve opened to address touch navigation concerns: #5503
- No visual regressions
There was a problem hiding this comment.
Nice work! I was able to navigate much better using voiceover keys. Previously, on develop, I could only move left/right on days.
One minor suggestion is to add a preview link to the current component on develop. That way we can open both quickly and compare.
|
Link to Date Picker [DEVELOP] added to description! |
Summary
Improved keyboard navigation for screen readers. JAWS and NVDA no longer prevent default keyboard navigation behaviors when navigating with the
left/rightarrow keys.As a minor improvement, this PR also updates button language to be more inclusive by removing "Click to" language!
Breaking change
This is not a breaking change.
Related issue
Resolves #4616
Related pull requests
Changelog →
Preview LInk
Date Picker →
Date Picker [DEVELOP] →
Problem statement
JAWS and NVDA prevent expected keyboard navigation within date picker calendar modals. In its current state, the up and down arrows navigate left and right, and using the left and right arrows spell out each letter of the selection.
Solution
By updating the wrapper date picker wrapper element to have the role of
application, the expected keyboard behavior is possible while screen readers are opened.Additionally, removing unnecessary roles from table elements allows screen reader users to navigate using table navigation controls defined by the screen reader (generally the screen reader's dedicated button + arrow keys).
Testing and review
Testing Checklist
Further considerations
Alternative solutions
This solution was based on the accessible screen reader offered by Deque University.
An alternative solution I demo'd was removing the table elements and using focusable spans & divs with
role="application"on the wrapper element. This was based on a fix Carbon implemented in their date picker, and it's dynamic markup.While testing with @amycole501, we found that while it did have great callouts and navigation from the screen reader, it did not highlight selected elements, which would be a new accessibility failure.
Draft PR for that change →
Possible downfalls
While the initial opening of the calendar works great for default keyboard navigation, tabbing into the month & year row and back into the calendar will require the user to use table navigation to navigate up and down. I believe this is because it is focusing the buttons within the TD's. This behavior exists in the Deque solution linked above as well.
The Month and Year grids are also only able to be navigated using left and right arrows at this time as well.
(Navigation above was with VoiceOver. Unsure of other screen reader behaviors after tabbing out of calendar grid at this time)
Before opening this PR, make sure you’ve done whichever of these applies to you:
git pull origin [base branch]to pull in the most recent updates from your base and check for merge conflicts. (Often, the base branch isdevelop).npm run prettier:jsnpm testand confirm that all tests pass.