RE: Does double announced content bother screen reader users?

Hi Chaals,

>>> So where is the list?

Ok, I will do some homework and come back with a draft. 
I'm pretty sure that others can contribute to this, too.

Best Regards
Stefan

-----Original Message-----
From: Chaals McCathie Nevile [mailto:chaals@yandex-team.ru] 
Sent: Montag, 30. November 2015 03:07
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; 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?

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 12:05:40 UTC