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

+1 from my memory...

There was almost WW3 over validation, and this was our compromise.

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:24 PM, Gregg Vanderheiden <
gregg@raisingthefloor.org> wrote:

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