Put accessibility in the website supplier brief by naming the pages and journeys in scope, the agreed evaluation target, the evidence you expect, and who will repair problems found before and after release. A general request to “make it accessible” leaves too much room for different interpretations of the work.

W3C's planning guidance places accessibility within responsibilities, resources and ongoing management. The brief structure below is an original practical method for discussing those responsibilities with a supplier. It is not a legal compliance determination, a certification checklist or a guarantee that every access need will be met.

Describe the website work in scope

List the main user tasks and the parts of the site involved. Include forms, navigation, downloads, media and relevant third party tools. A supplier cannot make a useful proposal if the brief mentions only page count while the difficult interactions are hidden in a booking service or an embedded form.

Identify what will be reused and what will be replaced. Existing components, content and integrations may have different owners. Record who can authorize a change to each one. If a supplier cannot modify an external tool, that limitation should be discussed during planning rather than discovered at the final review.

Our article on assigning accessibility ownership can help name those responsibilities. The business should retain an accountable contact even when a supplier performs the implementation. Outsourcing the work does not make decisions about service requirements disappear.

Agree on a specific evaluation target

Ask the supplier to identify the accessibility standard, version, level and scope proposed for the project, and have an appropriately informed reviewer confirm that target. Write it into the brief. Do not assume two people mean the same thing when they use a broad phrase such as “accessibility ready.”

Describe the evaluation methods and the evidence the supplier will provide. Automated checks can be part of the work, but their output should not be presented as a complete evaluation of every user journey. Ask how manual review and relevant user feedback will inform the assessment where appropriate.

Keep legal obligations and contractual acceptance distinct from this editorial planning guide. If the project requires a legal or specialist interpretation, assign that question to someone qualified to answer it. Do not let an AI-generated brief invent a legal requirement or a certification that the supplier has not offered.

Make content responsibilities explicit

Specify who writes and approves headings, link wording, image descriptions and instructions. Ask who prepares captions or other media alternatives required by the agreed scope. These decisions affect the experience even when the underlying component code is well implemented. They need time and review ownership of their own.

Provide representative content early enough for the supplier to test realistic pages. A demonstration built with short placeholder text may not reveal problems caused by the actual content. Use material you have permission to share and avoid unnecessary customer details in examples or test accounts.

State how new content will be checked after launch. A brief that covers only the first release may leave the team unable to maintain the agreed approach. Request practical guidance suited to the people who will edit the site, including the boundaries of what the editing interface can and cannot check.

Define how findings become repairs

Ask for an issue record that identifies the affected page or component, reproduction steps, observed behavior and expected behavior. Include the responsible owner and the result of the later verification. A list of scores or vague warnings is difficult to turn into an accountable repair process.

Agree how severity and release decisions will be made. The supplier should not silently redefine a requirement because a fix is inconvenient, and the business should not assume every issue has the same consequence. Record the decision maker and the information needed to assess an unresolved finding.

Our website change review guide describes checking the delivered behavior rather than relying on a completion message. Apply the same discipline here: implementation, review and verified resolution are separate events.

Include handover and maintenance

Request the information needed to continue the work: component guidance, known limitations, test records and a route for reporting new problems. Identify which person receives feedback and who can approve repair time. If a maintenance agreement exists, ensure its actual terms answer these questions rather than assuming coverage.

Plan a review when integrations or important user journeys change. Accessibility work should not vanish from the process after the supplier leaves. Give the internal owner enough information to recognize when a new change needs specialist review instead of relying on a broad assurance made for an earlier version.

Before sending the brief, read it as a set of decisions. Can the supplier identify what to build, what to evaluate, what evidence to return and who approves the result? Unanswered questions belong in the discussion. Making them explicit now is more useful than discovering incompatible assumptions at handover.

Sources

Related

Read next: Give accessibility work an owner.