An accessibility score can reveal problems, but it cannot tell you whether a person can complete a form, read an error, or use a menu with a keyboard or screen reader. A useful assessment names the pages and tasks in scope, records what was tested, and leaves the team with fixes it can verify.

The W3C’s WCAG Evaluation Methodology provides a structured approach: define scope, explore the site, select a representative sample, evaluate it, and report findings. The quick checks below help find issues early. They are not a conformance claim or a legal opinion.

A review that leads to usable fixes

Include complete journeys such as finding a service, submitting a form, and recovering from an error—not only isolated home-page elements.

Workflow 01

Define a representative sample

A home page scan misses templates, modal dialogs, account areas, forms, and documents.

What to check
Inventory page types and key tasks. Select representative views plus complete processes, including the steps before and after submission. State the WCAG version and level the review uses.
Evidence to record
Template list, top tasks, content types, third-party components, device and browser scope, and selected WCAG criteria.
Who reviews it
A reviewer agrees the scope with the site owner and records what was excluded.
Workflow 02

Run quick and automated checks

Missing labels, contrast failures, or broken semantics can be widespread across a template.

What to check
Use a reputable scanner and W3C Easy Checks to find repeatable issues. Inspect headings, link names, image alternatives, zoom, contrast, and form labels. Record the tool and version.
Evidence to record
Page URL, component, state, screenshot or code reference, tool result, and relevant success criterion.
Who reviews it
A reviewer confirms each issue and distinguishes an actual barrier from a false positive.
Workflow 03

Test with keyboard and assistive technology

A component passes a scan but focus disappears, instructions are not announced, or an error cannot be recovered from.

What to check
Move through the full task by keyboard. Check focus order and visibility, dialogs, menus, error messages, and form completion. Test selected flows with a screen reader and users with disabilities when feasible.
Evidence to record
Steps to reproduce, device and assistive-technology setup, expected behavior, actual barrier, and task impact.
Who reviews it
An experienced tester assesses the barrier and its priority; automated output alone cannot make that judgment.
Workflow 04

Fix, retest, and prevent regression

A patch changes one page while the shared component remains broken elsewhere.

What to check
Fix the shared component or content rule, verify the original task again, and add appropriate automated checks to the release workflow. Track unresolved issues with an owner and due date.
Evidence to record
Issue, affected views, root cause, fix, retest result, and remaining scope.
Who reviews it
The owner prioritizes remediation and makes any public statement only from a documented evaluation.

What stays with people

  • A clean automated scan does not establish WCAG conformance. W3C calls for automated and human evaluation.
  • Do not claim an entire site conforms based on a few pages unless the scope and sampling support that statement. Include complete processes in the assessment.
  • Accessibility is ongoing: new content, plugins, forms, and design changes can reintroduce barriers. Give editors checks they can repeat.

A sensible starting point

  1. Pick one high-value task, such as submitting a contact form, and list every view and state needed to complete it.
  2. Do W3C Easy Checks and a keyboard pass. Record issues with a reproducible step and the effect on the user.
  3. Fix the highest-impact shared barrier, then retest the entire task before expanding the review.

Sources and further reading

Related service: Web development.