A B2B website accessibility brief should define which buyer journeys must work, the standard being assessed, who will test them and what evidence is required before acceptance. Start with the path from finding a relevant service to submitting an enquiry and receiving confirmation. A page that looks finished can still prevent someone from completing that path.

For a marketing leader commissioning a website, the useful question is: can buyers reach the same information and complete the same actions with different ways of reading and operating the site? Turn that question into demonstrable acceptance conditions, then fund testing and repairs within the delivery plan.

This guide proposes a practical purchasing and release framework. It is not an accessibility audit of any particular website, a legal compliance assessment or a promise of higher conversion rates.

Define the outcome before choosing the test

An accessibility requirement such as “make the site accessible” leaves too much room for disagreement. A supplier may interpret it as running a scanner. A marketing owner may expect every campaign, document and booking flow to be usable. Resolve that difference before estimating the work.

Use five fields for each acceptance record: journey, environment, expected outcome, evidence and owner. A journey describes what the buyer wants to achieve. An environment identifies the browser, device and assistive technology combination being checked. The expected outcome is observable. Evidence shows what happened, and the owner is responsible for resolving a failure.

For example: a buyer reaches the cloud migration service page, opens the enquiry form with a keyboard, understands the requested fields, corrects an invalid email address and receives confirmation without asking another person to operate the site. Record the tested configuration and the release version beside the result.

Keep this record separate from a design sign-off. Approving typography and photography does not demonstrate that a form can be completed. Equally, passing a technical check does not establish that the offer is understandable. Your website messaging and accessibility work need their own evidence, even when they share a delivery team.

Put a clear scope in the supplier brief

Ask the supplier to name its proposed conformance target, evaluation method and exclusions. WCAG 2.2 provides testable accessibility criteria at levels A, AA and AAA. For a new B2B website brief, WCAG 2.2 Level AA is a useful target to discuss and specify. The applicable organisational or contractual requirement still needs to be established for the project.

Conformance concerns full pages and complete processes. Do not accept a claim that relies on testing only the first page of a booking or enquiry journey. A prioritised release review also does not establish whole-site conformance by itself.

List the public templates, campaign pages, languages, downloadable documents and third-party services inside the assessment. Include consent banners, chat tools, embedded calendars and anti-spam challenges when buyers encounter them. A component's commercial supplier is not the same thing as an acceptance owner.

For each external component, agree who can change it, who can escalate defects and what happens if a critical issue remains unresolved. Avoid discovering at launch that the agency can identify a problem but nobody has access or authority to fix it.

Ask for an evidence package, not a badge

The supplier's handover should identify the version tested, scope, methods, test environments, findings, repairs and remaining limitations. Ask to see an anonymised example of this format before appointing the supplier. The purpose is to assess the clarity of the working method, not borrow another customer's results.

Specify who retests repaired issues. An issue marked “fixed” by the implementer should not automatically become “verified”. Keep the original reproduction steps so the reviewer can repeat the same task and check for regressions nearby.

Review the buyer journey in four stages

The following review is an operational acceptance exercise. It helps a buyer commission and question specialist work; it does not replace a complete standards assessment.

1. Find the right offer

Ask the reviewer to start from a realistic entry point, such as a campaign landing page or a relevant article. Can they locate the service, understand where they are and reach the next useful action?

Inspect the navigation as an interaction, including its expanded and collapsed states. A screenshot of an open menu cannot show whether someone can open it, move through it and leave it. Include the mobile navigation even when most current enquiries arrive from desktop.

Record any point where the reviewer must guess what a control will do. Hand that finding to the content or design owner rather than treating every difficulty as a development defect. Clear landing-page intent is part of a usable route to enquiry.

2. Evaluate the evidence

Choose a representative case study, service comparison and product explanation. Ask the reviewer to extract the information needed for a buying decision, then follow the relevant next step.

If an essential explanation exists only in a visual, video or downloadable file, include that asset in the review. Make the content owner accountable for its useful alternatives and maintenance. A beautifully presented case study has limited practical value when its key evidence is difficult to access.

Include at least one long page and one content-heavy asset. Reusing an accessible template helps, but the actual content can introduce new problems after the template has been approved. Track template defects and content defects separately so the right person receives the repair.

3. Submit and recover

Test an enquiry with missing information, an incorrect field value and a recoverable submission failure, as well as the successful path. Use synthetic details in a controlled test destination so acceptance testing does not create real sales work.

For each failure, ask three questions: does the buyer know what happened, can they find what needs attention, and can they continue without unnecessary re-entry? W3C's form notification guidance explains the importance of understandable error feedback and clear success confirmation. Ask the implementer to demonstrate both, including their behaviour with assistive technology.

A form can look complete while its failure state remains unfinished. Make those states explicit deliverables. Test anti-spam checks in the same journey and agree a usable route for legitimate buyers who cannot complete a challenge. Do not solve the problem by removing security controls without a considered replacement.

4. Know what happens next

Review the acknowledgement page and any promised follow-up. The buyer should be able to distinguish a completed submission from an unresolved attempt. Confirmation should explain the next step using an expectation the business can actually meet.

Separately verify that the enquiry reaches its intended internal destination. This is an operational check, not a substitute for accessibility testing. Keeping the two results distinct avoids a common acceptance gap: the interface appears successful while the business has no actionable enquiry.

Combine technical checks with human evaluation

W3C's evaluation guidance states that automated tools alone cannot determine whether a site meets accessibility standards. Use automated checks for the issues they can detect, alongside knowledgeable manual evaluation. Ask for the actual scope of both rather than comparing suppliers by a single score.

For the acceptance session, have the specialist demonstrate the chosen journeys using a keyboard and relevant assistive technology, and inspect the experience with enlarged content and different viewport sizes. Record limitations in the test coverage. Avoid treating one person's successful session as evidence for every disability, configuration or page.

Budget for participation by people with disabilities during the project, with appropriate recruitment and compensation. W3C recommends involving users early and throughout development. Use those sessions to learn where the proposed experience falls short, alongside standards-based assessment. Do not ask participants to act as an unpaid certification service.

Use a release decision that cannot hide blockers

A long issue list is hard for a business owner to interpret. For release planning, add a consequence statement to each finding: which buyer task is affected, whether a workable route exists, and who can resolve it.

Use three operational statuses. Blocked means the agreed task cannot be completed in a tested environment. Restricted means it can be completed, but the reviewer records material difficulty or dependence on a workaround. Verified means the agreed test passed for the recorded version and environment. These are project-management labels, not WCAG conformance ratings.

Do not average them into a reassuring percentage. A large number of passing checks does not cancel a blocked enquiry journey. Review the failures against the agreed contractual target and release conditions; an internally accepted risk does not make a non-conforming experience conformant.

If the agency cannot repair a critical external widget in time, consider simplifying the journey or replacing the component. Evaluate the proposed alternative before release. An email address displayed nearby may provide contact, but it does not automatically repair the original journey or establish equivalent access.

A worked acceptance record

Consider a fictional professional-services website with a “Discuss your project” form. The following is an illustrative record, not a customer result.

  • Journey: service page to project enquiry, including an invalid email correction.
  • Environment: the named browser, operating system and screen reader versions used by the tester.
  • Expected outcome: the buyer understands the error, reaches the relevant field, corrects it and receives an understandable completion message.
  • Observed problem: a visual error appears, but the tester does not receive useful feedback and cannot identify what to correct.
  • Owner and repair: the form component owner investigates the feedback mechanism, while the content owner checks the instruction.
  • Retest evidence: repeat the original sequence against the repaired release, then verify the successful path and another field error.

The acceptance discussion now concerns a reproducible buyer barrier and a responsible owner. It no longer depends on whether a stakeholder finds the screen attractive or a scan produces a favourable headline score.

Preserve the improvement after launch

Assign continuing responsibility for the shared components, published content and third-party integrations. Establish which changes require another journey review: a new form, navigation change, campaign template, consent tool or booking provider should not inherit approval automatically.

Give content editors examples of good headings, descriptive links, meaningful image alternatives and accessible document handling within the actual CMS. Make the publishing checklist short enough to use and support it with training. A policy nobody can apply in the editor will not protect the released experience.

Track unresolved barriers, time to repair and recurring causes. Use enquiry completion data to investigate potential problems, not to infer a visitor's disability or claim an accessibility uplift without a valid study. Pair quantitative signals with direct feedback and careful testing.

If accessibility work is part of a wider rebuild, coordinate it with the website redesign SEO plan. They share routes, templates and release dates, but require different evidence. Keep both visible in the acceptance decision.

The most useful next step is a one-page brief: name the priority enquiry journey, the agreed assessment target, the evidence expected and the people authorised to resolve failures. That gives the supplier something concrete to deliver and the buyer something concrete to verify.