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.

By Kevin Hintzman, MBAFounder & Principal

Reading focusEvidence beyond a scan

Related pathWeb Accessibility

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.

  1. 01

    Location and state

    Name the page, template, component, process step, responsive state, and condition in which the issue appears.

  2. 02

    Observed behavior

    Describe what happened, what was expected, and the steps or input method used to reproduce it.

  3. 03

    User impact

    Explain the task barrier in plain language rather than relying on a rule identifier alone.

  4. 04

    Standards connection

    Identify the relevant WCAG 2.1 success criterion and conformance level within the review scope.

  5. 05

    Remediation guidance

    Provide enough implementation context for the responsible team to act without presenting one code pattern as universally correct.

  6. 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.

  1. 01

    Which pages, templates, states, tasks, and complete processes are included?

    Ask how the sample was chosen and how excluded content will be described.

  2. 02

    Which automated, manual, keyboard, zoom, reflow, and assistive-technology methods will be used?

    Look for documented methods rather than a single tool score.

  3. 03

    How will findings describe user impact and remediation?

    The output should be understandable to both decision-makers and the team responsible for fixes.

  4. 04

    What will be retested, by whom, and in which environments?

    Clarify whether remediation and retesting are included or separately scoped.

  5. 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.

A practical next step

Start with the pages and tasks that matter most.

Identify the site or approved review environment, priority pages or journey, known concerns, and reason for review. Do not send credentials or sensitive records through the public inquiry.

Request an Accessibility Review