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

Regarding DOM vs. Source, I'd say DOM, because that is were the "content"
is. The source may or not reflect JavaScript changes to the content, but
the DOM should always provide the current state of the content.

 I don't think the phrase "...in content USING markup languages..."  is the
same as "In markup content ..."

I agree 4.1.1 is wider than it needs to be, and we should definitely adjust
it for 2.1. There might be an argument to manage it in 2.0 via our
interpretation in the understanding, if we can overcome Jason's concern.

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 Thu, 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
>
>
>
>
>
>
> 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.
> >
> >________________________________
>