WCAG sets testable requirements for web content. EN 301 549 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 EN 301 549 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 the latest WCAG 2 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.
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 the latest WCAG 2 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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. Do not label V3.2.1 as an EAA harmonised standard merely because it is harmonised for the Web Accessibility Directive. ETSI listed V4.1.0, dated June 2026, as on approval on 25 July 2026; an approval-stage text is not a final standard or an Official Journal citation.
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.
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.
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.
ETSI final draft prepared in the EAA and Web Accessibility Directive standardisation work. ETSI lists V4.1.0 (2026-06) as on approval; approval-stage status is not an Official Journal-cited EAA harmonised standard.