EN 301 549

EN 301 549 is the European accessibility standard for information and communication
technology products and services.

It provides technical accessibility requirements for websites, mobile applications,
software, electronic documents, hardware, telecommunications, video and support
services.

The standard is particularly important for public-sector digital accessibility and
ICT procurement in Europe. It is also used by technology vendors, contractors and
private organisations that need to demonstrate the accessibility of digital products
supplied to European customers.

What is EN 301 549?

EN 301 549 is a European standard titled
Accessibility requirements for ICT products and services.

It was developed jointly by:

• The European Committee for Standardization, known as CEN.
• The European Committee for Electrotechnical Standardization, known as CENELEC.
• The European Telecommunications Standards Institute, known as ETSI.

The standard provides testable requirements intended to make ICT accessible to
people with a wide range of disabilities.

What is the current harmonised version?

The current version harmonised for the European Web Accessibility Directive is:

EN 301 549 V3.2.1 (2021-03).

Its reference was published in the Official Journal of the European Union in 2021.
From February 2022, it replaced the previously harmonised version, EN 301 549
V2.1.2.

Conformance with the relevant clauses of the harmonised version creates a presumption
of conformity with the accessibility requirements covered by Directive
(EU) 2016/2102.

What about EN 301 549 V4.1.0?

ETSI published EN 301 549 V4.1.0 in June 2026 as an approval-vote version.

A newly developed version does not automatically replace the legally harmonised
version. For a new version to obtain legal significance under the Web Accessibility
Directive, its reference must first be published in the Official Journal of the
European Union.

Organisations should therefore distinguish between:

• The newest technical draft or published standard.
• The version formally harmonised under a specific European law.
• Additional requirements imposed by national legislation or procurement contracts.

Is EN 301 549 a law?

EN 301 549 is a technical standard, not a law by itself.

It becomes legally relevant when legislation, procurement rules, regulations or
contracts refer to it.

Important legal frameworks connected with the standard can include:

• Directive (EU) 2016/2102 on public-sector websites and mobile applications.
• National laws implementing that directive.
• European and national public-procurement requirements.
• Accessibility requirements under the European Accessibility Act.
• Contractual accessibility requirements imposed by customers.

The precise legal obligation depends on the organisation, product, service,
jurisdiction and applicable legislation.

Who uses EN 301 549?

The standard may be used by:

• Public-sector bodies in European Union member states.
• National, regional and local government organisations.
• Public-sector website and mobile-application teams.
• ICT procurement departments.
• Software and hardware vendors.
• Web and mobile development agencies.
• Contractors supplying technology to public bodies.
• Accessibility auditors and testing providers.
• Private organisations seeking European accessibility alignment.

A private company may be asked to demonstrate EN 301 549 conformance when responding
to a public tender or supplying ICT to a European public-sector customer.

What types of ICT does EN 301 549 cover?

EN 301 549 is broader than a website standard. It covers many forms of information
and communication technology.

How is EN 301 549 organised?

The standard contains general requirements and technology-specific chapters.

Its main subject areas include:

• Functional-performance statements.
• Generic requirements.
• ICT with two-way voice communication.
• ICT with video capabilities.
• Hardware.
• Web content.
• Electronic documents.
• Software.
• Documentation and support services.
• Requirements for relay and emergency services.

Functional-performance statements

EN 301 549 includes functional-performance statements describing user needs that
may apply when a specific technical requirement does not fully address a product or
function.

These statements consider use:

• Without vision.
• With limited vision.
• Without perception of colour.
• Without hearing.
• With limited hearing.
• Without vocal capability.
• With limited manipulation or strength.
• With limited reach.
• With limited cognition, language or learning ability.
• While minimising photosensitive seizure triggers.

Functional performance is particularly important for ICT that does not fit neatly
into conventional web or software categories.

EN 301 549 and WCAG

EN 301 549 V3.2.1 incorporates the WCAG 2.1 Level A and Level AA success criteria
for relevant web content.

Many WCAG requirements are also applied to electronic documents and non-web
software, with adaptations appropriate to those technologies.

WCAG addresses web-content accessibility through four principles:

• Perceivable.
• Operable.
• Understandable.
• Robust.

Learn more about
WCAG 2.1 accessibility requirements.

Is EN 301 549 identical to WCAG?

No. WCAG is an important component of EN 301 549, but the European standard covers
additional technology and requirements.

Examples of areas beyond standard website WCAG testing include:

• Two-way voice communication.
• Real-time text.
• Video communication.
• Hardware controls.
• Closed functionality.
• Software interoperability with assistive technologies.
• Product documentation.
• Support services.
• Biometric functionality.

A website-only WCAG audit does not establish that an entire ICT product conforms to
EN 301 549.

Web accessibility requirements

The web chapter applies WCAG 2.1 Level A and AA to covered web pages and web-based
functionality.

Common requirements include:

• Text alternatives for meaningful images.
• Captions and alternatives for multimedia.
• Semantic headings and page structure.
• Sufficient text and user-interface contrast.
• Keyboard access to functionality.
• Logical focus order.
• Visible keyboard focus.
• Accessible forms and error messages.
• Meaningful link and control names.
• Content that supports text enlargement and reflow.
• Compatibility with assistive technologies.

Mobile-application accessibility

Mobile applications must support the relevant accessibility requirements for their
platform and functionality.

Testing may include:

• Screen-reader navigation.
• Accessible names, roles and states.
• Logical swipe and focus order.
• External-keyboard operation.
• Text enlargement.
• Orientation support.
• Touch-target size and spacing.
• Contrast.
• Error identification.
• Platform accessibility settings.

A mobile application should be tested on its supported operating systems and with
the assistive technologies available on those platforms.

Electronic-document accessibility

EN 301 549 applies relevant WCAG requirements to non-web electronic documents.

Examples include:

• PDF documents.
• Word-processing files.
• Spreadsheets.
• Presentations.
• Electronic forms.
• Reports and publications.

Document testing may address:

• Document title and language.
• Heading structure.
• Reading order.
• Alternative text.
• Table headers and relationships.
• Lists.
• Link purpose.
• Form labels.
• Colour contrast.
• Keyboard access.

Software accessibility

Software must expose information and functionality in ways that work with the
accessibility services of the operating environment.

Relevant requirements may include:

• Accessible names and descriptions.
• Programmatic roles and states.
• Keyboard operation.
• Focus management.
• Text and user-interface contrast.
• Support for platform accessibility APIs.
• Compatibility with assistive technologies.
• Accessible notifications and error messages.
• User preferences for colour, contrast and text size.

Hardware and closed functionality

Some ICT products have closed functionality, meaning users cannot attach or install
their own assistive technology.

Examples may include:

• Self-service kiosks.
• Ticketing machines.
• Payment terminals.
• Information terminals.
• Printers and multifunction devices.
• Public-access computers.

In these cases, accessibility may need to be built directly into the product through
speech output, tactile controls, visual alternatives, adjustable presentation and
accessible input methods.

Biometric identification

When ICT uses biometric characteristics for identification or control, it should not
rely exclusively on one biological characteristic when that would exclude users.

Examples may include:

• Fingerprint recognition.
• Facial recognition.
• Voice recognition.
• Iris or eye scanning.

An accessible alternative should be available where a user cannot provide or operate
the required biometric input.

Voice communication and real-time text

ICT supporting two-way voice communication may need to address:

• Audio quality.
• Volume adjustment.
• Hearing-aid compatibility.
• Real-time text.
• Caller identification.
• Accessible call controls.
• Visual alternatives for auditory signals.
• Auditory alternatives for visual signals.

These requirements can be relevant to telephone systems, conferencing tools,
communication applications and customer-service platforms.

Video communication

Video communication may require support for:

• Display of sign language.
• Appropriate video resolution and frame rate.
• Synchronisation of audio and video.
• Visual indication of audio activity.
• Accessible participant and call controls.
• Keyboard and assistive-technology operation.

Documentation and support services

Product accessibility includes the information and assistance required to use the
product.

Documentation and support should explain:

• How to install and operate accessibility features.
• Compatibility with assistive technologies.
• Known accessibility limitations.
• Required configuration steps.
• Accessible support channels.
• How to request documentation in an accessible format.

Support services should be able to communicate with users through accessible methods
appropriate to the service.

The Web Accessibility Directive

Directive (EU) 2016/2102 requires EU member states to ensure that covered public-sector
websites and mobile applications are perceivable, operable, understandable and robust.

EN 301 549 V3.2.1 is the harmonised standard used to provide a technical presumption
of conformity with the requirements covered by the directive.

Public-sector obligations commonly include:

• Accessible websites.
• Accessible mobile applications.
• Published accessibility statements.
• A feedback and request mechanism.
• Monitoring by member states.
• Periodic reporting to the European Commission.

Member states implement the directive through national law, so enforcement methods
and responsible bodies can differ between countries.

Web Accessibility Directive timelines

The directive’s original implementation deadlines were:

• September 23, 2019 for covered websites published after September 23, 2018.
• September 23, 2020 for covered websites published before September 23, 2018.
• June 23, 2021 for covered mobile applications.

These dates have already passed. Covered organisations should now be maintaining,
monitoring and reporting accessibility rather than treating the deadlines as future
targets.

Content exemptions under the directive

The Web Accessibility Directive contains exclusions and exemptions for certain types
of content and organisations.

Depending on the circumstances, these may involve:

• Office-file formats published before specified dates.
• Prerecorded time-based media published before specified dates.
• Live time-based media.
• Online maps and mapping services, subject to accessible alternatives for essential navigational information.
• Third-party content outside the organisation’s control.
• Reproductions of heritage-collection items.
• Content of extranets and intranets published before specified dates until substantially revised.
• Archived content that is no longer updated or required for active processes.

Exemptions should be assessed carefully. They do not create a general permission to
ignore accessibility.

Disproportionate burden

A public-sector body may determine that meeting a particular requirement would impose
a disproportionate burden, subject to the applicable national law and assessment.

The assessment should consider factors such as:

• The size, resources and nature of the organisation.
• The estimated cost and benefit.
• The frequency and duration of use.
• The effect on people with disabilities.
• The availability of accessible alternatives.

A disproportionate-burden claim should be documented and explained in the
accessibility statement. It is not equivalent to a blanket exemption from the
directive.

Accessibility statements

Covered public-sector organisations must publish an accessibility statement for
their websites and mobile applications.

A statement should normally include:

• The organisation’s conformance status.
• Known inaccessible content.
• The reasons for non-conformance.
• Accessible alternatives where available.
• A method for reporting barriers.
• A method for requesting accessible information.
• Information about the enforcement procedure.
• The date and method of the most recent assessment.

The statement should be based on current evidence and updated when the digital
service changes significantly.

EN 301 549 and the European Accessibility Act

The European Accessibility Act applies accessibility requirements to specified
products and services placed on the European market.

EN 301 549 can provide useful technical requirements for ICT accessibility, but an
organisation should not assume that the version harmonised for the Web Accessibility
Directive automatically establishes complete conformity with every obligation under
the European Accessibility Act.

The applicable legislation, harmonised standards, delegated acts and national
implementation measures should be reviewed for the specific product or service.

Learn more about the
European Accessibility Act.

EN 301 549 in public procurement

Public authorities can reference EN 301 549 when purchasing ICT products and
services.

Procurement documentation may require suppliers to:

• Identify applicable clauses.
• Provide an accessibility-conformance report.
• Describe testing methods.
• Disclose known limitations.
• Demonstrate key user journeys.
• Provide a remediation plan.
• Support acceptance testing.
• Maintain accessibility after product updates.

A generic statement that a product is “WCAG compliant” may be insufficient when the
tender covers software, documents, hardware, telecommunications or support services.

How to assess EN 301 549 conformance

1. Define the ICT product:
   identify websites, applications, software, hardware, documents, communication
   functions and support services.
2. Identify applicable clauses:
   determine which chapters and requirements apply to the product.
3. Define representative workflows:
   select the user journeys and functions that need to be tested.
4. Combine testing methods:
   use automated, manual, functional and assistive-technology testing.
5. Document evidence:
   record findings, affected users, requirements and reproduction steps.
6. Assign remediation:
   route barriers to development, design, content, hardware, procurement or support.
7. Retest corrections:
   verify that each barrier has been resolved.
8. Maintain conformance:
   repeat testing after significant product releases and content changes.

Automated testing

Automated testing can identify many web and software problems, including:

• Missing accessible names.
• Invalid markup.
• Insufficient contrast.
• Missing alternative text.
• Incorrect form associations.
• Duplicate identifiers.
• Some document-structure problems.

Automated tools cannot establish complete EN 301 549 conformance because many
requirements involve user interaction, meaning, hardware, communication, documents,
support and assistive-technology compatibility.

Manual and assistive-technology testing

Manual testing may be needed to assess:

• Keyboard operation.
• Focus order and focus management.
• Screen-reader interaction.
• Accessible mobile gestures.
• Caption and audio-description quality.
• Document reading order.
• Hardware controls.
• Communication functions.
• Accessible documentation and support.

Testing should confirm that users can complete meaningful tasks, not only that
individual components pass isolated checks.

Common EN 301 549 barriers

• A website menu cannot be operated with a keyboard.
• A mobile application exposes controls without accessible names.
• A PDF has no tags or logical reading order.
• A software dialog does not expose its state to assistive technology.
• A kiosk relies entirely on touch-screen visual controls.
• A video has no captions.
• A communication service does not support accessible call controls.
• A biometric process provides no alternative identification method.
• Product documentation is available only in an inaccessible format.
• Customer support cannot communicate through an accessible channel.

Documentation and evidence

Organisations should maintain evidence showing how accessibility was evaluated and
managed.

Useful records include:

• Product and version tested.
• Applicable EN 301 549 clauses.
• Testing tools and methods.
• Browsers, platforms and assistive technologies used.
• Pages, screens and workflows tested.
• Identified barriers.
• Remediation decisions.
• Verification results.
• Known limitations.
• Accessibility statements and conformance reports.

How Pluro supports EN 301 549 accessibility work

Pluro is an accessibility workflow platform that helps organisations manage digital
accessibility findings from detection through verified remediation.

Teams can centralise automated and manual findings, capture behavioural evidence,
assign responsibility, provide remediation guidance and preserve verification history.

Pluro can support the web and digital-software portions of an EN 301 549 programme,
particularly where organisations need to coordinate work across websites,
applications, development teams and content owners.

Pluro does not automatically certify an entire ICT product against EN 301 549.
Hardware, telecommunications, documentation, support, mobile and product-specific
requirements may require additional specialist assessment.

EN 301 549 checklist

• Confirm which version of the standard is contractually or legally relevant.
• Identify all ICT included in the assessment.
• Map applicable clauses to product functionality.
• Test websites and web applications against relevant WCAG requirements.
• Review mobile applications on supported platforms.
• Assess electronic documents.
• Review software and accessibility-API support.
• Assess hardware and closed functionality.
• Review voice, video and communication functions.
• Test documentation and support services.
• Document findings and known limitations.
• Verify remediation after corrections.
• Retest after significant product changes.

Important notice

This page provides general information and does not constitute legal advice or formal
certification. EN 301 549 applicability depends on the ICT product, applicable law,
member state, procurement process, contract and version of the standard referenced.

Review the official

EN 301 549 V3.2.1 standard
.

See how Pluro manages accessibility workflows
or
start a 14-day free trial
with no credit card required.