Plan an Accessibility Retrofit: Scope, Priorities and Acceptance - Yenra

Scope an accessibility remediation project, compare proposals and define the evidence required for acceptance.

A modular building model is separated into components beside a glass plan and teal ruler.
Conceptual retrofit planning: define the scope, dependencies and acceptance evidence before work begins.

An accessibility retrofit is a planned change to an existing service. A useful brief identifies the journeys that matter, the components that create barriers and the evidence needed to accept the result. Start with an inventory and a decision-maker who can assign resources. This guide helps a site owner or project lead commission and manage the work; individual technical repairs belong in a separate implementation plan.

Define what the project includes

List the websites, applications, templates, documents, languages, account roles and third-party services in scope. Identify important journeys such as applying, paying, booking or obtaining a record. Include error states, timeouts and confirmation steps. Record exclusions with a reason and an owner so they remain visible.

Specify the technical standard, edition and conformance level that the project will evaluate, plus any contractual requirements. Establish legal applicability with the responsible adviser. Federal procurement and other uses of Section 508 require their own scope assessment; the Section 508 guide explains that baseline.

Give bidders a representative sample and a way to request controlled access. A count of public pages alone can hide the complexity of a signed-in form, shared design system or document library.

Separate immediate access from permanent repair

Identify barriers preventing essential tasks and establish who can provide an effective interim route. At the same time, investigate shared causes: repairing a template, form component or publishing process may address many instances. Ask the team to distinguish a temporary workaround, a source correction and the deployment of that correction.

W3C’s Web Accessibility First Aid discusses responding to immediate barriers while broader work proceeds. Use an interim measure with an owner, a way for affected users to find it and a review date. Check whether it actually supports the task under the conditions in which people need it.

Request deliverables you can review

  1. Baseline findings: scope, methods, environments, reproducible issues and user impact.
  2. Repair plan: priorities, dependencies, responsibilities and the proposed sequence of changes.
  3. Implementation: source changes, revised content and evidence showing where each fix was deployed.
  4. Verification: retest steps, results, remaining barriers and coverage limits.
  5. Handover: maintainable documentation, staff training and regression checks.

Use the retrofit project brief as a starting outline. Tailor it before issuing a request for proposals. Ask suppliers to explain the human evaluation they include, the expertise required from your staff and how they will handle findings outside the initial sample.

Compare proposals against the same scope. A cheaper scan-only proposal and a project including content repair, component work and independent retesting deliver different things. Ask for assumptions and exclusions in writing, including how additional work is agreed.

Define acceptance before the first repair

Agree which journeys and states will be tested, who will perform the checks, which environments will be used and what evidence will be retained. For conformance evaluation, the WCAG-EM overview provides a framework for defining scope, selecting a representative sample and reporting findings. Match the method to the actual standard and service.

Specify how disputed or newly discovered findings are handled. A claim that a tool reports zero errors supplies one piece of evidence; acceptance also needs the agreed manual and user-task checks.

Make the improvement maintainable

Require the team to identify which components, templates and authoring practices changed. Give editors practical instructions for future documents and media. Assign ownership of vendor updates, regression testing and user feedback after the project ends.

Close the project with an issue register that distinguishes verified repairs from accepted limitations and future work. Retain the original scope, final tested version and approval record. That makes the next review a continuation of evidence rather than a fresh attempt to discover what was purchased.

Continue exploring