Back to reviews and guides

Accessibility Testing Guide: How to Test a Website for Accessibility

Practical Accessibility Testing Guide that explains a step-by-step workflow: scope, automated scans, manual keyboard and screen reader checks, user testing and reporting. Includes tools, common failures, prioritisation and a copyable issue template.

Accessibility Testing Guide

This Accessibility Testing Guide shows how to test a website for accessibility. Read it to learn a practical workflow, core checks for keyboard and screen reader users, the right tools, and how to report issues so they get fixed.

What is accessibility testing?

Accessibility testing checks that people with different abilities can use a site. It combines automated scans, manual checks and testing with real users and assistive technology. The goal is conformance to web standards and usable experiences.

Common standards are WCAG 2.1 and WCAG 2.2 at level AA. Use these as the technical yardstick. For UK organisations, remember the Equality Act 2010 and the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018. Many public services measure against WCAG. Check your legal team for exact obligations.

Types of accessibility tests

Automated testing

Automated tools find common markup and contrast problems fast. Use them for a broad sweep and continuous integration. They do not find everything. You must follow up with manual checks.

Manual expert testing

An expert tester performs keyboard-only navigation, screen reader checks, form interaction and ARIA validation. This testing finds logic, focus order and wording problems that tools miss.

Assistive technology testing

Test with at least one screen reader and one mobile screen reader. Test keyboard users and, where possible, switch users and voice-control users. This verifies real-world behaviour.

Real user testing

Recruit participants with relevant impairments and ask them to complete tasks. Observing real users uncovers barriers that neither tools nor experts predict.

Step-by-step testing workflow (practical)

  1. Define scope: pages, templates, components, PDFs and video assets. Decide which user journeys matter most.
  2. Baseline audit: run automated scans with axe, Lighthouse or WAVE. Save reports and screenshots.
  3. Manual checks: keyboard navigation, focus order, visible focus styles, headings, form labels, error messages, images, tables and links.
  4. Screen reader pass: test common flows with NVDA or VoiceOver. Check reading order, form announcements and link context.
  5. Media checks: captions, transcripts and audio descriptions for video. Check player keyboard access.
  6. Contrast checks: verify text and interactive element contrast with a contrast checker tool.
  7. ARIA and dynamic content: validate roles, states and live region behaviour during updates.
  8. User testing: run task-based sessions. Capture verbatim feedback and time-on-task if useful.
  9. Report: triage issues, include reproduction steps, assistive tech used and expected behaviour.
  10. Regression and CI: add automated checks to your pipeline and a smoke test that runs on key pages.

Common accessibility issues and how to test them

Keyboard navigation and focus

What to test

  • Tab order follows visual order.
  • No keyboard traps: user can exit interactive widgets with keyboard.
  • Visible focus indicator on links and controls.

How to test

  • Use Tab and Shift+Tab only. Try Enter and Space on controls.
  • Open and close menus and dialogs using keyboard alone.
  • Check skip links exist and receive focus.

Screen reader behaviour

What to test

  • Reading order matches visual order.
  • Form fields announce purpose, required state and errors.
  • Images have meaningful alt text or empty alt when decorative.

How to test

  • Listen to content with NVDA, VoiceOver or TalkBack. Move by headings, links and landmarks.
  • Complete forms and trigger validation messages.

Headings and landmarks

What to test

  • Logical heading hierarchy (H2 then H3, not H5 then H2).
  • Landmarks or ARIA landmarks for main regions.

How to test

  • Use the browser accessibility tree or a screen reader’s heading list to confirm order.

Colour contrast and text sizing

What to test

  • Contrast ratios for body text and interactive elements against background.
  • Text scales correctly when users zoom or change text size.

How to test

  • Use a contrast checker for normal text and large text.
  • Zoom to 200% and verify layout remains usable.

Forms, errors and labels

What to test

  • Every input has an associated label.
  • Error messages are programmatically associated with fields.

How to test

  • Try submitting without required fields. Check the error is announced and visible.
  • Check inline hints are accessible to screen readers.

Dynamic content and ARIA

What to test

  • Live regions notify assistive tech when content changes.
  • Custom widgets expose the correct ARIA roles, states and keyboard behaviour.

How to test

  • Trigger content updates and watch what the screen reader announces.
  • Validate that ARIA is used to communicate only what native semantics cannot.

Tools and how to use them

  • axe DevTools: browser extension for detailed automated checks.
  • Lighthouse: provides accessibility score and quick fixes.
  • WAVE: highlights errors and alerts in the page view.
  • Contrast checker: measure colour contrast for normal and large text.
  • Screen readers: NVDA on Windows, VoiceOver on macOS and iOS, TalkBack on Android.
  • Keyboard-only testing: no tool needed. Use Tab and Shift+Tab to move focus.

Practical checks to add to your CI

  • Run axe-core as part of the build for key pages and components.
  • Run Lighthouse for single-page apps and store reports.
  • Include a visual regression test for focus styles and large text layouts.

Prioritising issues

Use impact and frequency to set priority. The simplest model maps severity to user impact.

Severity Example Action
Critical Keyboard trap, cannot submit form Fix immediately
Major Screen reader reads labels incorrectly Fix in next sprint
Minor Non-essential layout contrast issue Schedule in backlog

Issue report template (copyable)

Field Contents
Title Short summary and page URL
Steps to reproduce Exact steps including keyboard or screen reader actions
Actual result What happened for the user
Expected result What should happen
Assistive tech e.g. NVDA 2023.2, VoiceOver iOS
WCAG reference Relevant success criterion(s)
Screenshots / logs Attach screenshots, axe report snippets and DOM snapshot
Severity / priority Critical / Major / Minor
Suggested fix Developer-focused recommendation

Running a single-page manual test: quick workflow

  1. Open the page and run an automated scan. Save the report.
  2. Tab through the page. Check focus, skip links and traps.
  3. Use a screen reader to move by headings, links and form fields.
  4. Trigger form validation. Check error announcements.
  5. Verify images, tables and media items for alt text, captions and controls.
  6. Record issues using the template and assign priority.

Testing with real users

Recruit participants with relevant impairments and ask task-based questions. Get consent and offer reasonable compensation. Observe but do not lead. Note where users pause, ask for help or use workarounds.

Final notes and next steps

Automated tools speed testing and catch many errors. Still, manual checks and user testing find the most harmful problems. Use the workflow here to build repeatable tests. Keep test artifacts, automation reports and issue templates with your project so fixes are verifiable.

Further reading and standards to check

  • WCAG 2.1 and WCAG 2.2
  • WAI-ARIA Authoring Practices
  • Equality Act 2010
  • Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018