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, final since December 2025, federal public sector organizations must make new and updated web pages conform from 5 December 2027, and mobile applications and digital documents from 5 December 2028. Large federally regulated businesses, those with 500 or more employees, take on the same web, app and document obligations on 5 December 2028; medium-sized ones are only required to train their staff. 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. It applies to designated public sector organizations and to businesses and nonprofits with 50 or more employees. New internet websites and their content had to meet WCAG 2.0 Level A from 1 January 2014, and all internet websites and web content had to meet Level AA from 1 January 2021, except live captions and pre-recorded audio descriptions. That is the floor an enforcement officer measures against. In practice, auditors and evaluators now work to WCAG 2.2 AA, the current W3C Recommendation since October 2023, so building to 2.0 alone means building to a version already two revisions old for a site that will run for years.
Separately from the technical standard, the AODA carries reporting obligations. Designated public sector organizations file an accessibility compliance report every two years, and businesses and nonprofits with 20 or more employees file one every three years. 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 meet the web content requirements of all three, because 2.2 is additive: it keeps every 2.1 success criterion except 4.1.1 Parsing, which was removed as obsolete, and adds new ones covering focus visibility, dragging alternatives, target size, consistent help, redundant entry and accessible authentication.
The hard part is proving you met the standard, 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 one of the most frequent reasons 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. Our guide to migrating thousands of documents sets out how to triage them.
- 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.