Website Accessibility Checklist: Record Page and Flow Evidence

Build an evidence-led accessibility review

Use four passes. First freeze the target and boundaries, then select pages and complete processes, run distinct evaluation methods, and preserve findings plus retests without rewriting the original result.

1. Freeze the version, scope, and claim boundary

   Name the target, canonical base URL, release, build, environment, date, evaluator, included areas, exclusions, and method basis. A result can become obsolete after a change, so keep it tied to the version that was observed. State before testing that the ledger records evaluation evidence and does not itself establish legal compliance, certification, or WCAG conformance.

   Sources: [wcag-2-2], [wcag-em-2-0]

2. Select representative pages, states, and complete flows

   Inventory common pages, distinct templates, essential functionality, important states, and complete processes. Explain why each sample belongs. Include every step of an essential flow, such as entering a booking task, correcting an error, submitting, and receiving confirmation. If a newly sampled page reveals a new content type or finding, expand the sample instead of assuming the original set was representative.

   Sources: [wcag-em-2-0]

3. Run manual, automated, and assistive-technology checks separately

   Record the method, tool, browser, operating system, viewport, assistive technology where applicable, expected behavior, observation, reviewer, time, and evidence for each check. Easy Checks can support a first review, while WCAG 2.2 evaluation depends on automated testing and human evaluation. Never copy a tool result into checks the tool did not perform or treat an automated scan as complete coverage.

   Sources: [wcag-2-2], [w3c-easy-checks]

4. Preserve failures, issues, fixes, and version-bound retests

   Link each failed check to one or more accountable issues and describe affected users, severity, owner, and state for each finding. After a change, keep the original failure and add a retest with the new ledger version, release, build, environment, reviewer, observation, and evidence. Mark an issue verified fixed only when its latest retest records a supported pass for that changed boundary.

   Sources: [wcag-em-2-0]

What this accessibility ledger owns

Use the pack to coordinate and preserve a website evaluation. Keep release orchestration, security assessment, legal interpretation, and formal conformance work with their accountable owners.

Three evaluation-ledger configurations

These configurations change the sample and method mix while preserving the same version, evidence, issue, and retest contract. They are planning examples, not findings or claims about a real website.

Make the evaluation boundary explicit

Use these rules to decide what to test or record next. A missing method, evidence item, owner, or retest is a visible gap, not a reason to infer a successful result.

1. An automated scan reports no findings or produces a high score, but the page or flow has no manual and assistive-technology evidence.

   Choose: Keep the relevant manual and assistive-technology checks at not_run, select applicable methods, and have named reviewers perform them in recorded environments.

   Tradeoff: The review takes more time, but the ledger does not convert machine coverage into claims about interaction, content meaning, task completion, or user experience.

2. A new sampled page, state, or random selection reveals a content type, technology, flow, or finding absent from the structured sample.

   Choose: Expand the inventory and sample, document the selection reason, and evaluate enough related pages or steps to understand the reach of the new finding.

   Tradeoff: The evaluation boundary grows, but the sample becomes more representative instead of preserving a convenient but incomplete scope.

3. A failed check is repaired on a later release or build and the team wants to replace the original result with pass.

   Choose: Preserve the failure, issue, environment, and evidence. Add a version-bound retest with the changed build, reviewer, observation, and evidence, then update the issue only from that retest.

   Tradeoff: The ledger carries more history, but it remains reproducible and shows what changed between the failure and verified fix.

4. Planned checks remain not_run or blocked, unresolved issues remain open, or the recorded environments no longer match the current website version.

   Choose: Keep the review in progress, findings recorded, or retest pending. Name the remaining checks, owners, environments, and version changes before independent review.

   Tradeoff: A release decision may wait or accept a separately authorized risk, but the accessibility record does not hide missing work.

5. Someone asks the ledger to establish legal compliance, certification, a public accessibility statement, procurement acceptance, or formal WCAG conformance.

   Choose: Escalate to the qualified legal, procurement, policy, accessibility, or independent-evaluation owner for that decision and keep this ledger as bounded supporting evidence only.

   Tradeoff: The checklist cannot answer the broader question by itself, but evidence and accountability stay aligned with the decision being made.

What this checklist cannot prove

A structured ledger improves traceability and repeatability. Its value still depends on sample quality, evaluator expertise, method selection, environment fidelity, evidence, and how the website changes after review.

• Easy Checks cover only a small set of issues and are a first review, not a definitive or comprehensive evaluation.
• Automated tools can detect only some barriers and can produce false positives, false negatives, or results that require human interpretation.
• A representative sample can miss pages, states, content, technologies, complete processes, locales, user needs, and interactions outside the selected boundary.
• Assistive-technology behavior varies across product versions, browsers, operating systems, settings, input methods, user skill, and combinations not recorded in the ledger.
• WCAG 2.2 addresses many needs but does not address every need for every person with a disability, even when a formal target is met.
• A locally valid schema and passing validator prove record consistency only. They do not test the website, inspect evidence files, or establish accessibility outcomes.
• The pack is not legal advice and cannot establish ADA, EAA, another legal obligation, contractual compliance, certification, or immunity from complaints or enforcement.
• A result tied to one release can become obsolete after changes to code, content, design, configuration, providers, browsers, or assistive technology.

Primary W3C references

These sources support different parts of the ledger. The article preserves their separate roles and does not present the pack as a W3C report, tool, endorsement, or conformance evaluation.

1. [wcag-2-2] World Wide Web Consortium:Web Content Accessibility Guidelines (WCAG) 2.2

   Checked August 1, 2026. Supports: Current WCAG 2.2 principles, guidelines, success criteria, conformance structure, the combination of automated testing and human evaluation, and the boundary that the guidance does not address every user need.

2. [w3c-easy-checks] W3C Web Accessibility Initiative:Easy Checks: A First Review of Web Accessibility

   Checked August 1, 2026. Supports: A quick first review of titles, text alternatives, headings, contrast, resize, keyboard focus, forms, motion, media alternatives, and structure, plus the explicit boundary that these checks are not definitive or comprehensive.

3. [wcag-em-2-0] World Wide Web Consortium:WCAG Evaluation Methodology (WCAG-EM) 2.0

   Checked August 1, 2026. Supports: Evaluation scope, product exploration, common views, essential functionality, representative samples, complete processes, documentation, reporting, and repeat-evaluation records.

Website accessibility checklist questions