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>
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?

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