ARIA Role Overrides

An explicit ARIA `role` changes the semantic role exposed to assistive technologies, but it does not automatically provide the native behavior, keyboard interaction, or state management associated with a real HTML control.

ARIA role overrides let authors replace or refine the semantic role that an element exposes in the accessibility tree. For example, `role="button"` can make a non-button element appear as a button to assistive technology, while `role="presentation"` can suppress some native semantics when its use is appropriate.

Changing a role does not transform the underlying HTML element. A `` is still a `` in the browser's interaction model: it does not automatically become focusable, respond to Enter or Space, or provide button behavior. The developer must implement any required interaction and state handling.

Native HTML elements are generally preferable when they already provide the required semantics and behavior. A real `<button>` supplies button semantics, keyboard behavior, focus participation, and browser-managed interaction without requiring an ARIA workaround.

ARIA roles also have constraints: some native semantics cannot be overridden arbitrarily, and certain roles require associated properties, states, or descendant structures. Invalid or conflicting role usage can create an accessibility tree that does not accurately represent the UI.

Key points

• An explicit `role` can change an element's exposed accessibility semantics.
• ARIA does not add native keyboard behavior, focus management, or default interaction.
• Prefer semantic HTML such as `<button>` over recreating native controls with ARIA.
• Some roles have required states, properties, or structural relationships.
• Use ARIA to improve semantics when native HTML cannot express the intended UI accurately.

Interview questions

What does `role="button"` do, and what does it not do?

It exposes the element as a button role to assistive technologies. It does not convert the underlying DOM element into a native HTML button. Focusability, keyboard activation, state handling, and other interaction behavior must be implemented when needed. When possible, I would use a real `<button>` instead.

Why shouldn't you use ARIA to recreate a native control when HTML already provides one?

Native elements provide semantics and browser behavior together, which reduces the amount of accessibility logic developers must maintain. A custom ARIA control can expose the correct role while still failing to implement focus, keyboard interaction, state changes, or other expected behavior. Using semantic HTML therefore avoids unnecessary custom behavior and reduces accessibility bugs.

Can an ARIA role override native semantics?

In some cases, an explicit ARIA role changes the semantic role exposed for an element. However, ARIA has defined constraints, and not every native semantic can be safely or meaningfully replaced. The result also depends on the element and the role being applied, so role selection should follow the ARIA specification rather than treating `role` as an unrestricted override.

How would you review a custom `div` used as a button?

I would first ask whether a native `<button>` could replace it, because that usually removes unnecessary accessibility complexity. If a custom control is genuinely required, I would verify its role, accessible name, focus behavior, keyboard activation, disabled or other applicable states, and how those states are exposed through ARIA. I would also test it with keyboard navigation and relevant assistive technologies rather than relying only on source inspection.

What is the relationship between ARIA roles and ARIA states or properties?

A role describes the type of interface object, while states and properties communicate additional characteristics about that object. Some roles require particular states or properties, and those values need to remain synchronized with the actual UI state. Assigning only the role can therefore produce incomplete or misleading semantics.