Accessibility used to arrive at the end of a public-sector web project, as a checklist someone ran the week before launch. It now arrives at the beginning, as a scored requirement in the tender, and the answer you give is compared against the answers other bidders give. Teams that treat it as a technical clean-up step lose points before a single page is built.
The confusion is understandable. Canada does not have one web accessibility rule. It has a federal standard, a provincial statute in Ontario, a separate government standard in Quebec, and procurement language that sometimes cites all three imprecisely. Here is what each one actually asks for, and what an evaluator expects to see in your response.
Three rulebooks, one technical target
Federal: CAN/ASC-EN 301 549:2024
Accessibility Standards Canada adopted the European standard EN 301 549:2021 as a National Standard of Canada on 31 May 2024, published as CAN/ASC-EN 301 549:2024. It is an identical adoption, so the web clauses point where the European ones point: WCAG 2.1 Level AA.
What makes this more than a paper exercise is the regulatory timeline attached to it. Under amendments to the Accessible Canada Regulations, federal public sector organizations face phased obligations for new and updated web pages, mobile applications and digital documents beginning in December 2027, with large and medium federally regulated businesses following in December 2028. Anything you build for a federal client between now and then will still be in service when those dates arrive.
Ontario: the AODA and the IASR
Ontario’s Integrated Accessibility Standards Regulation still names WCAG 2.0 Level AA as the legal requirement for public websites and web content. That is the floor an enforcement officer measures against. In practice, auditors and evaluators now work to WCAG 2.2 AA, and a move to that version is widely expected before the end of the decade, so building to 2.0 alone is building to a standard that will be superseded inside the life of the site.
Separately from the technical standard, the AODA carries reporting obligations. Designated public sector organizations and larger private and non-profit organizations file accessibility compliance reports on a fixed cycle. Missing the report is a distinct failure from missing the standard, and it is the one that generates correspondence.
Quebec: SGQRI 008 3.0
Quebec’s standard for government websites, SGQRI 008, reached version 3.0 and has applied to new content and redesigns since 29 April 2024. It is built on WCAG 2.1 Level AA. Content published before that date remains assessed against the previous version, 2.0, which creates a split obligation on any site that predates the change and has been added to since.
That split matters when you scope a redesign. Rebuilding the templates moves the new pages onto 3.0, but the archive you migrate does not automatically come with you. Deciding which historical content is remediated, which is retired, and which is republished is a content decision with a compliance consequence, and it belongs in the plan rather than in the final QA week.
The technical target is more stable than the paperwork
Read the three together and the useful conclusion is that the underlying target barely moves. Federal and Quebec both land on WCAG 2.1 AA today. Ontario is legally on 2.0 AA and practically on 2.2. Build to WCAG 2.2 AA and you satisfy all three, because 2.2 is additive: it keeps every 2.1 success criterion except one that was deprecated, and adds a small number of new ones covering focus visibility, dragging alternatives, target size, consistent help and redundant entry.
So the standard is not the hard part. The hard part is proving you met it, and keeping it met.
What evaluators ask for that bidders rarely prepare
- The standard, named and versioned. “Fully accessible” and “WCAG compliant” are not answers. “WCAG 2.2 Level AA, tested against CAN/ASC-EN 301 549:2024” is an answer, and it can be verified.
- A test record, not a plugin badge. Automated tooling catches somewhere around a third of failures. An evaluator who knows the field is looking for the manual portion: keyboard-only traversal, screen reader passes on the real templates, and results recorded per criterion rather than as a single score.
- A written list of known exceptions. Every large site has them, usually a third-party embed or a legacy document set. Declaring them with a remediation date reads as competence. Claiming none reads as an untested site.
- The editing experience. The site is accessible on launch day because you built it that way. It is accessible in year three because the people publishing to it cannot easily break it. Evaluators increasingly ask how the CMS constrains authors.
- Document handling. Public sector sites are document delivery systems. A PDF library that was never tagged is the single most common reason an otherwise compliant site fails an audit.
Where compliance is actually lost
In our experience the failure is almost never in the templates a development team wrote and tested. It is in the seams:
- Plugins that inject their own markup, particularly forms, sliders, calendars and cookie banners, none of which were part of your audit.
- Hand-built interactive components that reimplement a native control badly, when the native element would have been accessible for free.
- Brand palettes that cannot reach 4.5:1 on body text, discovered after the visual identity is signed off.
- Third-party integrations for payments, mapping or booking, which sit inside your page and outside your control.
- Content added after launch: untagged headings, link text reading “click here”, images with empty alt attributes, tables used for layout.
Four of those five are governed by decisions made before a line of template code is written. That is the real argument for putting accessibility in the requirements phase: by the time it is a testing problem, the expensive choices have already been made.
What to do before your next submission
- Name your target as WCAG 2.2 Level AA and say which standard you are testing against for the jurisdiction in question.
- Run a manual keyboard and screen reader pass on your own current site. It is the fastest way to find out whether your claim survives contact with a tester.
- Inventory your documents. Count them, find out how many are tagged, and decide what happens to the rest.
- Check your brand colours against the contrast requirement now, while changing them is still a design conversation rather than a rebuild.
- Write the exceptions list. It will be shorter than you fear and more persuasive than a claim of perfection.
Accessibility work rewards teams that start early and document as they go, and it punishes teams that treat it as a final inspection. The standards are settled enough to build against with confidence. The question an evaluator is really asking is whether you can show your work.
We build to that standard and hand over the evidence with the site. You can read how we approach it on our accessible WordPress development page.