[ Accessibility · Buyer guide 2026 ]

// 15 / 20

Website Accessibility & WCAG Buyer Guide 2026

Build accessibility into delivery and governance.

Plan WCAG audits, remediation and governance that survives beyond launch.

[ Quick answers ]// 01

Make important website journeys easier for more people.

What should accessibility testing cover?

Agree on the target requirements and representative journeys. Include manual keyboard, screen-reader and zoom checks alongside automated checks.

Does an accessibility widget prove compliance?

No single widget establishes compliance. Assess the underlying content and interface and verify remediation against agreed requirements.

Does AODA apply to our website?

In Ontario, the AODA requires public-sector organizations and businesses or non-profits with 50 or more employees to make public websites conform to WCAG 2.0 Level AA, with limited exceptions. Other provinces and federally regulated organizations have their own rules—confirm which apply to you.

How much does website accessibility work cost?

Plan for roughly $4,000 to $80,000+. An expert audit of key journeys sits at the lower end; remediation of design, code and content, document fixes, user testing and ongoing governance raise the cost.

[ Outcomes ]// 02

What a good engagement should deliver.

Use these as a checklist: any proposal worth signing should show how it will produce each one—and what evidence you will see along the way.

01

Testable accessibility target

A clear accessibility target—usually a WCAG version and level—with the pages, journeys and documents it applies to and how each will be tested.

Ask to see

The agreed standard, the test scope and a sample of the manual test scripts (keyboard, screen reader, zoom).

02

Prioritized remediation program

Problems ranked by how badly they block people, fixed in the shared components first, and re-tested to prove the fix worked.

Ask to see

A defect log with severity, owner, fix and re-test evidence for each issue.

03

Sustainable governance model

Accessibility built into how the site is run—training, release checks and monitoring—so problems don’t quietly return after launch.

Ask to see

A release checklist, a training plan for editors and developers, and a published accessibility statement.

[ Self-check ]// 03

Run a 15-minute accessibility self-check.

Ten checks anyone can try on their own site. See where the biggest gaps are and which first step—audit, remediation or governance—fits best.

Try each check on your own site—it takes about fifteen minutes. Answer honestly; “partly” is fine.

01 / Can you complete your main form or checkout using only Tab, Shift+Tab and Enter?
02 / Can you always see where the keyboard focus is on the page?
03 / Does the page still work and read properly when zoomed to 200%?
04 / Do meaningful images have descriptive alternative text?
05 / Do form fields have visible labels and clear error messages?
06 / Is text easy to read against its background everywhere?
07 / Do your videos have accurate captions?
08 / Are PDFs and other documents accessible, or offered as web pages?
09 / Do you publish an accessibility statement with a way to report barriers?
10 / Is accessibility checked before each website release?

A quick self-check, not an accessibility audit or proof of WCAG conformance. Confirm results with manual testing, including screen readers, against your agreed standard.

[ Delivery model ]// 04

Choose an approach your team can manage.

ModelUse whenWatch-out
Automated scanBroad recurring detectionCannot prove conformance
Expert auditRepresentative manual evaluationSnapshot without remediation
Remediation sprintKnown defects need correctionRegression without governance
Embedded accessibilityContinuous product deliveryRequires training and ownership
[ Evaluate proposals ]// 05

Questions that reveal real capability.

Ask for a relevant example, the decision made, the result or learning, and the person who would own the work.

  1. 01Which standard and conformance level will be accepted?
  2. 02Which pages, components, documents and journeys are sampled?
  3. 03What manual keyboard, screen-reader and zoom tests are included?
  4. 04How are severity, evidence and remediation verified?
  5. 05Will disabled users participate in research or testing?
  6. 06How are third-party tools and documents handled?
  7. 07What accessibility evidence accompanies each release?
  8. 08Who owns monitoring, training and regression response?
[ Risk ]// 06

Understand the risks before starting.

RiskEarly warningControl
Overlay dependencyWidget claimed as complianceFix underlying content and code
Automation-only auditNo manual testingMixed-method evaluation
One-time remediationDefects returnRelease gates and training
Document gapPDFs excludedContent inventory
No accountable ownerIssues ageGovernance and SLA
[ Value case ]// 07

Measure outcomes—not activity.

Set a baseline and a 90-day target for each with your team before work begins.

01Critical journey completion
02Defects by severity and age
03Keyboard and screen-reader pass rate
04Accessible document coverage
05Regression escape rate
06Remediation cycle time
[ First 90 days ]// 08

Move from evidence to operating rhythm.

01

Days 1–30

Obligations, inventory, representative audit and triage

Exit evidenceBaseline, owners, approved requirements and risks

02

Days 31–60

Remediate components, content and critical journeys

Exit evidenceWorking outputs, evidence and decision record

03

Days 61–90

Verify, publish evidence, train owners and establish monitoring

Exit evidenceMeasured result, operating owner and next backlog

[ Reference desk ]// 09

Speak the same language.

TermPlain-language meaning
WCAGWeb Content Accessibility Guidelines.
ConformanceMeeting defined accessibility success criteria.
Assistive technologyTechnology supporting disabled users.
Keyboard accessUse without a pointing device.
Accessibility statementPublic description of support and contact path.
RegressionA previously resolved problem returning.

Know what you are actually buying.

WCAG

In practice: A form's labels, errors and keyboard behaviour are checked against the agreed accessibility criteria.

Buyer decision: Set the target version and level in procurement and test real journeys.

Keyboard access

In practice: A keyboard-only user tries to complete checkout or submit an enquiry.

Buyer decision: Pair automated scans with human testing of important tasks.

Will an accessibility widget make our site compliant?

A widget cannot establish compliance for underlying content and interactions. Test the site itself, prioritize barriers and verify fixes against agreed criteria.

[ Project brief ]// 10

Make your next conversation count.

Choose an outcome, explore a delivery model and check what your team can already prove. The result is a brief you can copy into a planning conversation—no contact details required.

1 / What matters most?

Best when: Broad recurring detection. Watch for: Cannot prove conformance.

3 / What can your team confirm today?
[ Choose your next step ]// 11

Turn the guide into a decision.

Check your readiness, get a planning range or talk it through with us. Prefer the phone? Call 604.595.2495.

[ Readiness assessment ]

Are you ready to buy?

Step 1 of 2 — check each statement you can prove. Four or fewer checks usually mean discovery should come before a full implementation commitment.

0 of 6 checked. Discovery-first is the safer next step.

[ Cost estimator ]

Get a practical planning range.

Tell us enough to estimate the likely scope—not enough to slow you down.

[ Project consultation ]

Talk through the decision.

Share the outcome, timing and constraint. We’ll arrive prepared.