ARIA attributes validationWhat it checks and how to fix it

What it checks

Scans the rendered page for ARIA mistakes: aria-labelledby, aria-describedby and aria-controls pointing at IDs that do not exist, empty aria-label values, focusable elements inside an aria-hidden container, role values that are not valid WAI-ARIA roles, and dialogs without an accessible name. A page with no ARIA at all, or with ARIA and none of these mistakes, passes; any mistake is a warning.

Why it matters

Screen readers trust ARIA over the visible markup, so a broken reference or an invalid role leaves a control unnamed or announced as the wrong thing. A link or button inside an aria-hidden region still takes keyboard focus while being invisible to assistive technology, which strands keyboard and screen reader users. Bad ARIA is worse than no ARIA: these are WCAG failures that also expose a site to accessibility complaints.

How to fix it

Make every ARIA attribute point at something real and use only roles from the WAI-ARIA spec.

<!-- Wrong: the referenced id does not exist, the role is invented -->
<button aria-controls="menu-list" role="toggle">Menu</button>

<!-- Right -->
<button aria-controls="menu" aria-expanded="false">Menu</button>
<ul id="menu" hidden>...</ul>

Give dialogs a name, and never hide a container that still holds focusable elements:

<div role="dialog" aria-modal="true" aria-labelledby="dialog-title">
  <h2 id="dialog-title">Delete project?</h2>
</div>

<!-- When hiding off-screen content, make its contents unfocusable too -->
<div aria-hidden="true" inert>...</div>

Remove empty aria-label="" attributes (or fill them in), then re-test with axe DevTools or WAVE.