RE: APG grid pattern text ready for review

Stefan,

 

I understand your points, but disagree with many of the assumptions that seem to be leading you to your conclusions. I wish I had time to adequately explain why.

 

I believe functioning examples plus work by screen reader vendors to effectively support those examples will make the conversation much simpler. At this time, I am putting my focus there. Then, when we revisit this topic for ARIA 2.0, we can work through your concerns.

 

That said, there is one paragraph you wrote that feels a bit like the proverbial finger in a dike.

 

Stefan wrote:

>And by the way, Matt, when you bring your argumentation using role=grid for single column grids to the very consequences, 

>then simple lists in HTML would have never been invented 

>for we have <table> and you always can do tables with just one column. 

 

Single column grid does not equal either list or listbox.

And, Single column Table is not the same as single colun grid.

So, it does not follow that single column table is equal to list.

The argument is non sequitur.

 

>The role should tell you in advance what you have, list or grid. 

 

Just because a single column grid can present a collection of interactive elements that some people may describe as a list of elements, it does not necessarily follow that it is advantageous for screen readers to tell their users that it is a list.

 

The role helps the assistive technology present the element and provide useful interaction information. In web land, like in native word processing land and every other kind of document land, the screen reader convention has long been to use the word “list” for describing bulleted and numbered lists and outlines. They have conventionally used other words to describe interactive collections. Obviously, ARIA does not specify such conventions and does not have to be limited by them. But, at the same time, it is not necessarily useful to work against them without an overwhelming need to do so.

 

>For 2-dimensional layouts, we are in the same boat, 

>but still this is a “layout grid” for me and not a “data grid” 

>and the difference should be announced by screen readers since it determines the interaction behavior.

>In a layout grid you can navigate and interact but never edit content 

>while in a data grid you can. 

>This should be made clear to the user in advance.

 

I do not necessarily agree that you could never edit content in a grid used for layout. There is no need to place such a restriction on that type of usage of the grid role.

 

Whether content editing functions are provided is generally conveyed to users by context. That is true for all users. In some cases, it may also be communicated by the role of the element contained in a cell. And, in some less common cases, where the general presumption is that everything in the context is editable, the disabling of content editing may be communicated with aria-readonly.

 

In general, screen reader users do not require any extra affordances to understand these aspects of interaction. In fact, assuming they do could lead to excess verbosity that confuses rather than aids the user. There are too many experiences where so much meta information is provided by a screen reader that you can not hear the actual information through the noise. In such instances, there is often a higher level UI design issue that is aking the experience lousy for all users.

 

Again, I didn’t introduce the terms data grid and layout grid  into the design pattern as a method of classification. Assistive technology developers and users do not have any need or use for such classification. Instead, the design pattern is using these terms to help describe the broad utility of the pattern and assist designers with the process of determining appropriate interactions across such a diverse set of conditions.

 

Given this discussion, I will revisit the assumption that using the terms layout grid and data grid within the design pattern is a good idea. Perhaps it should be reworked in a way that does not use them.

 

Matt

 

From: Schnabel, Stefan [mailto:stefan.schnabel@sap.com] 
Sent: Thursday, August 18, 2016 1:05 AM
To: Matt King <a11ythinker@gmail.com>; ARIA Working Group <public-aria@w3.org>; Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
Subject: RE: APG grid pattern text ready for review

 

Matt, Bryan,

 

For lists that ARE interactive and contain non-presentational children we have a definition gap in ARIA 1.1, and the proposed solution using grid role for that is just a temporary workaround operating on “what we have” (not what we *should* have).

 

I’d like to comment on some of your statements.

 

>>> A table that has no headers is implicitly a layout table because there is nothing to definitively identify the table as a data table. All data tables must have headers, otherwise they will not be reliably conveyed by ATs as data tables.

 

If everybody obeys to this, then the WAI-role role=”presentation” for layout <table> would have never been invented. And FS would never had invented custom attributes for Jaws indicating the same. Your expectation is theory, but practice shows that explicit attributes indicating layout usage *are* needed, not because developers are evil but structural code won’t change but adding attributes is easy. Writing it “right” from the scratch may happen but is neither bullet-proof nor frequent according to my 20+ years experiences in this business.

 

>>> Why would a screen reader user want to know if the author was thinking of a particular grid as either a data grid or a layout grid? >From the user’s perspective, a grid is a grid is a grid, and you just start pressing arrow keys to see how it works.

 

Because the role variant drives the subsequent expectation. If something is called “grid” by screen reader I expect cells with potentially editable content, as ARIA 1.0 specification clearly defines <https://www.w3.org/TR/wai-aria/roles#gridcell>  it. Not so for layout grids. This is an entirely different animal. Just pressing keys is *not* sufficient, you should know in advance *what* you are about to navigate.

 

>>>> I have experienced cases where an interactive grid is converted into a listbox, however this requires a redrawing of the widget type in the DOM and they are not the same structure.

 

This is done as last resort mimicking selectable and interactive items as options and having group labelling plus aria-posinset/setsize for orientation. The visual representation of these items is often *not* like classy options in a native OS listbox. I would rather have a specialized role or role variant here for interactive lists that are *NO* classy OS list boxes. 

 

>>> A list is a different role type, and a grid is not the same thing as a list. A grid for example is an interactive widget, whereas a list is a structural role that is not.

 

This is not true anymore. We have now list items (especially in mobile scenarios) that ARE fully interactive (anything may happen on activation) and even CONTAIN non-presentational children. Look for instances at Apple iOS switches embedded in interactive list items. They mimicking  it already in HTML without having good roles for the composite construct.  There are maybe guidelines by Apple not to associate actions with the list item itself doing so (treat it as structural) but if I learned one thing from ARIA it is that is enables extensions before they are natively supported in host language. Up to today, HTML5 has no tree control element. ARIA has. And it is needed badly in business apps.

 

I understand that a column in  ARIA grid is similar in the sense that the container cell is focusable and may contain non-presentational children, but the cell itself is normally not intended to trigger actions, all interaction is basically limited to switching its states (such as selected). Or to put it different: a grid cell is *not* a button, it *contains* one. A grid cell *is* potentially editable, why a layout list item normally is *not*. The point is also  that the cell resides in a “grid” which is by nature a 2-dimensional list.

 

And by the way, Matt, when you bring your argumentation using role=grid for single column grids to the very consequences, then simple lists in HTML would have never been invented for we have <table> and you always can do tables with just one column. Pointless, again. The role should tell you in advance what you have, list or grid. For 2-dimensional layouts, we are in the same boat, but still this is a “layout grid” for me and not a “data grid” and the difference should be announced by screen readers since it determines the interaction behavior. In a layout grid you can navigate and interact but never edit content while in a data grid you can. This should be made clear to the user in advance.

 

Best Regards

Stefan

 

 

 

 

 

From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] 
Sent: Freitag, 29. Juli 2016 20:04
To: Schnabel, Stefan <stefan.schnabel@sap.com <mailto:stefan.schnabel@sap.com> >; Matt King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com> >; ARIA Working Group <public-aria@w3.org <mailto:public-aria@w3.org> >
Subject: RE: APG grid pattern text ready for review

 

“Omitting header cells is not distinctive enough. 

What should screen readers use as information to distinguish between the cases? Should they guess?”

 

Currently that is what screen readers do, they guess. A table that has no headers is implicitly a layout table because there is nothing to definitively identify the table as a data table. All data tables must have headers, otherwise they will not be reliably conveyed by ATs as data tables.

 

“ One-column layout grids: LISTS.

They are frequent. 

Shouldn’t there be a explicit indication for this a screen reader can use NOT to say “Grid” but “List” instead?”

 

A list is a different role type, and a grid is not the same thing as a list. A grid for example is an interactive widget, whereas a list is a structural role that is not.

 

I have experienced cases where an interactive grid is converted into a listbox, however this requires a redrawing of the widget type in the DOM and they are not the same structure.

 

 

Bryan Garaventa

Accessibility Fellow

SSB BART Group, Inc.

bryan.garaventa@ssbbartgroup.com <mailto:bryan.garaventa@ssbbartgroup.com> 

415.624.2709 (o)

www.SSBBartGroup.com <http://www.SSBBartGroup.com> 

 

From: Matt King [mailto:a11ythinker@gmail.com] 
Sent: Sonntag, 7. August 2016 03:12
To: Schnabel, Stefan <stefan.schnabel@sap.com <mailto:stefan.schnabel@sap.com> >; 'ARIA Working Group' <public-aria@w3.org <mailto:public-aria@w3.org> >
Subject: RE: APG grid pattern text ready for review

 

Stefan,

 

Why would a screen reader user want to know if the author was thinking of a particular grid as either a data grid or a layout grid? From the user’s perspective, a grid is a grid is a grid, and you just start pressing arrow keys to see how it works. Basic grid navigation is a very simple concept.

 

The purpose of making a distinction between data grids and layout grids for authors is to help them design an interaction that is appropriate for the content. If the interaction is appropriate, the user will understand the experience without ever being aware of such distinctions.

 

>From a screen reader developer perspective, the behaviors should always be the same regardless of the purpose of the grid. This is part of the beauty, simplicity, and power of the grid role.

 

Since a grid is a widget, screen readers should always reveal the semantics regardless of how many rows or columns it contains and regardless of whether it has headers or not. If a screen reader does not reveal the semantics, it is not respecting the intention of the role.

 

Matt

 

From: Schnabel, Stefan [mailto:stefan.schnabel@sap.com] 
Sent: Thursday, July 28, 2016 4:48 AM
To: Matt King <a11ythinker@gmail.com <mailto:a11ythinker@gmail.com> >; ARIA Working Group <public-aria@w3.org <mailto:public-aria@w3.org> >
Subject: RE: APG grid pattern text ready for review

 

Matt,

 

Besides from commenting in [2], I miss two very central points in the grid pattern text:

 

è Distinguishing between layout and data grid in code by explicit attribute declaration. 
Omitting header cells is not distinctive enough. 
What should screen readers use as information to distinguish between the cases? Should they guess?

è One-column layout grids: LISTS.
They are frequent. 
Shouldn’t there be a explicit indication for this a screen reader can use NOT to say “Grid” but “List” instead?

 

Best Regards

Stefan

 

 

 

From: Matt King [mailto:a11ythinker@gmail.com] 
Sent: Montag, 18. Juli 2016 03:07
To: ARIA Working Group <public-aria@w3.org <mailto:public-aria@w3.org> >
Subject: APG grid pattern text ready for review

 

The documentation (not yet the code examples) for the ARIA 1.1 grid design pattern is ready for review[1]. 

 

Please provide feedback and comments in ARIA practices issue #29:

https://github.com/w3c/aria-practices/issues/29

 

For reference, this new grid design pattern section replaces ARIA 1.0 design pattern sections for both "Grid" [3] and "Actionable, Sortable Column Header in a Grid" [4].

 

Matt King

 

References:

 

[1] ARIA 1.1 Grid Pattern

http://w3c.github.io/aria-practices/#grid

 

[2] APG 1.1 Issue #29 for grid pattern feedback:

https://github.com/w3c/aria-practices/issues/29

 

[3] ARIA 1.0 design pattern text for Grid:

http://www.w3.org/TR/2016/WD-wai-aria-practices-1.1-20160317/#grid

 

[4] ARIA 1.0 design pattern text for Actionable, Sortable Column Header in a Grid:

http://www.w3.org/TR/2016/WD-wai-aria-practices-1.1-20160317/#sortablegrid