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> 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 file
> directly and just update that accordingly whenever it changes.
>
>
>
>
>
>
>
> *From:* Alexander Surkov [mailto:surkov.alexander@gmail.com]
> *Sent:* Monday, September 28, 2015 12:59 PM
>
> *To:* Bryan Garaventa <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> 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. J
>
>
>
>
>
>
>
> *From:* Alexander Surkov [mailto:surkov.alexander@gmail.com]
> *Sent:* Monday, September 28, 2015 7:16 AM
> *To:* Bryan Garaventa <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> 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.
>
>
>
>
>