Canadian public-sector web accessibility requirements belong at the start of a project, in the tender itself. If the tender asks for an “accessible” site, every bidder will promise one, and you will have nothing to compare. A checklist run the week before launch comes far too late to help.
Part of the difficulty is that Canada has no single rule. There is a federal standard, a provincial law in Ontario and a separate government standard in Quebec, and tender documents sometimes cite all three loosely. Below, each one in turn, followed by what to ask for when you write the RFP.
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, under the name CAN/ASC-EN 301 549:2024. The adoption is identical, so its web clauses lead to the same place as the European ones: WCAG 2.1 Level AA.
The standard gained weight when the Accessible Canada Regulations were amended to require it. Federal public sector organizations must make new and updated web pages conform from 5 December 2027, then mobile apps and digital documents from 5 December 2028. Large federally regulated businesses (500 employees or more) take on the same web, app and document obligations on 5 December 2028. Medium-sized ones (100 to 499 employees) must make new and updated web pages conform from the same date. All three groups must train their staff in digital accessibility by 5 December 2027. A site you commission in the next year or two will very likely still be running 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 covers designated public sector organizations, and businesses and nonprofits with 50 or more employees. New websites had to meet Level A from 1 January 2014. From 1 January 2021, all websites and web content had to meet Level AA, with two exceptions: live captions and pre-recorded audio descriptions.
That is the floor an enforcement officer measures against. Many auditors and evaluators work to WCAG 2.2 AA instead, the version the W3C published in October 2023. Building to 2.0 alone means aiming two versions behind, on a site expected to run for years.
The AODA also has reporting duties, separate from the technical standard. Designated public sector organizations file an accessibility compliance report every two years. Businesses and nonprofits with 20 or more employees file one every three years. A missed report counts as its own failure, even on a site that meets the standard, and it is often the one that draws a follow-up from the province.
Quebec: SGQRI 008 3.0
SGQRI 008, Quebec’s standard for government websites, 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 is still assessed against version 2.0, so any older site that has kept growing carries two obligations at once.
The split matters when you scope a redesign. New templates put new pages on version 3.0, but the archive you migrate keeps its old status until someone deals with it. Somebody has to decide which older pages and documents get fixed, which get retired and which get republished. Make that call in the project plan, while there is still time and budget for it.
The technical target moves less than the paperwork
Put the three side by side and the target barely changes. Federal and Quebec rules both point to WCAG 2.1 AA. Ontario requires 2.0 AA by law, while many auditors expect 2.2. A site built to WCAG 2.2 AA covers the WCAG portion of all three, because 2.2 keeps every 2.1 success criterion except 4.1.1 Parsing (which the W3C retired as obsolete). It adds criteria on visible focus, alternatives to dragging, target size, consistent help, redundant entry and accessible authentication.
Any bidder can describe how they will meet the standard. Evidence that they met it, and that the site will stay compliant after launch, is harder to produce, so ask for it.
What to ask bidders to show you
- The standard, named and versioned. You can’t score “fully accessible” or “WCAG compliant”. “WCAG 2.2 Level AA, tested against CAN/ASC-EN 301 549:2024” can be checked. Name it in the tender and ask bidders to confirm it.
- A record of manual testing. Automated checkers find only part of the failures, so a plugin badge proves little. Ask for keyboard-only navigation, screen reader passes on the real templates, and results recorded criterion by criterion.
- A written list of known exceptions. Large sites usually have a few, often a third-party embed or an old set of documents. A bidder who lists them with a date for the fix has tested. A bid that claims none suggests the opposite.
- The editing experience. A site is accessible on launch day because it was built that way. Three years later it stays accessible only if the people publishing to it can’t easily break it. Ask how the CMS will keep your authors within the rules.
- Documents. Public sector sites deliver a great many PDFs. A library that was never tagged is a common reason for an otherwise compliant site to fail an audit. Ask what each bid does with them.
Where compliance gets lost
Templates that a developer wrote and tested tend to hold up in an audit. The failures turn up around them:
- Plugins that add their own markup, especially forms, sliders, calendars and cookie banners, which nobody included in the audit.
- Custom interactive components that rebuild a native control badly, where the plain HTML element would have been accessible from the start.
- Brand colours that can’t reach a 4.5:1 contrast ratio on body text, found out after the visual identity was approved.
- Payment, map and booking widgets from other vendors. They sit inside your page, and you can’t change their code.
- Content added after launch, such as headings that are only bold text, links that say “click here”, images with empty alt text and tables used for layout.
Four of those five come from decisions made before anyone writes template code. That is the best reason to put accessibility in the requirements phase. Once it becomes a testing problem, the expensive choices have already been made.
What to do before you issue the tender
- Set the target as WCAG 2.2 Level AA in the requirements, and name the standard that applies to your level of government.
- Test your current site by hand, with a keyboard and a screen reader. You will quickly learn how much work the redesign has to absorb.
- 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 explains how to sort them.
- Check your brand colours against the contrast requirement now, while changing them still means a design discussion and not a rebuild.
- Put an exceptions list in the bid form. A bidder who fills it in honestly is more convincing than one who claims perfection.
The standards are settled enough to build against with confidence. Compare bids on the evidence they promise to hand over, such as a test record, an exceptions list and a plan for the documents.
We build to WCAG 2.2 AA and hand over that evidence with the site. Our page on accessible WordPress development describes how.