What is ARIA?

ARIA (Accessible Rich Internet Applications), is a specification from the W3C and created to improve accessibility of applications by providing extra information to assistive technologies, such as screen readers, via attributes which could be added to HTML. Out of the box, screen readers will interpret HTML that conveys accessibility mapping information (e.g. a button but not a div). However, ARIA attributes can provide screen reader users with additional context and greater interactivity with content to correct misused HTML, or to convey information not available in HTML alone.

ARIA, by design, 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 is also beholden to its host language and must adhere to the rules of what elements it can, and cannot, be used on.

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 to progressively enhance markup as necessary. The properties and states 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 six 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

Edit on GitHub