ARIA Validator
Catch ARIA mistakes that break screen-reader output. The validator checks every role against WAI-ARIA 1.2 (including abstract roles that must not be used), every aria-* attribute name and value, required states such as aria-checked on checkboxes, required parent roles such as tab inside tablist, ID references in aria-labelledby and aria-describedby, focusable content hidden with aria-hidden, names on elements that cannot be named, presentational focusable elements and redundant roles.
- Encrypted connection
- No sign-up
- Free to use
How to use ARIA Validator
- Enter a URL or paste HTML.
- Click Validate ARIA.
- Fix failed rules first.
- Prefer native HTML elements where possible.
ARIA Validator features
Roles
Valid, abstract and redundant roles.
Attributes
Names and allowed values.
Required states
aria-checked, aria-valuenow, aria-expanded…
Context
Required parent roles.
References
Missing ids.
Paste mode
Analysed in your browser.
When to use ARIA Validator
- Custom widget development.
- Design system audits.
- Fixing screen-reader bugs.
- Accessibility reviews.
ARIA Validator FAQ
What is the first rule of ARIA?
Do not use ARIA if a native HTML element or attribute gives you the semantics and behaviour you need.
Why is aria-hidden on a link a problem?
Keyboard users can still focus it, but screen readers say nothing.
Does it see ARIA added by JavaScript?
No, only the HTML delivered by the server or pasted.
No ARIA is better than bad ARIA
Incorrect ARIA overrides correct HTML semantics and can make a working page unusable for screen-reader users.
Typical examples are role="button" on a div that cannot be focused, aria-labeledby spelled with one l, aria-hidden="true" on a container that still holds links, and tabs that are not inside a tablist. Each of these is invisible to sighted users and to most automated page-speed or SEO tools, which is why a dedicated ARIA check is worth running on every custom widget.
How it works: a URL is fetched once by our server through a guarded client that only connects to public addresses; the HTML (and, where needed, the stylesheets) is then analysed in your browser as inert text – scripts on the page never run. Pasted HTML is analysed without any request. Nothing is stored.
Automated testing has limits: tools can reliably find missing names, invalid ARIA, broken references, skipped headings and similar code problems, but roughly two thirds of WCAG criteria need human judgement – whether alt text is meaningful, whether focus order makes sense, whether content is understandable. Every result says what still needs manual testing.
The checks follow WCAG 2.2 and WAI-ARIA 1.2, the standards behind the European Accessibility Act, the Americans with Disabilities Act guidance, Section 508 and EN 301 549. Each finding names the success criterion so you can look it up and include it in a report or ticket.
Related tools on this site cover the rest of an accessibility review: the HTML accessibility checker, WCAG contrast checker, accessibility colour analyzer, keyboard navigation checker, ARIA validator, alt text generator, heading structure checker and the accessibility statement generator.
Who it is for: front-end developers checking a release, designers reviewing a component library, content editors, QA testers and agencies preparing accessibility audits for clients. No account, plugin or installation is needed.