- From: Matt King <a11ythinker@gmail.com>
- Date: Mon, 29 Aug 2016 14:41:18 -0700
- To: "'Schnabel, Stefan'" <stefan.schnabel@sap.com>, "'ARIA Working Group'" <public-aria@w3.org>, "'Bryan Garaventa'" <bryan.garaventa@ssbbartgroup.com>
- Message-ID: <00b201d2023e$140f9880$3c2ec980$@gmail.com>
Stefan, I hear your point about authors potentially confusing <table role=”presentation”> with the idea that there is such a thing as a “layout grid.”My main point is that, in practice, there is no such thing as a layout grid or a data grid but there are different uses of grid that one could describe as “layout” or “data presentation”. While I can see there might be a possibility for some initial confusion, it is somewhat mitigated by the fact that it is impossible to create a grid with role presentation since an element can have only one role. Nonetheless, I would like to address your concern, so I opened this issue: https://github.com/w3c/aria-practices/issues/107 Please comment on the issue with suggestions. As far as aria-readonly goes, it is not useful for describing the entire grid. Please read the updated language that addresses readonly in the 1.1 spec. TLDR; readonly describes the content of an individual cell and is only useful if the grid is in a context where the user assumes all cells contain editable text. Thank you for your feedback! Matt From: Schnabel, Stefan [mailto:stefan.schnabel@sap.com] Sent: Monday, August 29, 2016 3:51 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, I’d like to comment some of your statements. >>> 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. Yes. These examples should not only reflect true and real life scenarios but also exhibit all widget ARIA roles as children in grid and layout grid cells. Currently Jaws 17 + IE 11 isn’t even recognizing all widget roles when keyboard focus is on cell in application mode, as opposite when these widgets are directly focused as part of a form.. And of course, their values and actual states, too, are also not always read. I’m not sure that his has been ever completely scrutinized, honestly. We had to write tons of glue JS code to extract this info for Jaws from the inner cell on cell focus, otherwise a satisfying data grid browsing and using experience was simply not possible for blind end users, as our acceptance tests revealed. >>> 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. Then, are ARIA layout grids per default readonly=”false” like data grids? Is this realistic? Or is the opposite true? >>>. There are too many experiences where so much meta information is provided by a screen reader that you cannot hear the actual information through the noise. I agree. This should be highly configurable in the AT software. It is not by chance that Jaws has a speech verbosity manager and HTML speech options. The point is here Matt, that “relevant” is a VERY subjective thing. Something that distracts one user won’t bother another. I know people who cannot work in an office with crooked pictures on the wall. Others just don’t care. Personalization is here the key and NOT built-in heuristics. There should be simply a setting and a hotkey to speak ALL info. When I am on a grid cell I don’t need always this info, but I need a key command to access it when I feel I need it. The problem here is that different AT+browser combinations have different ideas WHAT IS relevant, what to be spoken immediately and what on special request. For instance, if you press INS+TAB in Jaws+IE, you get different details info then with Jaws+FF. I think you know what I mean. This not only calls, it yells for a standardization. >>> 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, we have to be clear about if a “layout grid” is identical to <table role=”presentation”>. I think it is NOT (since the cells for a layout grid are still there and focusable) but people may misunderstand and confuse this. Therefore, I really think the term “layout” should be avoided. But if so, can we say “just use grid, maybe with aria-readonly=true and you’re done”. Is it so? Best Regards Stefan From: Matt King [mailto:a11ythinker@gmail.com] Sent: Mittwoch, 24. August 2016 03:43 To: Schnabel, Stefan <stefan.schnabel@sap.com <mailto:stefan.schnabel@sap.com> >; 'ARIA Working Group' <public-aria@w3.org <mailto:public-aria@w3.org> >; 'Bryan Garaventa' <bryan.garaventa@ssbbartgroup.com <mailto:bryan.garaventa@ssbbartgroup.com> > Subject: 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 <mailto:a11ythinker@gmail.com> >; ARIA Working Group <public-aria@w3.org <mailto:public-aria@w3.org> >; Bryan Garaventa <bryan.garaventa@ssbbartgroup.com <mailto: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
Received on Monday, 29 August 2016 21:41:51 UTC