Testing website accessibility: automated vs. manual

You test website accessibility in two layers: an automated scan that quickly finds the measurable errors, and a manual check for everything a human has to judge. Automated tools such as axe-core, Lighthouse and WAVE find missing labels, empty links and incorrect ARIA. Whether alt text is accurate, whether your checkout works with only a keyboard and whether a screen reader reads your form out in a logical order is something no tool can see.

This article is part of our complete guide to website accessibility. Here you get an honest picture of what automated tools can and can't do, a step-by-step manual testing routine, W3C's official evaluation methodology and advice on how often to test.

The standard you test against is WCAG, W3C's Web Content Accessibility Guidelines. In Europe, level AA is usually the target. Which requirements that covers exactly is explained in WCAG 2.2 explained.

#What can automated tools do?

Automated accessibility tools check rules that can be derived objectively from the code, such as whether an image has an alt attribute or an input field has a label. They are fast, repeatable and suitable for running with every release. There are three tools you will come across most often.

axe-core is Deque's open-source testing library. According to the README on GitHub, axe-core has rules for WCAG 2.0, 2.1 and 2.2 at level A, AA and AAA, plus rules for best practices. Deque aims for zero false positives: an error axe-core reports should, in principle, really be an error. Borderline cases are marked by axe-core as "incomplete", with a note that manual review is needed.

Lighthouse is built into Chrome DevTools. According to the documentation on how the score is calculated, the accessibility score is a weighted average of automated audits, with weights based on axe's impact assessment. Each audit maps to an axe-core rule. Lighthouse lists manual checks separately, but they don't count towards the score.

WAVE from WebAIM shows errors and alerts as icons on your page. The browser extension tests the page as it is rendered in your browser, so also after JavaScript has run. The WAVE help page puts it plainly: WAVE can't tell you whether your content is accessible; only a human can determine that.

How many issues does an automated tool find? In 2021, Deque published its own study based on more than 2,000 audits. According to Deque, automated testing with axe covered an average of 57 percent of the issues found by volume. Two caveats: it is research by the vendor itself, and it counts issues by volume, not by success criteria. Common errors therefore carry a lot of weight. For your site, the share may turn out higher or lower.

#What can't automated tools do?

Automated tools can't judge whether something is understandable, logical or usable, and that is exactly where many of the most serious barriers are. A few examples that no scanner reliably catches:

• Quality of alt text. A tool sees that alt text is present, not whether "IMG_4032.jpg" or "image" describes the photo.
• Keyboard operation of custom components. A dropdown menu that only responds to a mouse click, or a pop-up that traps the focus, only shows up when you try it yourself.
• Logical focus and reading order. The code can be valid while the focus jumps from the header to the footer.
• Meaningful error messages. A tool can't see whether "Invalid input" helps the visitor solve the problem.
• Behaviour when zooming and reflowing. Overlapping text or cut-off buttons at 400 percent zoom only show up on screen.
• Content that only appears with JavaScript, if the tool reads only the raw HTML.

Colour contrast sits somewhere in between. axe-core has a contrast rule, but it only works on a page that is actually rendered. Text on a background image or gradient often produces an "incomplete". So measure contrast manually with a contrast checker as well.

#Automated or manual: by type of check

How much an automated tool can establish varies greatly by type of check. This table gives a practical overview of the most common checks.

The conclusion from the table: automated testing is a good first filter, but a large share of the criteria require human judgement. An overview of the errors we see most often in both layers is in most common accessibility errors.

#A step-by-step manual testing routine

A basic manual test doesn't require specialist software and finds exactly the problems scanners miss. Run these steps for each type of page: home, category, product, form and checkout.

1. Put your mouse away. Navigate with Tab, Shift+Tab, Enter, the space bar and the arrow keys. Can you reach every link, button and field? Is the focus always visible? Can you open and close menus, pop-ups and the cookie banner without getting stuck?
2. Check the order. Does the focus follow the visual reading order? Does the page start with a skip link to the main content?
3. Zoom to 200 percent. Use your browser's zoom. According to WCAG 2.2 (criterion 1.4.4), text must be resizable up to 200 percent without loss of content or functionality.
4. Test reflow at 400 percent. On a window 1280 pixels wide, zoom to 400 percent; that is equivalent to 320 CSS pixels. Criterion 1.4.10 requires the content to remain readable without horizontal scrolling, except for content such as tables or maps.
5. Measure contrast. Use a contrast checker or the colour picker in DevTools. Normal text needs at least 4.5:1, large text 3:1 (criterion 1.4.3).
6. Listen with a screen reader. Use NVDA on Windows or VoiceOver on a Mac or iPhone. Go through the headings, open a form and submit it with an error. Are labels, required fields and error messages read out?
7. Check forms separately. Do fields have visible labels, are the autocomplete values correct and does an error message appear as text next to the right field? More on this in accessible forms and checkout.
8. Write down what you find. For each issue, record the page, the criterion, the steps to reproduce it and the severity. You will also use this list when writing an accessibility statement.

For a first introduction, you can also follow W3C's Easy Checks. They warn themselves that a page can pass these quick checks and still have significant barriers.

#W3C's WCAG-EM methodology

WCAG-EM is W3C's evaluation methodology for determining to what extent a website or digital product conforms to WCAG. According to W3C's overview page, WCAG-EM 2 was published on 23 July 2026 as a W3C Group Note. The methodology adds no new requirements to WCAG, but describes how to set up an evaluation. Version 2 extends the approach from websites to apps and other digital products.

The methodology has five steps:

1. Define the scope: what does the evaluation cover, what is its goal and which level (A, AA or AAA)?
2. Explore the product: which key screens, functions, types of content and technologies are there?
3. Select a representative sample: a structured selection supplemented with random pages, if you can't test everything.
4. Evaluate the sample: check each page against the success criteria and record how you tested.
5. Report the findings: bring the results together and draw your conclusions.

W3C offers a free WCAG-EM Report Tool for this. For a web shop, step 3 is the most important: always include the complete ordering process, from product page to confirmation.

#Testing with people with disabilities

User testing with people with disabilities uncovers usability problems that a conformance check against WCAG doesn't bring to light. In Involving Users in Evaluating Web Accessibility, W3C gives some clear advice.

• Fix the obvious errors first, so testers don't get stuck on something you could have found yourself.
• Involve users during development, not only at the end.
• Don't assume one person speaks for everyone with the same disability.
• Always combine user testing with an evaluation against WCAG, because user testing alone doesn't determine whether your site conforms.

For a small business web shop, this doesn't have to be a big study. Three or four sessions in which someone using a screen reader, screen magnification software or only a keyboard orders a product often already produce concrete improvements.

#How often should you test?

How often you test depends on how often your site changes, but a fixed cycle in three layers works for most businesses.

Pay particular attention to changes that bypass your development team. A new chat widget, a different cookie banner or a payment step from a third party can make an accessible site less accessible in one go.

#Where Flowproof fits into this process

Flowproof is the automated first layer, not a replacement for manual testing. The accessibility check runs axe-core on your page's HTML and tests against WCAG 2.0, 2.1 and 2.2 at level A and AA. For each rule found, you see the success criterion, the level and the severity.

What the scan deliberately doesn't do: measure colour contrast automatically. That requires actual rendering in a browser, so Flowproof reports contrast as something to check manually. If your page only builds its content with JavaScript, the scan warns you that only the base HTML was tested. Flowproof also checks whether you have a link to an accessibility statement, whether there is a skip link and whether any audio plays automatically. The accessibility score is separate from the GEO score.

#How to check this on your own site

1. Run an automated scan on your homepage, a category page, a product page, your contact form and every step of the checkout.
2. Fix the most severe errors first, such as missing labels and buttons without a name.
3. Do the manual routine from this article on the same pages: keyboard, 200 percent zoom, 400 percent reflow, contrast and a screen reader.
4. Record your findings with page, criterion and severity, and include known issues in your accessibility statement.
5. Plan the next round: automated with every release, manual for new components and a full evaluation following WCAG-EM once a year.

Flowproof's accessibility check is included in the paid Pro and Business plans. You can start for free and compare the plans on the pricing page.