Introduction
Accessible Rich Internet Applications (ARIA) play a pivotal role in this realm, ensuring that web content and applications are accessible to all, including individuals with disabilities. This blog marks the beginning of our journey into the world of ARIA, where we will explore its attributes and their impact on web accessibility.
What is ARIA?
ARIA stands for Accessible Rich Internet Applications. As a set of attributes, it enriches standard HTML by providing additional semantics that make web content and applications more accessible to people with disabilities. Developed by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C), ARIA bridges gaps in accessibility that cannot be managed with HTML alone.
ARIA works alongside HTML, complementing it, to enhance the user experience for screen readers and other assistive technologies. By defining ways to make web content and applications more accessible, ARIA plays a crucial role in building an inclusive digital world.
The Importance of ARIA for Accessibility
Web accessibility is about creating an online space that’s usable by everyone, regardless of their ability or disability. ARIA attributes specifically help people with disabilities, such as visual impairments, by providing additional context or information that’s not typically conveyed through HTML.
Compliance with web accessibility standards, like the Web Content Accessibility Guidelines (WCAG), is not only a matter of ethical responsibility but also a legal requirement in many contexts. ARIA plays a vital role in fulfilling these standards by ensuring that web applications and content are more inclusive.
Overview of ARIA Attributes
ARIA attributes can be broadly classified into three categories: roles, states, and properties.
- Roles tell assistive technology what an element is, such as a button, dialog, or slider.
- States and properties provide additional information about the element’s current condition or configuration, like `aria-expanded` to indicate if a collapsible element is currently open or closed.
This layer of information helps assistive technologies convey the purpose and functionality of elements to users, enhancing the overall accessibility of the content. All of these attributes are defined in the W3C’s WAI-ARIA 1.2 specification, and MDN’s ARIA documentation is a friendlier place to look them up.
The Five Rules of ARIA
The W3C’s Using ARIA note sets out five rules. They are the quickest way to avoid the most common ARIA mistakes, and the Authoring Practices Guide repeats the spirit of them in its Read Me First page: no ARIA is better than bad ARIA.
- First rule: use native HTML first. If an HTML element or attribute already has the semantics and behaviour you need, use it instead of re-purposing another element with ARIA.
- Second rule: do not change native semantics unless you really have to. For example, do not put
role="tab"on an<h2>; wrap the heading or use a suitable element instead. - Third rule: all interactive ARIA controls must be usable with the keyboard. If you give an element a widget role, you must also make it focusable and handle the keys users expect.
- Fourth rule: do not use
role="presentation"oraria-hidden="true"on a focusable element. Doing so leaves keyboard users focused on something a screen reader cannot see. - Fifth rule: all interactive elements must have an accessible name. A button, link or form field with no name is announced as just “button” or “edit text”.
ARIA Attributes in Practice: Six Code Examples
These are the patterns we see most often when reviewing components, shown as a broken version and a fixed version where that helps.
1. Native button vs ARIA button
<!-- Avoid: needs tabindex, Enter and Space handling to work --> <div role="button" onclick="save()">Save</div> <!-- Prefer: focusable and keyboard-operable by default --> <button type="button" onclick="save()">Save</button>
The div version announces “Save, button” but cannot be reached with Tab or activated with the keyboard unless you add all of that yourself (rules one and three).
2. A disclosure with aria-expanded
<button type="button" aria-expanded="false" aria-controls="faq-1">What is ARIA?</button> <div id="faq-1" hidden>ARIA is a set of attributes...</div>
Your script toggles aria-expanded between “true” and “false” and removes or adds hidden on the panel at the same time. See our aria-expanded guide for the full pattern.
3. aria-labelledby vs aria-label
<!-- Visible text exists: point to it --> <h2 id="billing">Billing address</h2> <section aria-labelledby="billing">...</section> <!-- No visible text: supply a name --> <button type="button" aria-label="Close dialog">×</button>
Prefer aria-labelledby when visible text already exists, so the name stays in sync with what sighted users see. Use aria-label only when there is no visible text to reference.
4. A polite live region
<div role="status"></div> <!-- later, in JavaScript --> <!-- statusEl.textContent = "3 results found"; -->
role="status" has an implicit aria-live="polite". Add the container to the page before you need it and change only its text; screen readers then announce the update when the user pauses.
5. aria-hidden on focusable content (a common bug)
<!-- Broken: the link can still receive focus --> <div aria-hidden="true"><a href="/offer">See offer</a></div> <!-- Fixed: hide it from everyone, or make it inert --> <div hidden><a href="/offer">See offer</a></div>
This breaks the fourth rule. To remove a whole region from both keyboard and screen readers, use hidden or the HTML inert attribute rather than aria-hidden.
6. Form errors with aria-invalid and aria-describedby
<label for="email">Email</label> <input id="email" type="email" aria-invalid="true" aria-describedby="email-error"> <p id="email-error">Enter an email address like name@example.com</p>
aria-invalid tells assistive technology the value failed validation, and aria-describedby makes the error text part of the field’s announcement. Set aria-invalid back to “false” (or remove it) once the value is fixed.
ARIA Attributes Reference List
Here’s a reference list of the ARIA attributes in WAI-ARIA 1.2, grouped by what they do and each briefly described. For the authoritative, complete list, see MDN’s ARIA attributes reference or the specification itself. Note that some attributes, such as aria-label, are global and work on any element even though they appear in a group below.
Widget Attributes
- aria-autocomplete: Indicates whether user input completion suggestions are provided.
- aria-checked: Indicates the checked state of a checkbox or radio button.
- aria-disabled: Indicates that the element is perceivably disabled and non-interactive.
- aria-errormessage: Identifies the element that provides an error message for an object.
- aria-expanded: Indicates whether the associated content is expanded or collapsed.
- aria-haspopup: Indicates the presence of a popup, such as a menu or dialog.
- aria-hidden: Indicates whether an element is visible to screen readers.
- aria-invalid: Indicates the entered value in an input field does not match the expected format or value.
- aria-label: Provides a text label for an element.
- aria-level: Defines the hierarchical level of an element within a structure.
- aria-modal: Indicates whether an element is a modal when displayed.
- aria-multiline: Indicates whether a textbox accepts multiple lines of input.
- aria-multiselectable: Indicates whether the user can select more than one item.
- aria-orientation: Indicates the element’s orientation (horizontal/vertical).
- aria-placeholder: Defines a short hint in an input field.
- aria-pressed: Indicates the current “pressed” state of toggle buttons.
- aria-readonly: Indicates that the element is not editable but is otherwise operable.
- aria-required: Indicates that user input is required on an element.
- aria-selected: Indicates the current “selected” state of various widgets.
- aria-sort: Indicates if items in a table or grid are sorted.
- aria-valuemax: Defines the maximum allowed value for a range widget.
- aria-valuemin: Defines the minimum allowed value for a range widget.
- aria-valuenow: Defines the current value for a range widget.
- aria-valuetext: Defines the human-readable text of aria-valuenow.
Live Region Attributes
- aria-busy: Indicates whether an element is being updated.
- aria-live: Indicates that an element will be updated, and describes the types of updates the user agents, assistive technologies, and users should expect.
- aria-relevant: Indicates what types of changes in the live region are relevant.
- aria-atomic: Indicates whether the entire region or only parts of it should be announced by screen readers when the content changes.
Drag-and-Drop Attributes (Deprecated)
- aria-dropeffect (deprecated in WAI-ARIA 1.1): Indicated what functions could be performed when a dragged object was released.
- aria-grabbed (deprecated in WAI-ARIA 1.1): Indicated the “grabbed” state of an element in a drag-and-drop operation.
Do not use these in new work; screen reader support was never reliable. Instead, give every drag-and-drop action a keyboard and single-pointer alternative, such as “Move up” and “Move down” buttons, which WCAG 2.2 also requires under 2.5.7 Dragging Movements.
Relationship Attributes
- aria-activedescendant: Identifies the currently active descendant of a composite widget.
- aria-colcount: Defines the total number of columns in a table, grid, or treegrid.
- aria-colindex: Defines an element’s column index or position with respect to the total number of columns.
- aria-colspan: Defines the number of columns spanned by a cell or gridcell within a table, grid, or treegrid.
- aria-controls: Identifies the element(s) controlled by the current element.
- aria-describedby: Points to the ID of one or more elements that describe the current element.
- aria-description: Defines a description of an object.
- aria-details: Identifies the element that provides a detailed, extended description for an object.
- aria-errormessage: Identifies the element that provides an error message for an object.
- aria-flowto: Identifies the next element in an alternate reading order of content.
- aria-labelledby: Points to the ID of one or more elements that label the current element.
- aria-owns: Indicates that an element is parent to one or more elements in the DOM hierarchy.
- aria-posinset: Defines an element’s position in a set of items.
- aria-rowcount: Defines the total number of rows in a table, grid, or treegrid.
- aria-rowindex: Defines an element’s row index or position with respect to the total number of rows.
- aria-rowspan: Defines the number of rows spanned by a cell or gridcell within a table, grid, or treegrid.
- aria-setsize: Defines the number of items in a set.
Global ARIA Attributes
These attributes apply to all HTML elements regardless of whether an ARIA role is applied:
- aria-atomic
- aria-busy
- aria-controls
- aria-current
- aria-describedby
- aria-description
- aria-details
- aria-disabled
- aria-dropeffect (deprecated)
- aria-errormessage
- aria-flowto
- aria-grabbed (deprecated)
- aria-haspopup
- aria-hidden
- aria-invalid
- aria-keyshortcuts
- aria-label
- aria-labelledby
- aria-live
- aria-owns
- aria-relevant
- aria-roledescription
Best Practices for Using ARIA
While ARIA is powerful, it should be used thoughtfully and strategically. Here are some best practices:
- Use Native HTML Elements When Possible: Often, native HTML elements provide the necessary accessibility features without additional ARIA attributes. Use ARIA only when there is no native HTML alternative.
- Don’t Change Native Semantics Unless Absolutely Necessary: Avoid using ARIA to change the standard semantics of native elements, as it can confuse screen reader users.
- Ensure Dynamic Content Accessibility: Use ARIA to make dynamic content accessible. For instance, ARIA roles can inform users of updates to content that changes dynamically.
- Test with Assistive Technologies: Regularly test your use of ARIA with screen readers and other assistive technologies to ensure that it enhances, rather than complicates, the user experience.
How ARIA Attributes Map to WCAG 4.1.2
Most ARIA problems show up in audits as failures of WCAG success criterion 4.1.2 Name, Role, Value. It requires that every user interface component exposes a name, a role and its current states and values to assistive technology, and that changes are announced. Native HTML does this automatically; ARIA is how you do it for custom components. In practice: roles supply the “role”, aria-label and aria-labelledby supply the “name”, and states such as aria-expanded, aria-checked and aria-valuenow supply the “value”. W3C’s Understanding 4.1.2 explains the requirement, and our WCAG 4.1.2 guide shows how to test for it.
To check your ARIA in practice, combine keyboard testing, screen reader testing and an automated checker, which reliably flags invalid attributes and missing names. If you are new to ARIA, start with our ARIA essentials quick-start guide.
Conclusion
ARIA attributes are indispensable for creating an inclusive and accessible digital environment. This guide has covered the five rules of ARIA, six practical patterns and a reference list of attributes. For deeper dives into individual attributes, see our guides to aria-label, aria-labelledby and aria-expanded linked above.
Related Resources
Work With Us
If your team is still working through ARIA implementation, our accessibility remediation service can audit and fix your ARIA usage directly, and our training workshops can get your developers up to speed.
Get a free accessibility needs assessment — no commitment required.
