What is ARIA?

ARIA (Assistive Rich Internet Applications), is a spec from the W3C and created to improve accessibility of applications by providing extra information to screen readers via HTML attributes. Out of the box, screen readers work with regular HTML, but adding ARIA can provide screen reader users with more context and greater interactivity with content.

ARIA has no effect on how elements are displayed or behave in browsers. It does not add new functionality and is meant to act only as an extra descriptive layer for screen readers.

ARIA Attributes

ARIA attributes are predefined in the spec and are divided into two categories, roles and states & properties. Both can be added directly in the markup or via JavaScript and should be updated as needed based on user interactions. There are rules behind which elements may receive types of ARIA attributes, as well as design guidelines for how and when these should be updated in common interactive widgets.

ARIA Roles

An ARIA role is added via a role="<ROLE TYPE>" attribute and does not change for an element once set. There are four categories of ARIA roles.

States and Properties

ARIA states and properties are often used to support ARIA roles that exist on a page. Properties often describe relationships with other elements and for the most part, do not change once they’re set. States are more dynamic and are typically updated with JavaScript as a user interacts with a page. It’s common to refer to states and properties collectively as just ARIA attributes. Screen readers are notified when attributes change and can announce these changes to users after an interaction takes place.

When to use ARIA

Native HTML semantics should still be used whenever possible, but ARIA is useful when certain design patterns or interactions make it impossible to do so. For example, a complex tabbed-interface has no semantic equivalent with HTML, but a role="tablist" and its related attributes can be added to provide this detail to screen readers. ARIA is also useful to describe newer HTML elements that may not yet have full cross-browser support or be understood by screen readers.

To create accessible applications, basic principles of semantic HTML, keyboard support, and color contrast should still be the primary focus of developers. ARIA may be used to “fill in the blanks” where web page information isn’t understood or available to a screen reader via HTML alone.

ARIA Examples

    <nav role="navigation">
      <ul>
        <li>
          <a href="/">Home</a>
        </li>
        <li>
          <a href="/contact">Contact Page</a>
        </li>
      </ul>
    </nav>
<section aria-labelledby="KittensHeader">
  <h2 id="KittensHeader">All Abbout Kittens</h2>
  <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p>
</section>

The <section> element includes the ARIA property aria-labelledby which lists the ID of the section title. Screen readers will announce this title when they reach the <section> element, giving users a sense of the content contained in this portion.

<ul role="tablist">
  <li>
    <a href="#first-tab" role="tab" aria-selected="true" aria-controls="first-tab">Panel 1</a>
  </li>
  <li>
    <a href="#second-tab" role="tab" aria-selected="false" aria-controls="second-tab">Panel 2</a>
  </li>
</ul>
<div id="first-tab" role="tabpanel"></div>
<div id="second-tab" role="tabpanel"></div>

Each element has an ARIA role and attributes to create a complete tab widget. The relationship between a tab link and tab panel is now available to screen readers.

Edit on GitHub