Re: Automated A11y non-issues and SC Parsing 4.1.1

Thanks Patrick, appreciated. 

Josh 

Sent from TypeApp



On 18 Jul 2016, 13:37, at 13:37, "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