- From: Gregg Vanderheiden <gregg@raisingthefloor.org>
- Date: Thu, 29 Sep 2016 18:24:58 -0400
- To: Andrew Kirkpatrick <akirkpat@adobe.com>
- Cc: Jason J White <jjwhite@ets.org>, Jonathan Avila <jon.avila@ssbbartgroup.com>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
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 Thursday, 29 September 2016 22:25:29 UTC