An accessibility checker scans a web page against the Web Content Accessibility Guidelines (WCAG) and points out what fails. Good free ones are the WAVE and axe DevTools browser extensions and Lighthouse, which is built into Chrome. A checker is only the first of four steps, though: after it comes a keyboard test without a mouse, a short pass with a screen reader (NVDA on Windows, VoiceOver on a Mac) and a contrast check with an eyedropper. The target is WCAG level AA. No tool makes the call for you: the maker of axe says its engine finds on average 57 percent of WCAG issues automatically. The rest you only see by using the page yourself.
I tested my own website on 4 November 2026, eight pages: automated with axe, plus keyboard, contrast and video by hand. A screen reader pass wasn't part of it yet. The full results are below. In short: 207 findings, almost all from a handful of components that repeat on every page. kevinwelter.com is built and technically maintained by Ralf, my AI employee for websites; how he works is on Build and Modernize a Website With AI. Whether your site legally has to be accessible is a separate question, covered in Web Design for the Self-Employed: Worth It?.
Free accessibility checker tools at a glance
According to WebAIM, the WAVE extension runs entirely within your browser and sends no information to the WAVE server. Lighthouse scores a weighted average of pass or fail audits, weighted by axe's impact ratings; audits that need a human don't count, Google says. A 100 means the automated audits passed, nothing more.
How to test a website for accessibility
Step 1: run a checker
Run WAVE or axe on your key page types, not just the homepage: an article, a service page, the contact form, the checkout. Read the results in two piles: real violations and places the tool could not decide ("incomplete" in axe). Check the second pile by hand; it often holds the more important findings. And sort by cause, not by page: an error that repeats everywhere lives in a shared component such as the footer, and you fix it once.
Step 2: keyboard test
Put the mouse away. Tab moves forward, Shift + Tab back, Enter follows links, Space presses buttons, Esc closes menus. Can you always see where you are (WCAG 2.4.7 requires a visible focus)? Can you reach everything, including menus and forms? And do you get to the content quickly? A "skip to content" link at the top is the usual way. WCAG doesn't strictly require it, since the W3C techniques also accept landmarks and headings, but keyboard users appreciate it.
Step 3: screen reader
Ten minutes give you a first impression. On a Mac, Apple says Command + F5 turns VoiceOver on and off; on Windows, install NVDA. Open the list of headings and the list of links: do they make sense on their own? Are buttons named for what they do, and are images announced with alternative text?
Step 4: contrast
Under WCAG 1.4.3, normal text needs a contrast ratio of at least 4.5:1 against its background, large text (18 point, or 14 point bold) 3:1. The eyedropper in the Colour Contrast Analyser picks both colours straight from the screen. Watch grey or semi-transparent text and text over images or gradients, which checkers often can't calculate. If your site has a dark mode, test both.
My own website, tested
I tested kevinwelter.com on 4 November 2026. The run itself was done by Sebastian, who writes the posts on my website and measures: axe-core 4.14.0 in a Chromium browser driven by Playwright, read-only, 1,280 pixels wide, light mode. Eight pages: the homepage, the blog index, one article, Ralf's team page, the community page, contact, the English homepage and the AI basics hub.
The result: on each of the eight pages exactly three rules fail, 207 findings in total. 184 of them, nearly nine in ten, come from three components that appear on every page.
I checked by hand that the errors are real: the site is light, the text dark at 50 to 60 percent opacity, which produces the pale grey axe measures. In dark mode, same homepage, only 3 contrast findings remain, the three "Result:" boxes at 4.18:1. On a phone (390 pixels wide) the homepage shows the same 22 contrast and 4 name findings.
The good part: all 118 images have an alt attribute, every page has one H1 and the right language, and keyboard focus shows as a 2 pixel outline. Not tested: screen reader, zoom and forms. Less good: there is no "skip to content" link, and 13 tab stops come before the main content on the homepage. The most important finding didn't come from the count at all but from the "check by hand" pile: the video on my German community page, in which I tell the story myself, runs just over three minutes and has no caption track. Two still frames Sebastian pulled from the video show no burned-in captions either. WCAG 1.2.2 requires captions for prerecorded video with sound, already at the lowest level, A. How to produce them without much effort is in Auto-Generate Subtitles: A Guide.
As of 4 November 2026, none of this is fixed yet. The complete list with locations and fixes is written; it gets implemented through Ralf's fixed process: build, check desktop and mobile, live only after my approval. How a check like this fits into regular upkeep is in Website Maintenance: Tasks, Checklist, Cost.
What the law requires, briefly
This is not legal advice, just the context before the test. If you serve customers in Germany, the German Accessibility Strengthening Act (Barrierefreiheitsstärkungsgesetz, BFSG), which implements the European Accessibility Act, has applied since 28 June 2025 to online offers through which consumers conclude a contract; microenterprises providing services are exempt (section 3(3) BFSG). Who exactly is affected is covered in Web Design for the Self-Employed.
According to Germany's Federal Accessibility Agency (Bundesfachstelle Barrierefreiheit), the standard EN 301 549 is currently the central technical reference; it points to success criteria of WCAG 2.1, and an updated version is to point to WCAG 2.2. A test against WCAG 2.2, level AA, as above covers both. Complaints go to the joint market surveillance authority of the German states. The exact sections of the law are in AI Website Generators Compared. If in doubt, ask a lawyer.
Where Ralf comes in
Ralf has built more than 20 client websites and maintains kevinwelter.com technically. His process includes build, screenshots, mobile layout and click paths, and going live remains a human decision. An accessibility check fits right into that step: one axe run before each launch catches new errors before a shared component spreads them across every page. It is cheapest in a new build or when modernizing a website with AI, because colours and controls are decided in the design.
Frequently asked questions
What is the best free accessibility checker?
WAVE to start, because it shows findings right in the page; axe DevTools for developers, because it names the exact element. None replaces the keyboard and screen reader tests.
Is a Lighthouse score of 100 enough?
No. The score covers automated audits only; audits that need a human don't count, Google says. A missing caption track like the one on my video doesn't lower the score.
What does a WCAG checker actually do?
It checks a page's code against rules, usually WCAG success criteria. The W3C is clear about the limits: such tools cannot determine accessibility, they can only assist in doing so.
Which errors should I look for first?
On my site: text that is too pale, an announced name that doesn't match the visible text, and a video without captions. Also check alternative text for images, labels on form fields and whether everything works from the keyboard; WCAG requires all three at level A (1.1.1, 3.3.2, 2.1.1).
Should I test against WCAG 2.1 or 2.2?
Test against WCAG 2.2, level AA. It has been a W3C Recommendation since October 2023 (current version 12 December 2024), and content that meets 2.2 also meets 2.1, which EN 301 549 points to today.
What to do next
Take an hour and five pages: the homepage, a service page, an article, the contact form and the checkout, if you have one. Run WAVE or axe on each, note findings by cause, then do the keyboard test and ten minutes with VoiceOver or NVDA. Fix the causes that repeat on every page first. If you'd rather hand this to an AI employee who builds, checks and only goes live after your approval: Ralf is available as a ready-made, tested template in the Premium tier of my community, the AI Employee Framework.
