A useful website accessibility audit should leave your team with a practical repair plan—not just a score, a badge or a spreadsheet nobody can act on.
For a Canadian business comparing proposals, the important questions are straightforward: what will be tested, how will barriers be documented, who will fix them and how will the fixes be checked?
Ask for a written scope, an agreed WCAG target, automated and manual evaluation, reproducible findings, priorities, repair guidance and clear retesting terms. Confirm the legal requirements for your organisation separately. An audit is not a guarantee of legal compliance.
This guide is a procurement checklist for business owners and delivery teams. It is not legal advice or a substitute for an organisation-specific assessment.
Start with the Canadian context—not a generic compliance label
Accessibility obligations are not identical across every Canadian province, sector and organisation. Do not accept “Canada compliant” as a complete specification. Identify the relevant jurisdiction, sector, procurement requirements and technical target before comparing prices.
For Ontario, the government’s website accessibility guidance explains requirements for designated public-sector organisations and businesses or non-profits with 50 or more employees. It identifies WCAG 2.0 Level AA requirements for covered public websites and content, with specified exceptions. AODA is Ontario legislation; it should not be described as a rule applying to every Canadian website.
The WCAG version requested in a contract may differ from the legal baseline. You might commission a WCAG 2.2 AA evaluation as a technical improvement target, but that does not mean every Canadian law requires that version. Have the appropriate adviser confirm applicability, exceptions and any reporting obligations.
1. A scope that names the pages, journeys and exclusions
“Audit the website” is too vague for a dependable quotation. Before work starts, ask for a scope that identifies:
- The domain, subdomains and environment under review
- The WCAG version and conformance level being evaluated
- Representative templates and important user journeys
- Languages, documents, videos and authenticated areas included
- Third-party components such as booking tools and payment interfaces
- Access requirements and the date or version of the tested site
- What is excluded and why
A clinic may prioritise service discovery and appointment requests. A retailer may prioritise product selection, cart changes and checkout. An association may need membership, event registration and downloadable documents reviewed. The sample should follow what people actually need to do.
Ask how the auditor will account for a shared navigation component used on many pages. You do not need hundreds of identical tickets, but you do need to understand the reach of a reusable-component problem.
2. Testing methods—not just the name of a scanner
Automated tools help identify repeatable technical issues. They do not replace an evaluator checking whether a person can complete a task.
The W3C evaluation methodology overview describes a structured approach to defining scope, exploring the website, selecting a representative sample, evaluating it and reporting findings. Its reporting resources are useful when discussing the evidence you expect.
For procurement, ask the provider to describe its intended manual coverage. Depending on scope, this can include keyboard operation, visible focus, screen-reader interaction, zoom and reflow, form errors, dynamic updates and content structure.
The report should identify relevant browser and assistive-technology combinations, tool versions and test dates. A narrowly tested combination should not be represented as proof that every device and configuration works.
3. Findings your developer can reproduce
Each finding should explain the barrier, not simply attach a technical label. Request a consistent format:
- Location: affected URL, component and state.
- Reproduction: the actions needed to encounter the problem.
- Observed behaviour: what happened during the test.
- User impact: who may be blocked or disadvantaged.
- Reference: the relevant success criterion and evaluation result.
- Repair guidance: a practical direction for design, code or content work.
- Evidence: a suitably redacted screenshot, recording or test note where helpful.
Illustrative finding—not a result from a client website
Journey: requesting an appointment.
Observation: submitting an empty required field displays an error visually, but the tested screen reader does not announce or associate it with the field.
Impact: a visitor may not understand why the request cannot proceed.
Next step: review the field’s error association and announcement behaviour, then repeat the journey using the agreed keyboard and screen-reader setup.
The example shows the level of explanation to ask for. The exact criterion, severity and repair must be established from the actual implementation. It is not a universal code recipe.
4. Priorities that reflect the task people need to complete
A long issue count is not a delivery plan. Ask the auditor and implementation team to separate:
- Barriers preventing an essential action, such as completing an enquiry
- Shared-component issues affecting multiple journeys
- Template-specific problems
- Content or document work requiring an editorial owner
- Questions requiring further investigation or third-party involvement
Agree how severity is assigned. The number of automated warnings alone does not tell you which barrier has the greatest effect on users.
5. A clear handover from findings to fixes
An audit and remediation are different pieces of work. The proposal should say whether the provider will only report findings, support your developer or implement changes directly.
Before commissioning fixes, confirm who controls the source code, CMS, design system, documents and embedded tools. Some repairs require supplier cooperation or replacing a component; they cannot be completed merely by changing your website’s CSS.
For the distinction between the stages, see Accessibility Audit vs Remediation. For implementation support, review our accessibility audit and remediation services.
6. Retesting with a record of what changed
Do not assume that closing a developer ticket means a barrier has been resolved. Agree which fixes will be retested, in which environment, and whether connected journeys will also receive regression checks.
A useful retest record names the finding, the tested version, the date and the result. It distinguishes resolved items from partially resolved, unresolved, untested and out-of-scope items. New findings should not disappear into a blanket “passed” label.
Also decide who owns future content checks and component updates. A dated assessment is evidence about the evaluated version and scope—not a promise that all future changes will remain accessible.
What is not automatically included?
Unless agreed in writing, do not assume the price covers an exhaustive review of every page, all PDFs, multiple languages, source-code remediation, third-party replacement, legal advice, formal procurement documentation or unlimited retests.
If your procurement process requests an Accessibility Conformance Report using a VPAT template, name that deliverable explicitly. It must reflect the evaluation evidence and limitations; a template is not a certification.
An overlay subscription, scanner score or generic accessibility statement should not be substituted for the agreed evaluation and remediation work.
Before you accept a proposal
Ask these seven questions:
- Which standard, pages and complete journeys are included?
- Which manual checks and test environments will you use?
- Can we see a redacted example of the report format?
- How are findings prioritised and assigned to owners?
- Are fixes, documents and third-party work included or separate?
- What retesting and handover will we receive?
- Which exclusions, access needs and ongoing responsibilities should we budget for?
Avoid a fixed delivery promise before the provider understands the site. Page types, application states, documents, languages, access and retesting coverage all affect effort.
How eLan Technology can help
We deliver remotely from Nagpur, India, with scoped accessibility evaluation and implementation support for Canadian organisations. The proposal identifies the target, sample, testing, deliverables, exclusions and responsibilities. We do not present technical work as a guarantee of legal compliance.
Explore our Canada delivery approach, request a scoped quotation or schedule a consultation to discuss the journeys that matter most to your organisation.
If you need an initial direction before commissioning formal testing, our free website review has a narrower public-page scope. It is not a substitute for a full accessibility evaluation.