There are 2 methods of labelling a form control using the HTML label element. You can wrap the control inside the label element or you can include the for attribute on the label element, which has a value matching the id value of the control it is intended to label.
What the HTML5 specification says
The
labelrepresents a caption in a user interface. The caption can be associated with a specific form control, known as thelabelelement’s labeled control, either usingforattribute, or by putting the form control inside thelabelelement itself.
What it means:
Control labeled using for and id
<label for="tex">label</label> <input name="input" type="text" id="tex">
Control inside the label
<label>label wrapped <input type="text"></label>
Control labeled using for & id and inside the label
<label for="a2">label wrapped and for/id <input type="text" id="a2"> with text before and after input</label>
HTML5 Differences to HTML 4.01
These labelling methods are not new to HTML5, they are the same as in HTML 4.0. One difference to note is that in HTML 4 you could assign multiple label elements to a control:
More than one
LABEL
may be associated with the same control by creating multiple references via theforattribute.
This does not appear to be the case in HTML5, while not explicitly forbidden, it is not mentioned that it is allowed. It should also be noted that neither browsers or assistive technology (AT) have provided robust support for multiple labels.
Current accessibility support for form control labeling in browsers and AT
I ran some tests and found that a control labeled using for and id without placing the control inside the label element is by far the most robust method. I also found use of aria-labelledby is more robust across browsers and AT than the standard HTML method of placing a control inside the label.
Complete test and results: Testing form control labelling support in popular browsers and screen readers
Advice for developers
Assuming the testing is accurate:
Until browser implementers fix their accessibility support, if you want controls to be understandable to AT users label controls using for and id. Do not use the control inside the label method. Do not use a combination of the 2 methods.
Advice for Browser and AT implementers
Assuming the testing is accurate:
- Chrome: Implement accessibility support for
for/idandlabelelement wrapping. (filed a bug) - Safari: Implement accessibility support for
labelelement wrapping. (emailed bug report) - Firefox: fix the issue with duplication of label content when
for/idand wrapped combination is used. (filed bug) - NVDA: fix the issue of label repetition when a control is inside a
label.(filed bug)
Advice to self
Spend more time working on the HTML Accessibility API Mappings 1.0 so that how this accessibility stuff should and does work is specified somewhere.
Comments
Thanks Steve.
Note to self: help Steve with the “HTML to Platform Accessibility APIs Implementation Guide”.
thanks Dave, I have been a bit distracted and am still with HTML5 last call and related issues, but every time I investigate accessibility implementation issues in browsers, I believe a little bit more that the guide is needed.
As a developer, I cannot overstate the value of your tests, Steve. You wrote: The WAI-ARIA section of the specification states that so it appears the ability to include multiple references has shifted from the
labelelement’sforattribute to the WAI-ARIAaria-labelledbyattribute.Great stuff!
Hi David, am glad you find the information useful. Agree with your assessment about multiple labelling feature being taken over by
aria-labelledby.Steve, have you considered putting together an accessibility version of the ACID tests? They were intentionally gimmicky, but to good effect! Even when disagreeing with aspects of them, or their overall value even!, people felt compelled to do well on them.
For the first one, I would stick with non-controversial stuff. There seems to be plenty of such which needs a lot of interop work!
Actually, of course, you seem well on your way to having assembled enough significant tests. The point then is to market them. Perhaps Ian would get on board for such? The real question is how to make it “obvious” enough (the images that a correct rendering of the e.g., Acid 2 test were a very very clever marketing move). Looking at your label tests, the first table could be rendered in browsers even without a screen reader (thus, easily run by arbitrary people).
Oo, a thought. If the accessibility apis are Javascript accessible, you could render the page visibly as it “appears” to a screen reader. What You See Is What You (or They) Hear would be pretty compelling, I think.
Ok, I had a fantasy moment there 🙂 Even if users of stock browsers won’t be able to run the test per se, I think having a results page that made visible the broken behavior could be understandable enough to be picked up by the press.
Hi Bijan, yes it has crossed my mind, but in most cases you need to access the accessibility API info, which is not available without using an inspect tool in most cases. HTML5accessibility.com is my attempt at publicising browser accessibility support tables for new HTML5 features.
Thanks Steve!
Thanks for the follow-up and testing. The idea of an ACID test for assistive technology or Assistive Technology Accessibility Guidelines that define AT behavior for common accessibility implementations would be very cool. But alas, we can’t get AT vendors to become even peripherally involved in any other standards work, so I don’t suppose they’d have much interest in this. Still, it’s nice to have some more definitive guidance for developers.
Ok, I’ve puzzled over this today.
Let’s put aside the “Run it in my browser” problem. I think we can get the “ooo, that looks bad” effect quite easily. I did a little mock up based on your test results.
The idea is to “visualize” the negative experience that broken accessibility support produces in screenreaders.
Thank you for detailing the issue and testing across browsers and screen readers. Likely the first time its been done.
Screen reader Test #8 suggests that the “label” tag can be dropped in favor of the “aria-labelledby” attribute .. although the resulting html would be less meaningful to a machine.
Its too bad Test #3 “label wrapped” doesn’t work well on NVDA – as it produces the lightest html (no for/id attribs, no or html container for layout)
For my own work, I’ll watch the NDVA bug you filed and will switch to Test #2 “label using for/id” if its not fixed by the end of the year.
Hi Gary,
Not using a
labelelement that is associated using for/id or by wrapping results in the label text not being clickable, so I agree dropping of label is not recommended. The combination ofaria-labelledbyand label wrapping is the best option supported by modern browsers and AT, but not for older AT and IE <8. I think the NVDA guys will fix their bug and am hoping that Apple have upped their game in OS X Lion.Very useful. NVDA and JAWS read multiple labels associated with a form control via for/id in Firefox but not IE. It will help a great deal if Internet Explorer supports this.
Secondly, HTML5 should build on what already exists i.e. be backward compatible. In other words it should explicitly allow multiple labels to be associated with a form control.
And finally, why is it necessary to use ARIA to label standard HTML form controls? The ARIA specs direct one to use native features of the markup language. Use ARIA for dynamic content and custom controls for which it is specifically designed. Another method of labelling standard form controls does not enhance Web accessibility.
Hi Sailesh
I would suggest filing a bug against IE,
Browsers that do support such behaviour will continue to do so, preserving backward compatibility. If you feel strongly that the behaviour should be conforming in HTML5 I suggest you file a bug against the HTML5 spec.
While I have included some test cases using aria-labelledby, I have not advocated the use of ARIA to label standard form controls, but it is definitely one of the use cases and If I had cause to use a method that enjoyed the widest support amongst modern browsers and AT, I would consider using ARIA in conjunction with for/id.
Hi Steve.
Have you tested using aria-labelledby to target a single label for multiple inputs? Is that fully supported?
Hi Ted,
The test cases here aria-labelledby tests all use the same set of labels. If aria-labelledby is supported then targeting a single label for multiple inputs works fine.
Note: The tests i linked to above are sorely out of date (as can be seen from the browsers version numbers), am in the process of updating them. Good news is that IE9 supports
aria-describedbyandaria-labelledbywith single and mulitpleidreferences. But the referenced elements must be “Accessible HTML Elements” In most cases this means that the referenced elements must have atabindex="-1"added to them, refer to the MSDN info on Accessible HTML Elements and Making Non accessible Elements Accessible.That’s an interesting point about tabindex=-1. That’s not very intuitive.
Steve –
I put together a simple test for aria-labelledby and aria-describedby and found that both attributes worked just fine without the referenced elements needing a tabIndex of -1.
I used both semantic (label, p) and structural (span, div) elements to house the labels and descriptions. I would have assumed that it was the structural elements that were considered not to be Accessible Elements by IE, but that doesn’t seem to be the case.
What HTML elements are natively considered to be part of the Accessible Tree by IE and would require the use of tabIndex -1?
Here’s my test case:
https://public.yahoo.com/kloots/aria/aria-ie-labelling.html
– Todd
Hi Todd, am on vacation so will not be able to answer you until next week, will look into it upon my return thanks for the test page!
Hi Todd, I ran some tests against your test cases and also developed some more test cases. While
aria-describedbywith a single reference works in IE with NVDA and JAWS it is because they both work around the issue that IE does not provide thearia-describedbytext via the MSAA accessible name property. The issue still arises when eitheraria-labelledbyoraria-describedbyreferences multiple elements. (try test case 5. using span multiplearia-labelledbyandaria-describedbyreferences).