A website accessibility checker scans your pages for the barriers that lock real visitors out — missing alt text, unreadable contrast, broken keyboard navigation, and unlabeled forms. The best free ones (WAVE, axe DevTools, Lighthouse) take under a minute to run and hand you a plain list of what to fix, starting with the problems that affect the most people.
I ran my first accessibility check on a client’s site the way most people do: because someone complained. A regular visitor emailed to say she couldn’t read the pale grey text on the contact page, and the “Submit” button didn’t work with her keyboard. I’d looked at that page a hundred times and thought it was fine — it looked fine to me. The checker found 14 errors in thirty seconds, including three that had been live for two years. That gap between “looks fine” and “works fine” is exactly what a website accessibility checker exists to close.
What does a website accessibility checker actually test?
An automated checker loads your page the way a browser does, then inspects it against the Web Content Accessibility Guidelines (WCAG) — the shared standard for accessible web design. It checks the things a machine can reliably judge:
– Images: every meaningful image needs alt text; decorative images should be marked as such.
– Contrast: text must stand out enough from its background — roughly 4.5:1 for body text.
– Headings and structure: one H1, headings in logical order, so screen readers can navigate the page outline.
– Forms: every input needs a visible, associated label — placeholder text alone doesn’t count.
– Keyboard access: every link, button, and form field must be reachable and usable without a mouse.
– Links: link text must describe its destination — “click here” tells a screen-reader user nothing.
What it does not test is whether your site actually makes sense. A checker can confirm an image has alt text; it can’t tell you the alt text says “image123.jpg” instead of describing the photo. That’s why the checker is a starting point, not a verdict.
How do I run a website accessibility checker on my own site?
Three free tools cover nearly everything, and you can run all of them on the same page in under five minutes.
WAVE (wave.webaim.org) is the friendliest first step. Paste your URL, and WAVE draws your page with little icons marking every issue right where it occurs — red for errors, yellow for alerts, green for good structure. Click any icon to see what it means and how to fix it. WAVE is my default recommendation for anyone checking their own site for the first time.
axe DevTools (free Chrome and Firefox extension) is the one developers reach for. Open DevTools, run axe, and you get a precise list of violations with the exact HTML element responsible and a link to the rule it breaks. If you work with a developer, send them an axe report — it’s written in their language.
Lighthouse (built into Chrome) is the quickest of all. Open DevTools, go to the Lighthouse tab, tick the Accessibility category, and run it. You get a score out of 100 plus a list of failed checks. It’s less detailed than WAVE or axe, but it sits in the same report as your performance scores.
Run one, fix what it finds, then run it again. A second run confirms your fixes actually worked — and it usually surfaces a few issues the first pass buried under the bigger ones.
What do the results mean — errors, alerts, and contrast warnings?
Every checker sorts its findings, and the sorting matters more than the raw count. Here’s how to read them:
Errors are real barriers. A missing form label, an image with no alt text, a button with no name — these stop someone from using the page. Fix every error on your key pages: homepage, contact, checkout, and any page that carries a form.
Alerts are “check this yourself.” A checker flags a suspicious link or a long alt text as an alert, not because it’s definitely wrong, but because only a human can judge. A link that says “read more” is an alert — fine if the surrounding heading gives context, a real problem if it doesn’t.
Contrast warnings are the most common finding on real sites — and the most ignored. Light grey text on a white background fails WCAG for a reason: roughly 1 in 12 men has some form of color-vision deficiency, and low-contrast text is unreadable in bright sunlight for everyone else. If your checker flags contrast, darken the text or lighten the background. It’s usually a one-line CSS fix.
Don’t chase a perfect zero. A page with zero errors and two alerts you’ve reviewed is in excellent shape. A page with 40 errors and a pretty design is not.
Which accessibility issues should I fix first?
If the list is long, fix in this order — it mirrors how much each problem costs real visitors:
1. Keyboard navigation. Tab through your page using only the keyboard. If you can’t reach the menu, the form, or the buy button, that’s the top priority — keyboard users include people with motor impairments and power users alike.
2. Form labels. Every input needs a real label. This one fix rescues screen-reader users and also helps everyone on a phone, where tapping a tiny unlabeled field is guesswork.
3. Alt text on meaningful images. Product photos, diagrams, charts — describe what they show. Decorative images get empty alt text (alt="") so screen readers skip them.
4. Contrast. Fix the worst offenders first: body text, buttons, and navigation links.
5. Heading order. One H1, then H2s, then H3s — no skipping levels, no headings used just to make text big.
A useful trick: fix the issues that appear on your header, footer, and navigation once, and you’ve fixed them on every page at the same time.
What can’t an automated website accessibility checker catch?
Automated tools catch roughly a third of WCAG issues — the mechanical ones. The rest needs a human, and the most valuable human test takes two minutes: unplug your mouse and use your site with the keyboard alone. Tab through the menu, open a dropdown, fill in the contact form, submit it. If you get stuck or lose track of where focus is, your visitors do too.
The second test is free and humbling: turn on your operating system’s built-in screen reader (VoiceOver on Mac, Narrator on Windows) and listen to your homepage for sixty seconds. You’ll hear immediately whether your headings make sense out of order, whether your links say anything useful, and whether that image slider is announcing the same slide six times.
Finally, check your site at 200% zoom and at a narrow width — text that overlaps, buttons that vanish, and menus that break at high zoom are accessibility failures too, and they affect people with low vision directly. Try it on your own site with our responsive preview tool to see how the layout holds up at different sizes and zoom levels.
Frequently asked questions
Is a website accessibility checker free?
Yes — the best ones are. WAVE, axe DevTools, and Lighthouse are all free, and each one checks a page in under a minute. Paid tools exist for large sites that need scheduled scans across hundreds of pages, but a small site never needs them to get started.
Can an automated checker make my site fully accessible?
No. Automated checkers reliably find about a third of WCAG issues — the mechanical ones like missing alt text and low contrast. The rest, like whether your alt text is meaningful or your page makes sense when read aloud, needs a human check: keyboard-only navigation and a screen reader pass.
What is the difference between WAVE and axe DevTools?
WAVE is the friendlier starting point: it overlays issue icons directly on your page so you can see problems in context. axe DevTools is more technical — it names the exact HTML element and the rule it breaks, which makes it the better tool to hand to a developer. Most people benefit from running both.
How often should I run an accessibility check?
Run one after every redesign or template change, and re-check your key pages a few times a year. The highest-value habit is simpler: run a check on any page before you publish it, the same way you’d proofread the text.