How to choose an accessibility audit provider

Start with the standard and the level

An accessibility audit measures your product against a standard. If you do not name one, each provider picks its own, and reports cannot be compared.

Write it down: "Audit against WCAG 2.2 at Level AA." WCAG has three levels, A, AA and AAA, and each success criterion belongs to one of them. Many policies and contracts name Level AA, but check what applies to you: a customer contract, a public sector rule or an internal policy may set it. The UK Technology Code of Practice, for example, lists "make things accessible and inclusive" as one of its points for public services.

Define what is in scope

W3C's evaluation methodology, WCAG-EM, starts by defining the scope, then exploring the product, selecting a representative sample, evaluating it and reporting. Use the same order in your RFP.

Give the provider:

• The platforms: web, iOS, Android, desktop, PDFs or other documents.
• The key user journeys, such as sign up, log in, search, checkout, account settings.
• Logged-in areas and the test accounts to reach them.
• Third-party components you embed, such as payment or chat widgets, and whether they are in scope.

Then ask the provider to propose a sample of screens and explain how it chose them. A sample that covers every template and every step of the key journeys tells you more than a long list of similar pages.

The limits of automated scans

Automated checkers are useful and fast. They find issues such as missing form labels, missing text alternatives and some contrast failures. They cannot judge many things a person must judge:

• Whether a text alternative actually describes the image.
• Whether focus order and reading order make sense.
• Whether a custom component works with a screen reader.
• Whether error messages explain how to fix the error.
• Whether a user can complete a journey with a keyboard alone.

A proposal that relies only on scanners is one of the patterns in the red-flag checker. Ask each bidder to state how its effort splits between automated and manual work, and which screen readers, browsers and devices the manual testing uses.

What the report must contain

Ask for a redacted sample report before you choose. Each finding should have:

Field	Why you need it
WCAG success criterion and level	Lets you measure conformance and track progress
Location: screen, component, URL	Lets developers find it
Description and steps to reproduce	Lets developers confirm it
Assistive technology and browser used	Lets you retest in the same way
Severity or user impact	Lets you decide the order of fixes
Suggested fix	Saves developer time

The report should also state the sample tested, the dates, what was not tested, and an overall statement against the named level. A report that lists issues without success criteria is hard to act on and hard to retest.

Retest and ongoing work

A single audit is a snapshot. Agree how fixes are confirmed:

• Whether one retest is included, and the window for requesting it.
• Whether the retest produces an updated report.
• Whether the provider can review designs or components before release, so issues are caught earlier.

If accessibility is part of a wider QA engagement, ask how accessibility checks will run within each release, not only in a yearly audit.

Wording for your RFP

• "Evaluate against WCAG 2.2 Level AA. Map every finding to a success criterion."
• "Describe your sampling approach and list the screens and journeys you propose to test."
• "State the assistive technologies, browsers and devices used for manual testing."
• "Attach a redacted sample report from a previous audit."
• "State whether a retest is included, its time limit and its output."

The RFP generator lets you add accessibility to the scope, and the questionnaire includes a question on combining automated and manual checks against WCAG 2.2. For how to judge the sample report you receive, see how to read a vendor sample report. If mobile apps are in scope, the mobile device coverage guide helps you pick the devices for manual testing.

The selection path shows where a specialist lot like this fits alongside your main QA selection.