ARIA Roles

ARIA roles communicate the semantic purpose of elements to assistive technologies. They can supplement native HTML semantics when necessary, but native HTML elements should generally be preferred when they already provide the required semantics and behavior.

ARIA roles describe what an interface element represents, such as a `button`, `dialog`, `tab`, or `navigation` landmark. Assistive technologies can use this semantic information to present the element appropriately to users.

Roles are commonly assigned with the `role` attribute, for example `<div role="button">`. However, adding a role does not automatically provide the keyboard behavior, focus management, or interaction that users expect from the corresponding native element.

Native HTML elements usually provide both semantics and built-in browser behavior. For example, `<button>` is preferable to `<div role="button">` for an interactive button because the native element already has appropriate semantics, keyboard interaction, and focus behavior.

ARIA should therefore be used to fill semantic gaps or describe custom widgets when native HTML cannot express the required meaning. A role can also be combined with ARIA states and properties such as `aria-expanded`, `aria-selected`, or `aria-label` when those attributes accurately describe the current interface state.

Good ARIA usage requires keeping the accessibility tree consistent with the actual interface. If a custom element has a widget role, the implementation must also provide the interaction model associated with that widget and keep relevant states synchronized.

Key points

• ARIA roles communicate an element's semantic purpose to assistive technologies.
• Prefer native HTML elements when they already provide the required semantics and behavior.
• A `role` attribute does not automatically add keyboard interaction or focus management.
• ARIA roles can be used for custom widgets and semantic gaps in native HTML.
• ARIA states and properties should accurately reflect the element's current UI state.

Interview questions

What is an ARIA role?

An ARIA role communicates the semantic type or purpose of an element to assistive technologies. Examples include `button`, `dialog`, `navigation`, and `tab`. This information helps accessibility tools interpret the interface. A role does not by itself implement the expected keyboard or interaction behavior.

Why is `<button>` generally preferable to `<div role="button">`?

A native `<button>` already has the semantics and browser interaction expected of a button. A `div` with `role="button"` mainly changes how its semantics are exposed to accessibility APIs. Developers would still need to implement appropriate keyboard handling, focus behavior, and activation behavior for the custom element. Using the native element therefore avoids unnecessary accessibility work.

When should a frontend engineer use ARIA roles?

ARIA roles are useful when native HTML cannot adequately express the intended semantics, particularly for custom widgets and application-specific interface structures. Before adding ARIA, I would check whether an appropriate native element exists. If a custom role is necessary, I would also implement its required interaction pattern and keep its accessibility state synchronized with the UI. ARIA should enhance the semantic representation rather than substitute for correct HTML and behavior.

What is the difference between an ARIA role and `aria-expanded`?

A role identifies the semantic type of an element, such as `button` or `tab`. `aria-expanded` is a state that communicates whether controlled content is currently expanded or collapsed. They can be used together when appropriate, such as a button that opens a menu. The state should change when the actual UI state changes.

What can go wrong when ARIA is applied incorrectly?

Incorrect ARIA can expose misleading information to assistive technologies, causing the accessibility tree to disagree with the visible interface. A role can also create an expectation for keyboard and interaction behavior that the implementation does not satisfy. Incorrect states can make controls appear expanded, selected, or disabled when they are not. The safest approach is to use native semantics where possible and verify custom ARIA implementations with accessibility testing.