Standards
EN 301 549 vs WCAG: What Product Teams Should Know
A practical guide comparing EN 301 549 and WCAG for product teams, covering ICT scope, EU accessibility laws, WCAG 2.1 and 2.2, audit evidence, remediation, and retesting.
Quick answer: how are EN 301 549 and WCAG different?
EN 301 549 is the European accessibility standard for ICT products and services. WCAG, the Web Content Accessibility Guidelines, is the W3C standard that defines accessibility requirements for web content.
For product teams, WCAG is a core technical benchmark. EN 301 549 is broader. It can include web content, mobile apps, software, documents, hardware, telecommunications, support services, procurement requirements, and conformity evidence.
Why product teams should understand the difference
Product teams often hear EN 301 549 and WCAG used together, especially in European public-sector, procurement, SaaS, regulated, and enterprise contexts. Treating them as identical can create weak scope, incomplete audits, and unsupported conformity language.
WCAG helps teams test digital content accessibility. EN 301 549 helps teams understand accessibility across ICT products and services.
- WCAG explains many web and content accessibility requirements.
- EN 301 549 maps accessibility requirements across broader ICT categories.
- Product scope may include documents, apps, software, support content, and hardware-related interactions.
- Audit evidence should match the actual ICT category being reviewed.
- Legal or procurement claims should reference the correct version and scope.
What EN 301 549 covers
ETSI describes EN 301 549 as accessibility requirements for ICT products and services. The European Commission explains that EN 301 549 supports the Web Accessibility Directive as a harmonised technical standard and that it was developed by European standards organisations.
The standard is useful to product teams because it frames accessibility as a product and service issue, not only a website issue.
- Websites and web applications.
- Mobile apps and software interfaces.
- Electronic documents, PDFs, office documents, and digital content.
- Hardware, kiosks, telecommunications, and other ICT where relevant.
- Documentation, support services, procurement, and conformity evidence.
- Testing procedures and evaluation expectations for accessibility requirements.
What WCAG covers
WCAG explains how to make web content more accessible to people with disabilities. W3C describes WCAG as covering natural information such as text, images, and sounds, as well as code or markup that defines structure and presentation.
For product teams, WCAG is essential because many customer-facing barriers appear in web content, applications, documents, forms, navigation, media, and dynamic states.
- Perceivable content such as text alternatives, contrast, captions, and adaptable structure.
- Operable interaction such as keyboard access, focus, timing, navigation, and input methods.
- Understandable content such as readable text, predictable interaction, labels, instructions, and errors.
- Robust implementation such as valid semantics, accessible names, roles, states, and compatibility with assistive technologies.
- Success criteria grouped by conformance levels such as A, AA, and AAA.
Current version nuance: WCAG 2.1 and WCAG 2.2
The European Commission page on Web Accessibility Directive standards explains that EN 301 549 v3.2.1 is based on WCAG 2.1 and has been the harmonised version referenced in the Official Journal. AccessibleEU reports that EN 301 549 v4.1.1 was published in September 2026 and adopts WCAG 2.2 for websites, software, and digital documents.
However, AccessibleEU also states that v4.1.1 is not yet the legal reference standard until the European Commission formally cites it in the Official Journal of the European Union. Product teams should therefore verify which version applies to their market, contract, procurement, or legal context before making conformity claims.
- EN 301 549 v3.2.1 is based on WCAG 2.1 Level AA in the current EU legal reference context.
- EN 301 549 v4.1.1 was published in September 2026 and adopts WCAG 2.2.
- Published does not automatically mean harmonised for legal presumption of conformity.
- Contracts may require a specific version even before or after legal harmonisation.
- Audit reports should state the EN 301 549 version, WCAG version, scope, and evidence basis.
Where EN 301 549 goes beyond WCAG
The European Commission notes that EN 301 549 includes requirements that are not part of WCAG and can include requirements not relevant to the Web Accessibility Directive, such as computer hardware system accessibility.
For product teams, this means a WCAG audit may be necessary but not always sufficient. If the product scope includes non-web ICT, procurement, documents, support, hardware, or software behavior, the audit may need EN 301 549 mapping as well.
- Hardware controls, output, biometrics, and communication-related ICT where relevant.
- Software and platform behavior beyond web content alone.
- Digital documents and office file accessibility.
- Support documentation, user assistance, and service information.
- Procurement and conformity evidence expectations.
- Product and service-level accessibility requirements.
What this means for audit scope
An EN 301 549-aligned audit should start by defining the ICT scope. A website-only review cannot prove accessibility for mobile apps, software clients, admin portals, PDF workflows, hardware interactions, or support services unless those areas are included.
WCAG mapping should be included where web content, documents, or software interfaces are evaluated. EN 301 549 mapping should be added where the broader ICT standard is the target.
- Websites, apps, documents, software, hardware, and support services in scope.
- User roles, tasks, critical workflows, documents, and configurations tested.
- Applicable EN 301 549 version and clauses.
- Applicable WCAG version and conformance level.
- Exclusions, known limitations, vendor dependencies, and third-party components.
- Evidence expectations for findings and retesting.
What product teams should prepare
Product teams should prepare inputs that let auditors test the real product, not only the public marketing surface. The more complex the ICT, the more important scope and access become.
Preparation should include product states, user journeys, sample data, documents, support flows, release information, and known accessibility risks.
- Product inventory and platform list.
- Critical user journeys and business-critical tasks.
- Test accounts, roles, devices, browsers, and assistive technology expectations.
- Documents, templates, generated PDFs, emails, support content, and onboarding materials.
- Third-party components, embedded services, and vendor-controlled workflows.
- Target standard, version, clauses, WCAG level, and reporting needs.
Audit evidence should match the standard
A serious audit should not only say that a product passed or failed. It should provide evidence that explains the barrier, standard mapping, user impact, remediation action, and retest path.
Evidence should be selected based on the ICT category and issue type.
- Screenshots for visual, contrast, layout, focus visibility, and document structure issues.
- Keyboard paths for navigation, focus order, modals, menus, forms, and traps.
- Screen reader notes for names, roles, states, values, reading order, and status messages.
- Document checks for tags, headings, tables, links, forms, metadata, and reading order.
- Product or service evidence for support documentation, configuration, hardware, or vendor behavior.
- Retest evidence connected to the original finding ID.
Common mistakes
Most EN 301 549 and WCAG mistakes come from unclear scope or unsupported language. Product teams should avoid making broad claims from narrow evidence.
Use precise wording in audit reports, product documentation, procurement responses, and customer-facing accessibility statements.
- Treating WCAG conformance as full EN 301 549 conformity without checking broader ICT requirements.
- Claiming compliance with a new EN version before confirming legal or contractual applicability.
- Ignoring documents, software states, admin interfaces, help content, or vendor workflows.
- Relying only on automated scanning for complex product behavior.
- Using accessibility statements without current test evidence.
- Closing remediation without retesting the original barrier.
Practical recommendation
Use WCAG to evaluate web content and digital interaction quality. Use EN 301 549 when the product or procurement context requires broader ICT accessibility coverage. Always state the version, scope, method, evidence, and limitations.
For European public-sector, procurement, and enterprise product contexts, product teams should prepare for both WCAG-based testing and EN 301 549 mapping so audit findings can support remediation, conformity review, and customer trust.
Official references used
ETSI Human Factors standards page: https://www.etsi.org/technical-groups/hf/
European Commission Web Accessibility Directive standards and harmonisation: https://digital-strategy.ec.europa.eu/en/policies/web-accessibility-directive-standards-and-harmonisation
AccessibleEU EN 301 549 v4.1.1 update: https://accessible-eu-centre.ec.europa.eu/content-corner/news/european-accessibility-standard-en-301-549-has-been-updated-2026-09-07_en
W3C WCAG Overview: https://www.w3.org/WAI/standards-guidelines/wcag/
W3C WCAG 2.2 Recommendation: https://www.w3.org/TR/WCAG22/