EN 301 549 is a European ICT accessibility standard for products and services based on information and communication technologies; WCAG is a web content accessibility standard that EN 301 549 reflects for web, document, and software requirements.
Use this comparison to avoid treating a WCAG-only website audit as a complete European Accessibility Act evidence file for ICT products, services, documentation, support, or non-web software.
Structured answer sets in this page tree.
Cited legal and guidance references.
EN 301 549 and WCAG overlap, but they are not interchangeable. EN 301 549 V3.2.1 is structured around ICT products and services, including functional performance statements, hardware, web content, non-web documents, software, documentation, support services, and relay or emergency-service access. WCAG supplies web-content success criteria that EN 301 549 incorporates or adapts in specific clauses, so a WCAG test can be strong evidence for web content while still leaving EAA and ICT-standard questions unanswered.
A point-by-point comparison for teams deciding when WCAG evidence is enough for a web surface and when EN 301 549 or EAA records need more.
A European ICT accessibility standard for products and services, structured around functional performance statements and technical requirements for ICT features.
A web content accessibility standard reflected by EN 301 549 in web, non-web document, and software clauses, but not a full substitute for every EN 301 549 or EAA evidence need.
| Dimension | EN 301 549 | WCAG | Operational implication |
|---|---|---|---|
| Scope boundary | EN 301 549 V3.2.1 specifies functional accessibility requirements for ICT products and services and includes conformance checks for applicable requirements. | WCAG provides accessibility success criteria for web content; EN 301 549 reflects WCAG 2.1 content in clauses 9, 10, and 11. | Use EN 301 549 as the ICT evidence framework and WCAG as a web-content evidence source inside that framework where the EN clause points to it. |
| Covered actors | EN 301 549 covers web-based technologies, non-web technologies, hybrids, software, hardware, services, documentation, and support services where the relevant preconditions are met. | WCAG testing is strongest for web content and WCAG-derived checks, but it does not by itself test hardware interaction, closed functionality, support-service communication, or every software accessibility-service requirement. | Start the evidence plan by listing every ICT surface, then mark which surfaces are WCAG-testable and which require EN 301 549-specific assessment. |
| Trigger | Under the EAA, products and services conforming with harmonised standards or parts of harmonised standards cited in the Official Journal are presumed conforming only so far as those standards or parts cover the accessibility requirements. | WCAG can support the accessible web or mobile part of an EAA file, especially because the EAA uses perceivable, operable, understandable, and robust principles for websites and mobile services, but WCAG is not the EAA itself. | Check the EAA legal requirement, the harmonised-standard citation, and the standard clauses before claiming presumption of conformity. |
| Core obligations | EN 301 549 uses self-scoping requirements: when a precondition is true, the corresponding requirement and Annex C conformance check matter. | WCAG test results normally show pass, fail, not tested, or not applicable for selected success criteria on selected web content or software/content samples. | Attach WCAG results to the matching EN 301 549 clause, then separately record EN 301 549 applicability and any non-WCAG checks. |
| Evidence record | EN 301 549 evidence should include clause applicability, test procedures or evaluation notes, functional-performance links, non-applicable reasoning, defects, fixes, and retest status. | WCAG evidence should include tested pages or components, WCAG version and level used by the project, manual and automated findings, assistive-technology notes, and defect closure. | Keep a shared evidence index, but tag each artifact as WCAG evidence, EN 301 549 evidence, EAA product documentation, EAA service information, or Article 14 assessment support. |
| Timing and deadlines | EN 301 549 non-applicability can follow from a failed precondition, but that is different from an EAA fundamental-alteration or disproportionate-burden assessment. | WCAG not-applicable results only show that a success criterion was not relevant to the tested content; they do not resolve EAA Article 14 or EN 301 549 clauses outside the tested surface. | Do not use WCAG not-applicable rows as a legal exception record. Keep EN 301 549 applicability, WCAG test scope, and EAA Article 14 assessments separate. |
| Enforcement | An EN 301 549 claim should identify the version, applicable clauses, assessed ICT boundary, exclusions, and whether the claim is for procurement, product documentation, service information, or conformity support. | A WCAG claim should identify the WCAG version, conformance level, tested scope, date, and known exclusions or open defects. | Use cautious wording: WCAG conformance for a web surface is not the same as full EN 301 549 conformity or EAA compliance for the whole product or service. |
| Overlap and reuse | Use EN 301 549 when the work concerns ICT procurement, product or service accessibility evidence, non-web software, hardware, documentation, support, or a standard-based EAA conformity argument. | Use WCAG when the work concerns web content, page templates, web components, accessible documents or software content where EN 301 549 points to WCAG-derived requirements. | Most EAA teams need both: WCAG for detailed content testing and EN 301 549 for the wider ICT and evidence boundary. |
| Practical decision rule | EN 301 549 V3.2.1 specifies functional accessibility requirements for ICT products and services and includes conformance checks for applicable requirements. | WCAG provides accessibility success criteria for web content; EN 301 549 reflects WCAG 2.1 content in clauses 9, 10, and 11. | Use EN 301 549 as the ICT evidence framework and WCAG as a web-content evidence source inside that framework where the EN clause points to it. |
EN 301 549 V3.2.1 specifies functional accessibility requirements for ICT products and services and includes conformance checks for applicable requirements.
WCAG provides accessibility success criteria for web content; EN 301 549 reflects WCAG 2.1 content in clauses 9, 10, and 11.
Use EN 301 549 as the ICT evidence framework and WCAG as a web-content evidence source inside that framework where the EN clause points to it.
EN 301 549 covers web-based technologies, non-web technologies, hybrids, software, hardware, services, documentation, and support services where the relevant preconditions are met.
WCAG testing is strongest for web content and WCAG-derived checks, but it does not by itself test hardware interaction, closed functionality, support-service communication, or every software accessibility-service requirement.
Start the evidence plan by listing every ICT surface, then mark which surfaces are WCAG-testable and which require EN 301 549-specific assessment.
Under the EAA, products and services conforming with harmonised standards or parts of harmonised standards cited in the Official Journal are presumed conforming only so far as those standards or parts cover the accessibility requirements.
WCAG can support the accessible web or mobile part of an EAA file, especially because the EAA uses perceivable, operable, understandable, and robust principles for websites and mobile services, but WCAG is not the EAA itself.
Check the EAA legal requirement, the harmonised-standard citation, and the standard clauses before claiming presumption of conformity.
EN 301 549 uses self-scoping requirements: when a precondition is true, the corresponding requirement and Annex C conformance check matter.
WCAG test results normally show pass, fail, not tested, or not applicable for selected success criteria on selected web content or software/content samples.
Attach WCAG results to the matching EN 301 549 clause, then separately record EN 301 549 applicability and any non-WCAG checks.
EN 301 549 evidence should include clause applicability, test procedures or evaluation notes, functional-performance links, non-applicable reasoning, defects, fixes, and retest status.
WCAG evidence should include tested pages or components, WCAG version and level used by the project, manual and automated findings, assistive-technology notes, and defect closure.
Keep a shared evidence index, but tag each artifact as WCAG evidence, EN 301 549 evidence, EAA product documentation, EAA service information, or Article 14 assessment support.
EN 301 549 non-applicability can follow from a failed precondition, but that is different from an EAA fundamental-alteration or disproportionate-burden assessment.
WCAG not-applicable results only show that a success criterion was not relevant to the tested content; they do not resolve EAA Article 14 or EN 301 549 clauses outside the tested surface.
Do not use WCAG not-applicable rows as a legal exception record. Keep EN 301 549 applicability, WCAG test scope, and EAA Article 14 assessments separate.
An EN 301 549 claim should identify the version, applicable clauses, assessed ICT boundary, exclusions, and whether the claim is for procurement, product documentation, service information, or conformity support.
A WCAG claim should identify the WCAG version, conformance level, tested scope, date, and known exclusions or open defects.
Use cautious wording: WCAG conformance for a web surface is not the same as full EN 301 549 conformity or EAA compliance for the whole product or service.
Use EN 301 549 when the work concerns ICT procurement, product or service accessibility evidence, non-web software, hardware, documentation, support, or a standard-based EAA conformity argument.
Use WCAG when the work concerns web content, page templates, web components, accessible documents or software content where EN 301 549 points to WCAG-derived requirements.
Most EAA teams need both: WCAG for detailed content testing and EN 301 549 for the wider ICT and evidence boundary.
EN 301 549 V3.2.1 specifies functional accessibility requirements for ICT products and services and includes conformance checks for applicable requirements.
WCAG provides accessibility success criteria for web content; EN 301 549 reflects WCAG 2.1 content in clauses 9, 10, and 11.
Use EN 301 549 as the ICT evidence framework and WCAG as a web-content evidence source inside that framework where the EN clause points to it.
The clean boundary is this: WCAG is a content accessibility standard; EN 301 549 is an ICT accessibility standard. EN 301 549 V3.2.1 states that it reflects WCAG 2.1 content and uses WCAG-linked requirements in clauses 9, 10, and 11 for web, non-web documents, and software. It also contains requirements outside those WCAG-derived areas.
For an EAA program, this means a WCAG audit can support the web or app part of the file, but it should be tied to the EN 301 549 clause, product boundary, and accessibility requirement it supports. Do not label WCAG results as EN 301 549 conformance unless the EN 301 549 self-scoping conditions, applicable clauses, and conformance checks have also been addressed.
Use the comparison to label what WCAG proves, what EN 301 549 still requires, and which EAA product or service records need separate support.
A WCAG report usually answers whether sampled web pages, web components, or digital content meet selected WCAG success criteria. EAA evidence often has to answer a wider set of questions: whether the product or service is in scope, which Annex I requirements apply, whether harmonised standards or technical specifications were applied in full or in part, and whether product or service procedures keep accessibility conformity current.
EN 301 549 also requires scoping discipline. Its requirements are self-scoping, so the precondition for each requirement matters. A payment terminal, ticketing kiosk, e-reader ecosystem, banking service, mobile app, help desk, or downloadable document can require evidence that a web-page-only WCAG audit will not cover.
A useful comparison file should not ask whether the organisation is doing EN 301 549 or WCAG in the abstract. It should state what system is being assessed, which legal and standard boundaries apply, and what each evidence item proves.
The most important review question is whether the evidence is overclaiming. A WCAG pass can support EN 301 549 web-content requirements, but it does not by itself prove conformity for hardware, software interoperability, documentation, support services, EAA product obligations, or an Article 14 fundamental-alteration or disproportionate-burden position.
"applicable accessibility requirements"
"requirements are self-scoping"
"support accessibility"
"Harmonised Standards"