How to fix: Invalid ARIA roles

ARIA roles tell assistive technology what an element is, a button, a dialog, a tab, when the markup alone does not make that clear. WCAG Success Criterion 4.1.2 Name, Role, Value requires that the role of every user-interface component be exposed correctly. The role attribute only does this when its value is one of the defined WAI-ARIA role names; anything else is meaningless to the browser's accessibility layer.

Invalid roles are usually typos or invented names: role="buton", role="navigaton", role="dropdown", or a made-up role that sounds plausible but is not in the spec. When the browser encounters a role it does not recognize, it ignores it, so the element falls back to its native role, which may be nothing at all. A <div role="buton"> is announced as a generic group, not a button, and the user has no idea it is interactive.

There is a guiding principle here: no ARIA is better than bad ARIA. ARIA overrides native semantics, so a wrong or misspelled role actively misleads assistive technology rather than helping it. The strongest fix is almost always to use the native element, <button>, <nav>, <ul>, that carries the correct role automatically, and reserve a valid role attribute for the cases where no native element fits.

Screen reader users are affected directly. They depend on the announced role to know whether an element is a button to press, a link to follow, or a checkbox to toggle. An invalid role means the element is announced incorrectly or as a plain container, so its purpose and how to operate it are lost.

It also affects users of voice-control and other assistive technologies that target elements by role, and it can break expected keyboard behavior, since a control announced as the wrong thing sets the wrong expectations. The result is confusion and failed interactions on exactly the components meant to be interactive.

An invalid ARIA role is a Level A failure under SC 4.1.2, the most basic conformance tier, and WCAG 2.1 Level AA (which includes all Level A criteria) is the benchmark U.S. courts apply to ADA Title III claims. Broken roles are easy for an automated tool, and therefore a plaintiff's tooling, to detect at scale, which is why they surface in audits and demand letters.

The fix is usually trivial, correct a misspelling or drop the attribute in favor of a native element, yet the impact is high because the affected elements are interactive controls users need to reach. With web accessibility lawsuits rising and disproportionately targeting businesses under $25 million in revenue, clearing a documented Level A role error removes an obvious finding cheaply.

1. Find every element that carries a role attribute and check the value against the list of valid WAI-ARIA roles.
2. For each invalid value, decide whether it is a typo (role="buton" should be role="button") or an invented name with no real equivalent.
3. Prefer the native HTML element that has the role built in: use <button> instead of role="button", <nav> instead of role="navigation", <ul>/<li> instead of role="list".
4. Only keep an explicit role when no native element fits, and make sure it is a valid role name spelled exactly as defined.
5. Remember that no ARIA is better than bad ARIA: delete a role you cannot make valid rather than leaving it broken, then re-scan.

<div role="buton" onclick="submit()">Save</div>
<div role="navigaton">...</div>

<button onclick="submit()">Save</button>
<nav>...</nav>

AccessKnight selects every element that has a role attribute, normalizes the value (trimmed and lowercased), and compares it against its built-in set of valid WAI-ARIA role names. Any element whose role is not in that set is flagged, with the offending value named in the fix message so you can spot the typo or invented role immediately. Correcting the spelling, replacing the value with a valid role, or removing the attribute in favor of a native element all clear the finding.