HTML5 Accessibility Chops: form control labeling

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 label represents a caption in a user interface. The caption can be associated with a specific form control, known as the label element’s labeled control, either using for attribute, or by putting the form control inside the label element 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 the for attribute.

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/id and label element wrapping. (filed a bug)
  • Safari: Implement accessibility support for label element wrapping. (emailed bug report)
  • Firefox: fix the issue with duplication of label content when for/id and 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.

Categories: Technical

About Steve Faulkner

Steve was the Chief Accessibility Officer at TPGi before he left in October 2023. He joined TPGi in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. Steve is a member of several groups, including the W3C Web Platforms Working Group and the W3C ARIA Working Group. He is an editor of several specifications at the W3C including ARIA in HTML and HTML Accessibility API Mappings 1.0. He also develops and maintains HTML5accessibility and the JAWS bug tracker/standards support.

Comments

David Bolter says:

Thanks Steve.

Note to self: help Steve with the “HTML to Platform Accessibility APIs Implementation Guide”.

Steve Faulkner says:

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: This does not appear to be the case in HTML5, while not explicitly forbidden, it is not mentioned that it is allowed. The WAI-ARIA section of the specification states that Authors may use the ARIA role and aria-* attributes on HTML elements, in accordance with the requirements described in the ARIA specifications… so it appears the ability to include multiple references has shifted from the label element’s for attribute to the WAI-ARIA aria-labelledby attribute.

Steve Faulkner says:

Hi David, am glad you find the information useful. Agree with your assessment about multiple labelling feature being taken over by aria-labelledby.

Bijan Parsia says:

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!

Bijan Parsia says:

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

Bijan Parsia says:

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.

Bijan Parsia says:

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.

Steve Faulkner says:

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.

Jared Smith says:

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.

Bijan Parsia says:

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.

Gary says:

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.

Steve Faulkner says:

Hi Gary,
Not using a label element 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 of aria-labelledby and 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.

Sailesh Panchang says:

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.

Steve Faulkner says:

Hi Sailesh

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.

I would suggest filing a bug against IE,

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.

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.

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.

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.

Ted Drake says:

Hi Steve.
Have you tested using aria-labelledby to target a single label for multiple inputs? Is that fully supported?

Steve Faulkner says:

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-describedby and aria-labelledby with single and mulitple id references. But the referenced elements must be “Accessible HTML Elements” In most cases this means that the referenced elements must have a tabindex="-1" added to them, refer to the MSDN info on Accessible HTML Elements and Making Non accessible Elements Accessible.

Ted Drake says:

That’s an interesting point about tabindex=-1. That’s not very intuitive.

Todd Kloots says:

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

Steve Faulkner says:

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!

Steve Faulkner says:

Hi Todd, I ran some tests against your test cases and also developed some more test cases. While aria-describedby with a single reference works in IE with NVDA and JAWS it is because they both work around the issue that IE does not provide the aria-describedby text via the MSAA accessible name property. The issue still arises when either aria-labelledby or aria-describedby references multiple elements. (try test case 5. using span multiple aria-labelledby and aria-describedby references).