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
>>>
>>>
>>
>>
>
>
>