Most developers are familiar with the standard markup language of our modernweb, HyperText Markup Language (HTML).However, you may be less familiar withAccessible Rich Internet Applications (ARIA)(formally called WAI-ARIA): what it is, how it is used, and when—and when not—to use it.
HTML and ARIA play important roles in making digital products accessible,especially when it comes to assistive technology (AT) such as screen readers.Both are used to convert content into an alternate format, such as Braille orText-to-Speech (TTS).
Let's review a short history of ARIA, why it is important, and when and howbest to use it.
Introduction to ARIA
ARIA was first developed in 2008 by theWeb Accessibility Initiative (WAI) group—asubset of the overarching World Wide Web Consortium (W3C), which governs andregulates the internet.
ARIA is not a true programming language but a set of attributes you can add toHTML elements to increase their accessibility. These attributes communicaterole, state, and property to assistive technologies via accessibility APIsfound in modern browsers. This communication happens through the accessibilitytree.
"WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make web content and web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with HTML, JavaScript, and related technologies."
The WAI group
The accessibility tree
ARIA modifies incorrect or incomplete code to create a better experience forthose using AT by changing, exposing, and augmenting parts of the accessibilitytree.
The accessibility tree is created by the browser and based on the standardDocument Object Model (DOM) tree. Like the DOM tree, the accessibility treecontains objects representing all the markup elements, attributes, and textnodes. The accessibility tree is also used by platform-specific accessibilityAPIs to provide a representation that assistive technologies can understand.
ARIA on its own doesn't change an element's functionality or visual appearance.That means only AT users will notice differences between a digital product withARIA and one without it. That also means that developers alone are responsiblefor making the appropriate code and styling changes to make an element asaccessible as possible.
The three main features of ARIA are roles, properties, and states/values.
Roles define what an element is or does on the page or app.
<div role="button">Self-destruct</div>Properties express characteristics or relationships to an object.
<div role="button" aria-describedby="more-info">Self-destruct</div><div id="more-info">This page will self-destruct in 10 seconds.</div>States/values define the current conditions or data values associated with the element.
<div role="button" aria-describedby="more-info" aria-pressed="false"> Self-destruct</div><div id="more-info"> This page will self-destruct in 10 seconds.</div>While all three elements of ARIA can be used in one line of code, it's notrequired. Instead, layer ARIA roles, properties, and states/values until you'veaccomplished your final accessibility goal. Correctly incorporating ARIA intoyour code base ensures that AT users will have all the information they need touse your website, app, or other digital product successfully and equitably.
Recently, Chrome DevTools has created a way tosee the full accessibility treemaking it easier for developers to understand how their code impactsaccessibility.
When to use ARIA
In 2014, the W3C officially published the HTML5 recommendation. With it camesome big changes, including the addition of landmark elements such as <main>,<header>, <footer>, <aside>, <nav>, and attributes like hidden andrequired. With these new HTML5 elements and attributes, coupled withincreased browser support, certain parts of ARIA are now less critical.
When the browser supports an HTML tag with an implicit role with an ARIAequivalent, there is usually no need to add ARIA to the element. However, ARIAstill includes many roles, states, and properties that aren't available in anyversion of HTML. Those attributes remain useful for now.
This brings us to the ultimate question: When should you use ARIA? Thankfullythe WAI group has developed thefive rules of ARIA to help you decide howto make elements accessible.
Rule 1: Don't use ARIA
Yes, you read that right. Adding ARIA to an element does not inherently make itmore accessible. The WebAIM Million annual accessibility reportfound that home pages with ARIApresent averaged 70% more detected errors than those without ARIA, primarilydue to the improper implementation of the ARIA attributes.
There are exceptions to this rule. ARIA is required when an HTML elementdoesn't have accessibility support. This could be because the design doesn'tallow for a specific HTML element or the wanted feature/behavior isn'tavailable in HTML. However, these situations should be scarce.
Don't
<a role="button">Submit</a>
Do
<button>Submit</button>
When in doubt, use semantic HTML elements.
Rule 2: Don't add (unnecessary) ARIA to HTML
In most circ*mstances, HTML elements work well out of the box and do not need additional ARIA added to them. In fact, developers using ARIA often have to add additional code to make the elements functional in the case of interactive elements.
Don't
<h2 role="tab">Heading tab</h2>
Do
<div role="tab"><h2>Heading tab</h2></div>
Do less work and have better-performing code when you use HTML elements asintended.
Rule 3: Always support keyboard navigation
All interactive (not disabled) ARIA controls must be keyboard accessible. Youcan add tabindex= "0" to any element that needs a focus that doesn't normallyreceive keyboard focus. Avoid using tab indexes with positiveintegerswhenever possible to prevent potential keyboard focus order issues.
Don't
<span role="button" tabindex="1">Submit</span>
Do
<span role="button" tabindex="0">Submit</span>
Of course, if you can, use a real <button> element in this case.
Rule 4: Don't hide focusable elements
Don't add role= "presentation" or aria-hidden= "true" to elements that needto have focus—including elements with a tabindex= "0". When you addthese roles/states to elements, it sends a message to the AT that theseelements are not important and to skip over them. This can lead to confusion ordisrupt users attempting to interact with an element.
Don't
<div aria-hidden="true"><button>Submit</button></div>
Do
<div><button>Submit</button></div>
Rule 5: Use accessible names for interactive elements
The purpose of an interactive element needs to be conveyed to a user beforethey know how to interact with it. Ensure that all elements have anaccessible name for people using ATdevices.
Accessible names can be the content surrounded by an element (in the case of an<a>), alternative text, or a label.
For each of the following code samples, the accessible name is "Red leatherboots."
<!-- A plain link with text between the link tags. --><a href="shoes.html">Red leather boots</a><!-- A linked image, where the image has alt text. --><a href="shoes.html"><img src="shoes.png" alt="Red leather boots"></a><!-- A checkbox input with a label. --><input type="checkbox" id="shoes"><label for="shoes">Red leather boots</label>There are many ways to check an element's accessible name, including inspecting the accessibility tree using Chrome DevTools or testing it with a screen reader.
ARIA in HTML
While using HTML elements on their own is best practice, ARIA elements can beadded in certain situations. For example, you may pair ARIA with HTML inpatterns that need a higher level of AT support because of environmentalconstraints or as a fall-back method for HTML elements that aren't fullysupported by all browsers.
Of course, there are recommendations for implementing ARIA inHTML. Most importantly: don't overridedefault HTML roles, reduce redundancy, and be aware of unintended side effects.
Let's look at some examples.
Don't
<a role="heading">Read more</a>
Assigned the wrong role.
Do
<a aria-label="Read more about some awesome article title">Read More</a>
Correct role and an extra link description.
Don't
<ul role="list">...</ul>
Redundant role.
Do
<ul>...</ul>
Redundancy removed
Don't
<details> <summary role="button">more information</summary> ...</details>
Potential side effects.
Do
<details> <summary>more information</summary> ...</details>
No unintended side effects.
Complexities of ARIA
ARIA is complex, and you should always use caution when using it. While thecode examples in this lesson are fairly straightforward, creating accessiblecustom patterns can quickly get complicated.
There are many things to pay attention to, including but not limited to:keyboard interactions, touch interfaces, AT/browser support, translation needs,environmental constraints, legacy code, and user preferences. A little bit ofcoding knowledge can be detrimental—or just plain annoying—if usedincorrectly. Remember to keep your code simple.
Those warnings aside, digital accessibility is not an all-or-nothingsituation—it's a spectrum that allows for some gray areas like this.Multiple coding solutions can be seen as "correct," depending on the situation.What is important is that you keep learning, testing, and trying to make ourdigital world more open to all.
Check your understanding
Test your knowledge of ARIA and HTML
Which of the following is the best practice for building an accessible button?
<div id="saveChanges" aria-role="button" aria-pressed="false" tabindex="0">Go to shop</div>
Not quite. ARIA shouldn't be used when a semantic HTML element is available.
<a id="saveChanges" aria-label="Some awesome article title">Go to shop</a>
Not quite. While you could style this link like a button with CSS, it's not the best practice.
<button id="saveChanges" type="button">Go to shop</button>
Great job! Use the correct semantic HTML as well as the type to create a button.
