Remove layout grid examples

[aardrian]

The Layout Grid patterns are an unintended anti-pattern that implies a visual layout paradigm, partly as a result of decades of <table> layout mis-use and partly due to confusion with CSS grid layout.

Background

I understand grid as defined in ARIA 1.1 allows for more than Excel-style controls. Fundamentally it generates a widget with rows and cells (the columns are implied):

The grid role does not imply a specific visual, e.g., tabular, presentation. It describes relationships among elements.

Responsiveness

While the relationship between cells does not change as the layout does, effective arrow key navigation for sighted users relies on visual cues that may change in responsive layouts.

An author can choose to not make a layout responsive, which introduces its own usability challenges as scrollbars are necessarily introduced, warranting an additional keyboard-focusable container (with a role and an accessible name) in most current browsers.

Distinguishing Feature

The example pattern in APG includes the following:

The distinguishing feature (emphasis added) of grid that enables it to be used for grouping other widgets is that its cells are containers that preserve the semantics of their descendant elements. That is, grid cells do not override or suppress the semantics of the elements they contain. Thus, a link contained inside of a grid cell is presented to a screen reader as a link. By contrast, a link inside of a menu is presented as a menuitem, and a link inside of a listbox is presented as an option.

This is not a distinguishing feature. This is true of other native HTML containers. While excluding HTML is implied for some of the audience, not all will understand that implication.

Comparing to complex widgets is a false equivalency since these widgets have clear purposes beyond, say, containing a link.

If we restrict ourselves to roles, then region also has the distinguishing characteristic.

In Example 1: Simple List of Links, the grouping provided by grid offers no special semantic relationship beyond any other kind of grouping. The links, for example, could just as easily be contained within <li>s, which also offers count and position in a single axis.

Challenges in Example Pattern

The hints provided also fail to take into account zoom users, who may not see the arrow key graphic in the bottom left and who may not be able to see the entire set of instructions.

For many screen reader users to benefit from the arrow key navigation today, the container must be wrapped in an application role to prevent the screen reader from intercepting the arrow keys. However, this prevents screen reader users from arrowing through content letter by letter or word by word, having an outsized impact on novice screen reader users.

The first example can just as easily be a list of links with a CSS grid layout that is enhanced with arrow key navigation, without blocking standard screen reader navigation.

This feedback is generally true of the other two examples.

Documentation

While I appreciate that APG aims to create idealized patterns from the ARIA roles, this is a case where it fails to disambiguate with CSS grid, fails to reference the First Rule of ARIA (see #1228 for a more general warning), and fails to make a case for why this pattern is better for users.

APG as de facto Pattern Library

As APG is often referenced as a pattern library by enterprises and agencies, its lack of qualifying language and warnings means authors too easily copy and paste code while assuming it is tested across UA/AT combos. Complicating this is the perception that APG is a spec, when it is a Note.

This particular pattern came to my attention when I was presented with a card pattern enhanced with ARIA grid roles that made for a wholly inaccessible and unusable experience. The argument was that it followed this W3C pattern and therefore must be correct.

When clients point to these patterns that cannot work in real-world scenarios, I am placed in the unenviable position of having to recommend against relying on APG.

Request

I urge you to consider removing this pattern.

[JAWS-test]

I can only support that. I was very scared when one day the layout grid examples were published on the APG site. They contradicted everything I had previously explained to my customers about the grid: grids are interactive tables with the possibility of inline editing. In the meantime, there is one more reason to remove the layout grid examples: the new ARIA role table. This should also not be used for layout tables, but for tables that cannot be edited inline. This applies, for example, to Example 1 of the Data Grids: Minimal Data Grid. In my opinion, this example should also be removed or implemented with role=table.

However, this cannot simply be changed in APG, because the examples published here only represent the correct use of the role grid according to the ARIA specification. I.e. the problem is the ARIA specification, which since version 1.1 defines grid differently than before. I'm afraid it won't be possible to change that any more...

ARIA 1.1 says:

A composite widget containing a collection of one or more rows with one or more cells where some or all cells in the grid are focusable by using methods of two-dimensional navigation

• This means that even a single cell can be a grid (a column, a row).
• This means that some cells can get the focus and others can't. Thus the navigation for keyboard users may be completely arbitrary.

An unspecified value for aria-readonly does not imply that a grid or a gridcell contains editable content. [...] , it is not necessary for the author to specify a value for aria-readonly.

This means that a AT user has no chance to recognize whether the cell contents can be edited or not.

The grid role does not imply a specific visual, e.g., tabular, presentation. It describes relationships among elements

I.e. a grid can be anything. For example, according to the specification, a class diagramm could be a grid. Grid navigation for keyboard users is therefore unclear. And AT users can't recognize the visual representation.

If aria-readonly is set on an element with role grid, user agents MUST propagate the value to all gridcell elements owned by the grid and expose the value in the accessibility API. An author MAY override the propagated value of aria-readonly for an individual gridcell element.

This means that when an AT user reaches the grid, she or he cannot recognize whether it contains editable cells. She or he must navigate to all cells in order to recognize whether content can be changed.

Authors MAY indicate that a focusable gridcell is selectable as the object of an action with the aria-selected attribute.

This means that an AT user cannot recognize whether only information is contained in the grid or whether she or he can select values. Furthermore, she or he cannot recognize whether, for example, only a cell or an entire column was selected.

[mcking65]

Thank you for this feedback. It raises some important points that deserve careful treatment.

Given the extent of these comments, in addition to async discussion in this issue, it might be helpful if you were willing to join a discussion of the topic. It would not likely be until January or February, after we have APG 1.2 release 1 ready to ship.

[aardrian]

@mcking65, count me in.

[aardrian]

@mcking65

Given the extent of these comments, in addition to async discussion in this issue, it might be helpful if you were willing to join a discussion of the topic. It would not likely be until January or February, after we have APG 1.2 release 1 ready to ship.

I understand there has been a bit of a pandemic throwing every timeline ever into chaos.

Given that fact, and the January / February timeline having whizzed by, what sort of timeline are you thinking now?

[aardrian]

@mcking65

Given pandemic fun, the January / February timeline having whizzed by, and layout grids now an open issue on the ARIA spec (https://github.com/w3c/aria/issues/1324), what sort of timeline are you thinking now?

[mcking65]

@aardrian

We certainly thought ARIA 1.2 and APG 1.2 would be done by now. At this point, we are mostly tying up loose ends. So, it is time to start considering 1.3 work.

We could add this to the agenda on October 13 or October 27 if either of those would be good for you. Our meetings are at 11:00 Pacific time.

In preparation for that discussion, I'll ask some more questions in this issue with the goal of identifying the specific concerns that are most difficult to address asynchronously.

[mcking65]

First questions ...

@aardrian wrote:

The distinguishing feature (emphasis added) of grid that enables it to be used for grouping other widgets is that its cells are containers that preserve the semantics of their descendant elements. That is, grid cells do not override or suppress the semantics of the elements they contain. Thus, a link contained inside of a grid cell is presented to a screen reader as a link. By contrast, a link inside of a menu is presented as a menuitem, and a link inside of a listbox is presented as an option.

This is not a distinguishing feature. This is true of other native HTML containers. While excluding HTML is implied for some of the audience, not all will understand that implication.

I don't understand this point. It seems like some aspect of the APG language must not be sufficiently clear.

The APG language is saying that grid can be used to group other widgets, such as links, together into a single interactive container, i.e., a single Tab stop, because gridcell is different from other widgets. Which HTML elements do you have in mind that could work as focusable, interactive grouping elements?

@aardrian wrote:

Comparing to complex widgets is a false equivalency since these widgets have clear purposes beyond, say, containing a link.

Your point that complex widgets like listbox and menu have purposes beyond containing a link is valid. Yet, the point of the APG language is that a listbox actually cannot contain a link, it can only contain an option that may work like a link, i.e., an HTML link recast as an option when contained by a listbox. Once recast, there is a huge disadvantage compared to a link in a gridcell -- screen readers no longer see a link, they see an option.

It therefore seems important to compare gridcell to option and other widgets whose descendants are presentational. The relevant equivalency is that listbox, tree, and grid are all composite widgets that manage descendants and are thus a single tab stop. Beyond that, one way grid is very different, distinguished from, other composites is that gridcell descendants are not presentational.

So, I don't understand what you mean when you say the comparison made in the APG language is a false equivalency. Could you please clarify that point?