Several Screen Reader Issues with Data Grid Examples

[frastlin]

Hello, I have been reading through and experimenting with the grid examples at: https://www.w3.org/TR/wai-aria-practices/examples/grid/dataGrids.html# and reading through the documentation at: https://www.w3.org/TR/wai-aria-practices/#grid

I have found several bugs and a couple areas that could have a little more documentation. To make things a little more clear, I have an example of a grid using pure aria at: https://frastlin.github.io/Toolo/

I tested on Firefox using NVDA.

1. There should be some description of the differences between aria and html tables in the grid section. There are quite a few different behaviors in HTML and aria grids. It would be optimal if they were presented next to one another in the examples, so one could find the functionality they desire without lots of trial and error from a hard-to-find screen reader user:

*   Role=”grid” has aria-readonly="false" as default and <table> has aria-readonly="true" as default.
*   When arrowing through the examples with NVDA on Firefox, the <td> elements, when focused, do not read their content, but cells that have a child switch focus to the child and the child’s content is read. This means that most cells are blank when arrowing through the grid with NVDA on Firefox. Role ="gridcell" does read the cell’s contents though. The problem with role=”gridcell” is that the content of children is read twice.
*   Role=”gridcell” has aria-selected=”true” and <td> has no kind of selection.

2. Crazy and completely unexpected behavior happens when HTML and roles are mixed together in a table. For example, if one adds a <td element to the aria only table, then NVDA will read “cell” as it moves through cells. If one adds a div with role=”gridcell” to an HTML table, then those cells are read like a gridcell reads in the pure aria example, but there is no selection. The above examples all have role=”grid” on the table which is the only aria used and it is not necessary and promotes mixing roles and HTML.

3. There is little explanation of how navigation using tabindex and focus is achieved. All I can say is that it works when both are there, and doesn’t work if one is taken away. Also, there is no explanation that focus moves to the child of the cell if there is a child. There should be at leaste a link to:

https://www.w3.org/TR/wai-aria-practices/#kbd_roving_tabindex so the roving tabindex can be presented to someone who has never heard of it before.

4. In a grid it is often desired to have A-1 notation when moving through rows and columns. How does one properly achieve this? This would be suppressing the cell and row announcements and speaking the A-1 notation. What is the best way to speak A-1 notation? Same goes for formatting on cells (such as frozen cells, data validation in cells, formulas in cells…) Is an extra element at the bottom of the cell with role=”status” that has its innerHTML changed the best approach?

5. The advanced grid at:

https://github.com/w3c/aria-practices/issues/155 needs to be developed and then some of these issues may be given a precedent.

I think the above are probably a mixture of aria, NVDA, and programming bugs, but regardless, most people reading the documentation are not going to realize that 3 lines of code change the whole experience for a screen reader user, even though they are correct implementations of Grid. Especially when it comes to mixing aria and HTML. For some reason, many web developers stay as far away from native HTML widgets as they possibly can, which leads to some rather extreme cases of wrong aria implementations and lots of HTML and aria mixing. This is another reason why both aria and html should be presented, as most people will probably be looking for aria and not HTML examples.

I have been searching for the last year for a proper opensource grid implementation that I can use, rather than creating my own, but there isn’t one out there. This is really unfortunate as any project that uses any of the existing opensource applications is not going to be accessible to a screen reader user. I wish Google would make their grid implementation open as GSheets is a perfect example of an accessible spreadsheet. Thank you,

[mcking65]

@frastlin commented:

To make things a little more clear, I have an example of a grid using pure aria at: https://frastlin.github.io/Toolo/ I tested on Firefox using NVDA.

That has the structure of a grid, but is not a grid because it does not implement focus management. So, using role grid on that page is not valid. An ARIA grid is required to manage focus.

We have added a Read Me First section that explains the "promise of a widget role" as well as several other things that are very important to understand before using any of the examples. We plan to add a link to the read me first from every example page before our first release.

1. There should be some description of the differences between aria and html tables in the grid section.

To cover tables made with the ARIA role="table", we now have a table design pattern with an example. Note that the CSS for the example is not yet complete.

There should not be any differences between an HTML table and an ARIA table. So, if you find some, they are either browser or assistive technology bugs.

There are quite a few different behaviors in HTML and aria grids. It would be optimal if they were presented next to one another in the examples, so one could find the functionality they desire without lots of trial and error from a hard-to-find screen reader user:

HTML does not have a grid. However, if you mean differences between HTML tables and ARIA grids, yes there are many. Most important to understand is that a table is not a widget. It is a static structure as described in the pattern. Whereas, a grid is an interactive widget that manages focus inside of it.

There is a list of the most important differences at the beginning of both the grid and table design patterns.

• Role=”grid” has aria-readonly="false" as default and <table> has aria-readonly="true" as default.

Grid does not have a default for aria-readonly. A grid cannot be editable, so it cannot be read-only. The only reason to put aria-readonly on a grid is as a coding convenience for grids that have lots of editable cells. As a convenience to the author, browsers will propagate the value of aria-readonly from a grid to its descendants. This option should be used sparingly and with great care. We will demonstrate it when we complete issue #155.

Similarly, a table does not have a default value for aria-readonly because tables cannot be editable.

There has been some misunderstanding with respect to aria-readonly on grids due to some confusing and inaccurate language in the ARIA 1.0 spec. We cleaned that up in ARIA 1.1. However, NVDA still behaves in the ARIA 1.0 manner.

The most important takeaway is that grid is not an editable widget. And, screen readers, or other assistive tech, should not state that a grid is editable or read only. It might contain a mix of editable and read-only content, but that is typically only the case in spreadsheet-like grids. And, that distinction is made via context, not by adding a value of aria-readonly to the grid.

• When arrowing through the examples with NVDA on Firefox, the elements, when focused, do not read their content, but cells that have a child switch focus to the child and the child’s content is read. This means that most cells are blank when arrowing through the grid with NVDA on Firefox. Role ="gridcell" does read the cell’s contents though. The problem with role=”gridcell” is that the content of children is read twice.

These are NVDA bugs.

• Role=”gridcell” has aria-selected=”true” and has no kind of selection.

Correct; a table cannot be interactive, which means it cannot have rows or cells that are selectable. Of course, for years, people have worked around that in a wide variety of ways, e.g., a checkbox in the first column that indicates selection of the row.

2. Crazy and completely unexpected behavior happens when HTML and roles are mixed together in a table. For example, if one adds a <td element to the aria only table, then NVDA will read “cell” as it moves through cells.

That is invalid HTML. You can only use a td inside of a tr. You cannot use it inside of a <div role="row">. Similarly, you can only use tr inside of a table, tbody, or thead. You cannot use tr inside of <div role="table"> or <div role="grid">.

If one adds a div with role=”gridcell” to an HTML table, then those cells are read like a gridcell reads in the pure aria example, but there is no selection.

Again, this is invalid HTML, and you should not expect it to work.

The above examples all have role=”grid” on the table which is the only aria used and it is not necessary and promotes mixing roles and HTML.

Using role="grid" on a <table> element is valid. The descendant elements, such as td will have the correct implied role, e.g., gridcell. This is explained in the roles, states, and properties subsection grid design pattern.

3. There is little explanation of how navigation using tabindex and focus is achieved. All I can say is that it works when both are there, and doesn’t work if one is taken away. Also, there is no explanation that focus moves to the child of the cell if there is a child. There should be at leaste a link to: https://www.w3.org/TR/wai-aria-practices/#kbd_roving_tabindex so the roving tabindex can be presented to someone who has never heard of it before.

It is already there. On the data grid example page, under the heading "Role, Property, State, and Tabindex Attributes", there is a table. This is explained in the first row of that table and includes a link to the roving tabindex section of the guide.

4. In a grid it is often desired to have A-1 notation when moving through rows and columns. How does one properly achieve this? This would be suppressing the cell and row announcements and speaking the A-1 notation. What is the best way to speak A-1 notation?

Today, you could have rowheader and colheader cells that include A1 labeling. And, you could include a way to hide the top row and left column that contains them so the user can have control over that verbosity. However, there is no automatic way of suppressing screen reader announcement of coordinates. The user would have to do that manually.

We currently have w3c/aria#667 open for this.

Same goes for formatting on cells (such as frozen cells, data validation in cells, formulas in cells…) Is an extra element at the bottom of the cell with role=”status” that has its innerHTML changed the best approach?

Some aspects of this can be handled by screen readers. However, having the option to display formatting for the currently focused cell in a status area outside the grid could be really helpful, especially if the user can control whether it is present and if it is referenced with aria-describedby on the cell when it is visible.

5. The advanced grid at: #155 needs to be developed and then some of these issues may be given a precedent.

For sure.

I think the above are probably a mixture of aria, NVDA, and programming bugs

So far, we have not found any ARIA or programming bugs in the data grid examples. None of what you describe hints at a bug.

However, there are definitely some Firefox and NVDA bugs.

3 lines of code change the whole experience for a screen reader user, even though they are correct implementations of Grid.

Not sure which 3 lines you are talking about. But, it is definitely the case that the screen readers all need better grid support.

For some reason, many web developers stay as far away from native HTML widgets as they possibly can, which leads to some rather extreme cases of wrong aria implementations and lots of HTML and aria mixing.

That is why we are providing these cannonical examples that demonstrate correct implementation of ARIA.

This is another reason why both aria and html should be presented, as most people will probably be looking for aria and not HTML examples.

So far, all the examples are based on HTML; mixing is necessary. We emphasize the use of semantic HTML as much as possible and try to use only the amount of ARIA required to demonstrate the ARIA feature we are explaining.

BTW, the layout grid examples are made with div and span elements instead of HTML table elements.

I have been searching for the last year for a proper opensource grid implementation that I can use, rather than creating my own, but there isn’t one out there. This is really unfortunate as any project that uses any of the existing opensource applications is not going to be accessible to a screen reader user. I wish Google would make their grid implementation open as GSheets is a perfect example of an accessible spreadsheet.

This one is proper and open source, but not intended to support all browsers. The Read Me First section I mentioned above covers browser and assistive technology interoperability objectives.

I hope this answers your questions and addresses your concerns. If not, feel free to re-open the issue.