Streamline the touch screen reader experience for Calendar #3032
Conversation
|
Build successful! 🎉 |
|
Build successful! 🎉 |
There was a problem hiding this comment.
In my opinion, PageUp and PageDown should always increment or decrement by month regardless of the visible range, this way a screen reader user can quickly navigate to the previous or next month using the same command. advancing by two or three months is really confusing when using a screen reader.
| disabled={nextButtonProps.isDisabled} | ||
| onClick={() => state.focusNextPage()} | ||
| tabIndex={-1} /> | ||
| </VisuallyHidden> |
There was a problem hiding this comment.
I wonder if it might make more sense if the VisuallyHidden Next button were after the Calendar grid and the visible next button were to remain before the grid.
There was a problem hiding this comment.
Personally I found it to make sense that if you're on the date grid, you can shift tab to get to the previous button and tab to get to the next button. If we put them both before, then you have to tab through both to get to the dates, and shift tab to get to both buttons from the dates. What made you think putting the next button first would make more sense?
There was a problem hiding this comment.
The previous and next month buttons in native input[type=date] control are both before the table. Same is true for https://www.w3.org/TR/wai-aria-practices/examples/dialog-modal/datepicker-dialog.html. Feels more intuitive tabbing left to right, top to bottom.
I guess I did it so that page up/page down matched what the next/previous buttons do, but I suppose we could make them different. Is that what you were thinking? |
Yes. I'm fine with the next and previous buttons navigating by two or three months at a time, because the user is not immediately interacting with the grid, but for a keyboard or screen reader user interacting on a date within the table the behavior should remain consistent; PageUp or PageDown should navigate by month and Shift+PageUp or Shift+PageDown by year. Particularly with the date range picker, if I start selecting with focus within the first of three calendars in the visible range, and want to select a month, it would be really odd for three months to become selected, and to no longer be able to see the start of the selection or the two other months that were selected. |
devongovett
force-pushed
the
calendar-touch-screenreader
branch
from
3318a79 to
86c4609
Compare
|
Build successful! 🎉 |
|
I'll do the keyboard navigation change in a separate PR since it's not really related to the changes here. |
|
Build successful! 🎉 |
devongovett
force-pushed
the
calendar-touch-screenreader
branch
from
9133249 to
8a9a88f
Compare
devongovett
changed the title
|
Build successful! 🎉 |
devongovett
force-pushed
the
calendar-touch-screenreader
branch
from
5858248 to
8a9a88f
Compare
|
Build successful! 🎉 |
Depends on #3005.
This attempts to improve the experience of using a Calendar with a touch screen reader.
aria-hidden, and instead, the entire visible range is described in a visually hidden heading before the calendar grids (i.e. "March to May 2022"). This avoids extra swipes to get to the next day when navigating with a touch screen reader, and better conveys that there are multiple months visible before you navigate through them.aria-hiddenin the Calendar grid. This avoids touch screen reader users needing to swipe through all day names before getting to the actual days they can select. It also avoids day names being announced twice when focusing a date, because first the column header is announced and then the cell label which also includes the day name. This is potentially a little non-kosher, but I think it makes things easier to use and the column headers are kinda unnecessary for screen reader users.aria-labelof therole="group"element rather thanaria-describedbybecause VoiceOver on desktop does not announce thearia-describedbywhen tabbing into it.