What to Ask About Accessibility in a Website Proposal

“Accessible website” sounds reassuring in a proposal. It still leaves an important question unanswered: what work will the provider do, and how will you know what was checked? Before comparing prices, ask for the accessibility target, evaluation scope and evidence in terms you can understand.

You do not need to become an accessibility specialist to ask useful questions. You need enough detail to distinguish a design intention, an automated scan and a documented evaluation. This guide helps you prepare that discussion; it is not a legal assessment or a contract template.

Name the target, not just the intention

Ask which standard, version and conformance level the proposal targets. The W3C overview of WCAG explains that the Web Content Accessibility Guidelines contain testable success criteria at levels A, AA and AAA. A reference to “WCAG” without the version and level leaves the target unclear.

For example, if a provider proposes WCAG 2.2 Level AA, ask them to explain what that means for your project and how they will evaluate the work against it. That example is not a determination of the legal requirements that apply to your business. Have applicable obligations confirmed separately by a qualified adviser; do not infer them from a marketing phrase or this article.

Also ask whether the proposal promises to work towards a target or to deliver a specified conformance result. If the wording is ambiguous, request a plain-language explanation and a written revision. A shared understanding now is more useful than discovering at handover that each party meant something different.

Use a scope-clarification sheet

The following sheet is an original discussion aid, not prescribed contract wording. Fill it in with the provider. An unanswered item is a decision to resolve, not evidence that the website has failed an accessibility test.

Ask for answers that describe your actual site. “All key pages” is less useful than a list that includes the service page, enquiry form and confirmation screen. Likewise, “testing included” needs an explanation of the method and the deliverable, not just the name of a tool.

Follow one complete customer task

Consider a fictional repair business whose website lets a customer read about a service and request an estimate. This is an invented planning example, not a ZXP client or a test result. The owner asks the provider to include that journey in the evaluation discussion.

The conversation starts on the service page, continues through the enquiry form and includes what happens when required information is missing. It ends with the confirmation the customer receives on screen. The owner asks how the proposed checks will cover navigation, field instructions, error feedback and the confirmation state, rather than treating a screenshot of the empty form as the whole task.

If a separate booking service is introduced, add it to the discussion. Who evaluates the handoff? Who can correct a barrier in the external tool? What usable alternative will be provided if a customer cannot complete that route? A dependency may limit the developer’s control, but leaving it out of the proposal does not make the customer’s difficulty disappear.

Do not turn this one journey into a claim that the entire website conforms. W3C’s conformance evaluation guidance describes a process that defines scope, explores the site, selects a representative sample, evaluates it and reports findings. Ask the evaluator how the proposed coverage supports the conclusion they intend to make.

Ask what happens beyond the automated scan

W3C’s evaluation overview makes the distinction clear: tools can assist evaluation, but a tool alone cannot establish whether a site meets accessibility standards. Knowledgeable human evaluation is needed. A clean scan result is therefore not a complete answer to an accessibility promise.

Ask the provider to describe the human work in ordinary language. Which interactions will someone examine? What assistive technologies and browser combinations are relevant to the agreed evaluation? Who interprets the findings? You are looking for a credible method and appropriate expertise, not the longest list of product names.

Discuss whether people with disabilities will participate, how that work will be organised and what it is intended to reveal. W3C’s guidance on involving users explains that user evaluation can uncover usability issues that conformance evaluation alone does not find. It complements standards-based evaluation; a successful session with one participant should not be presented as proof that every user’s needs are met.

Agree how findings become fixes

Request a sample of the reporting format, with any client information removed. Can you see what was evaluated, what the issue is, where it occurs and what happens next? Ask how findings will be assigned, corrected and retested, and whether those steps are included in the proposed fee. A report and the work to resolve its findings are separate deliverables to clarify.

Record any unresolved issues and the plan for addressing them. Ask who will explain their effect on the promised outcome before you accept the work. Avoid reducing that conversation to a single score: you need to understand the barriers, the affected tasks and the limits of the evaluation.

Keep the report tied to the version of the site that was checked. If the form, navigation or content changes afterwards, ask the evaluator which findings or checks need to be revisited. An earlier report does not describe changes that were never examined.

Give later content an owner

The work does not end with a launch report. W3C’s planning and management guidance treats accessibility as part of ongoing web production, including responsibilities, training, monitoring and user feedback. Ask how your team will carry that work into routine updates.

For your proposal, make this concrete: who prepares image descriptions, reviews newly uploaded documents and checks changes to forms? What guidance will editors receive? Where should a customer report a barrier, and who will respond? These are questions about the proposed arrangement, not assumptions that a particular maintenance package includes them.

Bring the completed clarification sheet to your website discussion. Mark what has been agreed, what needs specialist input and what remains outside the proposed work. If you are discussing a website project with ZXP, share those requirements early and confirm the accessibility work, evidence and ongoing responsibilities in the agreed scope.