ARIA Role

An ARIA role tells assistive technologies what an interface element is: a button, tab, alert, navigation region. Semantic HTML tags already carry an implicit role. The role attribute is only necessary for components absent from native HTML, such as tabs or dropdown menus.

Your HTML already contains roles. A <button> is announced as "button". A <nav> is announced as "navigation". The browser builds an accessibility tree from the DOM, and each semantic tag carries an implicit role within it. The role attribute only comes into play when this automatic mechanism is insufficient.

#What the browser does for you

Each semantic HTML element is exposed in the accessibility tree with a role that assistive technologies consume directly:

A <div> or <span> has no role: it returns null in the accessibility tree (MDN Web Docs). The screen reader ignores it or announces its text content without context.

When you build a component that doesn't exist in native HTML, the role attribute declares its nature:

<div role="tablist">
  <button role="tab" aria-selected="true">Details</button>
  <button role="tab" aria-selected="false">Reviews</button>
</div>
<div role="tabpanel">Content of the selected tab</div>

The WAI-ARIA 1.2 specification defines approximately 80 roles. The W3C APG design patterns document for each one the keyboard behavior, required states, and expected structure.

#Assigning a role is signing a contract

The first rule of the ARIA in HTML specification: if a native HTML element with the intended semantics exists, use it. No role.

A <div role="button"> announces "button" to the screen reader. But it does not receive keyboard focus. The Enter and Space keys trigger nothing. Form submission doesn't work. The screen reader promises a button. The keyboard delivers nothing. That's an accessibility lie.

The WebAIM Million report confirms this at scale: pages using ARIA contain on average 41% more accessibility errors than pages without ARIA.

Three pitfalls come up constantly:

• Role without keyboard. role="button" without keydown handling for Enter and Space.
• Redundancy. <nav role="navigation"> doubles information that the browser already provides natively.
• Role changed mid-render. The specification forbids changing a role after rendering. A tab remains a tab.

#In summary

Semantic HTML first: your tags already carry the roles screen readers need. The role attribute is only for components absent from native HTML. And every role assigned requires its keyboard behavior and synchronized ARIA states. The W3C APG patterns are your reference.