RE: Automated A11y non-issues and SC Parsing 4.1.1

> I would think that in older AT (which takes a copy of the DOM/scrapes the source) this may have caused a problem. But in modern scenarios (where the information is obtained via the accessibility tree/API) this sort of dynamic change of whatever the element with a particular id is should be fine. I can also confirm that I've not seen any actual problems with these sorts of things (where two elements have same id, but one is always display:none'd for instance) in practice.

If the nodes with the same ID were added or removed as you suppose then they would not be caught by tools that test the DOM rather than source.  Most automated testing these days uses the DOM and has for many years.  If the source is used then the tool is at fault for using the source.

But my guess is that Josh is talking about a scenario where the ids might be hidden with CSS.  I can think of some scenarios where this could be an issue.  For example, aria-labelledby and aria-describedby can reference content with display none.  In these cases you could in theory have duplicate ids where the id is referenced and the wrong accessible name of description could be calculated.  So we can't just throw out this test.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group 
jon.avila@ssbbartgroup.com
703.637.8957 (Office) 
Visit us online: Website | Twitter | Facebook | Linkedin | Blog
Check out our Digital Accessibility Webinars!

-----Original Message-----
From: Patrick H. Lauke [mailto:redux@splintered.co.uk] 
Sent: Monday, July 18, 2016 8:35 AM
To: w3c-wai-gl@w3.org
Subject: Re: Automated A11y non-issues and SC Parsing 4.1.1

On 18/07/2016 13:24, Joshue O Connor wrote:
> Hi all,
>
> I have a client which uses multiple IDs in their UI widgets - these 
> IDs are 'active' at different times for different reasons depending 
> where the user is within a 'flow'. It hasn't demonstrated any a11y 
> problems, but is technically a fail of SC 4.1.1.

I would think that in older AT (which takes a copy of the DOM/scrapes the source) this may have caused a problem. But in modern scenarios (where the information is obtained via the accessibility tree/API) this sort of dynamic change of whatever the element with a particular id is should be fine. I can also confirm that I've not seen any actual problems with these sorts of things (where two elements have same id, but one is always display:none'd for instance) in practice.

> My client is doing really good work in terms of their a11y approach, 
> and I really don't want to fail them on this. But these 'errors' are 
> called out by automated tools, and will be visible to anyone else 
> testing the site. I just can't say they have resulted in a problem at all.
>
> What would you guys/gals do? Do this also represent a 'false negative'
> that we should address in 2.1 or Silver?

It's definitely a false positive in my book, and a good example of where tools which simply analyze the source (rather than the actual DOM tree) will struggle.

P
-- 
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke

http://flickr.com/photos/redux/ | http://redux.deviantart.com

twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Monday, 18 July 2016 13:06:40 UTC