How to use the EN 301 549 standard
21st January 2025
EN 301 549 is a technical standard that defines how to make information and communications technologies (ICT) accessible to users with disabilities. The standard also provides a verifiable evaluation methodology for the requirements, allowing it to be used to support accessibility legislation. The standard was originally developed to address procurement, then updated to address the European Web Accessibility Directive of 2016 . The current version has been further updated to address the European Accessibility Act of 2019 .
This explainer describes how the standard is organised, and how to interpret the requirements in its different sections. It also collates and comprehensively summarises the requirements, to help readers understand the characteristics of accessible products and services as defined by the standard. The guidance here will help with interpretation, but does not replace working with the standard directly.
Introduction
The European Accessibility Act (EAA) of 2019 defines accessibility requirements for information and communications technology (ICT) products and services in the EU, as a component of the European Union Digital Single Market Strategy. The act specifies that technical requirements need to be provided by “harmonised standards”. See the companion document, The European Accessibility Act: Understanding Digital Accessibility, for a detailed introduction to how this works in the EAA.
Standardisation request M/587 was taken up by European Telecommunications Standards Institute (ETSI), European Committee for Standardization (CEN), and European Committee for Electrotechnical Standardization (CENELEC), three European standards bodies whose mandates intersect for the goals of this standard. Previously, EN 301 549 addressed digital procurement, and was expanded to support the EAA in response to that mandate.
The name of the standard is a function of the ETSI numbering system resulting in the title “EN 301 549”. While the document has the title “Accessibility requirements for ICT products and services”, it is generally referenced by its name rather than title. For understandability, this document will usually abbreviate mentions to “the EN” or “the standard”.

Status of the standard
The public version of EN 301 549 at time of this writing was published in 2021. The standard has been under revision since then, with plans to present a mature draft to the European Commission in January 2025. The work schedule for the standard shows that it is not expected to reach this final stage until May 2026. The final version will be published in the Official Journal of the European Union. At that point, the standard will be legally considered to meet the requirements of the European Accessibility Act.
Given that the EAA comes into force in June 2025, this means there will not be an official standard in place at the time. Nonetheless, organisations need to meet EAA requirements, and the EN 301 549 draft is the best resource to follow.
An updated version of the standard is likely to be published this year as the standard continues the formal approval process. In the latest working draft, along with clarification and reorganisation, the most significant changes include additional requirements for real time text, and referencing WCAG 2.2 instead of 2.1 (see Requirements that reference Web Content Accessibility Guidelines). In anticipation of this change, we recommend using WCAG 2.2 instead of 2.1 as well, along with the latest version of WCAG2ICT (see Requirements that reference WCAG2ICT).
We plan to update this explainer to provide full details when an updated version of EN 301 549 is published.
Coverage of the European Accessibility Act
The EAA explainer describes what entities must conform to that law, and the role of standards like EN 301 549. For ICT, the EN 301 549 is the only available standard that is considered to meet the requirements of the EAA and thus invoke the “presumption of conformance”. Attempting to conform to the EAA without conforming to the EN 301 549 would be extremely difficult, so conforming to the EN 301 549 is the best way to ensure conformance with EAA requirements.
The EAA addresses primarily information and communications technology, which is what the EN 301 549 addresses. However, the EAA also incorporates accessibility requirements from other acts, which address non-ICT situations. The above explainer shows which requirements are not covered by EN 301 549 and suggests how to interpret those requirements separately. These are primarily in sections for:
- Electronic communications providing emergency service access
- Passenger transport
- Consumer banking
- Consumer network provision devices
- Distribution
If your product or service is involved in these areas, please review the relevant guidance in the EAA explainer.
Beyond the above non-ICT categories, a few ICT requirements from the EAA are not fully covered by the EN 301 549. The explainer mentions these in notes attached description of related parts of the standard.
Using this explainer
A challenge to interpretation of the standard is that requirements are organised by technology type, while most people working with it will be working on a specific type of accessibility feature. A visual designer would address visual design requirements, a hardware designer would address physical operation features, a subject matter expert might develop alternative content if needed, etc.
The remainder of this explainer is divided into three sections:
- How the standard addresses ICT accessibility - overview of the various types of ICT covered by the standard;
- How to read the requirements - explains the wording and structures used by the standard to set out requirements;
- Requirements by access type - a comprehensive summary of the requirements of the standard, organised in a different manner from the standard.
The first section explains how the standard organises requirements by type of ICT. Most products meet the definition of several types of ICT and must follow the requirements of each relevant section, in addition to general requirements for all ICT.
The second section provides advice about working with the specific normative requirements. The standard has both standalone requirements and requirements derived from Web Content Accessibility Guidelines 2.1, which require use of external resources. This section also summarises how to work with those resources.
The intent of the third section is to orient readers who are less familiar with accessibility. It describes various ways that accessibility is achieved in different situations. Its organisation is intended to allow people, who are working on different aspects of a product’s accessibility, to find and understand the requirements that relate to their particular role in developing the solutions. It is not, however, a complete guide to conformance.
Terms and concepts are introduced progressively, and explained on first use. Most of the content of the explainer attempts to summarise the content of the standard in an objective manner. Interpretive advice is given in notes, indented paragraphs that begin with the text ‘Note:’.
How the standard addresses ICT accessibility
The term “ICT” refers to computing devices (PCs, servers, smartphones) and the software that runs on them, as well as person-to-person communication devices and features (old-fashioned telephones, mobile phones, chat networks). Many different types of ICT are addressed in the standard. The standard is organised primarily with chapters for each type of ICT, as well as some common requirements applicable to all ICT.
The standard addresses specific types of information and communications technology, with requirements for each. Some of these are universal and apply to all ICT:
- Functional performance - high-level characteristics of accessible ICT, such as “usage with limited vision”, “usage with limited reach”, etc.;
- Generic requirements - requirements for accessible ICT beyond the type-specific ones below;
- Closed functionality - additional requirements for ICT that cannot be used with assistive technology and must therefore replicate those features in its own feature set.
The base requirements are expanded with requirements that relate to individual types of ICT:
- Real time text - tools that allow two-way communication over text, such as chat applications;
- Two-way voice - voice telecommunications tools, such as telephones and calling applications;
- Two-way video - video telecommunications tools, such as videoconferencing applications;
- Hardware - physical devices that provide any of the features addressed by the standard, and including considerations for the physical environment in which it is used;
- Web - applications and content available on the Web;
- Documents - electronic documents that are not served on the Web;
- Software - applications that run on a user’s device;
- Documentation and support services - online documentation and support for ICT products and services;
- ICT providing relay service access or emergency service access - phones and other devices defined in the European Communications Code.
A given product will typically encompass several of the above types. For instance, a modern mobile phone is hardware that provides two-way voice, software which enables the user to create documents and web content, all of which have documentation and support service requirements. The device may also provide relay service or emergency service access. Therefore, the device must conform to the standard in nearly all of the areas. On the other hand, a web service that does not provide communication services needs to comply primarily with the web portion of the standard.
Across all the technology types, the standard addresses many aspects of accessibility related to various user needs. For instance, users with perceptual disabilities have different accessibility requirements from users with motor disabilities. Accessibility needs may also be met in different ways depending on the situation. For instance, accommodating a perceptual disability may involve software adjustment to make the content more perceivable, while accommodating a motor disability may require adjustments to the hardware design.
Assistive technology
Support for “assistive technology (AT)” is one way that ICT is made accessible to certain users. AT is supplementary technology that is not part of a product itself, but can interact with it. Some assistive technologies support an individual’s physical interaction, and generally need to plug into the main device via a port. AT can also be installed as software on a computer or smartphone. This software interacts with the main application (the product under consideration) to allow the user to provide input or receive output in different ways but without separate hardware controls. The interaction between AT and application is moderated by specialised “application programming interfaces (APIs)”, which are features of the main device designed for this purpose. Some requirements therefore address how to provide support for AT.
Most of the accessibility requirements in the standard presume that the user can use assistive technology to interact with the ICT. Because many access needs are fulfilled by the AT, the ICT does not need to address those features. The standard accordingly does not prescribe requirements for features that can be used with AT.
Closed functionality
Technology that cannot be used with AT is called “closed functionality”. This includes hardware that lacks features to connect external assistive devices, and software that does not allow assistive technology software to interact with it. There are reasons for products to be designed in this manner, but they then must provide directly the features that would have been provided by assistive technology. This includes features like providing self-voicing of text, supporting customization of interaction, highlighting important alerts that could be overlooked, etc.
The concept of “closed functionality” is not a type of technology, it is a characteristic of how a feature was implemented. When a feature on any type of ICT is closed to assistive technology, the closed functionality requirements apply only for that feature. Other features of the product that are not closed to AT must still follow the applicable requirements for non-closed functionality.
Conformance
Each requirement in the standard begins with a “pre-condition”, beginning with “Where ICT …”. These conditions relate to the type of ICT or to a particular feature it may provide, like “Where ICT hardware has speech output” or “Where ICT is web page”. If the product does not match this pre-condition, then the requirement is not applicable for conformance.
For applicable requirements, the product or service must be known to meet the requirement. Annex C provides normative test procedures for each requirement, with explicit pass and fail conditions. Some test procedures mainly relate back to the requirement, and say “check that the product does not fail …”. Other test procedures provide details that must be verified during the test. In some cases, these details require following additional standards referenced by the requirement, in particular for hardware.
There are many ways to test the requirements of the standard, aided by tools evaluating the product and the process of its development. Robust procedures for accessibility conformance should be integrated into an organisation’s existing toolset. Internal or external accessibility experts should provide guidance for how to verify conformance of a specific product. It is important that the combination of procedures produce results with equivalent accuracy to the inspection process in the annex.
How to read the requirements
There is no single heading level that corresponds to the full set of requirements; instead requirements are found in sentences using the word “shall”. Aside from front matter and explanation of this principle, the word “shall” only appears on requirements. This differentiates formal requirements of the standard from other types of text.
Note: A few sections that might seem to be requirements use “should” instead of “shall”. These are recommendations, but not conformance requirements.
The standard does not use a specific format for its requirements, aside from the pre-condition and use of “shall”. Some requirements are simple sentences, others are paragraphs, and others include lists of details. The lowest heading level in a given section generally contains the formal requirements, while higher levels organise the requirements, but the specific heading levels vary from section to section. The headings have nested section numbers and section titles, so it is easy to point out a specific requirement.
The table referenced from Appendix: mapping table contains a full set of the requirements by section number, organised into the type of technology and type of accessibility feature they address.
Requirements that stand on their own
In most of the sections, the wording of the requirements provides the full context needed to follow the requirement. The level of detail varies according to the amount of context needed, ranging from simple sentences to multiple details with measurements and diagrams. Working with these requirements is a matter of going through the relevant sections and simply following the guidance.
The following sections contain only requirements that stand on their own:
- Section 5 Generic requirements
- Section 6 ICT with two-way voice communication
- Section 7 ICT with video capabilities
- Section 8 Hardware
- Section 12 Documentation and support services
- Section 13 ICT providing relay or emergency service access
Status of the standard
Web content is addressed in:
- Section 9 Web
For these requirements, the standard harmonises with Web Content Accessibility Guidelines (WCAG) 2.1. WCAG 2.1 includes three levels of conformance: A, AA, and AAA, where the higher levels reflect greater accessibility effort. The EN references each of the A and AA requirements, linking to each of them individually via corresponding sections of the EN. Some sections labelled “void” explicitly exclude certain AAA requirements in order to keep section numbering consistent with WCAG 2.1. AAA requirements are not included in EN 301 549 conformance requirements, though the standard encourages developers to follow them when applicable.
Note: the current version of the EN harmonises with WCAG 2.1. A new version, WCAG 2.2, was published after the content of the EN had been mostly finalised. Future updates to the standard are likely to update the WCAG reference. We recommend using WCAG 2.2 now, including its new A and AA success criteria that are not yet referenced by the EN.
WCAG uses a different structure than the EN. The WCAG requirements referenced by the standard are called “success criteria”, and are statements that should each evaluate to “true” when applied to the web content.
Note: The standard points out that success criteria are worded such that if the statement is not applicable to the particular content, it still evaluates to “true”. In practice it is easier to think of them as “not applicable”, so for example success criteria that address audio content do not apply to sites that do not have audio content.
While the wording of WCAG success criteria contains all the information needed to determine if content conforms, they do not generally provide enough information to understand what needs to be done to achieve conformance. Unlike the other requirements in the EN that stand on their own without reference to further resources, the WCAG success criteria are supported by explanatory documents.
The most important of these are the “Understanding” documents. There is one document for each success criterion, as well as others that explain other aspects of WCAG. The link to the document for each success criterion is in a box to the side, immediately before the text of the success criterion in the document flow. They can also be found directly from the full list of Understanding documents.
Understanding documents provide interpretive guidance to expand on the wording of the success criterion. While in some cases this is mainly clarification, in others the guidance points out important considerations and edge cases. Therefore it is important to review the full “Understanding” document for each success criterion when working on conformance.
At the bottom of the Understanding documents are lists of “techniques” to meet the success criteria. Many of the techniques apply to specific technologies, and you choose the ones for the technology you are working with. There are also many “general” techniques, which contain technology-neutral implementation approaches, some of which will still be implemented in a technology. The set also includes “failure” techniques, which are examples of common practices that need to be avoided to meet the success criteria; these apply to various technologies.
Note: the techniques are technical resources aimed primarily at developers, although many of the general techniques also address designers. They do not, however, address all situations. Also, many of the techniques are now implemented “under the hood” by content development frameworks. Although developers may therefore satisfy the success criteria in different ways, familiarity with these techniques will help them to understand how to use the framework properly.
In addition to referencing all the WCAG 2.1 AA success criteria, EN 301 549 also requires that web pages satisfy separate “conformance requirements” defined in WCAG. These include a requirement that an entire web page meets the requirements, all pages in a multi-page process meet the requirements, and any closed functionality not interfere with the accessibility of the content surrounding it. In most cases, following the success criteria will meet these conformance requirements, but it is important to check.
Note: In order to conform to EN 301 549 for web content, it is necessary for users of the standard to use these resources as well. The above is not a comprehensive explanation of how WCAG works, and it is important for people new to using WCAG to understand it more. The Introduction and Conformance sections of the specification, along with their related Understanding, provide a more thorough introduction. When you are familiar with these resources and are working with specific success criteria, the WCAG 2.1 Quick Reference provides a more compact view of the essential resources.
Requirements that reference WCAG2ICT
The Web Content Accessibility Guidelines were written to apply specifically to web content. As the industry looked for similar guidance for electronic documents and software, starting with WCAG provided a mature base. An interpretive document, Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT), examines each of the WCAG level A and AA success criteria and offers advice about how that guidance could be applied to documents and software.
Note: The current version of EN 301 549 was based on a 2013 version of WCAG2ICT, which provided interpretation for WCAG 2.0. WCAG2ICT was updated in 2024 to address new and changed success criteria in WCAG 2.1 and 2.2. This new version online has replaced the 2013 version. Because of this, there may be some variance between wording in the standard and wording in WCAG2ICT. The updated version, however, provides guidance related to WCAG 2.1 and 2.2, so it is useful to use this version.
EN 301 549 refers to WCAG2ICT for most of the guidance in:
- Section 10 Non-web documents, such as office documents and offline PDF
- Section 11 Software that runs on a consumer ICT device
Note: Unlike the web section above, which only contains requirements from WCAG, sections 10 and 11 both reference WCAG2ICT, and provide additional requirements that are not in WCAG2ICT. When using WCAG2ICT for software or documents, make sure not to overlook sections 10.5 - 10.6 and sections 11.5 - 11.8.
WCAG2ICT begins by defining some terms that it uses in addition to or in place of some terms used in WCAG. It also redefines some terms used in WCAG, to give them a more contextual meaning for documents and software.
The main body of the guidance examines each A and AA success criterion in WCAG. For each success criterion, WCAG2ICT:
- Copies the full text of the success criterion from WCAG, along with notes that accompany them in WCAG;
- Under a sub-heading entitled “Applying … to Non-Web Documents and Software”, it describes whether and how the success criterion should be reworded to apply to documents and software;
- If there are wording changes to the success criterion or clarification notes from WCAG, a new copy of the success criterion text is included, with the wording changes in change-tracking markup;
- If additional clarification is needed beyond wording changes, the Working Group added additional notes that are specific to WCAG2ICT.
Generally, WCAG2ICT provides the following kinds of interpretations:
- No change - the WCAG success criterion can be directly understood in the context of documents and software;
- Word substitutions - terms that apply to web content are replaced with corresponding terms for documents and software;
- Not applicable - the Accessibility Guidelines Working Group believes the WCAG requirement does not have meaning outside of the web.
The structure of WCAG2ICT expresses its advice in a clearly documented authoritative manner – but it requires picking out the updated requirements from the interpretive guidance. The EN 301 549 adapts the WCAG2ICT guidance, rewording them to use the standard’s “shall” convention. It includes notes critical to understanding, some from WCAG2ICT and some added by the writers of EN 301 549.
These changes make the wording in EN 301 549 generally more understandable than the corresponding WCAG2ICT guidance. The standard states that its requirements for documents and software are intended to harmonize with WCAG2ICT, so in principle it is not necessary to use WCAG2ICT. The more complete interpretive guidance in WCAG2ICT, however, means it is an important resource once you have familiarity with the structure.
Some requirements from WCAG2ICT presume the use of non-closed functionality. To address closed functionality, the standard provides two alternate versions of many of the requirements. One version adapts the WCAG2ICT guidance, and the other one provides additional requirements for closed functionality. Some of these also refer to corresponding requirements in section 5.1 addressing general closed functionality.
Note: The requirements in EN 301 549 for closed functionality collectively require such devices to provide the same accessibility affordances as “open technology” that can be used with AT. It is generally far less effort to implement software as open functionality and leverage the features of other tools, than to reinvent all of these solutions in a single product. Unless there is a compelling reason for it, we recommend avoiding the closed functionality path to conformance.
Requirements by access type
Important: This section provides a collated summary of the requirements set out by EN 301 549. This summary is not in normative language and is not comprehensive enough to be used on its own to meet the standard. The intent of this section is to help various stakeholders understand at a high level what conformance looks like. As you work on your own conformance, you will need to work directly with the standard, using the guidance above.
The standard is organised primarily by ICT type, but many people will find the standard easier to understand when organised by type of accessibility feature. For this analysis, we provide the following set:
- Perceivable - content is presented in a format the user can perceive
- Visual - aspects of the visual design that support perception by people with reduced vision
- Auditory - aspects of speech and other sounds to support perception by people with reduced hearing
- Speech - specific requirements for speech comprehension
- Tactile - requirements for parts of the user interface that users touch
- Operable
- Mobility and reach - operable by users with reduced reach
- Strength and dexterity - operable by users with reduced strength and dexterity
- Physical input - other aspects of accessible device operation
- Voice input - operable by users with non-standard speech
- Biometrics - product does not require specific biometric measurements
- Understandable
- Understandability - aspects of design and structure that support comprehension and avoid confusion
- Usable - ensure users of accessibility features have equivalent facility in using content
- Robust
- User control - provide ways for users to customise their experience of the ICT
- Safety and privacy - ensure ICT does not endanger users and that accessibility features do not compromise user privacy
- Fidelity and quality - specific requirements on content encoding to ensure it is rendered well enough for users to understand
- Assistive technology compatibility - specific requirements on how ICT should support external assistive technology
- Alternatives - ways to provide alternate content when it cannot be made directly accessible to some users
This uses the “Perceivable”, “Operable”, “Understandable”, “Robust” (POUR) model as a first level of organisation, with aspects of those categories addressed at the next level, which are adapted from the functional performance criteria in the EAA. “Alternatives” are a separate top-level category because they are a separate kind of accessibility accommodation rather than an aspect of accessible content itself.
Note: The table referenced from Appendix: mapping table contains a full set of the requirements by section number, organised into the type of technology and type of accessibility feature they address.
Perceivable
While alternate forms of content and input are important to provide accessibility to people who cannot use content that exists solely in a certain perceptual domain, or that requires certain abilities to operate. Doing so alone, however, is not sufficient to make ICT content and tools accessible. Many people access content with sight, hearing, or touch, but need support in order to fully perceive it. To support these needs, the standard describes characteristics that content and tools must incorporate to support a variety of users. While some of these requirements may affect design, most of them address ways for users to adjust the content to their needs.
Note: As described above, non-text content must provide alternate formats to allow users who cannot perceive it, to understand it. Even though these alternate forms are provided, the non-text content is also a part of the visual interface, and also needs to support the characteristics below. Accessible alternatives also need to support these requirements. For example, subtitles in video must be visually perceivable, and audio descriptions must not experience interference from other audio in the video.
Visual characteristics
For most ICT content, visual accessibility begins with text. The perceivability of text as displayed visually on a screen relates to aspects like font size and style, contrast with background, amount of space between elements, etc., and the standard addresses base requirements as well as adjustment.
Beginning with font size, many people who read effectively struggle to perceive the details in small text well enough to decode the words. The standard requires that text can be enlarged to at least twice its original size, without losing content due to clipping etc. This addresses the needs of many users who do not routinely use magnification tools, while generally not significantly affecting layout.
The standard also says that for text enlarged up to 400 percent of its original size, the layout must adapt as necessary to achieve an understandable flow without clipping or overlap. Scroll bars may be used, but only a vertical (preferred) or horizontal one, not both, unless the content is intrinsically larger such as a big table.
Some users need text enlarged beyond this level. The standard assumes that these people use screen magnification technology, which enlarges content without changing layout by creating an enlarged virtual display that the user can explore. Not all people with visual impairments of this degree use this kind of technology, or in all situations. Therefore, it is recommended that content support text enlargement above 400% when feasible.
The section on closed functionality addresses magnification requirements differently. If a device or content cannot work with external assistive technology to provide magnification features, then the device or content must provide built-in text enlargement capability. Instead of requiring support for a zoom range, this section specifies that it must be possible to enlarge text up to a certain portion of the field of view. This is defined in terms of the height of a capital letter H in the chosen font, where the standard requires that it be possible to enlarge that to occupy at least 0.7 degrees of the visual field, taking into account distance between viewer and display. The standard provides a formula that describes the mathematical relationships.
A full explanation of this particular requirement is beyond the scope of this explainer. A version of the formula that is reworked to solve for font size is:
- fontSize is the size in points for the typeface to render the intended size;
- viewAngle is the intended viewing angle in degrees, using 0.7 for a conformance evaluation;
- viewingDistance is the distance between the device and viewer in millimetres (mm);
- capHeightRatio is the proportion of the height of the capital letter H to the entire font glyph height, with a range of 0 to 1.
Note: An explanation of the derivation of this formula, and a tool to inspect fonts and perform the calculation, expand on this detail.
The table below is a modified version of the table provided in the standard, and shows the results of this calculation for common viewing distances.
Device |
Viewing distance |
Font size |
---|---|---|
Watch |
20 cm |
10 pt |
Mobile phone |
40 cm |
20 pt |
Desktop computer |
70 cm |
35 pt |
Self-service terminal |
1 m |
50 pt |
Small television |
1.3 m |
65 pt |
Wall television |
3.5 m |
175 pt |
Contrast of colours between the foreground and background is an important accessibility issue, and requirements apply to text and to user interface elements that the user must see. For text, the luminosity contrast between the text glyphs, and the background upon which they are painted, must be at least 4.5 to 1 according to a formula provided by WCAG. For text that is already large, user interface elements, and important graphical objects, the requirement is 3 to 1 according to the same formula.
The amount and placement of space in body text impacts readability. Increasing space between lines and paragraphs helps with tracking and differentiation. Increasing space between letters and words supports letter and word recognition. The standard requires that layout is not disrupted by modest adjustments to the space between letters, words, lines, and paragraphs.
Keyboard users need to be able to determine visually where the keyboard focus is at any moment. Designers sometimes hide the focus indicator, and this is allowed, but they must provide a way for users to activate the visual display of the focus indicator. The standard does not specify in detail how the focus indicator must be visible, but suggests that the standard keyboard cursor is generally sufficient. Other approaches, such as highlighting text selected for replacement, also meet this. When designing such approaches, ensure that the focus indicator itself meets visual accessibility requirements for size, contrast, etc.
For documents, the standard includes a requirement that, for synchronised media with subtitles, the subtitles do not obscure the main content. Generally, subtitles are positioned at the bottom of the screen and take up no more than three lines of text, and in many cases this requirement is sufficient. To support readability of subtitles, a semi-transparent background provides contrast with subtitle text while allowing action underneath to show through. In some cases, it is appropriate to position subtitles on another part of the screen to avoid obscuring content, but this can confuse some users and should be done in accordance with Deaf community recommendations.
For two-way video with subtitles, the standard requires that the user can adjust display characteristics of the subtitles to increase visibility. This may include text colour, box colour, opacity, size, typeface, etc. As subtitles are part of the visual interface, they should be scalable as described above. Ensure that changes to subtitle display do not result in them obscuring content. It may be appropriate to offer users a few known values rather than an indefinite range that could create unexpected display issues.
Note: the requirement for subtitle position applies specifically to documents including multimedia, and the requirements for subtitle characteristic adjustment and video quality apply specifically to two-way videos. We recommend following this guidance for video content in other types of ICT, such as web and software. It is also important for hardware to make it possible for applications and documents to meet these requirements.
Two-way video also includes a requirement to provide a visual indicator of audio activity, so non-hearing users can know that someone is speaking. This can be a simple indicator, or incorporate with other features.
Auditory characteristics
A few specific requirements support understanding of speech with limited hearing. First, hardware must support volume control over a range of at least 18 decibels (dBA). If the volume control uses discrete increments between minimum and maximum volumes, one of the steps must be for a gain of 12 dBA over the minimum.
When content provides audio descriptions, the producer is adding an audio track to existing audio. The description must not overlap with other important audio in the scene, or the result could be unintelligible. Typically, audio descriptions are timed and inserted into gaps in the dialogue and important sounds. If there is not enough time in the audio for sufficient description, extended audio descriptions include auto-pausing of the main video and audio while a description is being read.
Note: This requirement technically applies to non-web documents, but not to web documents. This is because the corresponding requirements in WCAG are AAA, which were not mapped into the EN 301 549 web requirements, but the requirement was added for non-web documents. We recommend that web content also follow this requirement.
Audiovisual content that provides subtitles for accessibility should allow the subtitles to be spoken on the user’s device. This can be in the form of a secondary audio track that is synchronised with the subtitles, or by providing subtitles in a text format that can be converted to speech on the user’s device. Users may mix the secondary audio with the main audio in a way that helps them to understand the subtitles and the main scene.
For closed functionality, the standard requires that visual information be available in audio or tactile form, using built-in speakers or standard headset connectors. Users should be able to control volume in all configurations, and reset to a 65 dBA or less. It must also avoid playing automatically for longer than 3 seconds any secondary audio that would interfere with audio output used for accessibility.
Speech output characteristics
Speech output requirements are only defined for closed functionality. Speech should be by default in the same language as the visual language, synchronised with the visual display, and provide user control over playback. While speech output is in use, the device should not play other audio unless it is less than 3 seconds, to reduce interference with the speech output. Speech output needs to include identification of any errors. When the user moves to new content while the computer is still voicing previous content, new content should normally interrupt the old content. Audio output also should not compromise the user’s privacy, outputting personal information only to private listening devices, and auditorily masking content that is visually masked, such as password entry forms.
Tactile characteristics
Hardware that provides numeric keypads must arrange them in the standard telephone order, with the number 5 in the centre and distinguishable by tactile means (such as a raised dot). The tool must have a mode in which the user can operate controls without using grasping, pinching, or twisting motions.
Shared-use devices, such as ticketing and information terminals, that can output speech should provide a tactile means for users to activate the speech mode. Keys, tickets, and fare cards that must be presented in a specific orientation must provide a tactile means for people to determine the correct orientation.
Closed functionality must ensure that operable parts can be discerned from each other by non-visual means, with tactile being the presumed approach. The standard does not describe how this may be done, but includes size, shape, position, tactile labels, etc. Controls with a toggle function that can be locked into a specific state (like a CAPS lock button) must provide a means to determine the state of the control through touch or sound without activating it.
Operable
In addition to perceiving content, users need to be able to operate products. Requirements in this section address the ways users physically interact with the device or content.
Mobility and reach characteristics
Mobility and reach relate to the physical environment in which ICT is used. Stationary ICT, such as information and ticketing terminals, must have an accessible approach in order for a person to use the technology. The standard allows either an accessible forward approach or an accessible side approach, with specific dimensions defining each. It also requires that the device be mounted so there is knee and toe clearance for users in wheelchairs. The operable part of the ICT must be within a specific forward or side reach range, which also takes into account size of allowable “obstructions” like desks or service counters.
Note: the standard is very prescriptive about the position of stationary ICT, and these prescriptions are designed for wheelchair users. In cases where there are multiple stationary terminals in a location, such as ticket machine banks, it may not be necessary or appropriate to follow this standard for every machine. The EAA explanation of “disproportionate burden” uses this example to point out that most of the machines do not need to conform as long as there are sufficient terminals in the area that do meet the standard.
Strength and dexterity characteristics
For hardware, there must be modes of operation that require a force of less than 22.2 newtons (N) to operate controls, with 2.5 to 5 N being the recommended range. This increases the chance that a user with limited manual strength or dexterity can operate the control.
Physical input characteristics
The standard includes a few generic requirements to facilitate operation of keyboards. For key presses, it should be possible for the user to configure a delay before another key press is accepted, to mitigate incidental key presses. The delay must be configurable to at least a half second. If the device supports key repeat, in which holding the key down triggers ongoing character entry, then it must be possible to configure the time before the repeat behaviour starts, as well as the time between repeats. The standard requires for both those parameters that they be adjustable up to two seconds.
Web, documents, and software have requirements about the use of pointers, such as mouse or touchscreen. Path-based gestures are the result of a pointer movement, and multipoint gestures include multiple contact points such as pinch-zooming. When ICT provides features that are activated with path-based or multipoint gestures, it must also provide ways to activate those features in a simpler pointer action, such as taps and clicks, double-taps and double-clicks, long presses. Providing icons or a menu to activate the feature is a way to meet this. It is not sufficient to provide other alternatives such as keyboard commands. This is because, when pointer operation is supported, it is a better mode for some users.
Note: The standard makes an exception for “essential” pointer actions, such as where the purpose of the gesture is to draw a path in a drawing application.
Pointer usage often involves activation of features from click or tap. Users with reduced motor control may activate click or tap accidentally, triggering unintended responses from the system. The system must provide ways for users to abort or undo unintended actuation of controls that change the state of the application.
Status of the standard
It can help users to provide keyboard-activated commands. Keyboard shortcuts that use only letters create problems for voice input users who may accidentally invoke commands when they pronounce letters. If those shortcuts are used, there must be options for users to turn off or remap them, or the shortcut must be active only when its relevant component already has keyboard focus.
Biometrics
Biometric input relies on detection of physical attributes of a user. Fingerprint scanners, face or voiceprint recognition, iris and retinal scanners, etc. use these characteristics to identify a user. Not all users are able to provide the requested biometric. For instance, a person without fingers cannot provide a fingerprint, or a person who does not speak cannot provide a voiceprint. Additionally, features such as voiceprint and facial recognition depend on algorithms trained on datasets about humans that often focus on selected groups that fail to include the full variation of human characteristics. This can make these biometrics unreliable for and exclusive of people with disabilities.
To address this, the standard requires alternate means of identification when a biometric form is provided. The alternate means is allowed to be a different biometric, but it is recommended to provide secure non-biometric means of identification as well.
Note: The standard does not prohibit biometrics, nor comment on specific types of biometrics. Products may use biometrics, but developers should take care to use the most minimally intrusive biometrics possible. There is concern that biometric information can be used to identify a person’s disability status and result in differential treatment, and some people experience distress from the process of providing a given biometric. Specific biometrics used, or a user’s choice to use alternate forms of identification, should not be used to profile the user in any way.
Understandable
Some accessibility requirements relate, not to the ability of the user to interact with it, but the usability to make sense of it as presented. Understandability is supported by consistent design, clear identification of components, and contextual support. People who use assistive technology and other accessibility supports in the content experience the content in a different manner from the visually apparent design. Therefore some supports are needed to make content equally understandable in an accessibility context.
Understandability
Documentation is important for users to know how to use a product and its accessibility features. Documentation for products and services must list and explain how to use the accessibility features. Documentation must also be available as an accessible web page or electronic document, in addition to included print documentation and other formats. Support services must also provide effective communication for people with disabilities, as direct features or through the use of relay services.
Consistency and predictability are important to use of web sites and multipage documents and software. Users rely on consistent layout and labeling and intuitive interaction for their particular mode. Web sites should provide consistent navigation across the site, and consistent identification of web pages. Web, documents, and software also need to provide labels or instructions on content that requires user input, and ensure that headings and labels are descriptive of their topic or purpose.
A key part of making content accessible is by making it available to assistive technology. The Assistive Technology section describes various content structures with meaningful semantic encoding. Some of these relate directly to understandability as well. Web pages and documents should have meaningful titles, and links in content should have a clear indication of its purpose. There must also be a meaningful sequence for content elements if presentation order affects its meaning.
Note: Examples of meaningful sequence in WCAG focus on the overall layout of the page, such as headings, navigation, main content, sidebars, layout choices that impact the sequence found by AT, etc. Layouts of forms and other user interaction components also need to have a meaningful sequence for controls, labels, instructions, error information, etc.
Some users access content using different senses than its original form. For instance, a screen reader user accesses a voiced representation of visual content. Interactive controls should be well labeled for their purpose, but are sometimes referred to using descriptions of shape, colour, position, etc. When using these descriptions, it is important also to use control labels in addition to visual characteristics in the reference.
One common form of confusion for users is when the system rejects input due to an error. Error messages that are visually apparent can be hard to find with assistive technology, and their context may not be clear. Users also need clear information about what caused the error. Therefore, the standard requires that error notification features include a text description of the error, along with clear suggestions for how to fix it.
Note: The standard does not require that error information be positioned in a particular manner relative to the control in which the error happened. It is helpful to design forms so that users can locate errors across the form, and find the specific error message from the relevant control.
In real time communication, speaker identification is a common and important feature for users to follow the conversation. Real time communication tools that provide identification of voice speakers and have text channels should provide speaker identification for text channels as well. In addition to identifying voice users, the speaker identification feature needs to recognize sign language speakers. This can be done with a manual control or a video recognition feature.
Usable
Beyond the above requirements that support understandability, the standard includes a functional requirement related to both understandability and usability, to provide features to support “users with limited cognition, language or learning”. It provides a few examples but does not provide formal requirements in support of this functional requirement. However, considering understandability to these users can have a large practical gain in accessibility to various audiences. We recommend exploring the document Making Content Usable for People with Cognitive and Learning Disabilities. Although the guidance in that document is not a formal part of the EN requirements, incorporating its guidance as much as feasible will help make your content more understandable to a large proportion of users.
Some aspects of web design convey meaning through presentation, such as size, colour, placement, etc. In order to use content, this meaning needs to be available to users of assistive technologies. This is best done using code semantics but can also be described in text.
Repeated content on web pages can be difficult for users who access content in a linear manner, where the actual content can be buried. The standard requires that there be a way for users to skip repeated content. This can be done using HTML semantics to organize content so assistive technologies can help identify repeated content to skip, and can also be done with explicit in-page links.
In web sites, a given web page can be difficult to find again. The standard requires that there is more than one way to locate a given web page. This can include providing (skippable) navigation menus on all pages, providing a search mechanism, even a site map. This helps users find content in the way that works best for them. Some web pages are part of a multi-step process (such as a form submission). The requirement does not apply to pages in the process, but it does apply to the starting point of the process.
Another usability problem can be unexpected actions as a user explores the page. Some users move among focusable controls, which include links, form buttons, and many custom components. When a control receives focus, or when the user interacts with the control, the control must not automatically cause a change of context that disrupts the user’s interaction. This is because opening a new web page or new application window unexpectedly can cause the user to lose their place on the content they were working with. It is allowed for content on the page to update if it does not disrupt the focus. A change of context is allowed if the users have been informed in advance that it will happen, such as when activating the submit button of a form or following a link to a non-web document.
A related challenge is content that appears when the user hovers the pointer or focuses the keyboard on a control, commonly known as “popups”. This can obscure other content, so it must be possible for the user to dismiss the popup. When the user wants to read the content of the popup, however, it must be possible to move the pointer or focus into the popup without the popup disappearing.
Movement on the screen can be distracting, and for some users it is so distracting that they are unable to focus on other content. Movement triggered by user action, such as playing a video, is an expected part of the interface. If the video auto-plays, though, the user must be able to stop it, unless it self-stops within 5 seconds. The same applies to other forms of motion, such as animated backgrounds, attention-grabbing widgets, etc. These are allowed but must play for no more than 5 seconds, or the user must be able to stop them. Although the standard does not require this, it is better to provide a single feature to stop all motion, rather than requiring users to stop each object with motion one by one. We also recommend providing a feature to prevent autoplay of any motion, allowing users to activate them as desired.
Note: The EAA clarifies that content provided by third parties must not compromise the accessibility of the primary content. In the case of motion, movement on a part of the page can disrupt a user’s ability to access the entire page. Therefore all third party content must conform to this requirement, including features like advertisements, for the content as a whole to conform.
The same requirement that addresses movement also addresses content that auto-updates, such as chat feeds, progress bars, stock tickers, etc. Distraction is also a concern here, but auto-updating content also brings issues of interruption and stability.
Robust
“Robust” is a concept that originally related to the code quality of content, enabling it to be processed by a variety of tools. For this explainer, the term is expanded to include aspects of the product or service that affect the accessible experience beyond the user interface. Providing for user control, safety, privacy, fidelity and quality of content ensures that users of accessibility features have an equivalent user experience.
User control
Users are better able to interact with ICT when they can control aspects of the experience. Most basically, users must be able to activate accessibility features. For closed functionality, this must be possible without any accessibility features already having been activated. Platforms that run software, such as operating systems, must allow users to use accessibility features, such as system-wide font and colour settings. Software must by default respect these settings for units of measurement, colour, contrast, font type, font size, and focus cursor.
When not enabled by default, users must be able to activate subtitles and audio descriptions – via a process that is not more difficult than other controls. Users must be able to adjust the display characteristics of subtitles to increase readability, such as with text and background colour, size, borders, etc.
Closed functionality providing speech output must provide a means for users to interrupt speech and request a repeat. It must also allow users to control the volume of private listening devices and speakers. The volume control on shared devices should be easily reset to below 65 dBA. Hardware supporting audio output must provide a means to adjust volume over a range of at least 18 dBA. If it uses non-continuous volume settings, one of the steps must be at 12 dBA above the minimum volume. The EAA also suggests providing enhanced audio features to reduce signal and background noise to increase clarity.
Many of the success criteria in WCAG also address user control. Web content, documents, and software must allow view in either landscape or portrait orientation. Time-dependent features must allow users to turn off, adjust, or extend time limits. Users must also be able to limit or prevent automatically playing visual or audio content. The ability to resize text, covered above as a visual characteristic, is also an important user control feature.
Keyboard shortcuts help some users, but may be difficult for users with limited manual dexterity to activate correctly. If those shortcuts are used, there must be options for users to turn off or remap them, or the shortcut must be active only when its relevant component already has keyboard focus.
Safety and privacy
Photosensitive seizures are a well known safety risk for some users. Specific requirements from WCAG apply to web content, documents, and software. Content that flashes more than 3 times in one second is a potential trigger, although the specific colours, degree of brightness change, and the amount of visual field occupied by flashing content must all be considered.
Note: The general functional requirement for all content is to “minimize” triggers; however, the WCAG requirement is that they be “avoided”. This means that for web content, documents, and software, providing advance warning of flashing content is not sufficient. We recommend applying the WCAG guidance and avoid triggers altogether in other product types as well, in particular services providing two-way video communication and audiovisual broadcast.
Another safety risk for users is when errors in input create unwanted and irreversible consequences, such as executing financial transactions, making legal commitments, submitting test responses, or modifying user data. For forms that submit this kind of information, there must be a mechanism to reverse an accidental transaction, or for the user to be given an opportunity to review detected input errors, or to check the entire submission before confirming.
It is important that using accessibility features does not compromise a user’s privacy. The standard provides a general requirement for all technologies to ensure users of accessibility features have the same level of privacy as other users. A common example risk is a masked entry field, often used for passwords, which visually hides the characters the user types. A screen reader might echoe the characters aloud as they are typed, which is a normal behaviour but should be disabled for masked entry fields unless the user is known to be using a private listening device (e.g., headphones). Any other kind of private user data in the content must also be delivered by audio only on private listening devices.
Note: Privacy requirements are defined in the standard as a general requirement and a couple requirements specific to closed functionality which elaborate on the general requirement. Technologies used for telecommunication, web content, documents, and software commonly have these privacy protections built in by default. There are, however, many ways still to create privacy problems unintentionally. We recommend reviewing all kinds of technologies for these privacy considerations.
Fidelity and quality
Many requirements in the standard address not new accessibility affordances, but ensuring that features are implemented with sufficient quality to be useful to users. It is also important that accessibility information not be lost during the content preparation process.
There is a general requirement to preserve accessibility information during conversion of formats and during transmission. Two-way video services must preserve subtitles and audio descriptions that are available in the source. The EAA further specifies for audiovisual broadcast that they preserve “subtitles for the deaf and hard of hearing, audio description, spoken subtitles and sign language interpretation are fully transmitted with adequate quality for accurate display, and synchronised with sound and video”. Software also must preserve accessibility information, ensure that software features do not disrupt accessibility features, and follow user preferences for display characteristics.
Many users navigate content using the keyboard, in particular by tabbing among links and controls. Both closed functionality and web content have requirements to not trap the keyboard by preventing the user from tabbing to other controls. Users also need controls to be identified clearly, so a requirement for web pages is that a control’s visible label and name in the accessibility API match.
Real time communication services must be interoperable with other RTT services by following certain specifications referenced by the standard. This includes a requirement to transmit content to the network within 500 milliseconds (ms) of being entered by the user. Services that provide speaker identification for voice users must provide speaker identification for RTT users as well.
Proper synchronisation of audiovisual content is also important to understanding. Requirements address synchronisation between audio and video track, subtitles with audio, and audio descriptions with audio and video. For closed functionality, this also applies to correlation between auditory output and content displayed on screen.
Quality of video is important to visual perceivability. Low resolution videos are harder to identify objects, and low frame rate can interfere with recognition. The standard specifies that video should support at least 240 px by 320 pixels (px), preferably at least 640 px by 480 px (QVGA and VGA resolution, respectively). It also requires that frame rate be at least 20 frames per second (fps), preferably at least 30 fps. Most modern video formats and tools meet or exceed these standards, but it is important to verify. For audio quality, two-way voice services must ensure the audio has a bandwidth of at least 7,000 hertz (Hz) in order to capture speech with sufficient fidelity.
Authoring tools are a category of software that produce content, which needs to meet EN 301 549 requirements. The standard requires that these tools guide the user in the creation of accessible content, and provide repair assistance if it can detect accessibility problems in the content. Tools that provide content templates must include accessible templates among the offerings.
Note: Authoring Tool Accessibility Guidelines (ATAG) 2.0 provides additional guidance for the creation of accessible content. While only some of that guidance is required for EN 301 549 conformance, we recommend following the full guidance in ATAG.
Two-way communication services that support connection to relay or emergency services must ensure that incoming and outgoing connections to those services are supported for voice, real time text, and video.
AT compatibility
When relying on assistive technology to support accessibility, the AT must have the necessary access. Many requirements in the standard address how to do this for various situations. Beginning with hardware, they must support standard connections to external devices, such as Universal Serial Bus (USB) for physical connections or Bluetooth for wireless connections. This allows a range of different types of assistive technology to connect to the device. Closed functionality must also provide standard couplings for audio devices, unless it provides its own audio output.
Telephone-type devices where the user holds the audio output to the ear must support magnetic coupling to hearing assistance technologies. Caller ID information should be available to assistive technology. Real time text should ensure that outgoing and incoming text can be differentiated programmatically.
Many of the requirements for web, documents, and software also relate to making information accessible to AT. The requirement for “Info and relationships” has broad impacts as it requires that “information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text”. This includes general structure of the content, the nature of different sections of the content, ensuring that labels for controls are coded to be available to AT, a categorisation of input types, the availability of status messages, etc. The name, role, and current value of controls also need to be available. It also requires that a meaningful linear reading sequence can be determined for the content. Encoding the human language of text is important to enable AT to use the correct vocabulary. All functionality of the content should be operable via a physical or virtual keyboard. When possible, visually styled text content should be encoded as text rather than as an image.
Note: for web content, the full relationship between HTML features and accessibility APIs is detailed in the draft document HTML Accessibility API Mappings 1.0. This is a good introduction to accessibility APIs for developers familiar with HTML. Accessible Rich Internet Applications (WAI-ARIA) provides ways to refine the way content is exposed to AAPIs, but this should be done in accordance with the requirements in ARIA in HTML. The ARIA Authoring Practices Guide provides additional recommendations for how, and when not, to use ARIA.
Note: At the time this version of the EN 301 549 standard was published, WCAG 2.1 included a requirement to use well-formed HTML in web pages, to ensure that AT could properly process the content. WCAG 2.1 has since been updated to remove this requirement, as AT now accesses content directly from the browser. We recommend paying attention to code quality, but this formal requirement is likely to be removed in the next version of the standard.
Section 11.5 Interoperability with assistive technology details requirements for software. Platforms for running software should provide accessibility functionality, and features for AT to interact with it. Commonly this is achieved via an Accessibility API (AAPI). Software running on a platform, in turn, should use those AAPIs. The remainder of the requirements in this section address specific features that should be available in AAPIs. Beyond those features, it is best to be familiar with the features of the accessibility API on the specific platform. Some AAPIs:
- Microsoft UI Automation on Windows
- OS X Accessibility Protocol on Mac
- IAccessible2 on Linux
- AccessibilityService on Android
- Accessibility API on IOS
Note: The EAA also requires that text documentation can be converted to other formats, which suggests that it should be able to be scanned and converted to text by optical character recognition (OCR).
Alternatives
Some types of content and interactions do not currently have ways to make them directly accessible to people with certain disabilities. It is therefore important to include alternative accessible forms, and most ICT technologies provide ways to do that. The standard requires alternatives for visual, auditory, speech, and tactile output, as well as voice and physical input, and biometrics.
Note: Alternatives are used when necessary in addition to direct accessibility features covered above. While proper use of alternatives is important for accessibility, it is not itself an alternative to providing more direct accessibility when possible.
Status of the standard
Content designed to be understood visually must have alternate content that conveys the same information. This includes information conveyed by non-text content such as images, embeds with closed functionality, audio, and video.
Static content such as images often suffice with a simple text alternative, colloquially known as “alt text”. The text briefly describes the role or information conveyed by the content, in a way that will be understood in context of its surrounding content.
If a short text alternative is not sufficient for this, an additional extended description can be provided. Extended descriptions vary based on the type of content and its context. For an image of an artwork, it may describe the characteristics of the art that lead to an interpretation. A photograph of a building may need relevant architectural or design characteristics to be pointed out. A chart may include a summary of the concept conveyed by the chart, and / or the tabular data from which it was generated.
Dynamic content such as videos require alternative content that conveys information from the video over time. Prerecorded video must provide an alternative in the form of either a text description or an audio track, with timing information. Text alternatives can be presented separately from the video but still require accurate timing information. An audio alternative should also include timing information, and is best presented in the form of a synchronised audio track that can be accessed as the video plays. In some cases, “extended audio descriptions” are recommended, in which pauses are introduced in the video playback in order to leave time for more audio information.
Note: Short videos and animations may not require timed descriptions for understanding. These objects may be better treated as general non-text content for which a short or extended description is sufficient.
While the standard does not state this explicitly, all non-text content should have a short text alternative, in addition to any other alternative formats required. The short text alternative labels the object and helps users determine if they want to access the extended alternatives.
Beyond alternatives for non-text content, the standard also requires alternatives to the use of colour to convey information. For example, if links or definitions are differentiated in body text solely by a colour change, some users may have difficulty finding them. Instructions such as “click the red button” also rely on a perception of colour to be able to follow the instruction. Text should be differentiated by additional visual aspects such as font style or adding an underline, and sometimes it is helpful to add a tooltip. Other visual objects should have design aspects that differentiate them in other ways than colour, such as shape or placement. Instructions relating to them should refer to multiple ways of identifying the object.
Voicemail or auto-attendant services of two-way voice communications ICT must be usable without vision. The standard recommends that services combine audio, real time text, and video communication features as a way to meet this requirement.
Self service terminals requiring a timed response must alert the user of the timing in multiple sensory channels. We recommend auditory alerts in addition to visual alerts, and tactile alerts where supported.
Auditory alternatives
Audio alternative requirements for web, documents, and software apply to pre-recorded audio, the same as for pre-recorded video above. Audio should have text alternatives with timing information. In the case of speech, the text is a transcript of the audio. For other types of audio, the text alternative should include descriptions of aspects of the audio relevant to understanding.
When included as part of multimedia content, audio alternatives must be provided in the form of subtitles synchronised to the video. These subtitles describe speech and sound action, just as audio descriptions describe visual action.
Voicemail or auto-attendant services of two-way voice communications ICT must be usable without hearing. The standard recommends that services combine audio, real time text, and video communication features as a way to meet this requirement.
As for video, self service terminals requiring a timed response must alert the user of the timing in multiple sensory channels. We recommend visual alerts in addition to auditory alerts, and tactile alerts where supported.
Multimedia content that combines video and audio must provide alternate content for both the video and audio. Audio alternatives must include synchronised subtitles. Video may use text alternatives, but synchronised audio descriptions are recommended. For videos with visual content important to understanding, extended audio descriptions may be needed.
Tactile alternatives
The EAA specifies that [hardware] products must provide alternatives to vision, auditory, speech and tactile elements. The EN standard doesn’t directly address this, as physical aspects of hardware design are meant to be addressed by other standards.
In the context of information and communications technology, this requirement applies to tactile aspects of the interface, such as input control and tactile output. Alternatives to tactile input include pointer input or voice input. Alternative to tactile output include visual or audio signals, and text content.
As for video and audio, self service terminals requiring a timed response must alert the user of the timing in multiple sensory channels. We recommend auditory and visual alerts, in addition to tactile alerts.
Voice input alternatives
Voicemail or auto-attendant services of two-way voice communications ICT must be usable without voice. The standard recommends that services combine audio, real time text, and video communication features as a way to meet this requirement.
Relay services must provide alternatives to voice input, which are intrinsic to their function. For alternatives to voice input, the relay service may support text, sign, or lip-reading.
Note: Except for relay and emergency services, the EAA and the EN standard do not specifically require that alternatives be provided for other two-way voice communication products and services. However, two-way voice communication is not usable for some users, so it is highly recommended that these products and services support real time text and video channels for the communications service when feasible.
Speech output alternatives
Voicemail or auto-attendant services of two-way voice communications ICT must be usable without speech. The standard recommends that services combine audio, real time text, and video communication features as a way to meet this requirement.
Relay services supporting speech-to-speech relay should enable users who are “speech impaired, have limited cognitive, language and learning abilities, as well as any other user, to communicate by providing assistance between them”.
Physical input alternatives
To accommodate users with limited reach or dexterity, a hardware control that “requires grasping, pinching, or twisting of the wrist” must have an alternative form of input. The standard does not specify what kinds of alternatives to provide. An alternate hardware control that does not require reach or dexterity may fulfil this requirement; supporting keyboard or pointer input are examples of this. Voice input is also recommended where feasible.
Input that can be triggered by motion of the device or user must also have alternate forms of input. For instance, on a mobile device a shake might trigger an undo command, in which case another way to activate that command must also be provided. Features activated by user motion monitored by a camera or other sensors, such as raising a hand to join a speaker queue, also need alternate ways to activate the feature. The standard exempts cases in which motion tracking is intrinsic to the functionality of the feature, as in a fitness tracker or games that incorporate user motion into the experience.
Appendix: Table of ICT types and access types
The organisation of the content above is shown in a mapping table, available in a separate document. The table provides a 2-dimensional overview of EN 301 549 requirements, with type of technology as column headers, and type of accessibility feature as row headers.
- The technology types are described in the section How the standard addresses ICT accessibility, except for the addition of a "Physical environment" column for requirements that relate to placement of ICT rather than its features.
- The accessibility feature types are the categories used in the Requirements by access type section. That section is essentially a row-by-row walkthrough of this table.
In addition to the EN 301 549 requirements, this table includes requirements from the European Accessibility Act, when they are not covered by the EN 301 549 standard. These come from my own interpretation, and are not required for an EN 301 549 conformance claim. In some cases, these provide useful reminders of related EAA requirements.
Both the EN 301 549 standard and the European Accessibility Act are formatted in ways that hinder providing deep links to the sections identified in the table. You can find the specific requirements as follows:
- EN 301 549 section numbers are easily found in its table of contents, or by text search of the section number or label from the table.
- For the EAA, the labels are invented for this table and not
necessarily searchable, and the section numbers in the document are not
formatted the same. The number pattern is:
- The first number is Annex I (not Chapter I).
- The second number is the Section number, a roman numeral.
- Each section provides nested lists of requirements, numbered with both arabic and roman numerals, and letters. Simply walk down the list to find the referenced item.
- Sometimes, inner lists aren’t numbered, in which case the position of the item in the list is indicated with a parenthesized ordinal number, e.g., "(3rd)".
The two main uses of this table is to find requirements by technology type, or by accessibility accommodation type.
- To find requirements for a particular technology type, find its column in the table and follow all the requirements in that column. Remember that Functional and General requirements apply to all technologies, and that most technologies incorporate features of more than one technology type. The full set of applicable requirements will therefore generally come from multiple columns.
- Specialists in certain types of content can find the row or rows in the table that apply, and follow the guidance there. Depending on the specific project, it might not be necessary to follow all the columns for the row, though it is useful to be aware of the broader set of requirements.

Document author: Michael Cooper on behalf
of The Digital Accessibility Centre Limited