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

Right... "present" is better than "visible"

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


===
display:none won't affect the DOM, and as Jonathan says, there are times
when things are referenced inside an element with display:none so this
proposition might address the issue, and tighten up the requirement in WCAG
2.1.





Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*
Tel:  613.235.4902

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

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 9:35 AM, Jonathan Avila <jon.avila@ssbbartgroup.com>
wrote:

> Ø  "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
>
> 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
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613.235.4902
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> 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 <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>
> To: "Patrick H. Lauke" <redux@splintered.co.uk>
> Cc: 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>
> 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 | https://github.com/patrickhlauke
>  http://flickr.com/photos/redux/ | http://redux.deviantart.com
>  twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
>
>
>
>
>
>