WCAG Checklist: What Scans Miss, From Keyboard to Screen Reader

A WCAG checklist is a compact set of tests mapped to WCAG 2.2 AA, and the quickest way to use one is to run an automated scan with Axe or Wave, then try a keyboard and screen reader smoke test. That mix mirrors what Gov expects of public sector teams, and it can help you spot real barriers.

TL;DR:

• Keep normal text at least 4.5:1 contrast, large text at 3:1, focus indicators at 3:1, and touch targets at least 24 by 24 CSS pixels.
• Automated tools catch only 30% to 70% of issues, so validate markup, test keyboard behavior, and check labels with a screen reader.
• Sample the homepage, contact page, each page template, every form, and newly published documents; repeat lightweight checks with every release and audit before a major launch.
• Fix keyboard traps, missing essential image descriptions, and unlabeled fields first; then address contrast, focus visibility, captions, transcripts, and unclear links.
• Put automated checks in continuous integration, add keyboard testing to quality assurance signoff, and train content authors to review image descriptions and link text.

Table of Contents

• What should you check on every page against WCAG 2.2 AA?
• How do automated, manual and assistive technology tests fit together?
• How many pages should you sample, and how do you keep evidence?
• What should you fix first?
• Why accessibility only works as a habit
• Need a hand running an accessibility audit?
• FAQ
• Sources

What should you check on every page against WCAG 2.2 AA?

WCAG 2.2 keeps its success criteria organised under four principles: perceivable, operable, understandable and robust. Run the checks below on every representative page, not just the homepage.

Perceivable: can people see, hear or otherwise take in the content?

• Check that every meaningful image has alt text that says what the image is for, and that decorative images have empty alt attributes.
• Look for images of text. If a headline is a picture, a screen reader user gets nothing.
• Measure colour contrast: 4.5:1 for normal text and 3:1 for large text. Low contrast is one of the most common issues accessibility specialists find, along with reliance on colour alone.
• Confirm that video has captions and that audio has a transcript.

Operable: can people use it without a mouse?

• Tab through the whole page. Keyboard testing should confirm that every interaction works, focus is never trapped, a working skip link exists and focus is visible.
• Make the focus indicator clear enough to spot, with at least 3:1 contrast against its surroundings.
• Make touch and click targets at least 24 by 24 CSS pixels, the WCAG 2.2 guidance.

Understandable: does it make sense?

• Write link text that works out of context. “Read our pricing” beats “click here”.
• Keep navigation consistent from page to page.
• Give every form field a visible label, offer error messages that suggest a fix, and avoid authentication steps that rely on memory puzzles.

Robust: will it work with assistive technology?

• Use semantic HTML before reaching for ARIA. A real button beats a styled div.
• Where ARIA is needed, make sure name, role and value agree with what the element does.
• Set the page language attribute and give every page a unique, descriptive title.

If you want the design side of this, our guide to website design best practices covers the layout and structure habits that make these checks easier to pass.

How do automated, manual and assistive technology tests fit together?

No single method catches everything. Automated tools typically detect between 30% and 70% of issues, so layered testing is what finds the rest. GDS experts compare scanners to a spellchecker: brilliant at high-volume, low-complexity errors, useless at judging whether a journey makes sense.

The DWP workflow is a good template: validate the HTML, run automated tools, test manually, then use assistive software. Here is a smoke test you can run on any page:

1. Validate the HTML and fix any broken markup that could confuse assistive technology.
2. Run Axe or Wave and note every flagged issue.
3. Tab through the page, checking focus order, the skip link, visible focus and any keyboard traps.
4. Hover and focus on menus and tooltips to check that revealed content can be dismissed and reached by keyboard.
5. Check reading order by reading the page top to bottom as a linear sequence.
6. Launch a screen reader and listen for sensible headings, labels, button names and form errors.

For the screen reader step, common pairings are NVDA or JAWS with Chrome or Edge, and VoiceOver with Safari. Try navigating by headings, jumping through landmarks and tabbing through a form. If you hear “button” with no name, or “edit text” with no label, you have found a defect.

Pro Tip: Do your first screen reader pass with the monitor off or the screen dimmed. You will notice missing labels far faster when you cannot cheat with your eyes.

How many pages should you sample, and how do you keep evidence?

You do not need to test every URL. GOV.UK describes simplified testing, with a small sample plus automated tools and quick manual checks, and detailed testing, where a wider sample is tested against every relevant success criterion. Pick the core pages:

• The homepage and contact page
• One page from each representative template (article, product, listing)
• Every form, including search and checkout
• Any newly published PDFs and other documents

Run lightweight checks on every release. Public sector guidance says to test regularly during development and get a formal audit before public beta, and the same rhythm suits any commercial site before a major launch. It matters because defects creep back in during updates, so one audit is never enough.

For every failure, record:

• The page URL
• The WCAG criterion failed
• A short description, with a screen capture or Axe output
• The fix owner and a retest deadline

What should you fix first?

Triage by user harm. Anything that blocks someone outright comes first, then visual problems, then clarity.

1. Blockers: remove keyboard traps, add alt text to essential images, and tie every form label to its input with matching for and id attributes. These are often quick fixes.
2. Visual issues: darken low-contrast text and add a clear focus style, such as a thick outline in a high-contrast colour. Expect a short design-system change that fixes many pages at once.
3. Media: add captions to video and transcripts to audio. Effort depends on volume, so log it as a content task with its own estimate.
4. Content clarity: rewrite vague links and fix heading levels so they follow a logical outline.

When logging in your issue tracker, tag each ticket small, medium or large, so the team can clear quick wins in the same sprint. If a redesign is already planned, fold these fixes into it, as our website redesign guide suggests.

Why accessibility only works as a habit

My view: accessibility checklists fail when they live in a document nobody opens. Put automated checks in your CI pipeline so regressions fail the build, add the keyboard test to QA sign-off, and schedule periodic assistive technology audits. Teach content authors to check alt text and link wording before they hit publish. Then use retrospectives to ask why the same issue keeps returning, and fix the root cause in the component or template. Inclusion is also a design question, as this piece on why inclusive design matters argues.

— Amir

Need a hand running an accessibility audit?

We offer web design and development that follows accessibility best practice. For current service details, see our web design and development services. You get a clear list of what to fix and who should fix it.

• Accessible redesigns built around semantic, keyboard-friendly templates

Take a look at our web design and development services, then contact us to talk about an audit or an accessible rebuild.

FAQ

What is a WCAG checklist?

A WCAG checklist is a list of practical tests, each mapped to a success criterion in the Web Content Accessibility Guidelines. WCAG 2.2 groups them under four principles: perceivable, operable, understandable and robust. Use it to check each page and record what passes or fails.

Which WCAG level should my website meet?

Aim for WCAG 2.2 AA. UK public sector websites and apps are legally required to meet it, and private sites that follow it are far less likely to exclude visitors. Check the regulations that apply to your organisation before assuming you are exempt.

Can automated tools check WCAG compliance on their own?

No. Automated tools such as Axe and Wave are a good first pass, but they miss problems with sequence, meaning and interaction. Pair them with manual checks and assistive technology testing to cover the rest.

How often should I run accessibility checks?

Run lightweight checks on every release and a formal audit before any major launch. Accessibility is continuous work, because updates can reintroduce defects that were already fixed.

Sources

• Exeter
• Keyboard accessibility: How to test – DWP Accessibility Manual
• What’s New in WCAG 2.2 | Web Accessibility Initiative (WAI) | W3C

Recommended

• Website design best practices: top 10 for better UX
• Website redesign guide 2026: plan it right

Amir WanasDirector, founder, AMW Media

Founded AMW Media in 2024 and runs strategy, paid media and the CRM builds. The reason everything here is in house and measured in revenue. Meet the team.