What it is
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.
Who it affects & why it matters
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.
How to fix it
- Find every element that carries a role attribute and check the value against the list of valid WAI-ARIA roles.
- For each invalid value, decide whether it is a typo (role="buton" should be role="button") or an invented name with no real equivalent.
- 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".
- Only keep an explicit role when no native element fits, and make sure it is a valid role name spelled exactly as defined.
- 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>How AccessKnight detects this
AccessKnight selects every element that has a role attribute, normalizes the value (trimmed and lowercased), and checks each token against the full set of valid WAI-ARIA role names — including the newer ARIA 1.2 and 1.3 roles such as meter, code, and time, plus the doc-* (digital publishing) and graphics-* extension vocabularies. Because role accepts a space-separated fallback list where the first valid token wins, an element is flagged only when none of its tokens is a valid role, 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.