How to test your website's accessibility in an afternoon

A sequence you can run yourself, with no tooling you have to buy, that finds the barriers that matter most — and shows you exactly where automated testing stops being useful.

Before you start

Pick one page, not your whole site. Ideally the one that carries the most value — a checkout, a signup, a contact form. Templates repeat, so a finding on one product page is a finding on all of them.

Work in the order below. It is arranged so the cheapest passes come first and each one narrows what the next has to look at.

1. Run an automated pass (10 minutes)

Install a browser extension — axe DevTools, WAVE or Lighthouse’s accessibility audit — and run it.

What this finds: images with no alt, a missing lang attribute, form fields with no associated label, some contrast failures, duplicate ids, empty links and buttons.

What it cannot find: whether the alternative text is accurate, whether the focus order makes sense, whether your modal traps focus, whether your errors are announced, or whether the page is usable at all. A page can pass every automated check and still be impossible to use.

Treat the result as a list of cheap fixes, not as a score.

2. Unplug the mouse (30 minutes)

This is the highest-value half hour in the whole sequence.

Put the mouse out of reach. Then:

  • Press Tab once on load. A skip link should appear.
  • Tab through the entire page, watching the focus indicator. Never lose sight of it.
  • Open every menu, modal and dropdown. Tab inside. Press Escape. Tab back out.
  • Complete the primary task end to end.

Write down every place you lost the focus indicator, could not reach a control, could not activate one with Enter or Space, or could not escape.

If the focus ever disappears behind your sticky header, that is a WCAG 2.2 finding in its own right — 2.4.11 Focus Not Obscured.

3. Submit every form wrong (20 minutes)

Deliberately break each form: leave it empty, use a malformed email, a short password, an invalid card.

For each error, ask three questions. Is it stated in text, not only in colour? Is it associated with the field it refers to? Does it say how to fix it, rather than just that something is wrong?

Then do it again with a screen reader running, and listen. This is where most sites fail hardest and most quietly.

4. Turn on a screen reader (45 minutes)

You already have one. VoiceOver on macOS is Cmd+F5. Narrator on Windows is Ctrl+Win+Enter. Learn four commands and stop there — you are not trying to become a proficient user, you are trying to hear your own page.

Then listen for:

  • Do the headings, read as a list, form an outline of the page?
  • Do the links make sense read out of context, or are six of them “read more”?
  • Are icon-only buttons announced as anything other than “button”?
  • When something updates without a page load — a cart total, a filter, a “saved” message — is it announced at all?

An important caveat. You are not testing whether a screen reader user can use your site. You are finding places where it obviously says the wrong thing. That is worth a lot and it is not the same claim.

5. Zoom and reflow (15 minutes)

Set the browser to 1280px wide and zoom to 400%. The page must reflow into one column with no horizontal scrolling — this is 1.4.10 Reflow, and it covers desktop magnification, not just phones.

Then apply increased text spacing (line-height 1.5, paragraph spacing 2em, letter spacing 0.12em). Nothing may be clipped or overlap.

6. Turn off the colour (5 minutes)

View the page in greyscale. Anything you can no longer tell apart was relying on colour alone: required fields, error states, chart series, links inside body text, selected tabs, variant swatches.

What you will have, and what you will not

After an afternoon you will have found, realistically, the majority of the critical barriers on that page — because the critical ones are mostly keyboard and form failures, and those are what this sequence is built around.

What you will not have is confidence about what you missed, and that gap is the honest argument for an external audit rather than a sales one. Testing your own interface has the same blind spot as proofreading your own writing: you know what it is meant to do, so you operate it the way it expects to be operated. Someone who has never seen it does not.

You also will not have the thing a procurement questionnaire or a legal adviser asks for: findings reproduced, evidenced, mapped to success criteria, and dated.

Frequently asked questions

Can I test accessibility myself?

Yes, and you should — the sequence below finds real barriers in an afternoon with no budget. What you cannot do by yourself is be confident about what you missed. Testing your own work has the same blind spot as proofreading your own writing: you know what it is supposed to do, so you unconsciously operate it the way it expects.

What is the best free accessibility testing tool?

Your keyboard, followed by the screen reader already installed on your machine — VoiceOver on macOS and iOS, Narrator on Windows, TalkBack on Android. Browser extensions add a useful automated pass, but they decide around a third of WCAG criteria at best, and the third they decide is not the third that stops people completing tasks.

How long does a proper test take?

The sequence here takes an afternoon for one template. A professional audit of a single page takes longer, not because the steps differ, but because every finding has to be reproduced, documented with evidence, mapped to a criterion and turned into something a developer can act on.

Official sources

Regulatory requirements vary by jurisdiction, service, organisation and other factors. Uxerfy provides accessibility assessments and compliance-oriented information, not legal advice or legal certification. Consult qualified legal counsel for a determination of your obligations.

Check your own site

Prioritised findings, with the evidence and how to fix them.