At its best, accessibility allows all users to consume the same content and interact with the same controls even if they are using assistive technology like a screen reader. In the event that plain HTML is unable to offer those using screen readers with a seamless experience, people often turn to ARIA, the Accessible Rich Internet Applications language. ARIA is really a sub-language that works in conjunction with HTML to offer alternate or supplementary information to screen readers.
Unfortunately, not all ARIA features are as well supported as HTML. Different combinations of browsers and screen readers can deliver different experiences, making accessible web development tricky in certain circumstances.
Aria-describedy
Aria-describedy is one of several ARIA attributes that offers special labeling or instructions for anyone using a screen reader. Consider a simple form field for “Start Date” that requires a two-digit month, four-digit year format for entry:
The <label> and <input> elements can be associated with the widely-supported “for” attribute. But what about the information pertaining to format? Some developers would suggest using aria-describedby to associate that additional instruction to the <input> as in the code below
<div>
<label for="sdate">Start Date:</label>
<input type="text" id="sdate" name="sdate" aria-describedby="sdate_description">
</div>
<p id="sdate_description">Please use mm/yyyy format</p>
Some combinations of browsers and screen readers will not read the description at all.Although this code would likely work for many combinations of browsers and screen readers, we want the most robust solution possible. Potential problems with this solution include:
- A few combinations will read the description, but not the label (aria-describedby is not supposed to override the HTML label, but sometimes it does).
- Some will read the description, but only after a pause long enough that users might begin typing data into the field, interrupting the screen reader, and never hearing the description.
- While aria-describedby often works well with simple text boxes like this, support for it with more sophisticated form fields like dropdowns or radio buttons is lacking.
An easy solution to this problem would be to do away with the separate description and include the extra instruction in the label itself. Support for the association of <label> and <input> elements using the for attribute is very strong:
<div>
<label for="sdate">Start Date (in mm/yyyy format):</label>
<input type="text" id="sdate" name="sdate">
</div>It’s not as appealing to look at, but it’s simple and robust. We could even improve this by using a sibling to aria-describedby — aria-label.
Aria-label
Aria-label allows an alternate, enhanced label to be read to screen readers without disturbing the HTML label that appears to sighted users. Two critical differences between aria-label and aria-describedby:
- Aria-label enjoys much wider and more robust support.
- Aria-label overrides the HTML label rather than supplementing it. In other words, screen reader users will hear the aria-label only.
Why would aria-label be an improvement in this situation? Because, depending on a user’s settings, screen readers sometimes attempt to read acronyms and abbreviations as words, resulting in a slurred mess. In this example, screen readers may stumble over the “mm/yyyy.”
We could use aria-label to deliver a more easily understandable label to screen reader users:
<div>
<label for="sdate">Start Date:</label>
<input type="text" id="sdate" name="sdate" aria-label="Start date in two digit month, four digit year format">
</div>
Sighted users will still see the “mm/yyyy” within the HTML label. Screen reader users, however, will hear “Start date in two-digit month, four-digit year format.” Note that the aria-label repeats the same text (“Start date”) that appears in the HTML label. Remember that the screen reader user will hear only what the aria-label contains because the aria-label overrides and replaces the HTML label.
Unfortunately, aria-describedby does not yet enjoy the extensive and robust support of aria-label and many other ARIA attributes. Who is to blame? It’s hard to say. Some believe that the official ARIA specification should be more explicit about how aria-describedby should be supported. Some believe that browser and screen reader makers are to blame. And, often, the different ways to code form fields that are common to different frameworks and content management systems can muddle things by introducing lots of extra <divs> and other code into the mix, possibly confusing the browser or screen reader.
The Importance of Alt Text
Intuitively, interactive content is usually more important than static content. If one image on one page lacks quality alt text, it’s a strike against accessibility, but it won’t make or break the experience for the user. In contrast, being able to activate buttons, follow links, interact with widgets, and submit forms can much more easily become a showstopper if they’re not made highly accessible.
The importance of forms, in particular, should never be underestimated. Forms often represent the culmination of a web experience for both user and site creator — think about submitting an application or completing an e-commerce transaction as examples. Forms are not a place where site creators want to take chances with user experience. Although aria-describedy can be an excellent tool in the right circumstances, it’s one to approach with caution… at least until it’s more widely and robustly supported.
