How to Test for WCAG Accessibility: A Practical QA Guide

A green scan is not an accessible product

An axe run, a WAVE overlay, or our free accessibility scanner will catch missing alt text, empty buttons, and a lot of contrast failures. That is useful. It is also only about a third of the work. Keyboard traps, screen reader names, focus order, and “this flow makes no sense if you cannot see the page” do not show up as a red badge.

WCAG accessibility testing is the rest of that job. RedQA still specialises in Playwright, Cypress and Selenium. Accessibility sits next to that suite: automated rules in CI, then a human with a keyboard and a screen reader on the journeys that matter.

Related reading: what WCAG 2.2 added, the most common WCAG failures, and the European Accessibility Act.

What you are actually testing

WCAG is organised around POUR: perceivable, operable, understandable, robust. For most product teams the target is WCAG 2.2 Level AA. The European Accessibility Act still points at 2.1, but 2.2 is backwards compatible. Building to 2.2 AA now is the safer default. See the 2.1 vs 2.2 comparison if you need the criterion list.

You are not testing “the homepage”. You are testing journeys:

• Land, read, and find the next action
• Sign in, including password managers and accessible authentication
• Search, filter, buy, book, or submit a form
• Errors, validation, and the path to help
• Dynamic UI: modals, menus, tabs, toasts, chat

If a journey cannot be completed with keyboard only, or the screen reader cannot name the control that submits it, the page has failed even if the scan is clean.

Layer 1: automated rules, including in CI

Start here every time. It is cheap, repeatable, and it stops regressions on the issues tools can see.

• Run the RedQA scanner on public URLs for a baseline
• Put axe (or equivalent) on critical pages in Playwright, Cypress or Selenium
• Fail the pull request on serious and critical violations, not on a PDF that nobody reads
• Re-scan after design-system or CSS token changes. Contrast failures love a “small palette tweak”

Do not treat a zero-issue report as a pass. Automated tools typically find roughly 30 to 40 percent of WCAG issues. Forms without a visible label that still have a placeholder, a dialog that never receives focus, a skip link that goes nowhere: those need a person.

If you only want the five-minute version of a scan, use How to Run a Free Website Accessibility Audit in 5 Minutes.

Layer 2: keyboard, focus and structure

Unplug the mouse. Tab through every in-scope journey.

What to check

• Tab order matches the visual order, and nothing useful is skipped
• Focus is always visible, including under sticky headers (WCAG 2.2 focus criteria)
• No keyboard trap in modals, cookie banners, date pickers or chat widgets
• Enter and Space activate buttons and controls the way click does
• Escape closes dialogs and returns focus to the control that opened them
• Headings form a real outline, not a pile of styled divs
• Forms have programmatic labels, error text tied to the field, and a name that still makes sense when the layout collapses

Target size and drag alternatives matter on 2.2. If a filter only works as a drag, there must be a click or keyboard path as well. Mobile has its own list: mobile accessibility testing.

Layer 3: screen readers and assistive tech

Pick the combinations your users actually use. For a typical UK or EU web product that means NVDA or JAWS with Chrome or Firefox on Windows, VoiceOver with Safari on macOS and iOS, and TalkBack on Android for the mobile app.

Listen, do not only watch:

• Does the control announce its name, role and state? “Button, collapsed” is a pass. “Click here” is not
• Do live regions tell the user a search finished, or a cart updated, without shouting on every keystroke
• Are images informative or silent? Decorative marks need empty alt, not a filename
• Do tables, tabs and custom widgets use real semantics or a div soup with leftover ARIA

ARIA is not a shortcut around native HTML. Wrong ARIA is worse than none. If a native button, link, or input will do, use it.

Playwright still belongs in the accessibility suite

Accessibility is not a one-off PDF. The same delivery pattern we use for functional QA applies here: critical path first, then CI/CD.

• axe (or similar) on the authenticated journeys in Playwright
• A keyboard smoke: tab to the primary action and activate it without a mouse
• Assert skip links, dialog focus, and “name, role, value” on the controls that take money or data
• Re-run after each design-system release

Cypress and Selenium can carry the same checks if that is already your stack. The tool is not the point. The point is that an accessibility failure on checkout is a release blocker, not a backlog tag.

What a first accessibility engagement looks like

You do not need to boil the ocean. You need a scope, a target standard, and a list the engineers can fix in priority order.

1. Agree the journeys and the bar: usually WCAG 2.2 AA, plus EAA if you sell in the EU
2. Automated baseline on those URLs
3. Keyboard pass on every in-scope flow
4. Screen reader pass on the same flows, with traces (what was announced, where it broke)
5. A report mapped to success criteria, severity, and a remediation order. Then re-test the fixes

That is the core of our accessibility testing work. The scanner is the starting point. The audit is the thing you can defend.

Get a quote if you need a WCAG audit, EAA help, or axe wired into Playwright. Or run a URL through the free scanner today.