How to Use ARIA Effectively with HTML5
ARIA stands for ‘Accessible Rich Internet Applications’ and can help make your website more accessible to people with disabilities such as hearing or visual impairment. Let’s see how we, as developers, can make life easier for them.
One way we can use ARIA is by adding it to our HTML. You may already be familiar with semantic elements in HTML such as nav
, button
or header
. It’s quite easy to see what these elements would be used for. These elements give more meaning to the content of a page, and we can use a combination of these elements and ARIA in our markup. However, there are a few things to keep in mind when using them together.
ARIA Roles
ARIA roles are added to HTML markup like an attribute. They define the type of element and suggest what purpose it serves. The following example identifies the element as some kind of banner:
<header role="banner">
The following example, often placed in a containing element, suggests that its content provides some information about the content within the containing element:
<div role="contentinfo">
This website was built by Georgie.
</div>
An alert with dynamic content should use role="alert"
:
<div role="alert">
Please upgrade to the latest version of your browser for the best experience.
</div>
This one is my personal favorite, which is used when an element is simply for presentation. If you imagine someone using a screen reader, think of the elements that they would not want read out. One example is an element that might contain a visual decoration, or is an empty element simply serving an image or background color.
<a href="aria.html" role="presentation">
<img src="aria-thumbnail.jpg" role="presentation" alt="Use ARIA effectively">
</a>
ARIA Attributes
ARIA attributes are slightly different from roles. They are added to markup in the same way, but there is a range of ARIA attributes available for use. All ARIA attributes are prefixed with aria-
. There are two types of attributes, states and properties.
- The value of states are bound to change as a result of user interaction.
- The value of properties is less likely to change.
An example of an ARIA attribute that is a state is aria-checked
. This is used to show the state of elements that are emulating interactive elements, such as checkboxes and radio buttons, but are not the native elements themselves (e.g. custom UI elements built with div
and span
tags).
<span role="checkbox"
aria-checked="true"
tabindex="0"
id="simulatedcheckbox">
</span>
An example of an ARIA attribute that is a property is aria-label
. This is used when a label for a form element is not visible on the page (perhaps because it makes no sense to make it visible, or if the design dictates this). For cases when label text is visible, aria-labelledby
is the more appropriate attribute to use.
This can be done with the figure
element as shown below.
<figure aria-labelledby="operahouse_1" role="group">
<img src="operahousesteps.jpg" alt="The Sydney Opera House">
<figcaption id="operahouse_1">We saw the opera <cite>Barber of Seville</cite> here!</figcaption>
</figure>
You can read more about supported states and properties on the W3C website.
Rules of ARIA
Before you get too keen, remember that we don’t want to be adding ARIA to every element, for a couple of reasons.
Use Semantic HTML Elements Where Possible
Default implicit ARIA semantics refers to semantics that are already applied to an element by the browser. Elements such as nav
, article
and button
have default implicit ARIA statements of role="navigation"
, role="article"
and role="button"
respectively. Before semantic HTML elements existed, it was common to have elements such as <div class="main-navigation" role="navigation">
. Now we are able to use nav
in place of div
, but we no longer need to add role="navigation"
because this is already implied. You can refer to this W3C table to check whether or not an ARIA attribute is required for a certain element.
Your Element Can Only Have One Role
An element should not have multiple ARIA roles. The definition of a role
is as follows:
Main indicator of type. This semantic association allows tools to present and support interaction with the object in a manner that is consistent with user expectations about other objects of that type.
An HTML element cannot have two role
s. All roles are semantic in some way or another, and going by the definition above, an element cannot be two types of an object. Can you have something that is both a button and a heading? No, it has to be one or the other. Choose the role
that best describes the function of your element.
Do Not Change Native Semantics
You should not apply a contrasting role
to an element that is already semantic, as adding a role
overrides the native semantics of an element. For example:
<footer role="button">
The second rule of ARIA use does, however, suggest that if you must, you use a nested HTML element instead.
<footer><button>Purchase this e-book</button></footer>
How Else Can You Make Your Markup More Accessible?
Use as Many Semantic Elements as Possible
This comes with practice, but if you think of the function of what you are building, it can give you a good idea as to what element you can use that would be much better than a div
or a span
. To practice, you could continually refer to what elements are available for you to use and familiarize yourself with them.
One of my favourite examples is the use of blockquote
, which is often misused. There are other similar elements which serve specific purposes:
q
– used to serve inline quotes, such as a direct quote by someone, within paragraph text.cite
– used to cite a creative work within text, such as mentioning a poem.
Here is an example containing the two elements above:
<p>In <cite>The Love Song of J. Alfred Prufock</cite> by T.S. Eliot, the clinical imagery of the line <q>Like a patient etherized upon a table</q> suggests themes of loneliness.</p>
There are many HTML elements that you may not have considered, including some new ones, so make sure you have a look at the possibilities!
alt
Attribute
This is an often forgotten piece of markup that can make a huge difference to the accessibility of your markup, especially for screen readers. It has actually been around since HTML2, and is described as follows:
text to use in place of the referenced image resource, for example due to processing constraints or user preference.
Due to processing constraints or user preference. Regardless of the image not loading (‘processing constraints’), a visually impaired user actually does not have a preference either. By default, they simply have trouble viewing the image the way a person without a visual impairment would. Although the spec says nothing about the term accessibility, it suggests that the image may not load as required, and the user has the ability to turn image loading off. Although we live in a world where the latter seems hard to believe, we cannot assume what our user does on the other end. Therefore we need to provide users with an alternative.
People often write alt
text such as “dog” for a photograph of their dog playing in the park, for example. Unfortunately, despite including this text, it really doesn’t paint a picture for the visually impaired. The following is more acceptable:
<img src="bobby.jpg" alt="My dog Bobby playing fetch in the park">
Note that the alt
attribute does not reflect the same purpose as the figcaption
element – the purpose of alt
is to provide alternative text for an image, while figcaption
can be a relevant caption for a figure
. Using the same example, this may be appropriate text:
<figcaption>Isn’t Bobby cute?</figcaption>
An Example Using Semantic HTML and ARIA, Taking Accessibility into Account
If you look at the example I included earlier in this article, you’ll see that I included something that:
- uses semantic HTML for an image and its caption
- uses the
cite
element appropriately - provides appropriate
alt
text - uses one of the ARIA attributes I’ve already mentioned
<figure aria-labelledby="operahouse_1" role="group">
<img src="operahousesteps.jpg" alt="The Sydney Opera House"/>
<figcaption id="operahouse_1">We saw the opera <cite>Barber of Seville</cite> here!</figcaption>
</figure>
Conclusion
ARIA roles and attributes can make a huge difference when your content is processed by screen readers and other assistive technologies. As the use of assistive technologies becomes more common, we need to consider integrating ARIA in our code as a regular practice.