You can check a good part of a website’s accessibility without paying for a tool. You need a browser, a keyboard and half an hour. The twelve tests below cover the most common faults. They don’t replace a full audit, but they quickly show whether a site is basically sound or has bigger problems.
The yardstick is the W3C’s Web Content Accessibility Guidelines, version 2.2, level AA. Each test names the matching success criterion in brackets so you can look it up.
First: does the law apply to you?
In the EU, the European Accessibility Act has applied since 28 June 2025. It doesn’t cover every website. Among other things it covers e-commerce services, meaning services through which consumers conclude contracts online, such as an online shop or an online booking system.
Microenterprises that provide services are exempt. The directive defines a microenterprise as having fewer than ten employees and an annual turnover or balance sheet total of no more than two million euros. A purely informational site for a trade business, with a phone number and a contact form, is generally not covered. Each EU country has written the act into its own law, Germany for instance as the BFSG, so details can differ.
It is worth checking anyway. An accessible site is easier for everyone: on a phone, in bright sunlight, with tired eyes. And if you add a shop or a booking later, the groundwork is done.
The twelve tests
1. Use only the keyboard (2.1.1)
Put the mouse aside. Move forward with Tab, back with Shift+Tab, open links and buttons with Enter, change options with the arrow keys. Can you reach every menu, every button, every form field? Can you get out of an open menu or dialog again? If you get stuck anywhere, that is a serious fault.
2. See the focus (2.4.7 and 2.4.11)
While tabbing, it must always be visible where you are, with a clear outline or underline. New in WCAG 2.2: the focused element must not be completely hidden behind a sticky header, a cookie notice or a chat window.
3. Zoom to 200 percent (1.4.4)
Set the browser zoom to 200 percent. Text must stay readable, and nothing should be cut off or overlap.
4. Zoom to 400 percent (1.4.10)
At 400 percent on a typical laptop, the page is roughly 320 pixels wide. There should be no horizontal scrollbar for running text now; content has to reflow into one column. You are testing the phone view at the same time. According to the Web Almanac 2025, 19 percent of mobile pages fully or partly prevent zooming. That is a fault in the code and quick to fix.
5. Measure contrast (1.4.3 and 1.4.11)
Normal text needs a contrast ratio of at least 4.5:1 against its background, large text 3:1. Interface parts such as input field borders need 3:1. The developer tools in Chrome, Edge and Firefox show the contrast when you inspect a text element. Contrast is the most common fault of all: in the WebAIM Million 2026, 83.9 percent of the most visited home pages had text with too little contrast. Usual suspects are light grey text, text on photos and placeholder text in forms.
6. Check the heading outline (1.3.1)
Each page needs exactly one main heading (h1), with h2 and h3 below it in a sensible order. The WAVE checker shows the outline as a list. If it reads like a table of contents, it’s good. Headings picked only for their font size stand out immediately.
7. Alt text for images (1.1.1)
Every image that conveys something needs alt text that says the same thing. “The team outside the workshop” is good; “IMG_2041” or “image” is not. Purely decorative images get an empty alt="" so screen readers skip them.
8. Forms with labels and clear errors (3.3.1 and 3.3.2)
Every field needs a visible label, not just grey placeholder text that disappears as you type. Submit the form once while empty: does each field say what is missing, and are you taken to the first error? An error shown only in red isn’t enough.
9. Link text that stands on its own (2.4.4)
“Click here” and “More” say nothing out of context. Screen reader users often list all the links on a page. “Prices for boiler servicing” works there too.
10. Targets big enough to tap (2.5.8)
New in WCAG 2.2: targets must be at least 24 by 24 pixels or have enough space around them. Watch out for small icons in the footer, links packed tightly together and the close button on notices.
11. Pause movement and declare the language (2.2.2 and 3.1.1)
Anything that moves on its own for more than five seconds, like a slider or a background video, needs a way to pause it. The page also has to declare its language (lang="en" in the HTML) so screen readers pronounce it correctly. You can see the value at the top of the code in the developer tools.
12. An automated test to finish
Finally, run a free checker: WAVE by WebAIM as a browser extension, or the Lighthouse audit in Chrome. They reliably find missing labels, contrast errors and empty links. What they can’t judge is whether an alt text is accurate or whether keyboard navigation makes sense. That’s why the automated test comes last here, not first.
One step further: screen readers and documents
If you have more time, try a screen reader. VoiceOver is built into Macs and iPhones, TalkBack into Android, and on Windows there is the free NVDA. Ten minutes already tell you a lot. Is the menu announced in a way that makes sense? Does a button say what it does, or just “button”? Are images described usefully? It feels unfamiliar at first, but you don’t need to be an expert to hear the obvious faults.
Documents are often forgotten. Menus, price lists or forms as PDFs are frequently unreadable for screen readers, especially when they are scanned. The simplest fix is usually to offer the content as a normal web page as well. Videos need captions, and audio-only recordings need a transcript.
And if you build for clients, write down what you checked and what you found. That helps you if someone asks later, and it helps the client write their accessibility statement if they need one.
Sorting the results
After the twelve tests you have a list. Sort it into three groups.
| Group | Examples | When to fix |
|---|---|---|
| Blocks use | keyboard trap, form can’t be submitted, zoom disabled | now |
| Makes use harder | low contrast, missing labels, invisible focus | in the next few days |
| Improvement | sharper link text and alt text, bigger targets | at the next redesign |
If the act applies to you, you also need to publish information on how your service meets the accessibility requirements.
Why an overlay can’t replace the check
Overlay plugins promise to make a site accessible with one line of code. They put a toolbar with font size, contrast and read-aloud options on top of the page. The faults underneath, such as a menu the keyboard can’t reach or a field without a label, stay where they are. Why that is, and what accessibility experts say about it, is covered in Accessibility without an overlay.
Till Heidrich’s view: The keyboard test is the most honest test there is. It takes five minutes, costs nothing, and once you have done it you look at websites differently.
A design that is already checked
Accessibility is cheapest when it is built into the design rather than repaired afterwards. Every design in the gallery is checked against WCAG 2.2 AA before sale, automatically and with a checklist, and the report is in the package. What you add later, such as copy, images, PDFs and embedded tools, you check yourself with the tests above. A checked design is a good start, not a guarantee for the finished website.