Accessibility finding
ARIA attributes contradict the element or what is on screen
Accessibility Error Severity: High
Part of the audit ARIA contradicts the element or its real state. Finding id: accessibility.ariaVsNative.
What it costs you
A screen reader announces what the attribute says, not what is on screen.
What to do
Worth checking which side is right; we assume the screen is. Bring the attribute in line with what the element is and does.
What it checks
- Role conflicts with the element
- Hidden from assistive tools but focusable
- Label points to a missing element
- Expanded or selected state out of sync
How to fix it
Keep attribute and screen in step, in one place
- For aria-hidden with focusable content: remove aria-hidden, or take the content out of the tab order while it is hidden (the hidden or inert attribute does both).
- For an id that is missing: print the element with that id, or correct the reference.
How to check: Run the scanners and the interaction script again. Then listen to the control with a screen reader before and after using it.
A real case
In WebAIM's 2026 scan of the top one million home pages, pages that used ARIA had more detected errors on average (59.1) than pages that did not (42).
Thresholds
| Name | Default | Meaning |
|---|---|---|
min_scanners | 2 | How many scanners must report the same element before it counts as a failure. |
How to verify by hand
A screen reader announcing the control before and after interaction.
What this relies on
The visual state is correct; the script forgot to update the attribute.