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
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 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:
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
<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 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
<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
button have default implicit ARIA statements of
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
roles. 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:
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!
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
- provides appropriate
- 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>
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.