RE: Litmus: 5 tests that break the recursive Alternative Text Calculation in all browsers and Assistive Technologies

Okay, I’ve created the GitHub project with results from the most common browsers at
https://github.com/accdc/w3c-alternative-text-computation


Desc: “A study of browser and Assistive Technology support for the W3C Alternative Text Computation.”

Please let me know if anything is missing, and if anybody wants to provide Edge Name and Description details just let me know.

From: Alexander Surkov [mailto:surkov.alexander@gmail.com]
Sent: Wednesday, September 30, 2015 5:45 AM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
Cc: PF <public-pfwg@w3.org>
Subject: Re: Litmus: 5 tests that break the recursive Alternative Text Calculation in all browsers and Assistive Technologies

3 browsers on Windows is a good start. I'm not sure if we need a whole project for this. In general only bugs filed against browsers are needed, when there's agreement on the behavior.

On Mon, Sep 28, 2015 at 8:01 PM, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> wrote:
I can see the value of it, but this is something I would need help from others to build, since I can test on a Win7 machine using 3 browsers, which leaves all others yet to be done.

Is this a project you and others you can think of might be able to help with? I can create a GitHub repo for it, and I believe it’s possible to create a wiki page for the repo, or we could modify the readme.md<http://readme.md> file directly and just update that accordingly whenever it changes.



From: Alexander Surkov [mailto:surkov.alexander@gmail.com<mailto:surkov.alexander@gmail.com>]
Sent: Monday, September 28, 2015 12:59 PM

To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>
Subject: Re: Litmus: 5 tests that break the recursive Alternative Text Calculation in all browsers and Assistive Technologies

Right. Results should be same across all browsers.

Having a result table would be helpful for discussing the use cases, because not every use case is covered by the spec and browser vendors might have reasons for their implementation varies.

On Mon, Sep 28, 2015 at 12:59 PM, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> wrote:
I don’t at the moment, but it shouldn’t be hard to do using Object Inspector or the equivalent on the Mac.

Off hand, Firefox did well except that it ignored the table structure as part of the naming calculation, and when referenced using aria-describedby, there was a difference in the algorithm that parsed displayed content versus the same content hidden using display:none, even though all three should match.

In IE, everything was broken. ☺



From: Alexander Surkov [mailto:surkov.alexander@gmail.com<mailto:surkov.alexander@gmail.com>]
Sent: Monday, September 28, 2015 7:16 AM
To: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>>
Subject: Re: Litmus: 5 tests that break the recursive Alternative Text Calculation in all browsers and Assistive Technologies

Hi, Brayan. Do you have a results table to see what browsers/screen_readers matches expectations?

On Thu, Sep 24, 2015 at 6:12 PM, Bryan Garaventa <bryan.garaventa@ssbbartgroup.com<mailto:bryan.garaventa@ssbbartgroup.com>> wrote:
Theoretically, the Alternative Text Calculation should be supported in all browsers equally, so I built 5 tests to see how well this is implemented; by using the same convoluted markup structure for each that combines many various aspects of labelling, including programmatically hidden content and nested markup structures. If equally supported, all browsers would reflect the same strings as shown below for the Name and Description calculation.

As it turns out, accurate recursion within browsers is inconsistently and unreliably supported, and no Assistive Technologies match any of these naming algorithms.

I've attached these test pages to this message, and they can also be accessed live using the urls below and saved out using Save As to test them locally.

1. Standard use of role="link" with nested content structures.
http://whatsock.com/test/Alternative%20Text%20Calculation/focusable%20role=link.html

The Accessibility Tree should match:
Name: "My name is Bryan Eli the weird. Where are my marbles?"
Description: ""

2. Standard form field with aria-labelledby to recursively process embedded markup.
http://whatsock.com/test/Alternative%20Text%20Calculation/form%20field%20with%20aria-labelledby.html

The Accessibility Tree should match:
Name: "My name is Bryan Eli the weird. Where are my marbles?"
Description: ""

3. Standard form field that uses an HTML label element with matching 'for' and 'id' attributes.
http://whatsock.com/test/Alternative%20Text%20Calculation/form%20field%20with%20label%20element.html

The Accessibility Tree should match:
Name: "My name is Bryan Eli the weird. Where are my marbles?"
Description: ""

4. Standard form field that uses aria-label to set the Name and aria-describedby to set the Description.
http://whatsock.com/test/Alternative%20Text%20Calculation/form%20field%20with%20aria-describedby.html

The Accessibility Tree should match:
Name: "Important stuff"
Description: "My name is Bryan Eli the weird. Where are my marbles?"

5. Standard form field that uses aria-labelledby to set the Name and aria-describedby to set the Description including hidden sections that surround the referenced elements.
http://whatsock.com/test/Alternative%20Text%20Calculation/form%20field%20with%20aria-describedby%20+%20hidden.html

The Accessibility Tree should match:
Name: "Important stuff"
Description: "My name is Bryan Eli the weird. Where are my marbles?"

So, whenever external containers are referenced via aria-labelledby or aria-describedby or the HTML label element using matching 'for' and 'id' attributes, the recursive Alternative Text Calculation should process the same subtrees even when aria-labelledby and aria-describedby referenced parent containers are hidden using CSS. When comparing these in the Accessibility Tree though, even within the same browsers, these algorithms don't match.

Additionally, screen readers such as JAWS and NVDA don't come anywhere near conveying the same algorithm, often varying widely across differing browsers.

Personally, I would like to see all browsers equally support the same algorithm, and have the same algorithm supported in ATs like screen readers as well, for all of the following interactive elements and ARIA roles:

* All HTML input, select, and button elements.
* All HTML A elements that include an 'href' attribute.
* All of the ARIA roles: "button", "checkbox", "link", "searchbox", "scrollbar", "slider", "spinbutton", "switch", "textbox", "combobox", "option", "menuitem", "menuitemcheckbox", "menuitemradio", "radio", "tab", "treeitem"

Otherwise, it will be impossible to create complex dynamic constructs that are consistently and reliably labelled for Assistive Technology users in the future.