Accessibility decision guide
What Does a Meaningful Website Accessibility Review Include?
Look beyond a dashboard score to the pages, states, tasks, input methods, evidence, and retesting that make a review useful.
Start with scope
A useful review names what was examined and what was not.
Website accessibility is experienced through complete tasks, not isolated code snippets. A review should identify the pages, templates, states, forms, media, user journeys, browsers, devices, input methods, assistive technologies, dates, and WCAG criteria included.
A green dashboard is not the same as a person completing the task.
The scope should follow the site's actual risk and use. A small brochure site, a donation flow, an application form, and an authenticated service do not present the same tasks or evaluation needs. Critical journeys deserve attention across every step and state required to complete them.
Wingspan Labs currently scopes its service baseline around WCAG 2.1 Level A and AA. W3C encourages use of WCAG 2.2 for newer work while noting that WCAG 2.1 remains a standard and was not superseded. Any expanded 2.2 review scope should be confirmed separately.
Four complementary methods
Use tools for what they can detect and people for what requires judgment.
- Automated testing
- Finds some rule-testable code, contrast, naming, language, and ARIA issues. It cannot judge meaning, complete tasks, usability, or full conformance.
- Manual evaluation
- Examines keyboard use, focus, reading order, landmarks, links, instructions, forms, errors, text spacing, zoom, reflow, and dynamic states within the sample.
- Assistive-technology sampling
- Runs named tasks with documented screen reader, browser, operating system, or other technology combinations. A sample cannot prove compatibility with every setup.
- Evaluation with disabled people
- Can reveal practical usability barriers and lived experience. It complements standards-based evaluation and must be intentionally scoped; it is not implied in every engagement.
A review should record tool and environment versions so findings can be understood and retested. The method also needs enough human judgment to distinguish a technical signal from the barrier a person may encounter.
Actionable findings
An issue record should help a team reproduce, understand, and fix the barrier.
- 01
Location and state
Name the page, template, component, process step, responsive state, and condition in which the issue appears.
- 02
Observed behavior
Describe what happened, what was expected, and the steps or input method used to reproduce it.
- 03
User impact
Explain the task barrier in plain language rather than relying on a rule identifier alone.
- 04
Standards connection
Identify the relevant WCAG 2.1 success criterion and conformance level within the review scope.
- 05
Remediation guidance
Provide enough implementation context for the responsible team to act without presenting one code pattern as universally correct.
- 06
Retest status
Record whether the included fix was retested, the method and environment used, and any limitation that remains.
Three different scopes
Review, remediation, and retesting are connected but not interchangeable.
- Review
- Identifies barriers within an approved scope and records supporting evidence, user impact, criteria, and priorities.
- Remediation
- Changes content, design, code, configuration, or process. Implementation responsibility must be explicitly scoped.
- Retesting
- Rechecks included fixes in documented environments and states. It does not certify every page or future change.
- Ongoing accessibility
- Requires governance, content practices, development standards, training, and continued evaluation beyond a single engagement.
A Wingspan Labs accessibility engagement can provide an issue register, WCAG-oriented findings, remediation guidance, and retest notes for fixes included in scope. Remediation implementation and coverage outside the approved scope are not automatic.
Before the work begins
Questions worth asking an accessibility reviewer.
- 01
Which pages, templates, states, tasks, and complete processes are included?
Ask how the sample was chosen and how excluded content will be described.
- 02
Which automated, manual, keyboard, zoom, reflow, and assistive-technology methods will be used?
Look for documented methods rather than a single tool score.
- 03
How will findings describe user impact and remediation?
The output should be understandable to both decision-makers and the team responsible for fixes.
- 04
What will be retested, by whom, and in which environments?
Clarify whether remediation and retesting are included or separately scoped.
- 05
What claim can the review responsibly support?
Expect scoped, dated findings and explicit limitations, not permanent or legal guarantees.
What this guide can and cannot show
A scoped review supports findings, not permanent certainty.
This guide is not a formal audit, legal opinion, ADA certification, WCAG certification, guarantee of conformance, or promise that a site is fully or permanently accessible. A sampled review does not establish the accessibility of pages, states, processes, technologies, or third-party content outside its scope.
Conformance claims require complete-process evaluation and other WCAG requirements, not merely a list of detected issues. Any public statement should be scoped, dated, evidence-backed, human-reviewed, and separately approved.
Primary sources
Guidance behind this framework.
- W3C: Web Content Accessibility Guidelines (WCAG) 2.1 The W3C Recommendation containing WCAG 2.1 principles, guidelines, success criteria, and conformance requirements.
- W3C WAI: Evaluating Web Accessibility Evaluation approaches, standards context, and guidance for reviewing websites and tools.
- W3C WAI: Selecting Web Accessibility Evaluation Tools Why tools support evaluation but cannot determine accessibility on their own.
- W3C WAI: Involving Users in Web Accessibility Evaluation How evaluation with disabled people can reveal usability barriers while complementing standards-based review.
- W3C WAI: WCAG 2 Overview W3C version guidance, including its encouragement to use WCAG 2.2 for newer work and the continuing status of WCAG 2.1.
- U.S. Department of Justice: Guidance on Web Accessibility and the ADA General DOJ guidance on web accessibility and the ADA; not a technical certification or a universal legal determination.
