Write the brief around what you want tested and what you want back, not around how many pages you are willing to pay for. A page count tells a supplier nothing about difficulty, and it is the single most common reason two quotes for the same site are ten times apart.
The nine things a brief needs
What the thing is, who uses it, which journeys matter, the timescale, the browser and assistive technology combinations, the target level, who will read the report, how much support you want afterwards, and whether you need help fixing what turns up.
Name the Journeys, Not a Page Count
Describe the tasks people come to your site to finish, and let the supplier tell you how many pages that turns out to be. A checkout is four pages until somebody enters a wrong card number, and then it is seven. GOV.UK's own guidance puts this first: name the user journeys, tasks, patterns or page types you want looked at, and hand over your component list if you keep one.
The reason this matters is structural rather than commercial. Under WCAG, a page that is part of a process only conforms if every page in that process conforms. So a journey is the unit that a conformance answer attaches to, and a brief that names journeys is asking the question the standard can actually answer. Our audit scope builder turns your journeys into a scope you can paste into the brief.
Say Which Browsers and Screen Readers Count
This is the item most briefs leave out and the one that decides whether two audits agree. WCAG does not pre-define which combinations of browser, operating system and assistive technology a site has to work with, so the evaluator sets a baseline, and the method requires them to set it with you before testing starts.
Get it into the brief and two things follow. Your supplier knows what to buy time on, and your report says what it was tested against, which is what makes a second opinion comparable to the first. Leave it out and a disagreement between two competent auditors becomes unresolvable, because neither report says what it was measuring.
Set the Level, and Think Twice About AAA
Almost every law that names WCAG names Level AA, so AA is the ordinary target and the brief should say so. AAA is available and it is a real answer for a specific piece of content. As a blanket target for a whole site it is one W3C advises against, in the standard itself, because some content cannot satisfy every AAA criterion at all.
If you want more than AA, name the specific criteria rather than the level. That gets you the extra work without buying an argument about whether a sign language interpretation was required on a product video.
Ask for the Report Items the Method Already Requires
W3C's evaluation methodology sets a required minimum for a report, which means you can ask for these by name and a supplier who follows the method already produces them. Four of them are the ones commercial reports most often drop.
- The accessibility support baseline. What it was tested against, written down.
- The technologies relied upon. Which web technologies have to be working for the result to hold.
- The random sample and how it was picked. The method adds a random set on top of the chosen one, and the selection method is a required report item, not a detail.
- The complete processes included. Which journeys were followed end to end, rather than which pages were opened.
Also ask for at least one worked example for every criterion that was not met. That is the difference between a report a developer can act on and a list of criterion numbers.
Say Who Will Read the Report
A report aimed at a developer and a report aimed at a director are different documents, and a supplier who does not know which one you want will guess. Say who reads it, say whether you need the findings as tickets, and say what format they have to land in.
Then add the line almost nobody adds. The report itself has to be accessible. An audit delivered as an untagged PDF that your own blind colleague cannot read is a bad look for everyone in the transaction, and the method requires a published evaluation statement and its report to be in an accessible format.
The Questions Worth Asking a Supplier
GOV.UK's advice on choosing is blunt and correct: do not automatically take the cheapest, check you get to talk to the auditors face to face, and make sure they are not relying only on automated tools. That last one is checkable. Ask what proportion of the work is manual, and ask what they do about the criteria no tool tests.
There is a real number behind that question. On our own classification of W3C's 432 techniques and documented failures we graded 356, and 10 of those can be settled by a machine outright. And 49 of the 86 success criteria in WCAG 2.2 have no automated rule written against them at all. A supplier who cannot say what they do about that gap is selling you the free scan with an invoice attached.
What to Leave Out
Do not ask for a guarantee of conformance, a promise of legal safety, or a score. Nobody can give you the first two honestly, and W3C's own methodology argues against the third, saying plainly that aggregated scores can mislead and that this is part of why WCAG has no rating scheme. A supplier who offers you a percentage is offering you a number that the standard declined to invent.
And do not ask for repair work in the same document if you want the evaluation to be independent. We never do the fixing, for that reason. If you want both, buy them separately and know who is checking whose work.