A useful accessibility-audit proposal states what will be examined, against which standard, through which methods and with what evidence. “WCAG check” or an automated score is not enough. Before comparing prices, align pages, journeys and states, then ask what remains outside coverage and how repairs will be retested.
An audit supports evidence-based remediation decisions. It is not automatic certification, a legal compliance guarantee or assurance that the product works for every person. If a particular contractual or regulatory obligation applies, have the client’s appropriate specialist confirm it, then translate it into an evaluable technical scope with a qualified evaluator.
Name the standard, version and level
State the evaluation reference explicitly, such as WCAG 2.2 at an agreed level, without treating that example as legal advice for every organisation. Ask how applicable criteria will be determined and how not applicable, not tested and passed results will be distinguished. The absence of a recorded defect does not automatically mean every requirement passed.
WCAG conformance requirements address full pages and complete processes rather than selected fragments. WCAG 2.2 conformance requirements. If evaluation is limited to a sample, conclusions must remain proportionate to that sample and methodology. A difficult step cannot simply be omitted while the entire journey is described as conforming.
If the project includes native applications or documents, ask for an appropriate scope and method for them. Do not extend a web-page finding to files or applications that were not evaluated.
Map coverage before settling the page count
Record important templates, special functions, roles, languages and states that are absent on initial load. One URL can contain dialogs, validation errors, dynamic tables and several submission steps. Counting links alone does not describe effort or risk.
For each selected item, record the reason: a critical task, shared pattern, technical complexity or documented complaint. Identify third-party elements and which party can change them. Excluding an external component from the audit contract does not remove its effect on the user journey. The limitation, owner and next action should remain visible.
Digital Accessibility Audit defines evidence, coverage and remediation priorities within the agreed engagement. The proposal should also confirm appropriate skills, access and capacity rather than relying on the service label alone.
Worked hypothetical: a public application portal
Imagine a portal with information pages, an application form and authenticated request tracking. The client proposes checking the homepage and five very similar pages. The evaluator reorganises the sample to include different patterns, a complete application journey and an error state, together with the information needed to understand the task. This is an illustrative sample, not a recommended audit size for every site.
The journey includes selecting a service, entering details, uploading an attachment, reviewing the application and receiving confirmation. The client supplies authorised test accounts and safe fictional files. The reviewed build is identified so the report does not mix results from changing releases.
Evaluation finds a barrier in the attachment-rejection message. The issue record includes location, state, reproduction steps, expected and actual outcomes, the relevant criterion after evaluator verification and the effect on task completion. If a shared component is responsible, the report explains that relationship rather than duplicating dozens of disconnected findings. It also avoids assuming that fixing one component automatically resolves every use.
After remediation, the original case is rerun, followed by agreed affected cases. If the upload component changes substantially during repair, retesting may need an explicitly approved scope extension. Unlisted journeys or an untested language remain outside the conclusion even when their appearance seems similar.
This example also separates evaluation from delivery management. Someone must own the fix, approve the changed behavior and make a stable build available for retest. An audit report cannot perform those steps by itself.
Agree the method, not merely the tool
WAI explains that no tool alone determines whether accessibility standards are met. Evaluation overview. Ask for the division between automated and manual checks, named environments and the process for verifying findings before delivery. Different tools can describe the same issue differently; the useful work is interpretation and reproducibility.
Specify whether assistive-technology testing is included and which combinations and tasks it covers. Separately state whether disabled participants will take part in research. An expert operating a screen reader is not evidence that participant research occurred. Recruitment, consent and accommodations require their own planning.
For proposal comparison, look at the treatment of complexity. A cheap page-count quote may omit authenticated states, errors or third-party handoffs. A larger quote may still be vague about evidence or retesting. Neither price nor length alone establishes useful coverage.
Report and retest acceptance checklist
- A dated scope listing pages, states, roles, languages and exclusions.
- A declared standard, version, level, methodology and test environments.
- Reproducible evidence, with severity and priority explained through consequences.
- Actionable recommendations and repair owners rather than raw automated warnings.
- A retest status for each relevant defect: resolved, remaining or unable to verify, with reasons.
- Conclusion limits and changes between evaluation and retest.
User Experience Design can reshape a journey responsible for a barrier. Website Design can specify affected layouts. Verification of implemented changes needs an agreed Software Quality Assurance scope. Separate evaluation, design, implementation and retesting responsibilities in the proposal.
A report should remain useful even where some repairs are deferred. It should identify the remaining barrier and accountable decision, not relabel an unresolved issue as fixed because a deadline arrived.
Frequently asked questions
Is checking a template once sufficient?
A template can form part of a sample, but content, states and interactions may differ. The evaluator should explain the coverage rationale and limits rather than treating visual similarity as proof of equivalence.
Does an automated score mean the site conforms?
No. It is a result within a particular method and coverage and requires appropriate interpretation and evaluation. Do not use it alone for a broad conformance claim.
Is retesting normally included?
Do not assume so. Specify rounds, included items, the window for receiving repairs and the treatment of new changes in the agreement.
Is the report a legal certificate?
No. It is technical evidence bounded by scope, method and date. Legal interpretation or a particular obligation requires the organisation’s appropriate specialist.
Begin with the journey map, release details and test permissions. Those inputs make proposal comparison more meaningful than comparing report length or the name of an audit tool.
Sources
- W3C: WCAG 2.2 conformance requirements.
- W3C WAI: Evaluating Web Accessibility Overview. Reviewed 26 October 2026.
