The Treasury Board Standard on Web Accessibility (SWA) governs Government of Canada websites and bleeds into vendor expectations during RFP technical evaluation. We unpack what SWA requires, how it relates to WCAG 2.0 / 2.1 AA, and how to demonstrate vendor-side compliance during a competitive bid.
The Standard on Web Accessibility is the Treasury Board of Canada Secretariat (TBS) policy that applies to public-facing Government of Canada websites and web applications. The substantive accessibility requirement is conformance with WCAG 2.0 Level AA (with TBS guidance pushing toward 2.1 AA in modernization work), plus a set of Canadian-specific requirements: Common Look and Feel (CLF) compliance, accessible PDF expectations, accessible web forms, and accessible video/audio.
The SWA technically applies to GoC sites, not vendor sites. But three vendor-side realities make it operationally binding for federal contractors:
1. **RFP technical evaluation.** Many RFPs include a corporate-website check as part of the capability evaluation. An obviously inaccessible vendor site signals the vendor doesn't understand the standard they're being asked to deliver against.
2. **Sub-deliverable inheritance.** When you build, host, or maintain anything that ends up under a GoC domain, your work has to meet SWA. Vendors who don't run their own house at SWA standards consistently miss SWA on delivery.
3. **Accessible Canada Act alignment.** Vendors are increasingly federally-regulated entities themselves under ACA Schedule II. ACA expectations track the WCAG 2.1 AA baseline.
**WCAG 2.0 / 2.1 AA** = the international content baseline. Both SWA and ACA reference it.
**SWA** = the federal TBS policy for GoC sites. References WCAG 2.0 AA, with TBS guidance moving toward 2.1 AA.
**AODA** = Ontario's provincial law. References WCAG 2.0 AA. Applies to Ontario-incorporated organizations meeting the size thresholds.
**Accessible Canada Act (ACA, 2019)** = federal law for federally-regulated entities (banks, telcos, federal-regulated transport, federal contractors meeting the test). References WCAG 2.1 AA in CRTC and Accessibility Commissioner guidance.
In 2026, designing to **WCAG 2.1 AA** clears all four with margin.
When you produce an audit for an RFP evaluator, the deliverable should include:
- A statement of scope (what was tested, what was not) - The WCAG 2.1 AA conformance matrix with pass/fail per success criterion - A representative sample of failed criteria with screenshots, code refs, and remediation guidance - An accessible PDF check (federal procurement evaluators check PDFs separately — most vendor sites fail here) - Form accessibility findings (label associations, error handling, focus management) - A remediation timeline with dates - A re-test commitment
PDF audits without screenshots, sample tests, or remediation guidance are not credible deliverables.
It's a Treasury Board policy that binds federal departments and agencies. For vendors, it operates as a procurement expectation rather than a direct legal obligation — but the practical effect is the same during a competitive RFP.
On vendor-built GoC deliverables: contract non-conformance, potential withholding of payment, and corrective-action obligation. On the vendor's own corporate site: lost technical-evaluation points and potentially disqualification on accessibility-sensitive files.
No. Automated scanners (axe, WAVE, Lighthouse) catch roughly 30-40% of WCAG issues. The remaining 60-70% require manual screen-reader testing, keyboard-only testing, and accessible-PDF review. Procurement evaluators experienced with accessibility know this and will discount audit reports that are obviously automated-only.
Yes. The SWA expects a published accessibility statement covering scope, conformance level, known limitations, contact channel, and date of last review. We include this on every vendor build.