Valid ARIA Roles

Why It Matters

• Roles drive how screen readers announce elements. A role="button" tells the screen reader "this is a button" and enables the user to activate it with Enter or Space. An invalid role means the element might be announced as generic text with no interaction cues.
• Keyboard behavior follows roles. Many ARIA roles come with expected keyboard patterns — arrow keys for menus, Tab for tab panels. An incorrect role can trigger the wrong keyboard behavior or no keyboard behavior at all.
• Invalid roles are silently ignored. If you mistype a role (like role="buttn"), the browser simply ignores it. There is no error, no warning — the element just behaves as if no role was set.
• Misapplied roles create confusion. Giving a block of static text role="button" tells screen reader users they can click it — but nothing happens when they try. That breaks trust.

How to Get It Right

1. Use native HTML elements first. Before reaching for a role, ask if a native element does the job. A <button> is better than <div role="button"> because it comes with built-in keyboard handling, focus management, and form submission support.
2. Reference the specification. The WAI-ARIA spec lists every valid role, along with its required attributes and expected behavior. If a role is not in the spec, it does not exist and will be ignored.
3. Match roles to element behavior. Only apply a role when the element actually behaves like that role. If something has role="link", it must navigate somewhere when activated. If it has role="checkbox", it must be toggleable.
4. Do not override native semantics unnecessarily. Adding role="presentation" to a table strips its table semantics from the accessibility tree. That is useful for layout tables but destructive for data tables.
5. Validate with accessibility tools. Browser developer tools and automated checkers will flag invalid or unrecognized role values, making them easy to catch before they reach production.

Common Mistakes

• Misspelling role names. role="navagation" instead of role="navigation" is silently ignored. Always copy role names from the spec rather than typing them from memory.
• Making up custom roles. role="card" or role="hero" do not exist in the specification. Browsers do not know what to do with them and will treat the element as generic.
• Using abstract roles. Roles like widget, landmark, and structure are abstract base types in the spec. They cannot be used directly in markup — only their concrete subtypes can.
• Adding roles to elements that already have them. Putting role="button" on a <button> element is redundant. It will not break anything, but it clutters the code and suggests a misunderstanding of how semantics work.