ARIA checker
Finds invalid roles and attributes, controls with no accessible name and ARIA that hides content people need.
What this check looks for
The audit runs this check with every other check, on the page as the browser renders it.
- Controls with no name
- Buttons, menus and toggles that screen readers announce only by their role.
- Invalid roles and attributes
- Misspelled roles, attributes that don't belong on an element and required attributes that are missing.
- Hidden but focusable
- aria-hidden on elements that keyboard users can still tab to.
- Broken references
- aria-labelledby and aria-controls pointing at IDs that don't exist or appear twice.
What a failure looks like
A close button in a dialog shows only an X icon. Screen readers announce "button" with no name.
<!-- Broken: an icon with no accessible name -->
<button class="dialog__close"><svg viewBox="0 0 24 24">...</svg></button><!-- Fixed: the button has a name, the icon is hidden -->
<button class="dialog__close" aria-label="Close">
<svg viewBox="0 0 24 24" aria-hidden="true">...</svg>
</button>How it shows in AccessGuard
Each finding names the WCAG criterion, explains the problem in plain words and shows the element that fails, so a developer can find it on the page.
WCAG criteria
Findings from this check name one of these criteria. How much of each the audit can decide on its own:
| Criterion | Level | Automation |
|---|---|---|
| 4.1.2 Name, Role, Value Missing names, invalid roles and broken ARIA are found automatically. Whether custom widgets behave correctly needs a person. | A | Partly automated |
What still needs a person
No automated tool can confirm these. AccessGuard marks related findings as Review, so nobody mistakes them for a pass.
- Whether custom widgets such as tabs, menus and comboboxes behave as their role promises.
- Whether state changes like expanded and selected are announced at the right time.
- Whether a native HTML element would do the job without ARIA.
Questions
Does adding ARIA make a site more accessible?
Only when it is correct. Wrong roles and attributes can make a page worse for screen reader users than no ARIA at all. Native HTML elements are the safest choice.
What does WCAG 4.1.2 require?
Every control needs a name, a role and a state that assistive technology can read, and changes to them must be exposed.
Why do duplicate IDs matter?
Labels and ARIA references point at IDs. When an ID appears twice, the reference can land on the wrong element and the control loses its name.
Related checks and guides
- Form labels checker
Finds inputs without labels, placeholders used as the only label, and fields that don't say what they collect.
- Keyboard and focus checker
Finds controls people can't reach by keyboard, focus styles that were removed, and focused elements hidden behind sticky headers.
- Headings and landmarks checker
Checks that pages have a clear heading outline, a main landmark and a way to skip repeated navigation.
- ARIA Attributes Explained: Roles, States & Properties Guide
Guide
- Accessible Combobox Pattern: ARIA + Keyboard Guide
Guide
Check a client page for aria issues
The free audit runs this check and every other one. Results in about a minute.