Column Headers Not Announced

[aardrian]

Describe the bug
When navigating the calendar grid (<table>) in JAWS, the column headers are not announced. All I hear is "two zero two zero dash zero four dash zero two" (or whatever is the date in this number format).

To Reproduce
Steps to reproduce the behavior:

1. Go to the grid,
2. Navigate between days within a week,
3. Observe the screen reader does not announce the day of the week.

Expected behavior
As I navigate from column to column, I should hear the column header. Specifically I should hear the day of week as I move through a week.

Screenshots
I made a video, but GitHub does not allow me to embed it.

Desktop (please complete the following information):

• OS: Windows 10
• Browser Chrome
• Version 85
• JAWS 2020

Additional context
Using first example at https://duetds.github.io/date-picker/

[arielsalminen]

Thanks for reporting this @aardrian! As it is a duplicate of #25, I’ll close it and let’s continue the discussion there.

[aardrian]

These are not the same issue.

#25 specifically asks for the day of the week to be added to every cell, which is too verbose for screen reader users and should only be considered as a last resort.

This issue is about getting the column headers to announce as they would for a regular table. If you do so, a column header will only be announced when a user changes columns, not rows, reducing the verbosity. Further, a screen reader user can choose to configure how the table column headers are announced overall, something they cannot do when the text is made part of every cell.

Because the outcome of correct column headers is functionally (and programmatically) not the same as that proposed in #25, I believe it is premature to close this.

[WickyNilliams]

Hey @aardrian I've finally started investigating this. I've been testing out some tweaks, which seem to greatly improve the experience.

In step 2, where you say "Navigate between days within a week", are you referring to navigation using the JAWS table navigation shortcuts (these actually seem broken for me in our current implementation), or the arrow key functionality we've programmed in?

Out of curiosity, is it more likely (in general) that a screen reader user would be using the table shortcuts over our built-in shortcuts to navigate through the calendar?

[aardrian]

I think you should consider re-opening this issue, especially if you are going to ask questions on it.

In step 2, where you say "Navigate between days within a week", are you referring to navigation using the JAWS table navigation shortcuts (these actually seem broken for me in our current implementation), or the arrow key functionality we've programmed in?

The JAWS, NVDA, VoiceOver table navigation commands do not work unless the user forces the screen reader back into browse mode (ref: https://tink.uk/understanding-screen-reader-interaction-modes/). So I did not test column header announcements that way. However, when I force JAWS back into browse mode I hear the column headers, though the table itself is truncated to only show me dates that are disabled.

When I navigate with arrow keys and move into a new column, I should hear the column header. I do not. By default, both a grid (the ARIA role) and a <table> expose row and column headers in the accessibility tree so a screen reader will announce them as the user changes a row or column.

When I arrow to today in the grid I hear: "two zero two zero dash one one dash one two Button, to activate press Enter." It does not announce the column header (or a very useful date).

Out of curiosity, is it more likely (in general) that a screen reader user would be using the table shortcuts over our built-in shortcuts to navigate through the calendar?

In my experience testing with skilled screen reader users, when they hear a grid or table, they start using the table navigation commands (not shortcuts) built into their screen reader. More skilled screen reader users will hear the dink that indicates they have been switched to forms or application mode, and when encountering this grid may force themselves back to browse mode (with a donk).

Assuming you are using JAWS, when you tab from the arrow buttons into the grid, you should hear dink. Move backward (Shift + Tab) to the arrow button and you should hear donk. Then press T and JAWS will announce the underlying table as a grid: "grid with 7 columns and 1 rows" (I am suggesting this approach to change modes to ensure you stay in the context of one control at a time.)

That "1 rows" announcement is a clue something is wrong. For November 2020 there should be 7 rows (6 rows of dates, 1 row of column headers).

Start navigating with JAWS table commands (Ctrl + Alt + arrow keys, ref: https://tink.uk/how-screen-readers-navigate-data-tables/) and you should hear pretty quickly something is wrong. If you remove the grid role from the <table> things suddenly work (for table navigation).

[WickyNilliams]

Excuse the delay, I haven't been working since Thursday. Sure, i'll reopen it now.

Those links were very useful, thanks.

What you described above mirrors the results from my testing last week. I think an errant role="gridcell" was throwing everything off… Removing this fixes the issues with table truncation. And it also appears to fix the issue at hand. Headers get read out both when using table navigation commands or using our own arrow key shortcuts.

I need to do some more testing across screen reader/browser combinations before making a pull request. I will report back with my findings.

By chance, I came across your article on role="grid", where you ultimately advise against grid unless building a spreadsheet-type application - would you say that advice also fits here? Should I drop it from the table?

[WickyNilliams]

Here are the results of my testing, having first removed the erroneous role="gridcell":

Using <table role="grid">

Browser	Announces weekday with table commands	Announces weekday with arrow shortcuts	Announces year/month change
VO/Safari	No	No	Yes
VO/Chrome	Yes	No	Yes
NVDA/Chrome	Yes	Yes but verbose - announces twice like: "2020-10-23 row 5 FRIDAY column 5 2020-10-23 button row 5" even within same column	Yes, but sometimes announces twice
NVDA/FF	Yes	Yes but verbose - announces twice like: "2020-10-23 row 5 FRIDAY column 5 2020-10-23 button row 5" even within same column	Yes, but sometimes announces twice
NVDA/Edge	Yes	Yes but verbose - announces twice like: "2020-10-23 row 5 FRIDAY column 5 2020-10-23 button row 5" even within same column	Yes
JAWS/Chrome	Yes	Yes	Yes
JAWS/Edge	Yes	Not sure how to get it to work?	No
JAWS/IE	Yes	No, and constantly announces "Not in a table"	Sort of - virtual cursor off - announces virtual cursor on - announces nothing

Using a plain ol' <table>

Browser	Announces weekday with table commands	Announces weekday with arrow shortcuts	Announces year/month change
VO/Safari	Yes	No	Yes
VO/Chrome	Yes	No	Yes
NVDA/Chrome	Yes	Yes but verbose - announces twice like: "2020-10-23 row 5 FRIDAY column 5 2020-10-23 button row 5" even within same column	Yes, but sometimes announces twice
NVDA/FF	Yes	Yes but verbose: "row 5 FRIDAY column 5 26 November button" even within same column	Yes, but sometimes announces twice
NVDA/Edge	Yes	Yes but verbose: "14 November data item row 4 Thursday column 4 14 November button" even within same column	Yes
JAWS/Chrome	Yes	Yes	Yes
JAWS/Edge	Yes	Not sure how to get it to work?	No
JAWS/IE	Yes	No	Sort of - virtual cursor off - announces virtual cursor on - announces nothing

You can see that the only significant change is that VO announces column headers when using table commands. So perhaps it is best to just use a table, as advised in your article?

Edit: I've just realised aria-selected doesn't work with a plain table, so perhaps that options is ruled out, despite the improvements in safari

[aardrian]

where you ultimately advise against grid unless building a spreadsheet-type application - would you say that advice also fits here?

I don't believe you need a grid role here. If all you are adding is arrow key navigation it does not help screen reader users any more than not having it. Keyboard-only users can benefit by making the grid a single tab-stop, but allowing them to press Enter / Space on a date already makes it less awful, and putting them month / year navigation above it is also good.

You can see that the only significant change is that VO announces column headers when using table commands. So perhaps it is best to just use a table, as advised in your article?

That would be enough reason for me. While macOS users may be a smaller set of users, VoiceOver / macOS users still rely overwhelmingly on Safari.

I appreciate that you did all that testing across screen readers and browsers. Since that is much of my "day job" I know how tedious it can be.

Edit: I've just realised aria-selected doesn't work with a plain table, so perhaps that options is ruled out, despite the improvements in safari

Since the control the user is activating is a <button>, the attribute you want is aria-pressed.

[WickyNilliams]

OK, in that case I'll drop the grid role.

I appreciate that you did all that testing across screen readers and browsers. Since that is much of my "day job" I know how tedious it can be.

For sure. I've been testing various combinations of approaches for days now, and it is such an arduous process. Utmost respect if you do this day in and day out. On the plus side, I've learnt lots about screen readers etc. Now I feel competent using them, whereas before I was just fumbling my way through.

Since the control the user is activating is a <button>, the attribute you want is aria-pressed.

Aha, that'll do it! Just tested this approach. Combined with dropping the grid role, we get selected/unselected announced in all the browser/screenreader combinations, and also column announcements in Safari/VO.

I'm also working on improving the date text:

	Before	After
Button in calendar view	2020-11-17	17 November
Open/close calendar button	2020-11-17	17 November 2020

Some screenreaders correctly recognise these are dates, adding ordinals and reading them like "November 17th, 2020" - which is a nice bonus.

[aardrian]

Now I feel competent using them, whereas before I was just fumbling my way through.

FWIW, I have been testing in screen readers for almost 20 years, and daily for the last 5 (including training some users). I still don't consider myself competent in them.

The better date announcement you are experiencing is screen reader heuristics kicking in. Usually they do a great job, but sometimes they announce things in ways you do not expect.

It sounds like you have come up with a fix. When you have something to test I am happy to check it out (time depending now that US holidays are bearing down).

[WickyNilliams]

Haha maybe competent is overstating it. I at least know how to operate them at the most basic level now. Learning about the different modes as you mentioned further up the thread was very enlightening.

Usually they do a great job, but sometimes they announce things in ways you do not expect.

Yeah, I saw some weird results while testing the current version. It at least seems consistent since making the changes above. At worst, it reads the text verbatim "seventeen November twenty twenty", which is clear enough.

When you have something to test I am happy to check it out

That would be very much appreciated. I'll hopefully be able to get an alpha version published tomorrow. I'll post a link here to a page that's all setup with the new version ready to test

[WickyNilliams]

Here is a codepen link using a beta version of the package, which includes all changes discussed here. I will appreciate any feedback! https://codepen.io/WickyNilliams/full/6b174affe088cd75f3f727a09a0e8d0a

[aardrian]

Not ignoring you; deadlines.

[WickyNilliams]

No worries mate. Whenever you have time 👍

[WickyNilliams]

Hey @aardrian sorry to hassle, but thought I'd ping you in case this fell off your radar.

If you can't dedicate the time at the moment (no sweat - totally understandable), I am considering merging this since IMO it is objectively better on every axis. I can make any tweaks you might suggest as a follow up PR

[aardrian]

You are correct! It fell off my radar. Let me take a run at it tomorrow.

[WickyNilliams]

Closing, as this should now be fixed with v1.2.0. Thanks for all your help and advice @aardrian!