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

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







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 Thursday, 29 September 2016 22:07:33 UTC