The Canadian federal government recently adopted CAN/ASC - EN 301 549:2024, Accessibility requirements for ICT products and services (EN 301 549:2021, IDT), which means that accessibility requirements for Canadian government services will reach the same level as in Europe. This is major news for service providers who work with the Government of Canada because the standards by which their services are judged have changed and even the procurement process for these products and services will change.
The best way to describe EN 301 549 is that a person should be able to perceive, understand, use, and get support for information and communication technology products regardless of disability, device choice, sensory or motor ability, cognitive skills, or communication mode. This is bigger than websites and even bigger than just applications. This is the whole enchilada: everything from non-web documents to kiosks, video, and even the procurement process itself must be fully accessible to all members of our community.
This is an exciting opportunity not only for Canadians but for Canadian companies. It is exciting that our government thinks that access and function for everyone are this important. And for companies in the space, this gives us the opportunity to work to one standard and access both Canadian and European government markets. This article will take a very quick look at the new standards, but you are strongly encouraged to read the full document - Accessibility requirements for ICT (Information and communication technologies) products and services .
Widening the definition of accessibility
For a long time, when we thought about accessibility in the context of providing services to Government of Canada clients, we thought in terms of the simplest parts of web accessibility. We thought of things like colour contrast ratios, alt text on images, keyboard navigation, labels for screen readers, and captions.
EN 301 549 is still concerned with these things but widens the definition to include the procurement process, technical support, documentation, compatibility with assistive technologies, video and audio, hardware devices, emergency communications, and even trade show kiosks. The new accessibility standards move toward a Canada without barriers. And while these standards don't apply to Canadian businesses as a whole, if building a company without barriers for employees and customers is important to you, these standards are a great way to move toward that.
Basic requirements of CAN/ASC - EN 301 549
We can break the requirements down into nine areas:
CAN/ASC - EN 301 549: Functional performance comes first
This requirement is going to force a lot of developers and designers to get very familiar with screen readers and other assistive technology. This is because CAN/ASC - EN 301 549 starts at the human level before any technical requirements. It requires that all users be able to locate, understand, and operate all functions within an application. Under the requirements, users have to be able to both use the functions and understand all the information provided regardless of barriers. This could be summarized as 'usable and useful for all'.
CAN/ASC - EN 301 549: Generic information and communication technology requirements
Once basic functionality is guaranteed, the standard broadens it dramatically to include essentially all communications technology, especially everything that has closed or locked-down functionality. Essentially, providers cannot assume that users can fix any issues by just bringing their own devices; accessibility has to be a deep part of their kiosk, information display, or hardware. Whatever the Government of Canada uses should be built with accessibility in mind but also shouldn't block any assistive technologies from working within it.
CAN/ASC - EN 301 549: Web requirements
Nothing in this part of the standard should be new to anyone. At this point, I would consider these minimum requirements for all front ends, though the industry does not agree with me on that.
Many of the requirements here come from WCAG 2.1, but the European Commission notes that the standards go beyond it. Everything here should be familiar to most front-end developers:
- Text alternatives for non-text content
- Captions and audio descriptions where applicable
- Meaningful structure
- Keyboard access
- No keyboard traps
- Visible focus
- Sufficient contrast
- Reflow/responsive layout
- Accessible names, roles, and values
- Clear headings and labels
- Error identification and suggestions
- Predictable navigation
- Status messages that assistive technology can detect
All basic stuff, but very useful for all developers to know.
CAN/ASC - EN 301 549: Non-web documents
This one is going to be a really difficult one for government to adopt just because of the sheer number of documents they have and the complexity of older versions they have to maintain. Accessibility Canada's guidelines specifically point to all non-web documents (things like Word documents, PDF files, forms, reports, spreadsheets, and any downloadable summaries) as required to be just as accessible as web-based documents.
This means that documents will need things like:
- Programmatically determinable language
- Meaningful structure
- Readable order
- Accessible links
- Non-text alternatives
- Proper headings
- Accessible tables
- Keyboard/assistive technology compatibility where applicable
CAN/ASC - EN 301 549: Software requirements
Siteimp is built with Tauri and so my bias might be shining through here, but this part of the requirements makes me strongly think that government procurement and desktop applications built with web technologies will be a very good mix. The best way to describe these requirements is that you can take all the web accessibility requirements and apply them to all software used by the Government of Canada.
CAN/ASC - EN 301 549: Video and audio requirements
I may be wrong here, but I feel like this part of the requirements creates a world where effectively all communications have to be available in many different modes. In other words, it's not enough to have a video. That video needs to have properly synced video, audio, and captions, an audio description, and discoverable captions and audio description tools.
Where I get a little confused is when it comes to audio-only content. I assume that audio-only content requires a transcript published in both official languages. But please confirm that with someone smarter than me. :)
CAN/ASC - EN 301 549: Two-way voice communication
You will notice that I have some doubts about audio transcripts and even the level of detail required. This section is why I am fairly confident about the need for good quality transcripts and recorded sign language interpretations of audio communications. The spirit of this section is that all communication systems must support more than one way of communicating. This will apply more to hardware and communications systems than typical websites, but the spirit is worth understanding in case you're in a weird grey area.
CAN/ASC - EN 301 549: Hardware requirements
This is an area where EN 301 549 is much stronger than WCAG 2.1. It extends accessibility not only to content but also to hardware and considers things like physical touch.
To be compliant, hardware must have:
- Reach ranges
- Tactile indicators
- Operable controls
- Mechanical keys
- Displays
- Connectors
- Physical access to controls
- Volume/audio controls
CAN/ASC - EN 301 549: Documentation and support services
This may be my favourite part of the whole standard because it states that it's not enough to make sure a product is accessible but that its support channels must be fully accessible as well. This is a powerful requirement because it means that all users will not only be entitled to the full function of the Government of Canada, but if they need help they will be able to receive it.
The procurement angle
This part is important for businesses that serve the Canadian government. Accessibility testing will be part of the procurement process and the best way to get ahead of this will be for companies to implement their own accessibility standards both for technical delivery and testing.
In my experience, the best way to get developers thinking about accessibility is to design an experiment where they are dropped into the deep end of one type of accessibility. Have them spend four hours doing basic things online (or trying to) with their monitor turned off, no mouse/pointer, and a screen reader and keyboard as their primary interface. While screen readers only account for one narrow side of accessibility, this is the easiest way to show people what it's like to use typical technology in a different way. Many people will feel lost during this experiment and that feeling is a great way to get them thinking about all types of accessibility during the technical grooming process where they turn product requirements into implementation plans.
It's also important that automated testing won't be enough and won't provide enough evidence of accessibility compliance for procurement processes. These requirements will require extensive investments in proper accessibility testing.
Conclusion
CAN/ASC - EN 301 549 changes the accessibility conversation because it makes accessibility much larger than a website checklist. It asks whether people can perceive, understand, operate, communicate, get help, and use information and communication technology across real barriers and real contexts.
For teams building products or services for the Government of Canada, this means accessibility needs to become part of the whole delivery process: planning, design, development, testing, documentation, support, and procurement evidence. A colour contrast check or a quick automated scan may still be useful, but it is not the whole job.
The practical path forward is to start building accessibility into the way teams work. Test with keyboards and screen readers. Review documents. Check support flows. Make sure help content is accessible. Ask whether users can complete real tasks, not only whether a page technically passes a tool.
This article is not legal or procurement advice, and the standard itself is the document that matters. But the direction is clear: accessibility is becoming a deeper expectation for government technology in Canada. That is good news, but it is also a lot of work. The organizations that start treating accessibility as a normal part of quality now will be in a much better position when it shows up in procurement, delivery, support, and review.