A website accessibility review process that goes past the automatic checks
Automated checks catch the mechanical problems: a missing language, missing alt text, focus you can't see. They can't tell you whether a person using a keyboard, a screen reader or 200 per cent zoom can actually book an appointment. A sound review runs the automatic checks first, then has a person try the site's main jobs with each of those tools, and fixes what they trip over.
What is already checked, and what isn't
On an Anticode site, some basics are enforced before publishing. The design gate blocks pages that lack a declared language, a phone viewport, visible keyboard focus, support for reduced motion or alt text on images. That's a useful floor, and it means your review time goes on the things a machine can't judge.
| Question | Who answers it |
|---|---|
| Is a page language declared? | The design gate, before publishing |
| Can you see where keyboard focus is? | The design gate checks a focus style exists; a person checks it's visible on every background |
| Do images have alt text? | The design gate checks it's present; a person checks it says something useful |
| Does animation respect a reduced-motion setting? | The design gate |
| Can someone complete the booking form with a keyboard alone? | A person |
| Does the page make sense read aloud, in order? | A person with a screen reader |
| Does text stay readable at 200 per cent zoom? | A person |
| Is the wording plain enough to follow? | A person, ideally not the author |
Before you start
- List the site's three most important jobs, such as reading the opening hours, sending an enquiry and finding the phone number. The review follows these, not every page at random.
- Pick your tools. VoiceOver is built into Macs and iPhones; NVDA is a free screen reader for Windows; TalkBack ships with Android. One of them is enough for a small site.
- Set aside an hour and a spreadsheet with columns for page, problem, who it affects and fix.
- Run the release checklist in Anticode first, so you aren't reviewing a version that would fail a publish check anyway.
The review, step by step
- Keyboard only. Unplug the mouse or ignore the trackpad. Press Tab from the top of each page. Every link and button should receive focus in the order you read it, the focus outline should be visible every time, and you should be able to finish each of your three jobs. Note anywhere focus disappears or jumps.
- Zoom. In a desktop browser, zoom to 200 per cent, then 400 per cent. Text should reflow into one column without words being cut off or forcing sideways scrolling. Check the navigation still opens.
- Screen reader. Turn it on and listen to the home page from the top. Does it announce the page name? Do headings come in a sensible order? Do links say where they go, or are there five that just say "read more"? Then complete one form with it running and listen for each field's label.
- Images. For each photo, read its alt text without looking at the picture. Would you know why it's there? A team photo described as "image" fails; "The four clinic staff outside the front door" passes. Decorative pictures can be described briefly.
- Colour and contrast. Run a free contrast checker over body text, buttons and any text placed on a photo. Make sure nothing relies on colour alone, such as a required field shown only in red.
- Motion. Switch on your device's reduce-motion setting and reload. Anything that slides or fades should calm down.
- Plain language. Ask someone outside the business to read the services page and tell you what you offer and how to book. If they hesitate, the copy needs work.
Fixing what you find
Sort the spreadsheet by impact: anything that stops a job (a form someone can't send) comes before anything that slows it. Most fixes on an Anticode page are small. Rewrite vague link text or headings in the visual editor. For alt text that's present but unhelpful, or a section in the wrong order, ask for the change in a sentence, for example "describe the hero photo as the bakery counter at opening time". After each batch of fixes, run the release checklist again and repeat the keyboard test on the pages you touched.
Write down what you fixed and when. If you publish an accessibility statement, this log is what it's based on, and it shows good faith if someone reports a problem later.
Who should do it, and how often
In a small business the person who knows the site best should run the first review, then hand the plain-language step to someone who doesn't. Repeat the keyboard and screen-reader steps after any redesign, any new form, and once a year as part of an annual website review. Best of all, invite a disabled user to try the site and pay them for their time: they'll find things a checklist won't.
What Anticode doesn't do here
Anticode doesn't run a screen reader, test with real users, or certify a site against WCAG or any law. The design gate catches missing basics; it doesn't judge whether alt text is any good or whether a page is easy to understand. Files you link to, such as PDFs hosted elsewhere, are outside its checks entirely. For the design side, see focus state design and zoom and reflow.
Questions people ask
Is an automated checker enough on its own?
No. Automated tools find missing attributes and some contrast problems, but not whether a form makes sense when read aloud or whether a person can finish a task. Use them first, then test by hand.
Which screen reader should I use?
Whichever is built into the device you have: VoiceOver on a Mac or iPhone, TalkBack on Android, or the free NVDA on Windows. Learn five commands and test your three main tasks.
How long does a website accessibility review process take for a small site?
An hour or two for a five-page site, plus time to fix what you find. Repeat the shorter keyboard check after each significant change.
Does passing the design gate mean my site is accessible?
It means certain basics are present. Accessibility depends on how real people get on with the site, which only testing shows.