In-depth guide to implementing ARIA for web accessibility

• What is ARIA and why is it important?
• ARIA Roles
  • banner
  • navigation
  • main
  • complementary
  • role
• ARIA States and Properties
  • aria-expanded
  • aria-checked
  • aria-label
  • aria-describedby
  • aria-hidden
• Implementing ARIA in HTML
• ARIA Best Practices

Accessible Rich Internet Applications (ARIA) is a set of attributes designed to improve the accessibility of web content and applications. By using ARIA, web developers can create more accessible and user-friendly websites for people with disabilities. In this comprehensive guide, we will delve into the purpose of ARIA, its implementation, and various attributes. We will also provide real-life examples to help you understand how to enhance your website's accessibility using ARIA.

If you're interested in accessibility for the web please see our article An Introduction to Web Accessibility.

Check out the MDN article on ARIA for a preface.

¶What is ARIA and why is it important?

ARIA stands for Accessible Rich Internet Applications. It is a set of attributes that can be added to HTML elements to improve their accessibility for users with disabilities, particularly those who rely on assistive technologies such as screen readers. ARIA helps bridge the gap between web content and assistive technologies by providing additional information about the role, state, and properties of elements.

Being as clear as possible: ARIA is a set of attributes added to HTML elements that describe the element's state. In the first version of the world wide web, HTML documents were simple, with no interactivity. Now many elements are purely for aesthetics, or may be hidden until interacted with. These elements are difficult to describe for screen readers. In comes ARIA.

Web accessibility is crucial because it ensures that everyone, regardless of their abilities, can access and interact with websites and applications. Implementing ARIA can significantly enhance the experience for users with disabilities, making the web more inclusive and usable for all.

¶ARIA Roles

ARIA roles define the purpose or function of an element on a web page. They help assistive technologies like screen readers understand the purpose of each element, which in turn enables them to convey the information to users effectively. Some common ARIA roles include:

¶banner

Indicates that an element serves as a site-oriented banner, usually containing the website's logo and main navigation.

Example:

<header role="banner">
  <h1>Company Logo</h1>
  <nav>...</nav>
</header>

A banner doesn't necessarily need to be an image, as the example above shows.

¶navigation

Represents a section of the page that contains navigation links. Typically this is your nav bar, but it can also be used for footer navigation, sidebars and in-page navigation.

Example:

<nav role="navigation">
  <ul>
    <li><a href="#home">Home</a></li>
    <li><a href="#about">About</a></li>
    <li><a href="#contact">Contact</a></li>
  </ul>
</nav>

It's always best to use semantic HTML too, so in the above example the navigation is wrapped in a nav element.

¶main

Represents the main content of the document. There should only be one element with this role per page.

Example:

<main role="main">
  <h1>Page Title</h1>
  <p>Page content...</p>
</main>

Again, always use semantic HTML where possible. In this case it's main.

¶complementary

Indicates content that is related to the main content but can be considered separate, such as a sidebar or related articles section.

Example:

<aside role="complementary">
  <h2>Related Articles</h2>
  <ul>...</ul>
</aside>

Another semantic HTML usage here with aside. In this specific example we're also showing a list of related articles, which could also be used with <nav> semantic HTML element with a navigation ARIA role.

¶role

Indicates a search form or functionality within the page.

Example:

<form role="search" action="/search" method="get">
  <label for="search">Search:</label>
  <input type="search" id="search" name="q" />
  <button type="submit">Search</button>
</form>

These are just a few examples of ARIA roles. There are many more roles available to help define the structure and function of various elements on a web page.

¶ARIA States and Properties

ARIA states and properties provide additional information about an element's current condition or characteristics. They can be used to describe elements that have dynamic content or behavior, such as form controls, tabs, or collapsible sections.

It's important to remember to manipulate these attributes as their values change. An example of this, which we'll come onto shortly, is aria-expanded that describes the state of an element that can have its visibility toggled (like a drop-down menu). When the drop-down is shown you'll need to use JavaScript to update the value of aria-expanded.

In this section we will list some of the most common ARIA states and properties that you will find.

¶aria-expanded

Indicates whether an expandable element, such as a dropdown menu or collapsible panel, is currently expanded or collapsed.

Example:

<button aria-expanded="false" aria-controls="menu">Open Menu</button>
<ul id="menu" role="menu" hidden>
  ...
</ul>

Remember to update the aria-expanded value using JavaScript when updating the state of the menu.

¶aria-checked

Represents the checked state of elements such as checkboxes or radio buttons.

Example:

<input type="checkbox" id="option1" aria-checked="false">
<label for="option1">Option 1</label>

Again, remember to update this based on the state of the checkbox.

¶aria-label

Provides a human-readable label for elements that don't have an accessible name, such as icons or buttons with no text.

Example:

<button aria-label="Close Modal">X</button>

aria-label works great for screen readers. In the above example, without the aria-label a screen reader would read out something like "Button with text X", which could mean many things. With the aria-label in place the screen reader would read out "Close Modal", giving much better context.

¶aria-describedby

Associates an element with additional descriptive text, which can be read by assistive technologies to provide more context to users.

Example:

<input type="text" id="username" aria-describedby="usernameHelp">
<span id="usernameHelp">Enter your username here.</span>

¶aria-hidden

Indicates whether an element is hidden from assistive technologies, either because it's not relevant or because it's only used for visual decoration.

Example:

<span aria-hidden="true" class="icon icon-arrow">➔</span>

These are just a few examples of ARIA states and properties. There are many more available to help convey the status and characteristics of various elements on a web page.

¶Implementing ARIA in HTML

To implement ARIA in your HTML, simply add the appropriate ARIA attributes to the relevant elements. Remember that ARIA should be used as a supplement to proper semantic HTML markup, not as a replacement. Start by using correct HTML elements and attributes, and only add ARIA where needed to enhance accessibility.

Here are some general guidelines for implementing ARIA:

• Use ARIA roles to define the purpose of elements.
• Use ARIA states and properties to describe dynamic content and behavior.
• Ensure that all interactive elements have an accessible name, either through native HTML attributes (e.g., alt for images, label for form elements) or ARIA attributes (e.g., aria-label, aria-labelledby).
• Test your implementation with various assistive technologies, such as screen readers and keyboard navigation, to ensure that your ARIA markup is effective.

For ARIA states and properties you'll need to ensure you keep the value of the state up to date as the element changes state. For example, if you have an accordion element that expands and contracts to show and hide content as the user interacts with it (or automatically over time like a carousel) then you must ensure your JavaScript changes the ARIA labels accordingly. It's also important to ensure that the ARIA property's initial state is also correct and this should always be done server-side wherever possible, rather than relying on JavaScript. For example, if you're showing part of a form that has validation errors then ensure the page loads with those ARIA properties in the correct state rather than loading them and adjusting the state onload in JavaScript.

¶ARIA Best Practices

Following best practices when implementing ARIA can help ensure that your website is as accessible as possible. Here are some general tips:

• Don't overuse ARIA: Only use ARIA attributes when necessary to improve accessibility. Unnecessary use of ARIA can make your site more confusing for assistive technology users.
• Prioritize native HTML elements and attributes: Always use native HTML elements and attributes where possible, as they provide built-in accessibility support.
• Validate your ARIA markup: Use validation tools, such as the W3C ARIA Validator, to check your ARIA implementation for errors and inconsistencies.
• Test with real users: Conduct usability testing with individuals who rely on assistive technologies to gain valuable insights into the effectiveness of your ARIA implementation.
• Test with various input methods: Screen readers, keyboards, etc. Don't just test with the equipment you use.
• ALWAYS update dynamic elements: Ensure your dynamic elements that have ARIA properties update the values of those properties with state changes.

ARIA plays a crucial role in making the web more accessible for users with disabilities. By understanding and implementing ARIA attributes, roles, states, and properties in your web content, you can create a more inclusive and user-friendly experience for all visitors. Use this comprehensive guide as a reference when implementing ARIA in your projects and remember to follow best practices to ensure maximum accessibility.