WCAG sets testable requirements for web content. V3.2.1 applies WCAG 2.1 requirements within a wider European ICT standard that also covers hardware, software, documents, communications, documentation, and support.
A WCAG report can support part of an assessment, but neither a WCAG result nor EN 301 549 V3.2.1 by itself proves European Accessibility Act compliance.
Use WCAG to assess web content against a named version and conformance level. Use when the claim covers a wider ICT product or service, including non-web software, documents, hardware, two-way communication, video, biometrics, documentation, or support. EN 301 549 V3.2.1 uses WCAG 2.1 in clauses 9, 10, and 11, then adds requirements and applicability conditions. V3.2.1 is harmonised for the Web Accessibility Directive, not the European Accessibility Act; check the EAA legal requirement and any EAA-specific Official Journal citation before claiming a presumption of conformity.
Side-by-side comparison
EN 301 549 vs WCAG for EU Accessibility Act evidence
A point-by-point comparison for teams deciding when WCAG evidence is enough for a web surface and when 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.
Second framework
WCAG
A web content accessibility standard reflected by in web, non-web document, and software clauses, but not a full substitute for every EN 301 549 or EAA evidence need.
EN 301 549 vs WCAG for EU Accessibility Act evidence
V3.2.1 specifies functional accessibility requirements for ICT products and services and includes conformance checks for applicable requirements.
WCAG provides testable success criteria for web content. WCAG 2.2 is a W3C Recommendation, while V3.2.1 uses WCAG 2.1 in its web, document, and software clauses.
Use as the wider ICT evidence framework and WCAG as a source for the criteria the EN clause applies. Record both versions because choosing WCAG 2.2 does not change the WCAG 2.1 baseline inside V3.2.1.
covers web-based technologies, non-web technologies, hybrids, software, hardware, services, documentation, and support services where the relevant preconditions are met.
WCAG applies to web content. Its criteria can be applied to non-web documents and software through an adaptation such as clauses 10 and 11 or WCAG2ICT, but a web-only WCAG audit does not test hardware interaction, closed functionality, support-service communication, or every software requirement.
Start the evidence plan by listing every ICT surface, then mark which surfaces are WCAG-testable and which require -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 web-content part of an EAA file, and adapted WCAG criteria can support native-app testing. WCAG is not the EAA, and WCAG conformance does not address every Annex I requirement or economic-operator duty.
Check the EAA legal requirement, the exact Official Journal citation, the standard edition, and the clauses it covers before claiming a presumption of conformity. V3.2.1's Web Accessibility Directive citation is not an EAA citation.
uses self-scoping requirements: when a precondition is true, the corresponding requirement and Annex C conformance check matter.
A WCAG audit may report pass, fail, not tested, or not applicable for selected criteria and samples. A WCAG conformance claim must cover full pages, every page in a process when applicable, and all other conformance requirements at the claimed level.
Label a sampled report as an audit, not a conformance claim. Attach each result to the matching clause, then separately record EN applicability and non-WCAG checks.
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 the version and level, full pages and complete processes in scope, sample limitations, manual and automated findings, accessibility-supported technologies, assistive-technology notes, open defects, and closure evidence.
Keep a shared evidence index, but tag each artifact as WCAG evidence, evidence, EAA product documentation, EAA service information, or Article 14 assessment support.
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 clauses outside the tested surface.
Do not use WCAG not-applicable rows as a legal exception record. Keep applicability, WCAG test scope, and EAA Article 14 assessments separate.
An claim should identify the edition, applicable clauses, assessed ICT boundary, exclusions, and purpose. State separately whether V3.2.1 is being used for Web Accessibility Directive presumption, procurement criteria, testing structure, or voluntary EAA support.
A WCAG claim should identify the WCAG version, conformance level, full pages or processes covered, date, relied-on technologies, and unresolved limitations. A sample-based audit should not be presented as conformance for an untested site or product.
Use bounded wording. WCAG conformance for a defined web surface is not full conformity or EAA compliance for the whole product or service, and V3.2.1 has no EAA presumption solely because it is harmonised for the Web Accessibility Directive.
Use when the work concerns ICT procurement, wider product or service testing, non-web software, hardware, documents, communication features, documentation, support, or an ICT clause map. Verify a separate EAA legal basis before making an EAA conformity claim.
Use WCAG when the work concerns web content, page templates, web components, and the adapted document or software criteria to which points. Choose the legal or contractual version first, then consider the additional WCAG 2.2 criteria.
Many EAA ICT teams use both: WCAG for detailed content criteria and for the wider ICT boundary. The evidence file still needs the EAA scope, Annex I mapping, operator records, and valid standard citation.
V3.2.1 specifies functional accessibility requirements for ICT products and services and includes conformance checks for applicable requirements.
WCAG provides success criteria and conformance requirements for web content. V3.2.1 applies WCAG 2.1 through its web, non-web document, and software clauses.
Use WCAG for the content criteria and for the wider ICT assessment. Then map both to the EAA requirement and confirm that the cited standard version has the legal effect being claimed.
Supports the ICT standard scope and the WCAG relationship described on the ETSI EN 301 549 page.
ICT products and services
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
WCAG provides testable success criteria for web content. WCAG 2.2 is a W3C Recommendation, while V3.2.1 uses WCAG 2.1 in its web, document, and software clauses.
Operational implication
Use as the wider ICT evidence framework and WCAG as a source for the criteria the EN clause applies. Record both versions because choosing WCAG 2.2 does not change the WCAG 2.1 baseline inside V3.2.1.
Supports the WCAG version and backwards-compatibility distinctions and confirms that EN 301 549 V3.2.1 uses WCAG 2.1.
Technical coverage
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
WCAG applies to web content. Its criteria can be applied to non-web documents and software through an adaptation such as clauses 10 and 11 or WCAG2ICT, but a web-only WCAG audit does not test hardware interaction, closed functionality, support-service communication, or every software requirement.
Operational implication
Start the evidence plan by listing every ICT surface, then mark which surfaces are WCAG-testable and which require -specific assessment.
Supports the ICT categories and EN 301 549 structure that extend beyond web-content testing.
web based technologies, non-web technologies and hybrids
Use for EAA compliance
EN 301 549
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
WCAG can support the web-content part of an EAA file, and adapted WCAG criteria can support native-app testing. WCAG is not the EAA, and WCAG conformance does not address every Annex I requirement or economic-operator duty.
Operational implication
Check the EAA legal requirement, the exact Official Journal citation, the standard edition, and the clauses it covers before claiming a presumption of conformity. V3.2.1's Web Accessibility Directive citation is not an EAA citation.
Supports V3.2.1's harmonised status for the Web Accessibility Directive and the legal boundary for uncited new versions.
Core obligations
EN 301 549
uses self-scoping requirements: when a precondition is true, the corresponding requirement and Annex C conformance check matter.
WCAG
A WCAG audit may report pass, fail, not tested, or not applicable for selected criteria and samples. A WCAG conformance claim must cover full pages, every page in a process when applicable, and all other conformance requirements at the claimed level.
Operational implication
Label a sampled report as an audit, not a conformance claim. Attach each result to the matching clause, then separately record EN applicability and non-WCAG checks.
Supports the conformance-level, full-page, complete-process, and accessibility-supported requirements.
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
WCAG evidence should include the version and level, full pages and complete processes in scope, sample limitations, manual and automated findings, accessibility-supported technologies, assistive-technology notes, open defects, and closure evidence.
Operational implication
Keep a shared evidence index, but tag each artifact as WCAG evidence, evidence, EAA product documentation, EAA service information, or Article 14 assessment support.
Supports EAA product documentation, service information, and Article 14 assessment records.
assessment of whether compliance
Non-applicability and exceptions
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
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 clauses outside the tested surface.
Operational implication
Do not use WCAG not-applicable rows as a legal exception record. Keep applicability, WCAG test scope, and EAA Article 14 assessments separate.
Supports the Article 14 distinction between technical non-applicability and EAA fundamental-alteration or disproportionate-burden assessment.
fundamental alteration
Claim boundary
EN 301 549
An claim should identify the edition, applicable clauses, assessed ICT boundary, exclusions, and purpose. State separately whether V3.2.1 is being used for Web Accessibility Directive presumption, procurement criteria, testing structure, or voluntary EAA support.
WCAG
A WCAG claim should identify the WCAG version, conformance level, full pages or processes covered, date, relied-on technologies, and unresolved limitations. A sample-based audit should not be presented as conformance for an untested site or product.
Operational implication
Use bounded wording. WCAG conformance for a defined web surface is not full conformity or EAA compliance for the whole product or service, and V3.2.1 has no EAA presumption solely because it is harmonised for the Web Accessibility Directive.
Supports the need for product and service records that show how applicable accessibility requirements are met.
how the relevant accessibility requirements
Which testing framework to use
EN 301 549
Use when the work concerns ICT procurement, wider product or service testing, non-web software, hardware, documents, communication features, documentation, support, or an ICT clause map. Verify a separate EAA legal basis before making an EAA conformity claim.
WCAG
Use WCAG when the work concerns web content, page templates, web components, and the adapted document or software criteria to which points. Choose the legal or contractual version first, then consider the additional WCAG 2.2 criteria.
Operational implication
Many EAA ICT teams use both: WCAG for detailed content criteria and for the wider ICT boundary. The evidence file still needs the EAA scope, Annex I mapping, operator records, and valid standard citation.
Supports the broader standards role for ICT accessibility, EAA, the Web Accessibility Directive, and procurement.
support accessibility
Standards relationship
EN 301 549
V3.2.1 specifies functional accessibility requirements for ICT products and services and includes conformance checks for applicable requirements.
WCAG
WCAG provides success criteria and conformance requirements for web content. V3.2.1 applies WCAG 2.1 through its web, non-web document, and software clauses.
Operational implication
Use WCAG for the content criteria and for the wider ICT assessment. Then map both to the EAA requirement and confirm that the cited standard version has the legal effect being claimed.
Supports the ICT standard scope and the WCAG relationship described on the ETSI EN 301 549 page.
ICT products and services
Practical decision rule
How should teams decide what evidence is enough?
If the question is limited to a website or web component, choose the required WCAG version and level, test full pages and complete processes where making a conformance claim, and map results to clause 9 when EN 301 549 is part of the assurance claim.
If the question involves a covered EAA product or service, add the EAA scope analysis, Annex I requirement mapping, harmonised-standard citation check, and product or service documentation evidence.
If the system includes non-web software, hardware, documents, communication features, support services, or closed functionality, add -specific applicability and conformance checks before making an ICT accessibility claim.
If V3.2.1 is used for EAA work, describe it as testing support unless an applicable EAA Official Journal citation or national rule establishes the stronger legal effect claimed.
If an exception is being considered, keep WCAG non-applicability, precondition results, and EAA Article 14 assessments in separate records.
Supports the requirement to distinguish V3.2.1's Web Accessibility Directive citation from any EAA legal effect.
1
Section 1
Where EN 301 549 and WCAG overlap
WCAG 2 is a W3C technical standard for web content. Its success criteria are organised at Levels A, AA, and AAA. Conformance applies to full web pages and, when a page is part of a process, every page in that process. A sampled audit can identify findings, but it is not a site-wide WCAG conformance claim unless the tested scope and all conformance requirements support that claim.
is an ICT accessibility standard. V3.2.1 reflects WCAG 2.1 in clause 9 for web content and applies adapted WCAG requirements in clause 10 for non-web documents and clause 11 for software. It also adds conditional requirements outside WCAG, including functional performance, hardware, two-way communication, video, biometrics, closed functionality, documentation, and support services.
For EAA work, tie each WCAG result to the clause, ICT boundary, and Annex I accessibility requirement it supports. Do not label WCAG results as EN 301 549 conformance until all applicable EN preconditions, clauses, and conformance checks have been addressed. V3.2.1's Web Accessibility Directive citation does not create an EAA presumption. ETSI now publishes EN 301 549 V4.1.1 (2026-09). Publication of an edition does not by itself establish an EAA presumption of conformity; verify the relevant Official Journal citation and the requirements it covers.
Name the WCAG version, level, full-page or process scope, tested technologies, sampling method, open defects, and date.
Use WCAG results for web content and for document or software clauses that explicitly apply adapted WCAG success criteria.
Use mapping for ICT boundaries beyond a website: hardware, closed functionality, software interfaces, documents, documentation, support services, relay services, and emergency-service access.
Keep EAA legal scope separate from standard conformance: Directive (EU) 2019/882 sets accessibility requirements for covered products and services, while harmonised standards can create presumption of conformity only for the requirements they cover.
Supports the boundary that EN 301 549 V3.2.1 is an ICT accessibility standard and documents its technical relationship to WCAG 2.1; verify the version and Official Journal status before claiming EAA presumption of conformity.
Official W3C overview of WCAG 2.0, 2.1, and 2.2, their publication status, conformance levels, backwards compatibility, and the relationship to EN 301 549.
Normative WCAG 2.2 source for success criteria and conformance requirements, including conformance levels, full pages, complete processes, and accessibility-supported use.
Official source confirming that V3.2.1 is harmonised for Directive (EU) 2016/2102 and that new EN or WCAG versions have no EU legal effect until the relevant standard is cited.
Official ETSI Human Factors page, retrieved 15 October 2026, listing published EN 301 549 V4.1.1 (2026-09). Publication is separate from Official Journal citation.
Recommended next step
Build an EAA evidence file that does not overclaim WCAG coverage
Use the comparison to label what WCAG proves, what EN 301 549 still requires, and which EAA product or service records need separate support.
Why WCAG-only tests may be insufficient for EAA evidence
A WCAG audit usually reports findings for sampled pages, components, or content against a named WCAG version and level. A formal WCAG conformance claim is narrower and stricter: it applies to full pages, covers every page in a process when a page is part of that process, and must satisfy all conformance requirements. Record whether the deliverable is a finding report, a representative-sample assessment, or a conformance claim.
EAA evidence answers wider questions: whether the product or service is in scope, which Annex I requirements apply, what the assessed system includes, whether an EAA-cited harmonised standard or technical specification was applied in full or in part, and whether product or service procedures keep accessibility current. V3.2.1 can organise ICT testing, but its Web Accessibility Directive citation does not create an EAA presumption of conformity.
also requires scoping discipline. Except for clause 12 on documentation and support services, 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.
Add an clause matrix showing applicable, not applicable, pass, fail, and remediation status.
Keep WCAG test evidence, but label the version and level, full pages or processes, sample limits, components, assistive-technology checks, browser and device combinations, defects, and closure evidence.
Add non-WCAG evidence where relevant: hardware interaction checks, closed-functionality review, software accessibility-service support, accessible product documentation, support-service communication, and service conformity procedures.
For products, keep technical documentation and any EU declaration of conformity evidence required by the EAA; for services, keep the general terms or equivalent accessibility information described for service providers.
Supports the EN 301 549 structure covering functional performance, ICT requirements, self-scoping requirements, and the relationship to WCAG-derived clauses.
Supports the distinction between V3.2.1's Web Accessibility Directive harmonisation and an EAA presumption-of-conformity claim.
3
Section 3
Evidence pack fields for the comparison
The comparison file should state what system is being assessed, which legal and standard boundaries apply, and what each evidence item proves. Name V3.2.1 when that is the assessed edition. Name WCAG 2.0, 2.1, or 2.2 and Level A, AA, or AAA rather than writing only "WCAG compliant."
A WCAG pass for a defined web surface can support web-content requirements. It does not prove conformity for hardware, software interoperability, documentation, support services, the entire site when only a sample was tested, EAA product or service obligations, or an Article 14 fundamental-alteration or disproportionate-burden position.
WCAG 2.2 adds success criteria to WCAG 2.1 and W3C encourages use of the latest version, but V3.2.1 still uses WCAG 2.1. Testing to WCAG 2.2 can improve coverage and remains backwards compatible with 2.1, subject to W3C's note that Success Criterion 4.1.1 Parsing is obsolete in 2.2. Keep the legal or contractual baseline separate from the additional criteria the team chose to test.
Product or service boundary: covered EAA product or service, ICT components, web surfaces, non-web documents, native software, hardware, support services, and third-party dependencies.
Standard mapping: exact edition and clause, WCAG version, level, and criterion where relevant, applicability precondition, test method, result, defect link, remediation owner, and retest date.
EAA link: Annex I requirement, harmonised standard or technical specification applied in full or in part, technical documentation or service information location, and any Article 14 assessment.
Claim control: approved wording for procurement, customer assurance, accessibility statements, declarations, and release notes so public claims do not exceed the tested scope.
Official ETSI source for EN 301 549 scope, structure, and technical requirements.
Supports the boundary that EN 301 549 V3.2.1 is an ICT accessibility standard and documents its technical relationship to WCAG 2.1; verify the version and Official Journal status before claiming EAA presumption of conformity.
Supports the EN 301 549 structure covering functional performance, ICT requirements, self-scoping requirements, and the relationship to WCAG-derived clauses.
Show 9 more
Supports the clause-based EN 301 549 evidence structure and the ICT categories that go beyond WCAG-only web tests.
Supports the ICT standard scope and the WCAG relationship described on the ETSI EN 301 549 page.
Supports the ICT categories and EN 301 549 structure that extend beyond web-content testing.
Supports the self-scoping and conformance-check boundary for EN 301 549 evidence.
Supports clause-based conformance and the wider ICT evidence set.
Supports the EN 301 549 self-scoping concept and non-applicability boundary.
Supports versioned EN 301 549 scope and clause-based evidence.
Supports using EN 301 549 across ICT product and service categories while recognising its WCAG-derived web, document, and software clauses.
Supports the EN 301 549 ICT scope, self-scoping structure, and relationship to WCAG-derived clauses.
"Accessibility requirements for ICT products and services"
More quoted passages
"ICT products and services"
"self-scoping"
"web based technologies, non-web technologies and hybrids"
"Conformance is achieved"
"test procedures"
"pre-condition is false"
"V3.2.1"
"software and hardware as well as services"
"requirements in the present document are called self-scoping"
Primary legal source for EAA scope, Annex I accessibility requirements, Article 14 exceptions, conformity evidence, and Article 15 presumption of conformity.
Supports the EAA scope, Annex I accessibility requirements, Article 14 exception framework, and Article 15 presumption-of-conformity rule.
Supports the need for product technical documentation, service accessibility information, conformity evidence, and Article 14 assessments where used.
Show 6 more
Supports the EAA requirements for covered products and services, conformity evidence, and exception records.
Supports the Article 15 presumption-of-conformity boundary and the EAA web/mobile accessibility principles.
Supports EAA product documentation, service information, and Article 14 assessment records.
Supports the Article 14 distinction between technical non-applicability and EAA fundamental-alteration or disproportionate-burden assessment.
Supports the need for product and service records that show how applicable accessibility requirements are met.
Supports separating EAA scope, Annex I requirements, harmonised-standard presumption, and Article 14 assessments.
"accessibility requirements for products and services"
Official source for V3.2.1's harmonised status under the Web Accessibility Directive and the rule that uncited new versions do not change EU legal obligations.
Official source confirming that V3.2.1 is harmonised for Directive (EU) 2016/2102 and that new EN or WCAG versions have no EU legal effect until the relevant standard is cited.
Supports the distinction between V3.2.1's Web Accessibility Directive harmonisation and an EAA presumption-of-conformity claim.
Show 2 more
Supports V3.2.1's harmonised status for the Web Accessibility Directive and the legal boundary for uncited new versions.
Supports the requirement to distinguish V3.2.1's Web Accessibility Directive citation from any EAA legal effect.
Normative source for WCAG 2.2 success criteria and conformance requirements.
Normative WCAG 2.2 source for success criteria and conformance requirements, including conformance levels, full pages, complete processes, and accessibility-supported use.
Normative source for WCAG conformance levels, full-page scope, complete processes, accessibility-supported use, and optional conformance claims.
Show 2 more
Supports the conformance-level, full-page, complete-process, and accessibility-supported requirements.
Supports the requirements for a WCAG conformance claim and the distinction from a sampled audit.
Official W3C source for WCAG purpose, versions, conformance levels, backwards compatibility, and the current relationship to EN 301 549.
Official W3C overview of WCAG 2.0, 2.1, and 2.2, their publication status, conformance levels, backwards compatibility, and the relationship to EN 301 549.
Supports the version history, backwards-compatible relationship among WCAG 2.0, 2.1, and 2.2, and W3C's recommendation to use the latest version.
Show 1 more
Supports the WCAG version and backwards-compatibility distinctions and confirms that EN 301 549 V3.2.1 uses WCAG 2.1.
Published European standard. The cover identifies V4.1.1 (2026-09); its foreword distinguishes publication from Official Journal citation and the resulting legal presumption.
Official ETSI Human Factors page, retrieved 15 October 2026, listing published EN 301 549 V4.1.1 (2026-09). Publication is separate from Official Journal citation.
Historical V4.1.0 draft for comparison with earlier evidence. ETSI now publishes V4.1.1 (2026-09); use the published edition for a new mapping and verify Official Journal status separately.