Using aria-describedby to provide helpful form hints

Posted on Tuesday, 23 December 2014 by Léonie Watson

When a form field has a label, screen readers will announce it automatically when focus moves to the field. If additional information is available to help people complete the task, it’s also a good idea to associate it with the field in question.

Quick label recap:

<label for="password">Choose a password</label>
<input type="password" id="password" …>

If this field was included in a form for creating a new account, the field might have the following additional information displayed:

<label for="password">Choose a password</label>
<input type="password" id="password" …>

<p>Your password must be at least 10 characters in length. It must contain a mixture of upper and lower case letters, numbers and punctuation marks.</p>

The additional information will be visually styled and positioned to make its relationship to the field apparent. However, a screen reader user who tabs through the form (from one field to the next) will be completely unaware that the additional information exists.

The aria-describedby attribute is used to provide an accessible description for an object within the user interface. Where the programmatically associated label provides the field’s accessible name, the aria-describedby attribute associates the field with the additional information to provide the field’s accessible description.

<label for="password">Choose a password</label>
<input type="password" id="password" aria-describedby="hint" ...>

<p id="hint">Your password must be at least 10 characters in length. It must contain a mixture of upper and lower case letters, numbers and punctuation marks.</p>

The aria-describedby attribute takes the idref of the paragraph containing the additional information as its value. It works in the same way as the for/id attribute pairing between the <label> and the <input>.

Note: it is possible to associate multiple sources of information using aria-describedby. Refer to Notes on Using ARIA in HTML for more information.

When a screen reader focuses on the field in this example, it will announce the label, the type of field, then the additional information (in that order). One of the advantages of this is that the additional information is announced last, so screen reader users are not obliged to listen to it every time they move to that field. They can listen to it if they choose, but if not they can listen to the label announcement and then carry on without waiting for the rest.

About Léonie Watson

Léonie (@LeonieWatson) was Director of Developer Communications at TPG (2013-18), is co-chair of the W3C Web Platform Working Group working on HTML and Web Components, writer for Smashing magazine, and Net magazine, and regular conference speaker.


  1. @aria-describedby is an attribute I would definitely use.

    I understand the last paragraph, but I want to be sure about my understanding. Are screen readers actually reading (or using) this information, or are you stating what screen readers should be doing with this information?

    If possible, could you name some of the screen readers that are actually using this attribute and its information in the correct way?

    I do not like adding things to a page because it looks good, but rather because it is good

  2. @H.E.A.T.

    This is a technique you can use now. Currently Firefox, Chrome, Internet Explorer and Safari support aria-describedby (although note the IE exception mentioned in the post). Of the screen readers you can use with these browsers, NVDA, Jaws, Window-Eyes, Safari (OSX and iOS) and Orca all work with aria-describedby at this time.

  3. Much appreciation for your response, Ms. Watson. Yes, I have been looking for a way to associate detailed instructions on completing forms as in your example.

    Sometimes there is little usable real estate on the screen, especially if you’re trying to maintain an above-the-fold approach in your design.

  4. @H.E.A.T.

    You’re welcome.

    With people using so many different devices in so many different configurations, it’s difficult to predict with any certainty where the fold will be. One option might be to break the form into multiple chunks, instead of presenting it as a single page?

    This can reduce the amount of content on-screen and increase the likelyhood that the content will appear above the fold on more devices. It also makes it easier to include useful content like hints, and has the added benefit of simplifying the overall UX.

Comments for this post are closed.