How to test your website for accessibility

How do I test a website for accessibility?

A test has three levels: an automated scan, a manual review by you or by experts and, for important journeys, feedback from disabled people. No level replaces the others.

Decide beforehand what you are measuring against. For most projects, WCAG 2.2 at level AA is a sensible goal. With WCAG-EM, the W3C describes a five-step method: define the scope, explore the website, select a representative sample, evaluate it and report the results. This order is a good guide for small teams too. The first round does not have to be perfect. What matters more is that you can repeat it: same pages, same journeys, same notes.

Which pages should you test?

Do not test a hundred similar product pages; test each template once. A good sample includes the home page, navigation, search, a content page, a product or service page, the contact form, login, basket and checkout, and an error page.

Think about states as well: an open menu, a form showing error messages, a dialog, the cookie banner and a success message. Important PDF downloads belong in the sample too, as do areas behind the login that a public scan cannot reach. For each page, note which task people complete there. That way you later assess not just individual errors, but whether the journey works as a whole.

What does an automated test find, and what does it miss?

A scanner quickly finds technical errors: missing text alternatives, insufficient contrast, form fields without names or faulty heading structures. It cannot tell whether an alt text describes the right thing, whether the focus order is logical or whether instructions are understandable.

The Accessonaut check uses axe-core, ranks every finding by importance and explains how to fix the problem. According to the W3C, no automated tool alone can determine whether a website meets accessibility standards. That is why a scan is a starting point for your work, not a certification. Use the results as a task list with specific locations.

How do you carry out a manual test?

• Page title: Check in the browser tab that every page has a unique, fitting title.
• Keyboard: Put the mouse aside and operate navigation, dialogs and forms with Tab, Shift+Tab, Enter and Escape. Focus must be visible at all times.
• Zoom: Zoom the page to 200 per cent and check that content and functions remain available.
• Contrast: Measure text and background colours with a contrast tool. Normal text needs at least 4.5:1.
• Colour: Check that information can be recognised without colour too, such as required fields, errors or links in running text.
• Headings: Check that the headings structure the page and follow a sensible hierarchy.
• Forms: Deliberately submit incorrect information and check that errors are named clearly.
• Motion and media: Check that carousels and animations can be paused and that videos have captions.
• Mobile: Repeat the most important steps on a smartphone, in landscape orientation as well.
• Language: Read instructions and button labels aloud. Without prior knowledge, do you understand what happens next?

How do you test with a screen reader?

Free or built-in screen readers are enough for a first test: NVDA on Windows, VoiceOver on Mac and iPhone, TalkBack on Android. Allow some time to learn them, because operating them is very different from using a mouse. Test with a browser the screen reader is designed for, for example VoiceOver with Safari.

Listen to whether links, buttons and fields are announced clearly. Jump through the page using the list of headings and fill in a form. Pay attention to whether error messages and status changes such as ‘Item added to basket’ are read out. Typical findings are buttons that are only called ‘button’, images whose file name is read out, and dialogs that are not announced as dialogs. You will find detailed instructions in the article on screen reader testing.

Why should you involve disabled people?

People who work with a screen reader, magnification or voice control every day notice hurdles that get lost in a quick test. These include cumbersome journeys, unclear terms or operation that works but takes far too long.

Include such feedback above all for key journeys, such as ordering, booking or signing up. Record observations without generalising too quickly: one person does not speak for everyone with the same disability. Plan time and fair pay, and prepare concrete tasks, such as ‘Order this product in size M’.

In what order should you fix the findings?

A button that cannot be operated can block an entire journey. A missing form field name makes entering data with a screen reader harder. Start with obstacles like these, then move on to problems that appear on many pages, and deal with one-off cases last.

For each finding, read the explanation, the location and the related WCAG reference. If the cause lies in a shared component such as the header or a product card, you fix it there once for all pages. A simple classification helps: blocking, obstructive or annoying. For each item, record who will fix it and by when.

How do you document results and retest?

Note the issue, the affected URL, the change and the result of the retest. Check the same journeys again after major releases. Regular testing makes progress and new problems traceable.

Set fixed triggers for a new test: a new template, a new plugin, a theme update or a changed checkout. You can repeat automated scans frequently to spot new technical errors early. Repeat the manual tests of the most important journeys after major changes.