Skip to main content
Start Free TrialBook a meeting
Web Content Accessibility Guidelines

WCAG testing that stands up to scrutiny

Automated scans, manual audits and assistive-technology testing - what each one catches, what each one misses, and the process that produces evidence rather than a score.

ADA compliance guide
WCAG testing is the process of checking a website against the success criteria of the Web Content Accessibility Guidelines. It has three layers: automated scanning, which reliably detects roughly a third of the criteria (contrast, alt text, labels, ARIA errors); manual expert review with keyboard and screen readers, which covers the judgement-based majority; and documentation, which turns results into evidence - an audit report or a VPAT. A credible WCAG test always combines all three; a score from a scanner alone is not conformance.

What is WCAG testing?

WCAG testing means evaluating pages against each applicable success criterion of the Web Content Accessibility Guidelines and recording a pass, fail or not-applicable result. Because every criterion is written as a testable statement, a WCAG test is closer to a technical inspection than to a review: two competent testers examining the same page should reach the same conclusions.

Testing is also the entry point to everything else in an accessibility program. You cannot remediate what you have not found, and you cannot claim conformance - in an accessibility statement, a contract or a VPAT - without test results behind the claim.

Automated vs manual WCAG testing

The single most important fact about WCAG testing: automation alone cannot determine conformance. Tools are precise about what they can see and blind to what they cannot.

Automated testingManual testing
CatchesContrast failures, missing alt attributes, unlabeled inputs, invalid ARIA, missing language, duplicate IDs, empty linksWhether alt text is meaningful, keyboard traps and focus order, screen reader announcements, error recovery, logical reading order, media quality
Share of criteriaRoughly one third, reliablyThe remaining two thirds
Speed and scaleThousands of pages per dayHours per template
RoleBreadth: every page, every releaseDepth: every criterion, on representative flows

How to run a WCAG test, step by step

  1. Define the sample. You do not test every page - you test every template and every critical user flow: home, navigation, search, forms, checkout or lead flow, PDFs, and anything behind login.
  2. Automated pass. Scan the whole site to map machine-detectable failures and their density. A single page takes seconds in the accessibility checker; full coverage comes from the crawler.
  3. Keyboard-only pass. Unplug the mouse. Every interactive element must be reachable in a sensible order, operable, and show a visible focus indicator. This one hour finds more Level A failures than any tool.
  4. Screen reader pass. Walk the critical flows with NVDA or JAWS on Windows and VoiceOver on Mac or iOS. Listen for names, roles, states and announcements of dynamic changes.
  5. Criterion sweep. Work through the remaining criteria systematically - zoom and reflow, text spacing, media, timeouts, motion - and record a verdict for each.
  6. Report. Every failure gets a location, the violated criterion, severity, and a recommended fix. Conformance claims get dated evidence. This is the difference between a test and an audit.

When to test - and when a test is not enough

Three triggers should always start a WCAG test: before a redesign ships (fixing templates pre-launch is ten times cheaper), after legal exposure changes (a demand letter, an EAA obligation, a public-sector bid), and on a schedule, because content teams break criteria without knowing it.

A point-in-time test decays from the day it finishes. If the site changes weekly, pair testing with continuous monitoring so regressions surface as they appear rather than at the next annual audit. And when the result needs to persuade someone else - a customer, a court, a regulator - the output must be documentation signed by certified auditors, not a dashboard screenshot.

Frequently asked questions

What is WCAG testing?

Evaluating a website against each success criterion of the Web Content Accessibility Guidelines and recording pass/fail results - through a combination of automated scanning and manual expert review.

Can I test WCAG compliance with a free tool?

Partially. Free automated checkers reliably detect roughly a third of the criteria and are the right first step. They cannot judge meaning, keyboard flows or screen reader behaviour, so a passing scan is not a conformance claim.

What is the difference between WCAG testing and an accessibility audit?

Scope and evidence. A test tells you what fails; an audit tests every applicable criterion on a defined page sample and produces documented, dated results that can support a VPAT or legal defence.

How often should a website be tested against WCAG?

A full audit at least annually or per major release, automated scanning continuously. High-change sites pair the two so regressions are caught within days.

Which screen readers should WCAG testing cover?

The practical minimum is NVDA or JAWS on desktop Windows browsers and VoiceOver on iOS - together they represent the large majority of screen reader use.

Sources
  • W3C WAI, Evaluating Web Accessibility Overview - w3.org/WAI
  • W3C, Website Accessibility Conformance Evaluation Methodology (WCAG-EM) - w3.org/TR/WCAG-EM
  • WebAIM, Screen Reader User Survey - webaim.org

Last updated . Reviewed by the EqualWeb accessibility team.

Test your site the way an auditor would

Start with a free automated scan, then let certified IAAP/CPWA specialists run the manual passes and hand you criterion-level documentation. No credit card required.

Book a meeting Start Free Trial