data grids appear to be pretty choppy with JAWS and NVDA

[DavidMacDonald]

https://w3c.github.io/aria-practices/examples/grid/dataGrids.html

It seems like all 3 examples have troubles with both screen readers. It seems to be beyond a simple little bug in a screen reader.

The user presses the tab key and moves into the table. The non-actionable items get keyboard tab focus using the arrow keys, but once the user hits a real interactive element like the links in the description column, the screen reader goes into forms mode and the arrow keys change to character to character. Pressing the ESC key to exit forms mode messes up the arrow navigation for the non actionable focused items and the intended functionality of the arrows doesn't appear to work.

I wonder if it would not be better to just leave off the arrow navigation JS from the table, and let users navigate the table normally CNTL+ALT+arrows.

I would like to hear from some native screen reader users about their experiences with these examples, to see if these examples are as hard to work with as it appears to me.

[JAWS-test]

What do you mean by "both screenreaders" - there are more than two. I can confirm the problem for NVDA. This is clearly a bug of NVDA and should be fixed. The problem does not occur with JAWS. The cause of the problem seems to be that for buttons and links not the cell (role=gridcell) gets the focus, but the button or link. However, this is intended so that the operation is possible efficiently. However, NVDA now thinks that it is no longer in a grid, but on a button or link and changes the mode. This is a bug, but it is also due to the fact that the corresponding behavior is not regulated in the ARIA specification and is only described in the WAI-ARIA Authoring Practices.

In grids, there should be no mode switching unless you explicitly (with F2, Enter) switch modes.

Screen readers should automatically switch to form mode in grids to enable arrow key navigation. In addition, it should always be possible to navigate with Ctrl+Alt+Arrow keys (table navigation), as long as the screen reader is in reading mode.

[sinabahram]

I've never met a non-trivial grid that has worked correctly with a screen reader, even those coded by experts. Not saying it isn't possible, but I've simply never encountered one. All three of the linked examples don't even have a mechanism for jaws to enter a non-browse mode without me forcing it by turning off the virtual cursor and then proceeding to use the arrow keys. That's with jaws 2021, latest update, and Chrome, latest stable e.g. 91.x.

Can't wait for ARIA-AT to have some more publish-ready results so that this can be demonstrated objectively across a series of assertions.

[sinabahram]

@JAWS-test , both screen readers being mentioned are in the title of the issue, namely Jaws and NVDA.

[JAWS-test]

@sinabahram

All three of the linked examples don't even have a mechanism for jaws to enter a non-browse mode without me forcing it by turning off the virtual cursor and then proceeding to use the arrow keys.

I don't understand that:

• When I read the page with the virtual cursor (for example, using the arrow keys), JAWS never automatically switches to forms mode (for any interactive element). I can, however, switch to forms mode at any time by pressing Enter. This works for all interactive elements that need to be operated in forms mode, including grids.
• When I tab, JAWS automatically switches to forms mode as soon as an interactive element needs to be operated in it. This affects grids as well as many other elements.

So far everything works correctly with JAWS in all three examples. And also with NVDA - except for the bug when links and buttons within Gridcell get the focus.

[sinabahram]

@JAWS-test yup, and enter doesn't work.

[JAWS-test]

@sinabahram

Enter works by default. I have now examined this more closely: Enter only does not work if the virtual cursor is on an element that is not reached in forms mode, such as the column headings in the first table. Mostly all cells get the focus. If not, indeed the problem occurs. The question now would be:

• Is this a bug of JAWS (where should JAWS put the focus after Enter?).
• Or is this a bug of the first example because it contains non-focusable cells?

[JAWS-test]

To return to the initial question:

• I think grids have their justification - and in those rare cases where I can either edit content inline (like in an Excel spreadsheet) or where arrow key navigation is necessary (to avoid unnecessary tab navigation steps, for example). It is possible to implement grids correctly. However, there are some bugs in screen readers, so grids should never be used without first testing them. In addition, the ARIA specification for grids contains some inconsistencies that I think should be fixed
• In practice, almost every table is marked as a grid, which is usually done incorrectly and is completely unnecessary. Thus, in WCAG audits, I usually recommend removing the grid roles. The developers then like to refer to the WAI-ARIA Authoring Practices, which propagate an extensive use of grids. I think this is wrong and therefore support https://github.com/w3c/aria-practices/issues/1233.

[shirsha]

Tested today and still NVDA, JAWS. VO on chrome. Visually, these pills looks like a list of elements, but programmatically they are exposed as a table with rows as number of pills. Each pill is narrated as two columns, One is pill name and another is to remove button for the pill. Visually it looks like a list of links and would expect to tab through them. Unless I read through the instructions, I'm not aware of how to navigate through the pills.

I recommend using <ul> <li> for this kind of examples.