How to Test a Website for WCAG Conformance

What accessibility testing for WCAG conformance means

Accessibility testing for WCAG conformance checks whether web content meets the Web Content Accessibility Guidelines (WCAG) success criteria at a chosen level. The tests combine automated scanners, manual inspection, and real-world checks with assistive technology to show whether pages meet the stated WCAG level and which issues remain.

WCAG versions and conformance levels

WCAG is published as a series of versions and grouped by conformance levels: A, AA, and AAA. A test should name the WCAG version used and the target level. Test scope must list which pages, components or user journeys were included and which were excluded.

How to plan a WCAG conformance test: step-by-step

1. Define scope. Pick representative pages and interactive components. Include public pages, templates and key apps or flows.
2. Set the target level and WCAG version. Record this in the test brief.
3. Create a test matrix. Map success criteria to pages and components for sampling.
4. Choose tools and testers. Combine automated tools, an accessibility specialist, and at least one screen reader user when possible.
5. Run automated scans to find likely violations and common errors.
6. Manually verify each automated finding and test criteria that need judgement, like keyboard focus and semantics.
7. Test with assistive technology. Perform keyboard-only navigation and at least one screen reader pass on key pages.
8. Write the report. Include failures, test steps, screenshots, severity, and a remediation plan with owners and deadlines.

Testing methods and when to use them

Automated testing

Automated tools quickly flag low-hanging fruit such as missing alt attributes, empty headings and some ARIA issues. They are useful for large-scale sweeps and for integrating checks into CI pipelines. Automated results always need manual verification because many WCAG criteria require human judgement.

Manual inspection

Manual checks cover semantics, focus order, form labelling, link purpose, reading order and keyboard interaction. Inspect the DOM, read element roles and attributes, and review visible text against expected behaviour.

Assistive technology testing

Test with at least one screen reader and one keyboard-only user flow. Typical choices are NVDA on Windows and VoiceOver on macOS or iOS. Include a mobile screen reader pass for responsive pages. Real users reveal issues automated tools miss.

Keyboard testing

Keyboard tests must check tab order, focus visibility, ability to operate custom controls, and skip-links. Verify that all interactive elements are reachable and usable without a mouse.

Colour and visual checks

Check colour contrast, text resizing and content reflow. Use a contrast tool to inspect foreground and background pairs used across templates and components. Also test at large text sizes and with zoom.

Sample test cases and checklist

Use these sample test cases on each representative page or component. Mark each as pass, fail or needs review.

Test	What to check	Pass evidence
Keyboard navigation	All interactive elements reachable and operable via Tab, Enter, Space and arrow keys where relevant	Tab order follows reading order; focus visible; no trapped focus
Alternative text	Images, icons and functional graphics have meaningful alt text or null alt for decorative images	Accurate alt text or alt=“”
Form labels	Inputs have programmatic labels and error messages are announced	Label element or aria-label present; errors described
Colour contrast	Text and UI components meet contrast requirements at the target WCAG level	Contrast tool screenshots for failed pairs
ARIA and roles	ARIA used only where native semantics cannot provide the role; no conflicting attributes	Correct roles, states and properties in DOM
Captions and audio	Recorded audio has captions or transcripts; live audio has equivalent alternatives	Captions present and synced where required
Dynamic content	Updates are announced to assistive tech using appropriate ARIA live regions or focus management	Screen reader reads updates or focus moves predictably

Tools and when to use them

• Browser dev tools Accessibility pane for semantics and contrast checks.
• axe or axe-core for rule-based automated checks and CI integration.
• Lighthouse or Accessibility Insights for combined audits and actionable results.
• Colour contrast analyser tools for foreground/background pairs.
• Screen readers: NVDA, VoiceOver, and commercial screen readers where available.
• Keyboard-only testing without tools to validate interaction sequences.

Reporting and making a conformance claim

A test report should include scope, WCAG version and level targeted, test dates, methods, sample pages, detailed findings, severity and remediation steps. When making a conformance claim, state the WCAG version and level, describe the test scope and list known exceptions or excluded content. Keep evidence attached or archived for future audits.

Common mistakes and how to avoid them

• Relying only on automated scans. Automated tools miss context and behaviour that need a human tester.
• Testing only home pages. Interactive components and templates can hide the worst failures.
• Using ARIA instead of native HTML. ARIA should enhance semantics, not replace correct HTML tags.
• Ignoring focus management in dynamic interfaces. Modal dialogs or single-page apps must move and restore focus predictably.
• Not testing with real screen readers. Simulators and tool summaries do not replicate real assistive technology behaviour.

Integrating accessibility testing into development

Make accessibility checks part of the workflow. Implement automated checks in pull requests, add unit tests for key components, and include accessibility stories in component libraries. Schedule regular manual audits and involve users with disabilities for validation. Track regressions in the issue tracker and measure time to fix as a quality metric.

Next steps and further reading

Start with a scoped audit of key user journeys. Use the sample checklist and add organisation-specific success criteria. Keep test records and update the conformance claim when issues are fixed. For ongoing work, combine automated CI checks with periodic manual and assistive technology testing.