How to test your website for accessibility

Automated scanners alone are not enough: this 7-step test plan walks you through checking your website systematically – from keyboard to screen reader.

Why a test plan beats a single tool

Many site owners run an automated scan, fix a few reported errors and consider the job done. That falls short: accessibility can only partly be checked by machines. Whether a page can really be operated with a keyboard, whether a screen reader reads the content in a way that makes sense, or whether form error messages are understandable – you have to try that yourself.

The test plan below therefore combines automated tools with manual checks. You do not need any special equipment: a current browser, a keyboard and the screen reader that already ships with your operating system are enough to get started. The benchmark is WCAG 2.2, the international standard for accessible web content.

Step 1: Automated scanners as a starting point

Automated tools find typical technical errors quickly and reliably: missing alt attributes, insufficient contrast, unlabeled form fields, broken ARIA attributes. Three proven, free tools:

• Lighthouse: built into Chrome and Edge. Open the developer tools (F12), switch to the Lighthouse tab, select the Accessibility category and generate the report.
• axe DevTools: a browser extension by Deque. After installation you will find a dedicated tab in the developer tools that highlights issues directly in the code.
• WAVE: an evaluation tool by the US organization WebAIM (not affiliated with Wave Tools – the similar name is a coincidence). It overlays icons directly on your page, which makes problems very easy to see.

Do not just scan your home page – test every page type: home page, content page, form page, product or blog post page, search results.

Step 2: The keyboard test

Put your mouse aside and operate your website using only the keyboard. The Tab key moves you forward through all interactive elements, Shift+Tab moves you backward, and Enter or the space bar activates them. Watch for three things:

1. Order: Focus should move in a logical sequence – usually from top left to bottom right, following the visible structure. If it jumps around erratically, something is wrong with the document structure.
2. Visibility: You must be able to tell at all times which element currently has focus. If the focus outline is missing (often removed via CSS with outline), keyboard users are lost.
3. No traps: You must be able to leave every element again. Classic traps are embedded widgets, cookie banners and modal dialogs that cannot be closed with Escape.

Also test menus, accordions, sliders and date pickers – that is exactly where many websites fail.

Step 3: Basic screen reader test

A screen reader reads the page the way blind and severely visually impaired people perceive it. For a basic test you do not need to buy anything:

• Windows: NVDA is free and widely used. After launching, it starts reading automatically; press H to jump from heading to heading and Tab to move through interactive elements.
• macOS and iOS: VoiceOver is built in. On the Mac you start it with Cmd+F5; on the iPhone you enable it in Settings under Accessibility.

Ask yourself three questions while listening: Does the page make sense without a screen? Are images announced with meaningful alternative text, or just with file names? When you reach buttons and links, do you learn what will happen when you activate them – or do you only hear "link" and "click here"? Even ten minutes with a screen reader will teach you more about your website than any report.

Step 4: Zoom to 200 percent and reflow

Many people with low vision enlarge content in the browser. WCAG requires that text remains usable at 200 percent zoom without loss of content or functionality. Here is how to test:

1. Enlarge the page step by step to 200 percent using Ctrl and Plus (Mac: Cmd and Plus).
2. Check whether text gets cut off, elements overlap, or controls slip out of the visible area.
3. Additionally, shrink the browser window to about 320 pixels wide or zoom to 400 percent: the content should now rearrange into a single column (reflow) without forcing you to scroll horizontally.

If your website is built responsively and cleanly, it usually passes this test without extra work – if not, you will immediately see where it breaks.

Step 5: Check color contrast

Insufficient contrast is one of the most common barriers of all. WCAG requires a contrast ratio of at least 4.5:1 between normal text and its background, and at least 3:1 for large text (from about 24 pixels, or 19 pixels bold). Controls and graphical icons also need at least 3:1.

For measuring, use the WebAIM Contrast Checker, the color picker in your browser's developer tools, or desktop apps such as the Colour Contrast Analyser. Focus on the usual suspects: light gray text on white, placeholder text in form fields, text on photos, and buttons in brand colors. Do not rely on your impression on your own, well-calibrated monitor – measure it.

Step 6: Forms and error messages

Forms are where barriers cost the most – this is where orders and inquiries get abandoned. Fill out every important form once completely, once deliberately wrong, and once using only the keyboard. Check that:

• Every field has a visible, programmatically associated label – placeholder text inside the field is no substitute, because it disappears as soon as you start typing.
• Required fields are marked as such, not only by color.
• Error messages appear as text right next to the affected field and explain specifically what is wrong and how to fix it – "Invalid input" on its own helps no one.
• After submitting with errors, the data already entered is preserved.
• Time limits, for example in booking flows, can be extended or turned off.

Step 7: Review content – alt text, headings, link text

Finally, look at the editorial level, which no tool can judge:

• Alt text: Does the alternative text describe what the image shows and what function it serves? Do purely decorative images have an empty alt attribute? Our article How to write good alt text shows how to get this right.
• Heading hierarchy: Exactly one H1 per page, followed by a gapless outline (H2, then H3 beneath it). Headings are structure, not styling – choosing an H4 because it looks nicely small sabotages screen reader navigation.
• Link text: Every link should make sense on its own. "Read more" and "here" do not – "Download the price list as PDF" does.

Prioritize, document, keep going

After the seven steps you will have a list of findings. Sort them by impact: blockers that prevent use entirely come first (keyboard traps, unlabeled forms, unusable navigation), followed by major hurdles such as missing alt text on key pages and weak contrast, and finally polish.

Document every finding with the page, a description, the affected WCAG criterion and the planned fix. This documentation pays off twice: it is the working basis for your team – and it provides the facts for your accessibility statement, in which you have to name known limitations and planned measures anyway.