Skip to main content

WAI-ARIA: Roles, States, and Landmarks for Accessible Web Applications

The Accessible Rich Internet Applications specification (WAI-ARIA, commonly called ARIA) is a technical specification from the W3C that allows developers to enhance the accessibility of web content when native HTML semantics are insufficient. ARIA provides attributes that communicate roles, states, and properties of user interface elements to assistive technologies.

ARIA is essential for building accessible custom widgets, dynamic content, and rich internet applications. However, it must be used carefully — incorrect ARIA can make content less accessible than no ARIA at all.

The Five Rules of ARIA

Before using any ARIA, internalize these rules established by the W3C:

Rule 1: Use native HTML first. If you can use a native HTML element or attribute with the semantics and behavior you need, use it instead of adding ARIA. A <button> is always better than <div role="button">.

Rule 2: Do not change native semantics unnecessarily. Do not override the implicit role of an HTML element with a conflicting ARIA role unless it is truly necessary.

Rule 3: All interactive ARIA controls must be keyboard operable. If you add role="button" to an element, you must also implement keyboard handlers for Enter and Space activation. ARIA adds semantics only — it does not add behavior.

Rule 4: Do not use role="presentation" or aria-hidden="true" on a focusable element. These attributes tell assistive technologies to ignore the element, but if the element can receive keyboard focus, it creates a confusing experience where the user can focus on something that has been hidden from their screen reader.

Rule 5: All interactive elements must have an accessible name. Every button, link, input, and interactive widget needs a name that assistive technologies can announce. This can come from the element's text content, a <label>, aria-label, or aria-labelledby.

Landmark Roles

ARIA landmark roles define the major structural regions of a page. Screen reader users can navigate directly to these landmarks, providing an efficient alternative to scanning through all content sequentially.

banner — The site-wide header, typically containing the logo and primary navigation. Equivalent HTML: <header> (when a direct child of <body>).

navigation — A collection of links for navigating the site or page. Equivalent HTML: <nav>. If multiple navigation landmarks exist on a page, each should have a unique label via aria-label (e.g., "Main navigation" and "Footer navigation").

main — The primary content of the page. There should be only one main landmark per page. Equivalent HTML: <main>.

complementary — Supporting content that is related to but separate from the main content. Equivalent HTML: <aside>.

contentinfo — Footer information such as copyright, privacy links, and legal notices. Equivalent HTML: <footer> (when a direct child of <body>).

search — A search facility. Equivalent HTML: <search> (recently introduced in HTML).

region — A generic landmark for content that is important enough to warrant direct navigation but does not fit other landmark roles. Equivalent HTML: <section> with an accessible name.

form — A form landmark. Equivalent HTML: <form> with an accessible name.

Best practice is to include all page content within landmark regions so that screen reader users do not miss any content when navigating by landmarks.

Widget Roles

ARIA defines roles for interactive widgets that go beyond native HTML capabilities:

dialog and alertdialog — For modal and alert dialogs. Must trap focus and be dismissible.

tablist, tab, and tabpanel — For tabbed interfaces. Use aria-selected on tabs and aria-labelledby on panels.

menu, menubar, menuitem — For application-style menus (not navigation menus). Use with caution — these roles imply specific keyboard interaction patterns.

combobox — For autocomplete and select-with-search patterns. Involves coordinating aria-expanded, aria-activedescendant, and a listbox.

slider — For range input widgets. Requires aria-valuemin, aria-valuemax, aria-valuenow, and aria-valuetext.

tree and treeitem — For hierarchical tree views.

ARIA States and Properties

States and properties communicate the current condition of interactive elements:

aria-expanded — Indicates whether a collapsible section, dropdown, or accordion panel is currently expanded ("true") or collapsed ("false").

aria-selected — Indicates the current selection state in tabs, list items, or grid cells.

aria-checked — Indicates the checked state of checkboxes and radio buttons. Can be "true", "false", or "mixed" for tri-state checkboxes.

aria-disabled — Indicates that an element is visible but not interactive.

aria-hidden — Removes an element from the accessibility tree entirely. Use carefully — it makes content invisible to screen readers.

aria-live — Defines a live region whose content changes should be announced by screen readers. "polite" announces at the next pause in user activity. "assertive" announces immediately, interrupting any current speech.

aria-label — Provides an accessible name as a text string when no visible label exists.

aria-labelledby — Associates an element with one or more elements whose text provides the accessible name. Preferred over aria-label when a visible label exists.

aria-describedby — Associates an element with supplementary descriptive text, such as help text or error messages.

Live Regions

Live regions are areas of a page that update dynamically, where changes should be announced to screen reader users without requiring them to navigate to the updated area. Common use cases include search result counts, form validation messages, chat messages, stock tickers, and notifications.

Set aria-live="polite" for updates that are important but not urgent — the screen reader will announce them at the next convenient pause. Set aria-live="assertive" for urgent updates that should be announced immediately, such as error alerts. Use assertive sparingly, as it interrupts whatever the user is currently doing.

The role="status" attribute implicitly creates a polite live region. The role="alert" attribute creates an assertive live region. These roles are often simpler to use than explicitly setting aria-live.

Er vefsíðan þín aðgengileg?

Skannaðu vefsíðuna þína ókeypis og fáðu WCAG-einkunn þína á nokkrum mínútum.

Skannaðu síðuna þína ókeypis