The European ICT accessibility standard, clause by clause
EN 301 549, explained for people who have to answer a tender.
Procurement documents across Europe reference this standard by number and expect you to know what it contains. Most suppliers do not, because it is long, structured by technology rather than by product, and written for conformity assessment rather than for reading. This page maps it: which clauses apply to a website, which to your documents and software, which you can ignore, and what a credible answer looks like when a buyer asks for conformance.
We test web content at WCAG 2.2 AA, which covers clause 9 with room to spare.
The structure, in one table
The standard is organised by technology rather than by product, which is why suppliers struggle to find themselves in it. This table is the shortcut: find the rows that describe what you actually sell and ignore the rest with a clear conscience.
| Clause | Subject | Applies to a typical website supplier? |
|---|---|---|
| 4 | Functional performance statements | Framing, not a checklist |
| 5 | Generic requirements | Rarely, unless you ship hardware or closed systems |
| 6 | Two-way voice communication | Only for communications features |
| 7 | Video capabilities | If you publish or stream video |
| 8 | Hardware, including terminals | Only if you provide devices or kiosks |
| 9 | Web content | Yes. This is the core clause |
| 10 | Non-web documents | Yes, if you publish files |
| 11 | Non-web software | Yes, for native or desktop applications |
| 12 | Documentation and support services | Yes. Help pages and support channels count |
| 13 | Relay and emergency access | Only for communications providers |
For most suppliers the honest working scope is 9, 10 and 12, with 11 added when there is an app. Saying that explicitly in a report is itself a sign of competence: buyers see plenty of documents that claim conformance with clauses the supplier has no product for.
Clause 9 in practice
If you read only one clause before answering a tender, read this one, because for a website it carries almost all the weight.
Clause 9 does the simplest thing possible: it adopts the WCAG success criteria at levels A and AA for web content. That has two consequences worth understanding.
The first is that a proper WCAG 2.2 AA audit answers clause 9 directly, criterion by criterion, without translation. Our findings report is written that way, so the numbers in it map onto the numbers a buyer expects to see.
The second is that clause 9 inherits everything WCAG says, including the criteria that are easy to overlook: focus visibility, error identification and suggestion, consistent navigation, status messages. These are the ones that appear as gaps in supplier reports, usually because the supplier tested with a tool that cannot check them.
Clause 10 and clause 12: the two that catch people out
Documents you publish
Price lists, manuals, terms, reports. If the file carries information that exists nowhere else, it is in scope, and untagged files are a common finding.
Your help pages
Support content is explicitly covered. A help centre that is itself inaccessible is a documented contradiction.
Your support channels
Chat widgets, ticket forms and phone alternatives have to be usable by the same people who need them most.
Your product documentation
Where it describes accessibility features, it must describe them accurately, which means somebody has to have tested them.
In practice we test these alongside the site, because a customer who hits a barrier goes to support next, and a support channel that also fails turns a finding into a complaint.
Presumption of conformity, and what it does not mean
When a standard is harmonised and cited in the Official Journal, conformity with it gives a presumption of conformity with the legal requirements it covers. That is a genuine legal advantage and it is why procurement references the number rather than describing the requirements in prose.
It is not a shield for a document that says the right words. The presumption attaches to the product conforming to the standard, not to the report claiming that it does. If the checkout fails a criterion in clause 9, the presumption is rebutted by anybody who opens the site with a keyboard, and the report becomes evidence of a misstatement rather than of compliance.
Which is the same conclusion as everywhere else on this site: the document is only as good as the testing behind it.
Answering the procurement question well
Five elements, in this order, and each of them is checkable by the person reading your submission.
- State your scope. Which clauses apply to what you supply, and why the others do not.
- State your method. Automated and manual, which assistive technology, which browsers, which flows, on which dates.
- Report by clause. Supports, partially supports or does not support, each with a one-sentence remark that a human can act on.
- List the gaps and the plan. With dates you can meet, not dates that sound good.
- Name who signed it. An external tester with a registered company carries more weight than an internal review, and a verification code closes the question entirely.
The mechanics of the two document formats are compared on the VPAT page, and the testing that feeds both is described on the audit page.
What we deliver against this standard
Testing of your web content against WCAG 2.2 AA, which covers clause 9 and exceeds it, plus a check of the documents and support channels that fall under clauses 10 and 12. A findings report written by clause and by criterion, so it can be transferred into whatever report format your buyer uses. The public accessibility statement required by the European Accessibility Act, signed by Europe Services SE and carrying a verification code. Monthly re-testing, a hosted feedback channel, and five years of records.
What we do not do is sign your supplier report as though we were the vendor, because that document is your representation about your own product. We provide the evidence it rests on, including the method section buyers scrutinise, and we keep it current so the version you send in November is not describing March.
How the standard evolved, and why the version matters
The first edition arrived in 2014 and was the first of its kind in Europe: a single technical specification for accessible ICT that public buyers could cite instead of writing their own requirements. Later revisions aligned it with WCAG as that standard itself advanced, extended the treatment of documents and software, and refined the sections on hardware and two-way communication.
For a supplier the practical consequence is simple: cite the version you tested against and the date. A report that names the standard without a version is ambiguous, and an old version can be read as a claim about criteria that have since been tightened. Buyers who handle these documents regularly check the version line before they read anything else, for the same reason they check the date on a VPAT.
The same applies to the WCAG version behind clause 9. Testing at 2.2 covers 2.1 and 2.0 entirely, so stating it removes a question rather than creating one. Stating conformance to an unnamed version of WCAG invites the buyer to assume the weakest reading.
The functional performance statements in clause 4
Clause 4 is the part most people skip, and it is the part that explains why the rest exists. Instead of listing technical criteria it describes outcomes: usage without vision, with limited vision, without perception of colour, without hearing, without vocal capability, with limited manipulation or strength, with limited reach, and with limited cognition. Everything technical in the later clauses is a means to one of those ends.
It is worth reading once, because it changes how findings are prioritised. A contrast failure on a decorative caption and an unlabelled payment button are both single criteria in a report. Read against clause 4, one of them means a person cannot complete a purchase without vision, and the other means a caption is harder to read. Reports that rank by criterion number treat them identically. Ours rank by what the person cannot do, which is the same logic clause 4 uses.
Where this standard sits among the others
It helps to see the relationships rather than memorising them. WCAG is written by the web standards community and defines the criteria for content. This European standard adopts those criteria for web content and adds requirements for everything that is not a web page: documents, software, hardware, support. European legislation, including the Accessibility Act and the earlier public sector directive, then refers to the standard rather than repeating its contents. National laws transpose the legislation, sometimes adding their own procedural detail.
So the chain runs from a criterion your developer can fix, through a clause your buyer can cite, to a law your regulator enforces. A supplier who understands that chain answers questionnaires quickly, because every question in them is somewhere on it. A supplier who does not tends to answer with a paragraph about commitment, which scores nothing.
Questions about the standard
What is EN 301 549?
The European standard for accessibility requirements of ICT products and services, used as the technical reference behind European legislation and public procurement.
Who publishes it?
The three European standardisation organisations responsible for telecommunications and electrotechnical standards, on a mandate from the Commission.
Is it a law?
No. It is a standard. Legislation refers to it, and conformity with a harmonised standard creates a presumption of conformity with the legal requirements it covers.
How does it relate to WCAG?
It incorporates WCAG success criteria for web content and applies equivalent requirements to documents and software.
Which clauses cover websites?
Clause 9 is web content. Clause 10 covers non-web documents and clause 11 non-web software.
What about hardware?
Clauses 5 to 8 deal with generic requirements, two-way communication, audiovisual equipment and hardware, including self-service terminals.
What is clause 12?
Documentation and support services: your help pages, manuals and support channels have to be accessible too.
And clause 13?
Relay and emergency service access, relevant to communications providers.
Do I need to read the whole standard?
No. For a website, clause 9 plus the parts of 10, 11 and 12 that match what you publish is normally the working scope.
Is conformity with the standard enough for the EAA?
Conformity with the relevant harmonised standard gives a presumption of conformity with the legal requirements it covers, which is why procurement references it.
Do public buyers require it?
Yes. European public procurement of ICT references it directly, and suppliers are asked to report against it.
Which report format do buyers want?
The European edition of the accessibility conformance report, keyed to the clauses of this standard.
Does it apply outside the EU?
Not as law, but it is widely used as a reference in international tenders.
Is it the same as Section 508?
No, but the two are aligned in substance through WCAG, and the international report edition covers both.
How do you test against it?
We test web content against WCAG 2.2 AA, which covers clause 9 comfortably, and check the documentation and support requirements separately.
What do we receive?
A findings report, a signed statement, a public verification code, a hosted feedback channel, monthly re-testing and five years of records.
How much does it cost?
690 € a year for the EU, 1,290 € for three domains and six languages, 1,990 € including the UK and Canada.
Where do we start?
Free scan, then the audit.