Accessibility checker: find WCAG 2.2 issues and the elements to fix
This accessibility checker tests your page against WCAG 2.2 A and AA and groups the issues by impact, with the exact elements to fix, from colour contrast and form labels to tap targets and zoom.
- Free, no account
- Results in under a minute
- Audits against WCAG 2.2 A and AA
Example result:example-shop.hr
WordPress 6.8Sample shop · homepage · mobile Chrome · the same check you get for your own site
What we found
Show 7 passed checks
Fix these first
From the example above. Check your own site to get the fixes that apply to it.
Problem: 1 critical accessibility violation
Critical issues stop some visitors from using the page at all, for example buttons a screen reader cannot name or forms that cannot be filled in.
How to fix it: Open the technical detail to see each rule and the elements affected.Problem: 2 serious accessibility violations
Serious issues make parts of the page very hard to use with a screen reader, keyboard or zoomed-in display, so some visitors give up before they buy or get in touch.
How to fix it: Open the technical detail to see each rule and the elements affected.Problem: 1 link or button has no accessible name
Icon-only links and buttons are read out as "link" or "button" with nothing else, so screen reader users cannot tell the cart from the search.
How to fix it: Add visible text, or aria-label="…" on the link or button, that says where it goes or what it does.
What the website accessibility checker tests
axe-core plus our own checks, run on the page as Chromium renders it.
Critical accessibility issues
Finds issues that stop some visitors from using the page at all, like unnamed buttons.
Serious accessibility issues
Finds issues that make parts of the page very hard to use with a screen reader or keyboard.
Moderate accessibility issues
Finds issues that slow visitors down, such as headings out of order or unnamed page regions.
Minor accessibility issues
Finds small inconsistencies that add friction for people using assistive technology.
Text colour contrast
Checks text stands out enough from its background to read on a phone or with weaker colour vision.
Page landmarks
Checks for header, navigation, main and footer areas that screen reader users jump between.
Skip to content link
Checks keyboard users can jump past the menu to the main content in one keystroke.
Form field labels
Checks every form field has a label, so screen readers can say what each one is for.
Link and button names
Checks icon-only links and buttons have a name that screen readers can read out.
Image alt text
Checks images have alternative text for screen readers, broken images and image search.
Tab order
Checks keyboard focus follows the order things appear on screen, without forced jumps.
Page language
Checks the page declares its language, so screen readers use the right pronunciation.
Show 10 more checks
Text colour contrast
Checks text stands out enough from its background to read on a phone or with weaker colour vision.
Page landmarks
Checks for header, navigation, main and footer areas that screen reader users jump between.
Skip to content link
Checks keyboard users can jump past the menu to the main content in one keystroke.
Form field labels
Checks every form field has a label, so screen readers can say what each one is for.
Link and button names
Checks icon-only links and buttons have a name that screen readers can read out.
Image alt text
Checks images have alternative text for screen readers, broken images and image search.
Tab order
Checks keyboard focus follows the order things appear on screen, without forced jumps.
Page language
Checks the page declares its language, so screen readers use the right pronunciation.
Zoom on phones
Checks visitors can pinch to zoom the page on their phone to read small text.
Tap target size
Checks links and buttons are at least 24×24 px, so visitors don't mis-tap on phones.
Show 2 more checks
Zoom on phones
Checks visitors can pinch to zoom the page on their phone to read small text.
Tap target size
Checks links and buttons are at least 24×24 px, so visitors don't mis-tap on phones.
How the accessibility checker works
Render the page
Your page is loaded in Chromium, so the audit sees what visitors see after scripts run.
Run axe-core
The page is audited with axe-core against WCAG 2.2 A and AA. Violations are grouped by impact, from critical to minor, with the CSS selectors of the affected elements.
Add our own checks
On top of axe we check colour contrast, landmarks, a skip link, form labels, link and button names, alt text, tab order, page language, mobile zoom and tap-target size.
Automated checks find about a third of WCAG issues. Keyboard and screen-reader testing by a person covers the rest.
Accessibility checker questions
Which WCAG 2.2 criteria can an automated checker test?
The ones with a clear yes-or-no answer in the code: colour contrast, alt attributes, form labels, link and button names, page language, headings and landmarks, zoom and tap-target size. That is roughly a third of the success criteria. Whether alt text is meaningful, the focus order makes sense or a screen-reader user can finish a checkout needs a person with a keyboard and a screen reader.
Does this checker test colour contrast?
Yes. Text on the rendered page is checked against WCAG 2.2 AA: a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, from 24 px, or about 18.5 px bold. Each failure lists the element, its colours and the ratio it reached. Text over images or gradients cannot be measured reliably, so it is left for you to review by eye.
Does it check keyboard accessibility?
Partly. It checks what can be read from the page: a skip link, a tab order without positive tabindex values, and names on every link and button. It cannot press Tab through your menus and forms, so test that yourself: every control should be reachable and usable with the keyboard alone, in a sensible order, with a visible focus outline.
Can I check a page behind a login?
No. The checker opens public URLs as a first-time visitor without cookies, so pages behind a login, a checkout step or a consent wall are not reached. Test those in your own browser while logged in, with the Lighthouse panel in Chrome's developer tools or the axe DevTools extension, and use this checker for your public pages.
Does a clean result mean my site is WCAG compliant?
No. Automated tools can find only about a third of WCAG issues, because many criteria need human judgement, such as whether alt text is meaningful or the reading order makes sense. A clean result means the common, detectable mistakes are gone. Keyboard and screen-reader testing by a person covers the rest.
How do I test a website for accessibility?
Use three passes. First an automated checker like this one, which renders the page in Chromium and audits it with axe-core plus our own checks. Then use only the keyboard: every control must be reachable, visibly focused and usable. Finally, listen to the page with a screen reader and zoom it to 200 %. The automated pass takes a minute and catches the most common problems.
Is this accessibility checker free?
Yes, with no sign-up. getReport is funded by donations, not plans, and the complete report with all seven modules is one click away, also free. It stays at its shareable link for 12 months, is not listed publicly and carries a noindex tag, and nothing about your visitors is collected.
Related free tools
All 59 tools →Free, funded by the people who use it
No account, no paid plan. Donations keep it running.