- From: Chaals McCathie Nevile <chaals@yandex-team.ru>
- Date: Mon, 30 Nov 2015 12:07:04 +1000
- To: "Bryan Garaventa" <bryan.garaventa@ssbbartgroup.com>, "Schnabel, Stefan" <stefan.schnabel@sap.com>
- Cc: "Michiel Bijl" <michiel@agosto.nl>, Léonie Watson <lwatson@paciellogroup.com>, "Matt King" <a11ythinker@gmail.com>, "mzehe@mozilla.com" <mzehe@mozilla.com>, "ARIA Working Group" <public-aria@w3.org>, "Protocols and Formats Working Group" <public-pfwg@w3.org>
On Wed, 25 Nov 2015 19:05:17 +1000, Schnabel, Stefan <stefan.schnabel@sap.com> wrote: > Hi Brian. > >>>> It is true that we have weak areas within complex widgets, such as >>>> Grids and Treegrids for example, where the roles and states of >>>> embedded active elements like checkboxes and radios and the like are >>>> not conveyed .... > > Right. One reason for this is that <td> element is treated as a dumb > container in the HTML table model, > whereas it has DEFINITELY <fieldset> element capabilities when one or > more widgets are put into. > And no, the solution is *not* putting fieldsets into <td> elements :) > > The solution is *also not* having allowed "override" > and-to-be-interpreted roles on <td> like "<td role='checkbox'" since we > can have multiple focusable sub-elements in a cell (there are really use > cases for that). > > We need a clever HTML5 standard data grid element in HTML5 with a > standard extensibility concept for cell content containing n individual > focusable items. > > Not less than that. Oh yes, and it should at least mimic Microsoft > listview control layout and behaviour, if configured so. > > I can give you a list of features required from a business perspective, > but beware, this list is looooooong. > Nothing of that is offered already as standard HTML5 table feature. > Everything has to be done/coded by hand. So where is the list? It might be long, but without a problem statement we're unlikely to see a lot of momentum toward a solution… cheers > Again and again, forever and ever. With unclear details, > yet-to-be-communicated tech issues for browser and AT vendors and so on. > I see that for 20 years now and I think it is time to raise my voice. > And not just mine. > >>>> It would be good to hear what others think about this too. > > Indeed. > > Regards > Stefan > > From: Bryan Garaventa [mailto:bryan.garaventa@ssbbartgroup.com] > Sent: Mittwoch, 25. November 2015 09:24 > To: Schnabel, Stefan <stefan.schnabel@sap.com> > Cc: Michiel Bijl <michiel@agosto.nl>; Léonie Watson > <lwatson@paciellogroup.com>; Matt King <a11ythinker@gmail.com>; > mzehe@mozilla.com; ARIA Working Group <public-aria@w3.org>; Protocols > and Formats Working Group <public-pfwg@w3.org> > Subject: RE: Does double announced content bother screen reader users? > > It is true that we have weak areas within complex widgets, such as Grids > and Treegrids for example, where the roles and states of embedded active > elements like checkboxes and radios and the like are not conveyed when > interfacing with the parent role of Gridcell as is needed for the > intended interactivity of the primary navigation of the widget. > > Since much of this goes back to the AT and how it parses embedded > information, or the lack of it within these widget types, I'm not sure > this is solvable from a spec perspective beyond that of general guidance > for the actual roles being used. It would be good to hear what others > think about this too. > > It seems that the ATs would need to have an algorithm for parsing > embedded active elements in order to convey their roles and states > properly. The tricky bit comes into play with complex embedded widget > types, such as an ARIA Listbox that includes 300 Options. How would an > AT then calculate the correct information when the parent Gridcell has > focus for instance? Or if one Gridcell includes the same Listbox plus a > Checkbox, Radio, and Toggle Button? Or if the same Listbox was > multiselectable or included checkable Option nodes some with mixed > states, etc. This easily becomes convoluted. > > In this case though, the example isn't a complex widget, but rather just > a simple data table that includes a checkbox in one cell. > > If the correct naming algorithm is used across Oss for desktop and > mobile, then all should reflect the same label for that standard > checkbox, regardless whether this is on a desktop or mobile touch device. > > > From: Schnabel, Stefan [mailto:stefan.schnabel@sap.com] > Sent: Tuesday, November 24, 2015 10:46 PM > To: Bryan Garaventa > <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> > Cc: Michiel Bijl <michiel@agosto.nl<mailto:michiel@agosto.nl>>; Léonie > Watson <lwatson@paciellogroup.com<mailto:lwatson@paciellogroup.com>>; > Matt King <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>; > mzehe@mozilla.com<mailto:mzehe@mozilla.com>; ARIA Working Group > <public-aria@w3.org<mailto:public-aria@w3.org>>; Protocols and Formats > Working Group <public-pfwg@w3.org<mailto:public-pfwg@w3.org>> > Subject: Re: Does double announced content bother screen reader users? > > Hi Bryan, > > double announcements with Jaws occur often. > > We should *not* be content solving label for cat issues in static tables > with minor interactivity (although this is a valid use case). The > problem layer is deeper. > > Putting a form element in a table cell and expecting cross-platform > accessibility by magic with a tad of Aria-labelling is NOT a clever > future approach for HTML5. > > The entire thing suffers from the impossibility to provide a normative > common cross browser cross platform cross screen reader approach for > data tables with interactive editable complex cell content. Checkbox in > a cell is just the beginning and even this causes issues, as we see. > > Although this is annoying, I think this is nothing an author can do > better using the current table accessibility model. This is what I hear > mantra-like from our web developers all of the time. Instead, IMHO, > Jaws and browser should handle this internally, but nobody defines > exactly how. > > I just want to state: if you have suceeded creating a solution for your > editable interactive table using keyboard interaction concept or > additional virtual nav which runs fine in Firefox / IE with Jaws and you > take the term "web app runs everywhere" serious and open the app in iOS > with VoiceOver exploring by touch your data grid you are immediately > thrown in annother universe that follows different rules. Not the cell > is prime, but content of cell is, and you have to rearrange > relationships, think about dataset and rowcol pos again where to put > that in the DOM and so on. > > But this is not the fault of iOS or the screen readers or any party > involved alone. It is the result of many years of ignorance of *all* > parties involved to demand and establish a standard editable > hierarchical data grid for web applications. Aria grid and treegid roles > started to address this, but it will still need years to come until we > have major homogenization accross all platforms and user agents, and > frankly, I believe, if not even the HTML HOST language delivers a > solution, the situation will never improve. > > Are we in the same camp with this opinion? > > Best Regards > Stefan > > > > Sent from my iPad > > On 25.11.2015, at 01:36, Bryan Garaventa > <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> > wrote: > This is just one of those things that happens sometimes. > > In this case, when navigating by cell using JAWS in FF for example, JAWS > is first reading the cell header association including its column and > row header text, then it reads the content which is a checkbox that > includes the same label text. This is why it sounds like a duplication. > > If you just use the up/down arrow keys instead to navigate by line, it > will just read it once since JAWS isn't also trying to track and convey > the cell association at the same time. > > Sometimes you will get double announcement too when you include an > explicit label on a widget using aria-label, and also include a title > attribute for sighted mouse users, both of which convey the same > information. Since aria-label sets the Name property and the title > attribute sets the Description property, both are sometimes announced > when the widget receives focus. > > From: Michiel Bijl [mailto:michiel@agosto.nl] > Sent: Tuesday, November 24, 2015 3:16 PM > To: Léonie Watson > <lwatson@paciellogroup.com<mailto:lwatson@paciellogroup.com>>; Matt King > <a11ythinker@gmail.com<mailto:a11ythinker@gmail.com>>; Bryan Garaventa > <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>; > mzehe@mozilla.com<mailto:mzehe@mozilla.com> > Cc: ARIA Working Group <public-aria@w3.org<mailto:public-aria@w3.org>>; > Protocols and Formats Working Group > <public-pfwg@w3.org<mailto:public-pfwg@w3.org>> > Subject: Does double announced content bother screen reader users? > > Hi Léonie, Matt, Bryan, Marco, and PF/ARIA WG members, > > There was a discussion on a11ySlackers about how to properly label form > inputs inside of a table. In this > example<http://dir.agosto.nl/accessibility/table.html> [1] there is a > table with cats. There is a column for their name, softness, cuteness, > and one with a checkbox so you can select the cat to give him or her > snacks. In the example I've labelled all checkboxes with first their > column header (Give snacks to) and then their row header (their name; > e.g. Lara). This should make it clear what that checkbox does. Problem > is that if you use tables mode to navigate and you land on the checkbox; > you header either-depending on which direction you navigate-the column > or row header twice. > > My question is if this bothers any of you? Because it seems like a valid > way to add much needed information to such a setup. > > -Michiel > > [1] http://dir.agosto.nl/accessibility/table.html -- Charles McCathie Nevile - web standards - CTO Office, Yandex chaals@yandex-team.ru - - - Find more at http://yandex.com
Received on Monday, 30 November 2015 11:07:44 UTC