RE: Question: testing for non-unique id values SC 4.1.1

> I do not know how much of a problem this is today or which AT is affected how much.

I'd say it continues to be a serious issue.  We see all sorts of crazy issues and when we can't track down the issues we turn to the validator.   We found that browsers almost always fix things visible but the issues are manifest in the AT either through the accessibility API or by the AT.

We ran into a page on the desktop where a left quote was used on an attribute on the HTML element along with a matching straight quote.  A desktop assistive technology couldn't see the page content correctly.   The page looked fine.

On Android we ran into an issue with TalkBack where a combo box was completely invisible in Firefox.  Turns out the first item in the option list had a blank value and no label attribute.  Blank values must have a label attribute to validate.  Adding the label attribute solved the issue.

Some valid nested structures even cause screen reader issues such as when explicit labels contain links -- some AT still have issues with that but it's gotten better.

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: Gregg Vanderheiden [mailto:gregg@raisingthefloor.org] 
Sent: Thursday, September 29, 2016 6:25 PM
To: Andrew Kirkpatrick
Cc: Jason J White; Jonathan Avila; GLWAI Guidelines WG org
Subject: Re: Question: testing for non-unique id values SC 4.1.1

From my memory  - this one originated from two things

1)  Browsers are so good at repairing bad code - that a lot of HTML had errors that did not affect normal use of the page (the browsers repaired them)
2) there was a big push by some that WCAG REQUIRE that all html pages pass validation in order to pass WCAG.    Since WCAG can only address accessibility problems - we examined whether non-valid HTML had any impact on accessibility.  The only thing identified was that some AT would read the HTML — and because the AT did not have all the repair abilities of browsers - the AT could get messed up by bad markup.   Specifically it could get messed up by code that did not parse.   Hence the SC.  

I do not know how much of a problem this is today or which AT is affected how much.  

Gregg


> On Sep 29, 2016, at 6:06 PM, Andrew Kirkpatrick <akirkpat@adobe.com> wrote:
> 
> This seems to be a great example of why 4.1.1 is not really accomplishing what people may hope. 
> 
> I think that it is a reasonable interpretation of 4.1.1 that what matters for HTML is that the source markup doesn’t have duplicate id attribute values. Does the DOM count as a markup language? I don’t think so (am willing to be convinced otherwise) and if not then 4.1.1 doesn’t apply to anything other than the markup-based source:
> 
> "In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features."
> 
> If this is accurate, then it sounds like we have a use-case defined where 4.1.1 is more strict than it needs to be because some types of redundant id attribute values don’t affect the end-user.
> 
> If there is a problem with the id’s being duplicated, then there will always be a different failure as a result (label is incorrectly identified? 4.1.2. Table headings incorrectly identified? 1.3.1, etc.).
> 
> For now, I suspect that we may need to deal with 4.1.1 covering too much ground.
> 
> Are there examples of duplicate id’s which do result in a problem for users but that don’t trigger a separate failure?
> 
> Thanks,
> AWK
> 
> Andrew Kirkpatrick
> Group Product Manager, Standards and Accessibility Adobe
> 
> akirkpat@adobe.com
> http://twitter.com/awkawk

> 
> 
> Th
> 
> 
> 
> On 9/29/16, 16:01, "White, Jason J" <jjwhite@ets.org> wrote:
> 
>> 
>> 
>>> -----Original Message-----
>>> From: Jonathan Avila [mailto:jon.avila@ssbbartgroup.com]
>>> I think this is also a broader question -- if there is a failure for 
>>> content that is hidden and never shown in any responsive mode such 
>>> as a input without accessible name used as a honey pot with 
>>> display:none -- is that really a failure of any of the criteria?
>> [Jason] It may be a failure. In particular, I am concerned that assistive technologies implemented in scripts (e.g., as browser extensions) may encounter difficulties. For example, if they use querySelector() or getElementById() to match an element with a specified ID, the search of the document tree won't be restricted to "visible" nodes.
>> The kind of script demonstrated by Lisa Seeman on behalf of the COGA Task Force at TPAC last week provides a very good example of what I have in mind. It can be implemented as a browser extension that offers cognitive support (an assistive technology) to the user.
>> I would only consider loosening the requirements of WCAG if we could be sure that duplicate IDs or other departures from the success criteria in "hidden" content wouldn't result in problems for assistive technologies, including those which are browser-based rather than platform-based.
>> 
>> 
>> ________________________________
>> 
>> This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.
>> 
>> 
>> Thank you for your compliance.
>> 
>> ________________________________

Received on Friday, 30 September 2016 00:35:58 UTC