How to test website accessibility: automated and manual

Testing for accessibility has two halves that need each other. Automated tools are fast and repeatable, and they find real bugs. They also cannot answer many of the questions that decide whether a person can use your site. This guide explains where that line sits, gives you a 15-minute manual routine you can run on any page, and shows where GotAlt's scan, deep audit and bookmarklet fit.

What automated testing catches, and what it misses

Automated tools check properties a program can read off a page: an attribute is missing, a heading level jumped, a form field has no label. Those checks are cheap, so a tool can run them on every page on every release. The limit is that a lot of accessibility is about meaning and behavior, which a program cannot judge from markup alone.

Karl Groves writes that an automated tool "can definitively test for approximately 25-29% of best practices for WCAG 2.0" and "cannot test for approximately 40%" (Karl Groves, Automated Lies with One Line of Code). Sources disagree on the exact share of WCAG that is machine-detectable, and roughly a third is the defensible framing. None of the figures here, or on our methodology page, put automated coverage anywhere near most of WCAG. Our methodology page and why scanners miss issues say the same.

Layer 1: automated checks

Start with automation, because it clears the cheap problems and shows how large the job is. GotAlt offers three kinds, which differ in what they can see.

• The free scan fetches a page, plus up to two linked pages, and runs 16 rule-based checks on the HTML your server sends. It is fast and repeatable. It does not see content a script adds afterwards, and it does not compute rendered colors. Run the free scan, and read what each check maps to on the methodology page.
• The bookmarklet runs in your own browser on the page as rendered. It works on a staging site, localhost or a page behind a login, and it measures the contrast of the text actually painted on screen. It sees one page, once, at the moment you click, and a site's security settings can stop a bookmarklet running. Text over images is listed for a manual check rather than guessed at. Get the bookmarklet.
• The deep audit adds a judgment that parsing cannot make. It downloads the images and asks a vision model whether each description is true, and it also reads link text and headings for sense. It opens up to six images per page, not all of them. See the deep audit, or use the alt text checker on one page.

Single-purpose tools help when you want to check one thing. The color contrast checker measures a pair of colors, the image contrast checker handles text over a photo, the heading checker and link text checker read HTML you paste in, and the PDF accessibility checker reads a PDF in your browser without uploading it. For the rendered page, including content added by scripts, the bookmarklet is the quickest check.

Whatever you use, read a clean result as "these checks found nothing", not as "this page is accessible".

Layer 2: a 15-minute manual routine

Run this on your home page, your most-used template and any page with a form. It uses nothing but a browser and, for step 3, a screen reader. W3C publishes a similar set of quick checks, Easy Checks, and describes them as quick rather than exhaustive: a page can seem to pass them and still have significant barriers.

1. Keyboard (4 minutes)

Put the mouse aside. Press Tab repeatedly from the top of the page and watch.

• Can you reach every link, button, field and menu item? (WCAG 2.1.1)
• Can you always move on again? If focus gets stuck in a widget, that is a keyboard trap. (WCAG 2.1.2)
• Can you always see where focus is? (WCAG 2.4.7)
• If the page repeats a block such as a menu, is there a way to skip it, for example a "Skip to content" link that works on the first Tab? (WCAG 2.4.1)
• Does focus follow the visual order, and do menus and dialogs open, close and return focus sensibly? Shift and Tab together move backward.

2. Zoom to 200 and 400 percent (3 minutes)

Text must be resizable up to 200 percent without assistive technology and without loss of content or functionality (WCAG 1.4.4 Resize Text, Level AA). Content must also reflow without scrolling in two dimensions at a width equivalent to 320 CSS pixels (WCAG 1.4.10 Reflow, Level AA), which W3C notes is a starting viewport 1280 CSS pixels wide at 400 percent zoom. So start from a browser window about 1280 CSS pixels wide (your browser's developer tools can set the width), then zoom with Ctrl and plus (Command and plus on a Mac) to 200 percent, then to 400 percent. W3C makes an exception for content that needs two-dimensional layout, such as maps, diagrams, video, games and data tables (the cells of a table must still reflow), so sideways scrolling inside one of those is not by itself a failure.

• At 200 percent, does any text get cut off, overlap or disappear?
• At 400 percent, does the page fit the width with no sideways scrolling to read a line, outside those exceptions, and with nothing lost?
• Are menus, search and the cart still reachable?

A page that disables zoom in its viewport tag is caught by the free scan before you start.

3. Screen reader basics (4 minutes)

You do not need to become an expert to learn a lot. Listen to one page with the screen reader that suits your computer, and compare what you hear with what the page shows. Different screen readers announce things differently, so treat one run as a sample, not a verdict.

• NVDA is free to download and runs on Windows 10 and later.
• Narrator is built into Windows 11 and starts with Windows, Ctrl and Enter pressed together.
• VoiceOver is Apple's screen reader for Mac, iPhone and iPad, and on a Mac Command and F5 turns it on and off (Apple on vision accessibility).

Check four things. Does each image announce something useful, or a filename, or nothing where a description is needed? Does the screen reader's list of headings read like an outline of the page? Does its list of links make sense without the surrounding text? Does each form field announce its label? Each screen reader documents its own shortcuts for those lists. WebAIM's guide to evaluating with NVDA lists the Elements List (NVDA plus F7, which shows links, headings and landmarks) and the H key to move between headings.

4. Color and contrast (2 minutes)

Run the bookmarklet to measure the text actually on screen against the 4.5:1 minimum (3:1 for large text) from WCAG 1.4.3. Then do what a tool cannot: look at the page and ask whether color alone is carrying meaning, such as an error shown only in red or a required field marked only by color (WCAG 1.4.1). Check text over photos with the image contrast checker, and hover and focus states yourself. The color contrast guide has the thresholds and method.

5. Forms (2 minutes)

Find a form and use it with the keyboard only. Does every field have a visible label that stays when you type? Submit the form empty and then with a mistake. When an error is detected, the field in error must be identified and the error described in text (WCAG 3.3.1). Does focus move to the problem, and can a screen reader user find the message?

Where GotAlt's tools fit in a testing plan

A reasonable rhythm is the free scan after each release, the bookmarklet on the pages you just changed, and the manual routine on key templates before launch and after any redesign. Paid plans re-check the pages you nominate every week, which keeps the automated layer running between your own tests.

Test with people, and keep a record

The strongest test is a person who uses assistive technology every day, working through a real task on your site: finding a product, filling a form, checking out. Even a few sessions show problems no checklist predicts. W3C's pages on involving users in evaluating web accessibility and on the WCAG-EM evaluation methodology explain how to do each. Keep a dated record of what you tested, with which tools and browsers, and what you found, because it becomes the accurate basis for your accessibility statement.

If you are working through a fix list as well, how to make a website accessible orders the work, and the six most common accessibility errors shows what tends to turn up first. For criterion-by-criterion detail, use WCAG 2.2 explained and the WCAG 2.2 checklist.