RE: Re[2]: Automated A11y non-issues and SC Parsing 4.1.1

Ø  "duplicate ids, where the ID is referenced by the attribute(s) of elements and is visible in the DOM tree."

The term visible in the DOM tree is problematic.  Do you mean visible with the current CSS or do you mean exists in the DOM tree?  I would prefer a term that was more clear that we were talking about being present in the DOM tree.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>
703.637.8957 (Office)
Visit us online: Website<http://www.ssbbartgroup.com/> | Twitter<https://twitter.com/SSBBARTGroup> | Facebook<https://www.facebook.com/ssbbartgroup> | Linkedin<https://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog/>
Check out our Digital Accessibility Webinars!<http://www.ssbbartgroup.com/webinars/>

From: David MacDonald [mailto:david100@sympatico.ca]
Sent: Monday, July 18, 2016 9:28 AM
To: josh@interaccess.ie
Cc: Sailesh Panchang; Patrick H. Lauke; WCAG
Subject: Re: Re[2]: Automated A11y non-issues and SC Parsing 4.1.1

My understanding is that the only time duplicate ids are a problem is when they are referenced by attributes of elements, and the AT doesn't know which one to go for.

Perhaps we could amend 4.1.1 to say something like:

"duplicate ids, where the ID is referenced by the attribute(s) of elements and is visible in the DOM tree."

Wouldn't this address false positives?

Also, I think crawlers that use a headless browser don't run into this problem, right?

Cheers,
David MacDonald



CanAdapt Solutions Inc.
Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd<http://twitter.com/davidmacd>

GitHub<https://github.com/DavidMacDonald>

www.Can-Adapt.com<http://www.can-adapt.com/>



  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy<http://www.davidmacd.com/disclaimer.html>

On Mon, Jul 18, 2016 at 8:59 AM, josh@interaccess.ie<mailto:josh@interaccess.ie> <josh@interaccess.ie<mailto:josh@interaccess.ie>> wrote:
Thanks Sailesh. Lets focus on 4.1.1 for this thread *grin.

Josh


------ Original Message ------
From: "Sailesh Panchang" <spanchang02@yahoo.com<mailto:spanchang02@yahoo.com>>
To: "Patrick H. Lauke" <redux@splintered.co.uk<mailto:redux@splintered.co.uk>>
Cc: w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>
Sent: 18/07/2016 13:49:17
Subject: Re: Automated A11y non-issues and SC Parsing 4.1.1
Yes it is a false positive if same id does mmot occur at same time on the page.  FPs occur for other SCs too so all need to be addressed by 2.1?

Sailesh. ...Sent from my iPhone
 On Jul 18, 2016, at 8:34 AM, Patrick H. Lauke <redux@splintered.co.uk<mailto:redux@splintered.co.uk>> wrote:
 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<http://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