What the standard is
EN 301 549 is a technical standard describing accessibility requirements for information and communications technology. It exists because legislation needs something concrete to point at. A law can say products must be accessible; a standard says what that means clause by clause, in terms somebody can test.
Canada adopted it as CAN/ASC-EN 301 549 and identifies it as the technical benchmark for digital accessibility under the Accessible Canada Act. The European Union references it for public sector websites and procurement. The practical effect is that the same standard turns up in several regimes, which is good news: work done once counts in more than one place.
Its defining feature is breadth. WCAG is about web content. EN 301 549 is about technology that carries information, which is a much larger category.
| Category | Examples in scope |
|---|---|
| Web content | Public websites, web apps, intranets, login areas |
| Software | Desktop applications, mobile apps, internal tools |
| Electronic documents | PDFs, spreadsheets, presentations, forms |
| Hardware | Kiosks, terminals, devices with interfaces |
| Communication | Two-way voice and video, real-time text |
| Support | Documentation, help desks, training material |
How it relates to WCAG
For web content, EN 301 549 incorporates WCAG by reference, at Level AA. So if your website meets WCAG 2.1 AA, you have satisfied the web content portion of the standard. Nothing is gained by treating them as two separate projects for your website.
The difference appears outside the browser. A desktop application has no WCAG criteria written for it, but it still has keyboard operability, focus visibility, contrast and name-role-value requirements. EN 301 549 restates those ideas in a form that applies to software generally, and adds requirements that have no web equivalent at all.
- Closed functionality: a device where a user cannot attach their own assistive technology, such as a payment terminal, has to provide the accessibility itself
- Biometrics: an alternative is needed where a biological characteristic cannot be used by everyone
- Preservation of accessibility information: a product that passes data onward must not strip the accessibility information out of it
- Real-time communication: requirements for captions and for text alongside voice and video
- Documentation and support: help material must itself be accessible, which is often overlooked
The third point is the one that quietly breaks things in otherwise good systems. A document generator, a reporting tool or a PDF exporter that discards headings and alt text makes inaccessible output from accessible input, and nobody notices until someone tries to read the output.
What the extra scope means in practice
If you have been running an accessibility programme aimed at your public website, the standard widens it in three directions that each carry real work.
- Inwards, to employee-facing systems. Intranets, admin panels, HR portals and internal line-of-business tools. These are usually worse than public sites because nobody sells to them and nobody audits them.
- Sideways, to purchased software. Anything your staff must use to do their job, whether you built it or bought it.
- Outwards, to everything you publish. Documents, forms, and the help material that explains your product.
Inwards is where I would start, for a reason that has nothing to do with compliance. An employee who cannot use the tool required for their job is being prevented from working, which is a more serious problem than a customer who finds your marketing site awkward. It is also the area with the highest chance of a complaint that is hard to defend.
Documents are in scope, and this is the awkward part
Electronic documents fall within the standard, which means a PDF that assistive technology cannot read is a barrier even if the page linking to it is perfect. Most organisations have years of these.
Remediating a large PDF archive is slow, skilled work, and doing all of it is rarely the right answer. The useful move is to triage, then to change what you produce going forward.
| Document type | Recommended action |
|---|---|
| Forms people must complete | Rebuild as accessible web forms; this is the highest value change |
| Current policies and key information | Publish as web pages, keep the PDF as a secondary copy |
| Frequently downloaded documents | Remediate properly, in order of download volume |
| Historical archives, rarely accessed | Leave, and provide an accessible version on request |
| Everything produced from now on | Fix the authoring process so new documents start accessible |
The last row is the one that decides whether this is a project or a permanent cost. If your templates have real heading styles, your images carry alt text and your tables have header rows, accessible documents come out of ordinary work. If not, you are remediating forever.
Converting a must-complete form from PDF to a web form is also the change users notice most. It tends to improve completion rates for everybody, which makes it the easiest part of an accessibility programme to justify.
Procurement is where the standard bites hardest
The single most expensive accessibility mistake an organisation makes is buying a tool that cannot be made accessible and then requiring staff to use it. You inherit a problem you cannot fix, because the source code is not yours.
Fixing this costs nothing except adding questions to a purchase process.
- Ask for an accessibility conformance report, stating how the product meets the standard clause by clause
- Read it rather than filing it, and look for how much is claimed as partially supporting
- Ask specifically about keyboard operation and screen reader support for the main workflow
- Test the trial version yourself by keyboard before signing
- Put accessibility obligations in the contract, including a commitment to fix defects
- Ask what happens to accessibility in future releases
Step four is worth more than the other five together. Ten minutes in a trial account, using the keyboard only, tells you more than any document a vendor will send you. Vendors who have done the work are usually pleased to be asked; vendors who have not tend to answer a different question.
A workable approach
Treating EN 301 549 as a single compliance project tends to stall, because the scope is genuinely large. Treating it as four streams that each have an owner tends to move.
- Web: get to WCAG 2.1 AA, fixing systematic issues in the design system first. See our web accessibility guide for the criteria that matter most
- Software: inventory internal tools, triage by how essential they are, and fix or replace
- Documents: fix the authoring templates, rebuild must-complete forms, triage the archive
- Procurement: add the questions above, so the problem stops growing
Run the procurement stream first even though it delivers nothing visible. It is the only one that prevents new work, and it is a single afternoon of changes to a purchasing checklist.
For the Canadian regulatory context around this standard, including the reporting cycle and the proposed conformance deadline, see the Accessible Canada Act and your website.
We audit and remediate websites and web applications to WCAG 2.1 AA, including internal tools and login areas, and we rebuild inaccessible PDF forms as web forms that work. Tell us what you are responsible for and we will tell you where the real barriers are before you commit to anything.