Day of week should be announced to screen readers when navigating the calendar

[JamesCatt]

Is your feature request related to a problem? Please describe.
Currently the days of the week aren't announced by a screen reader when navigating the calendar. The <table> structure is correct, so presumably this is due to the use of grid + gridcell roles. Whatever the cause, the result is that screen reader users don't know what day of the week their currently-focused date is.

Describe the solution you'd like
Simplest solution would be to append or prepend the day of the week to the hidden text in each button, i.e.:

<span class="duet-date__vhidden">Thursday, 2020-09-24</span>

This could be done with Date.toLocaleDateString() to support internationalization.

Describe alternatives you've considered
The only alternative I can think of would be to drop the use of grid and just use a plain table, but this doesn't seem like a good solution—it would mean sighted keyboard users would be forced to TAB through the calendar instead of using arrow keys.

Additional context
Tested with JAWS, NVDA and MacOS Voiceover.

[arielsalminen]

@JamesCatt Thank you for reporting this! I think we’d like to keep the grid role, but we’re also aware that the support for it isn’t all the way there yet for it. That being said, this still needs to be solved somehow and I think your suggestion is pretty good idea.

[aardrian]

The only alternative I can think of would be to drop the use of grid and just use a plain table, but this doesn't seem like a good solution—it would mean sighted keyboard users would be forced to TAB through the calendar instead of using arrow keys.

Note that grid roles on their own have no impact on keyboard-only users -- a developer is responsible for adding arrow key navigation. Further, grid roles are only exposed to screen reader users (not keyboard-only users who are not using a screen reader).

Arrow key navigation can be retained for keyboard-only users no matter the role.

[JamesCatt]

Arrow key navigation can be retained for keyboard-only users no matter the role.

@aardrian Fair point. I guess I was thinking that without grid the arrow key interactions wouldn't be intuitive for a screen reader user—although come to think of it maybe there are screen reader users who aren't familiar with grid interaction anyway.

That being said, if it was removed then the arrow key interaction could catch a screen reader user by surprise, no? I'm guessing without the role then the screen reader would stay in browse mode by default and the arrow keys wouldn't trigger the JS, but if they flipped into focus mode then it could get a little hairy. Admittedly it might be a bit of an edge case though.

[aardrian]

I was thinking that without grid the arrow key interactions wouldn't be intuitive for a screen reader user—although come to think of it maybe there are screen reader users who aren't familiar with grid interaction anyway.

Skilled screen reader users are already familiar with table navigation commands. Without column headers and positioning information arrow keys will confuse unskilled screen reader users (they will not know their place in the table).

That being said, if it was removed then the arrow key interaction could catch a screen reader user by surprise, no?

Take a standard <table> and add role="grid". You will see arrow keys and table navigation work the same as a regular <table>.

Since arrow keys are used by screen reader users to navigate content already (including word or letter at a time), in order to remove that ability and pass the arrow press through to the page you will need to do more than add a grid role.

I'm guessing without the role then the screen reader would stay in browse mode by default and the arrow keys wouldn't trigger the JS, but if they flipped into focus mode then it could get a little hairy. Admittedly it might be a bit of an edge case though.

The screen reader stays in virtual/browse mode with or without the role. The user can change to forms/focus mode by tabbing or putting focus on a form element (and exit it with Esc). What you really want is to trigger application mode so the screen reader does not intercept the arrow presses before they make it to your script (I am greatly over-simplifying).

So, to recap:

• a screen reader user can navigate a <table> with set commands (Ctrl + Alt + arrow keys for JAWS and NVDA, for example);
• a screen reader user can navigate content with arrow keys (up and down move to the previous/next item in the DOM);
• a screen reader user can navigate within content with arrow keys (left and right navigate by letter);
• column headers are announced when the user navigates to a new column (not within a column);
• row headers are announced when the user navigates to a new row (not within a row);
• this is all done in virtual/browse mode;
• if a cell contains interactive content (a button, a link, etc) a screen reader user can still tab to it.

All of the above is true if the user encounters <table role="grid"> unless you script it to pass through arrow presses and/or break the grid or table semantics and neuter standard table navigation commands.

References:

• https://tink.uk/how-screen-readers-navigate-data-tables/
• https://tink.uk/understanding-screen-reader-interaction-modes/
• https://adrianroselli.com/2017/11/hey-its-still-ok-to-use-tables.html
• https://sarahmhigley.com/writing/grids-part1/

[aardrian]

The items I list above are also why I asked #26 to not be closed. Column headers are a better way of exposing this information to screen reader users -- barring testing with users telling you otherwise.

[WickyNilliams]

Thanks for all the useful info and links @aardrian. I'll be sure to read through them all.

I am definitely in the unskilled screen reader user category you noted. It's hard for me at times to discern what is expected behaviour and what is surprising behaviour for screen readers, as I don't have the experience of using them day in, day out. There are likely subtleties and conventions that pass me by.

I agree, #25 seems like a preferable solution. But let's not have two open issues discussing the same problem, albeit with different proposed solutions. I will edit the title of this issue to describe the problem, rather than the solution.

Aside: is there any value in using <time> element within the calendar as an additional semantic enhancement?

[aardrian]

Aside: is there any value in using <time> element within the calendar as an additional semantic enhancement

No.

<time> is primarily for exposing machine-readable dates. A screen reader exposing it is pointless if the browser does not take the datetime attribute value, localize it to the page or user preferences, and then hand it off through the accessibility APIs to the screen reader. You can see in the Accessibility API Mappings for <time> that on its own its text node is treated as text.

For example, if I use the built-in inspector in JAWS (Shift + JAWS key + F1) and look at the <time> node in one of my blog posts (which only announces the text string), I get the following:

Tag TIME has 5 parameters:
datetime=2020-02-07T08\:35\:46-05\:00
display=inline
role=time
tag=time
xml-roles=time
MSAA Role=429

The browser hands over no human-readable data other than the text node.

That being said, if it does not add bloat to the page (compared to a JS library, it will not) it may be worth adding it if there is some machine slurping that data that is unknown to me.

[aardrian]

Can this issue be changed from "enhancement" to "bug"? The referenced closed issue was definitely a bug.

[WickyNilliams]

Sure, I just updated the labels.

Ah ok. My thinking was a screen reader is a machine reading the page, so I was curious if it would trigger the dates to be read out in a more convenient format or anything like that. But if not, seems like a needless change!

[aardrian]

A screen reader announces the content that the user agent provides. A browser (user agent) is a machine, but one that act on behalf of the person to parse code into human-readable content.

By machine-readable, I mean something that slurps things RDF data, such as a search engine, to use for structuring, sorting, filtering data that may or may not eventually be re-purposed and presented to users in raw or aggregate form.

[WickyNilliams]

Fixed in #51, released in v1.2.0