ARIA - General Information and Guidelines
What is ARIA?
ARIA (Accessible Rich Internet Applications) is a W3C (World Wide Web Consortium, an international organization that creates standards for the World Wide Web).
ARIA can be used to enhance accessibility when native HTML is not enough.
When used properly, ARIA can...
enhance accessibility of interactive controls
define helpful landmarks for page structure
improve keyboard accessibility and interactivity
Most HTML elements have default semantics or meaning that can be conveyed to screen reader users. When necessary, ARIA can override and change those semantics.
However, ARIA should not be used when HTML provides sufficient semantics for accessibility.
When to use ARIA
Following are some basic rules on using ARIA.
A. If you can use HTML a native HTML element or attribute, then do so.
HTML is the foundation of web accessibility. ARIA should not be used when HTML provides sufficient semantics for accessibility! When used incorrectly, ARIA can introduce significant accessibility barriers.
B. Do not change native semantics, unless you really have to.
Most HTML elements have default semantics or meaning that can be conveyed to screen reader users. When necessary, ARIA can override and change those semantics.
A <ul> element, for example, defines an unordered list. When encountered by a screen reader, it is identified as an unordered list. Screen readers also announce the number of list items, enable list item navigation, and much more. If an ARIA role is added to the <ul>—for example, —<ul role="navigation">—then the list semantics are overridden and lost. The element now becomes a navigation landmark (see below) and the accessibility benefits of the unordered list are gone. Instead, <div role="navigation"><ul>...</ul></div> provides the benefits of the navigation landmark AND the benefits of the unordered list. (Better yet, <nav><ul>...</ul></nav> is semantically equivalent without relying on ARIA at all.)
C. All interactive ARIA controls must be usable with the keyboard.
The ARIA Design Patterns define standard keyboard interactions for ARIA widgets and controls. This allows everyone to use the widget using the keyboard, and ensures that instructions provided by screen readers align with the actual functionality in the page.
D. Interactive controls must have proper semantics and cannot be hidden
Any element that is keyboard focusable (using the Tab key), must have proper semantics so that it will be identified as a link, button, form control, etc., or other element with an appropriate role value. Since role="presentation" removes semantics, it must never be applied to a focusable element.
Interactive elements must also be visible. Do not hide focused elements with CSS or with aria-hidden="true".
E. All interactive elements must have an accessible name
Text that describes an interactive control must be presented to screen reader users when the control is in focus. A button must have descriptive text (such as "Register") and a text input must have a descriptive label (such as "First Name"). The content that screen readers announce to identify a control is called its "accessible name". ARIA can also be used to define accessible names.
The three components of ARIA
The three main components of ARIA are roles, properties, and states.
Roles
Roles define what an element is or does. Most HTML elements have a default role that is presented to assistive technology. For example, <button> has a default role of "button" and <form> has a default role of "form". ARIA can define roles that are not available in HTML, and can also override the default roles of HTML elements (see Rule #2 above).
An example of an ARIA role is <form role="search">. In HTML, all forms have the same semantics. But with ARIA, you can define the semantics of a particular form as being a search form.
Default HTML roles should not be duplicated using ARIA—avoid things like <button role="button">.
Properties
ARIA properties define additional semantics not supported in standard HTML. An example is <button aria-haspopup="true">. This property extends the standard button to cause a screen reader to announce that the button, if activated, will trigger a pop-up.
States
ARIA states are attributes that define the current condition of an element. They generally change based on user interaction or some dynamic variable. An example is <input aria-invalid="true">. This property will cause a screen reader to read this input as currently being invalid (meaning it needs to be corrected), but this state value could easily be changed to false dynamically based on user input.
W3C ARIA Authoring Best Practices and Guidelines
https://www.w3.org/WAI/ARIA/apg/