Free ARIA checker for any web page
A page's URL in, every ARIA problem out, with the element and what is wrong with it.
Check a page's ARIA
Example A made-up clinic's booking page. Enter yours to check it.
4 ARIA problems to fix
| Problem | Element |
|---|---|
| Button has no accessible name Button has no text content or aria-label. Screen readers cannot identify this button. | <button class="dialog__close"> |
| Invalid ARIA boolean value aria-expanded="yes" is invalid. Use 'true' or 'false', not 'yes' or 'no'. | <button aria-expanded="yes"> |
| Misspelled ARIA attribute aria-labeledby is not a valid ARIA attribute. Did you mean aria-labelledby? | <input type="email" aria-labeledby="email-label"> |
| ARIA role missing required parent Element with role="tab" must be contained within an element with role: tablist. | <div role="tab"> |
3 more need a person to review
| Problem | Element |
|---|---|
| Menu role used for navigation role="menu" is designed for application menus (like desktop app menus), not for website navigation. Navigation links should use <nav> with role="navigation". | <nav role="menu"> |
| Focusable element hidden from assistive technology aria-hidden="true" is set on a focusable element. This creates a confusing experience. If a stylesheet hides it until it opens, this is fine; if not, it fails. The page's HTML alone cannot say which. | <a href="/book" class="cta" aria-hidden="true"> |
| ARIA reference to non-existent id aria-describedby points at id 'price-note', which is not on the page. If that element only renders later (an error message, a popup), this is fine; if not, the reference does nothing. | <p aria-describedby="price-note"> |
What this check looks for
The tool above checks for these things on the page you give it.
- Buttons with no name
- Icon buttons with no text or label, which screen readers announce only as "button".
- Invalid attributes and values
- Misspelled or made-up aria- attributes, and true or false attributes set to anything else, such as "yes".
- Roles out of place
- A tab outside a tab list, a menu item outside a menu, and site navigation marked up as an application menu.
- Hidden but focusable
- aria-hidden on elements that keyboard users can still tab to.
- Broken references
- aria-labelledby, aria-describedby, aria-controls and aria-owns pointing at IDs that don't exist.
The fix, in HTML
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>
What still needs a person
No automated tool can confirm these. AccessGuard marks related findings as Review, so nobody mistakes them for a pass.
This check maps to WCAG 4.1.2 Name, Role, Value, level A, and is partly automated.
- 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
-
Checks
Form labels checkerFinds 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, controls a keyboard reaches but nobody can see, focus styles that were removed, and focused elements hidden behind sticky headers.
-
Headings and landmarks checker
A page's URL in, its heading outline and landmarks out, with what is wrong in them.
-
Guides
ARIA Attributes Explained: Roles, States & Properties GuideARIA roles and attributes can make complex UIs accessible to screen readers, but misuse makes things worse. Learn when to use ARIA, when to skip it, and the most common mistakes to avoid.
-
Combobox Pattern: Accessible Dropdowns With ARIA Code
Native select first. When you truly need a custom dropdown, this is the role structure, the keyboard map and the focus handling that make it usable.
-
Button vs Link Accessibility: The Choice That Breaks Keyboards
Links go somewhere and buttons do something, and picking the wrong one quietly locks keyboard and screen reader users out.
-
Accessible Navigation Menus and Dropdowns That Work
Site navigation is a disclosure pattern, not an ARIA menu, and choosing it fixes most keyboard and screen reader bugs in one go.
-
Agent Ready Website: What AI Browser Agents Need to Read
Browser agents read the same names, roles and labels as screen readers, so the WCAG fixes that help people also stop agents getting stuck.
-
How to Test With a Screen Reader: A 20 Minute Website Pass
The smallest screen reader routine that finds real bugs: one reader, a handful of keys and a pass of about 20 minutes per page template.
-
How to Build an Accessible Modal Dialog, with Code to Copy
What a dialog has to do when it opens, while it is open and when it closes, with the WCAG criterion behind each requirement.
-
Accessible Forms: WCAG Inputs, Labels, and Errors
Missing labels, broken error handling, and inaccessible inputs block real users from completing forms. Learn how to fix common WCAG form violations with practical code examples.
Every check, not only ARIA
The free audit runs this check and every other one. Results in about a minute.