How to test website accessibility: free tools and manual checks

Here's a story we hear often. Someone runs Lighthouse, gets a green 100 for accessibility and moves on. A week later a customer writes in to say they couldn't pay, because the card form can't be reached with a keyboard. Both things are true. The automated check passed, and the site still failed a real person.

This guide shows how to test properly on a small budget: which free tools to run, a 15-minute manual routine, a first go with a screen reader, and when to pay for an audit.

Can an automated checker tell me if my website is accessible?

No. Automated checkers find some problems quickly, but many accessibility questions need a person to answer them. When the UK Government Digital Service tested 10 tools on a page with 143 known failures, the best found 41%. W3C puts it plainly: evaluation tools “can not determine accessibility, they can only assist in doing so.”

The GDS test (opens in a new tab) dates from February 2017, and its 41% (from Asqatasun) included the tool's prompts for manual checks. Tools have improved since, but the gap has the same cause. Software can tell that an image has no alt text. It can't tell that “red dress” is the wrong description for a photo of a blue suit, or whether your focus order makes sense.

So treat a checker as a smoke alarm, not a building survey. It's still worth running: the WebAIM Million 2026 (opens in a new tab) found detectable failures on 95.9% of the top one million home pages, so most sites have quick wins waiting. As W3C's guide to choosing tools (opens in a new tab) says, “Human judgement is required.”

Which free accessibility testing tools should I use?

Use one or two automated checkers, a contrast checker and a screen reader. Tools apply different rules and report results differently, so two checkers usually catch more than one. Every tool below has a free version. Check each one's current terms before you rely on it, because names, features and pricing change.

What can I check by hand in 15 minutes?

Quite a lot. W3C's Easy Checks (opens in a new tab) cover page titles, alt text, headings, contrast, skip links, visible keyboard focus, page language, zoom, captions and form labels. Pick one important page, such as a product page or your booking form, and give each check a minute or two. You'll find things no checker reports.

W3C says these checks “cover just a few accessibility issues”, so they aren't a full evaluation. They're still the best quarter of an hour you can spend:

1. Page title (1 minute). Does the browser tab say what the page is, such as “Book a table | Rosa's Kitchen”, rather than “Home” everywhere?
2. Images (2 minutes). Show the alt text with WAVE or similar. Is it accurate? Is decoration skipped?
3. Headings (2 minutes). List the headings and read them on their own. Do they work as a table of contents?
4. Contrast (2 minutes). Check body text, small grey text, button text and text over images.
5. Keyboard (4 minutes). Put the mouse aside and Tab through the page (see the next section).
6. Zoom (2 minutes). At 200%, then 400%, can you still read everything and use the menu without scrolling sideways?
7. Forms and language (2 minutes). Click each field's label; in a well-built form that puts the cursor in the field. Check the tool's report for a missing page language.

How do I test with a keyboard?

Put the mouse away. Press Tab to move forward, Shift+Tab to go back, Enter to follow links, Space or Enter to press buttons, and the arrow keys inside menus and radio buttons. Every interactive element should be reachable, you should always be able to see where you are, and you should never get stuck.

On a Mac, Safari skips links when you press Tab until you turn on “Press Tab to highlight each item on a webpage” in its Advanced settings. Then check:

• Can you always see where you are? If the focus outline disappears, a keyboard user is lost.
• Is the order logical? Focus should follow the reading order.
• Is anything covered? A sticky header or cookie banner hiding the focused element fails WCAG 2.2's Focus Not Obscured criterion.
• Can you get out again? Open every menu, pop-up and date picker, then try to leave. Escape should close dialogs.
• Does the whole journey work? Add a product, change the quantity, apply a voucher and reach payment without the mouse.

Write each failure down precisely: “Size selector on the product page can't be opened with Enter or Space” gets fixed far faster than “keyboard doesn't work”.

How do I test with a screen reader for the first time?

Start with the screen reader your device already has, or NVDA on Windows, and listen to one page. You're not trying to use it like an expert. You're checking that headings, links, buttons, images and form fields are announced with sensible names, and that nothing important is silent.

• Mac: Command+F5 turns VoiceOver on and off; Control+Option+U opens the rotor, a list of headings, links and form controls.
• Windows: in NVDA, press H to jump between headings and Insert+F7 to list links and headings.
• Phone: turn on VoiceOver (iPhone) or TalkBack (Android) and swipe right to move from item to item. Learn how to switch it off first.

Listen for what matters most. In WebAIM's 2024 screen reader survey (opens in a new tab), 71.6% of respondents said they first navigate a long page by its headings, so start there. Then pull up the links list: five links called “Read more” tell nobody anything. “Add to basket, navy jumper” is a useful button; “button” isn't. Finally, fill in a form and check that every field and error is read out.

Keep your conclusions modest. If it sounds broken to you, it probably is; if it sounds fine, that isn't proof. For how experienced users actually work, read how disabled people use the web.

How do I check zoom, reflow and text spacing?

Zoom your browser to 200% and check that text grows without being cut off or overlapping. Then test reflow: at 400% zoom in a window 1,280 pixels wide, content should fit without sideways scrolling. Finally, increase the spacing between letters, words, lines and paragraphs, and check that nothing breaks or disappears.

These map to WCAG's Resize Text (1.4.4), Reflow (1.4.10) (opens in a new tab) and Text Spacing (1.4.12) (opens in a new tab). Reflow uses a 320 CSS pixel width, which W3C notes “is equivalent to a starting viewport width of 1280 CSS pixels wide at 400% zoom.” Text Spacing asks that nothing is lost when a reader sets line height to 1.5 times the font size, paragraph spacing to 2 times, letter spacing to 0.12 times and word spacing to 0.16 times.

A text-spacing bookmarklet, a small script saved as a bookmark, applies all four values in one click. Look for text spilling out of buttons and labels cut off at the edge. At 400% zoom a laptop shows roughly what a small phone does, so a well-built responsive site passes much of this already.

How do I check forms, errors and checkout?

Fill in each important form three times: once correctly, once with every field empty, and once with deliberate mistakes. Every field should have a visible label, every error should be explained in words next to its field, and you should be able to paste into password and verification-code fields.

• Errors. “Invalid input” in red isn't enough. “Enter the expiry date as MM/YY”, next to the field, is. After submitting, focus should move to the error summary or the first problem field.
• Logins and codes. Under WCAG 2.2's Accessible Authentication criterion (opens in a new tab), blocking paste or password managers fails unless there's another way in.
• CAPTCHAs and time limits. Screen reader users ranked CAPTCHA the most problematic item on the web in WebAIM's survey. Check for an accessible alternative, and that time limits can be extended.

Our website accessibility checklist has a fuller list for shops, including cookie banners and pop-ups.

What does a professional accessibility audit include, and when do I need one?

An accessibility audit is a specialist's structured review against a named standard, usually WCAG 2.1 or 2.2 Level AA. It combines automated scans with manual and assistive-technology testing of your key templates and journeys, and ends in a prioritised report. You need one when the law applies to you, before a major launch, or when clients ask for evidence.

Before you agree a price, ask:

• Which standard, version and level will you test against?
• Which templates and journeys are in scope? For a shop: home, category, product, basket, checkout, account pages and forms.
• Do you test by hand with screen readers, keyboard and zoom, and on which browsers and devices?
• Does the report rank issues by severity, locate them and suggest fixes?
• Is a re-test included?

Prices vary widely with provider, country and scope, so compare what's included. If the European Accessibility Act covers you, an audit also backs up your public statement; our guide to the EAA explains who's covered.

Why test with disabled users?

Because meeting a standard and being easy to use aren't the same thing. A checkout can pass every WCAG criterion and still take a screen reader user twenty minutes. W3C says that evaluating with disabled users “identifies usability issues that are not discovered by conformance evaluation alone”, and it shows your team how people really use the site.

You don't need a lab. A handful of sessions on your most important task, such as finding a product and paying, will teach you more than another round of scans. Recruit through disability organisations, research agencies or your own customers, and pay people for their time. Let them use their own devices and settings. W3C's guide to involving users in evaluation (opens in a new tab) covers the practical side.

What do I do with the results?

Sort the issues by how badly they block people and where they happen, fix them in the site's own code and content, test again, and record what's still outstanding. An unlabelled field in the checkout matters more than a contrast slip in the footer, and a fix in a shared template repairs every page that uses it.

1. Prioritise. Blockers on key journeys (checkout, booking, sign-up) first, then shared templates, then one-off pages.
2. Fix at the source. Change the theme, component or content, not just the symptom.
3. Re-test. Repeat the same checks, by hand as well as with tools.
4. Document. List known issues, with dates, in your accessibility statement. Our guide to WCAG 2.2 explains the newer criteria.
5. Repeat. Add a keyboard check and a scan to every release.

If you use an accessibility widget, ours included, test with it closed. A panel like SiteAccessible gives visitors extra ways to adjust the page, but WCAG asks whether the page works in its default state. Some audit schemes won't assess pages running an overlay script, so check with your auditor first.