Why it matters
The first rule of ARIA is not to use it when HTML will do, because wrong ARIA is worse than none: a role="menu" on a site navigation makes screen readers switch into application mode and expect arrow keys, an aria-labeledby typo silently does nothing, and a role="tab" outside a tablist breaks the widget. Linters catch some of this in JSX; browsers say nothing at all.
This validator checks pasted HTML against the WAI-ARIA 1.2 role model and the ARIA in HTML rules. For every element it resolves the role (taking the first valid token in a fallback list), checks each aria- attribute exists, is allowed on that role and has a valid value, that ID references point at real elements, that required attributes are present unless HTML already provides them, that widgets contain the children they must and sit inside the parent they must, that the role is allowed on that element, and that nothing focusable is hidden with aria-hidden. Each finding has a rule id, the line it's on and a concrete fix, and the source is shown with problem lines marked.
How it works
- InputHTML with roles and aria- attributes
- In your browserChecked against ARIA 1.2 and ARIA in HTML
- OutputProblems by line with fixes
Where it fits in a designer's workflow
- Plan
- Design
- Build
- Test
- Launch
By the numbers
Show the numbers as a table
| Rule | Problems |
|---|---|
| required-children | 3 |
| required-parent | 3 |
| attr-required | 2 |
| attr-value | 2 |
| idref-missing | 2 |
| role-redundant | 2 |
| widget-focus | 2 |
| aria-in-html | 1 |
| attr-invalid | 1 |
| attr-unsupported | 1 |
| hidden-focus | 1 |
| name-prohibited | 1 |
| name-required | 1 |
| role-abstract | 1 |
| role-invalid | 1 |
How to use it
- Paste the HTML.
- Work through the errors first, then the warnings.
- Use the marked source to find each line.
- Check the structure table for the widgets you're building.
FAQ
Is ARIA ever required?
Only when HTML has no element for what you're building, like tabs, a tree or a combobox with custom behaviour. For buttons, links, checkboxes and landmarks, the native elements are better and need no ARIA.
What's a required owned element?
Some roles only work with specific children: a tablist must contain tabs, a list must contain listitems, a listbox must contain options. Screen readers count and navigate those children, so missing or extra ones break the widget.
Why is role="button" on a <button> flagged?
It's redundant: the element already has that role. It does no harm, but it's noise, and the habit leads to conflicting roles.
Why do some attributes say 'not supported'?
Each role supports a fixed set of states. aria-checked on a button, for example, is ignored; a toggle button uses aria-pressed instead.
Does it check keyboard behaviour?
Only that widget roles on non-focusable elements are flagged. Whether arrow keys and Enter work needs a running page; the ARIA Authoring Practices Guide lists the keys each widget needs.
