- From: Steve Faulkner <faulkner.steve@gmail.com>
- Date: Fri, 25 Apr 2014 09:57:08 +0100
- To: Mark Rogers <mark.rogers@powermapper.com>
- Cc: Karl Groves <kgroves@paciellogroup.com>, "public-pfwg-comments@w3.org" <public-pfwg-comments@w3.org>, "w3c-wai-ig@w3.org" <w3c-wai-ig@w3.org>
- Message-ID: <CA+ri+VmU3+4=x_ej0G5vtU0TznC0uzh=4BeuqHcVQZ=U3Xs0WQ@mail.gmail.com>
Yes, it is, that's right, which is why its a conformance error in HTML and WCAG 2.0 to have duplicate id values in a document. -- Regards SteveF HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/> On 25 April 2014 08:00, Mark Rogers <mark.rogers@powermapper.com> wrote: > Is the problem here not caused by duplicate IDs? > > > > The behaviour of the DOM method getElementByID is specified as undefined > if there are duplicate IDs in the DOM: > > http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-getElBId > > > > Anything built on the DOM then suffers from undefined behaviour when > duplicate IDs are present. I’d be surprised if browser accessibility APIs > didn’t use the same underlying ID mapping as as getElementByID (otherwise > you’d get weird inconsistencies between ACC APIs and DOM APIs) > > > > Worth thinking about this from the browser implementation perspective. The > HTML spec defines IDs as unique, so a browser implementation is likely to > use a fast hash lookup to map unique IDs to a single DOM node. If duplicate > IDs are present then lookup for a duplicated ID is likely to return, > depending on the exact implementation: > > - First matching node in HTML parse order > > - Last matching node in HTML parse order > > > > I believe this is the motivation for F77 > > http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140311/F77 > > > > Best Regards > > Mark > > > > Mark Rogers - mark.rogers@powermapper.com > PowerMapper Software Ltd - www.powermapper.com > > Registered in Scotland No 362274 Quartermile 2 Edinburgh EH3 9GL > > > > > > > > > > *From:* Karl Groves [mailto:kgroves@paciellogroup.com] > *Sent:* 22 April 2014 16:01 > *To:* public-pfwg-comments@w3.org; w3c-wai-ig@w3.org > *Subject:* Difference in behavior between HTML label and aria-labelledby > > > > Working on an audit recently I observed a client who had reused ID > attributes for form controls in a tabpanel interface. They do this because > some form fields are shared across panels. The duplicate fields are hidden > with a CSS declaration of display:none. I came across this on the heels of > a discussion with my good friend and co-worker, Steve Faulkner about this > same topic and I wanted to bring it up here. > > > > I've created a test file and uploaded it at: > > http://karlgroves-sandbox.com/a11yVisible.html > > > > The first field is a normally labelled field, using label[for] pointing to > the field's ID > > > > The second example is a single label with 'for' with 3 fields sharing the > same ID. The first two fields are hidden with display:none and > visibility:hidden, respectively. JAWS and VoiceOver recognize the third > field, skipping the first two. > > > > The third example uses aria-labelledby to reference two IDREFs, one of > which is hidden with display:none. JAWS and VO read both. This behavior is > correct according to ARIA spec[1] > > > > The fourth example uses a label[for] and aria-describedby. JAWS and VO > behave differently, from what I can tell. JAWS behaves as according top > ARIA spec[1] but VO does not. > > > > > > This raises a few questions for me. First, for those who may also be > inclined to test the URL above: are your results similar. > > > > Second, and more importantly, why the difference between the behavior of > label[for] and aria-labelledby? The ARIA spec says "Skip hidden elements > unless the author specifies to use them via an aria-labelledby or > aria-describedby being used in the current computation." If the > definition of "hidden" says "Indicates that the element is not visible or > perceivable to any user. " and "Authors are reminded that > visibility:hidden and display:none apply to all CSS media types; therefore, > use of either will hide the content from assistive technologies that access > the DOM through a rendering engine." > > > > If that's the case, why allow an exception when authors use > 'aria-labeledby' and 'aria-describedby'? Further, why the difference in > behavior from how the label element behaves? > > > > Last, how will the proposed labelfor behave? > > > > > > > > > > > > 1 - http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_nd > > 2 - http://www.w3.org/WAI/PF/aria-implementation/#def_hidden > > > > -- > > Karl Groves > Senior Technical Lead Accessibility Software Consultant & Director of > Training > The Paciello Group > @karlgroves > Phone: +1 443-875-7343 > > >
Received on Friday, 25 April 2014 08:58:16 UTC