RE: Difference in behavior between HTML label and aria-labelledby

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<mailto:mark.rogers@powermapper.com>
PowerMapper Software Ltd - www.powermapper.com<http://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<tel:%2B1%20443-875-7343>