EN 301 549 Accessibility requirements for ICT products and services - Annex E (informative) Guidance for users of the present document
Table of contents for Annex E
Note: This Annex is not a mandatory part of this Standard.
E.1 Introduction
This explanatory annex is designed to enable users of the present document to make best use of it.
The standard was originally intended for procurement purposes. The scope is now changed and the current version also contains the minimum requirements of the European Web Accessibility Directive (Directive 2016/2102 [i.28]).
EN 301 549 contains a wide range of requirements to cover a variety of ICT solutions. There are for example requirements on function, physical characteristics and software. No matter if you are responsible for procuring, testing, planning, manufacturing, maintaining or reporting on accessibility, it is necessary to understand which requirements are relevant for a specific product or service in a specific situation or context.
Testing for accessibility requirements does not always result in a yes or no. Sometimes, you end up in a grey zone where it is equally important to understand the prerequisites and potential alternatives for different end user groups. Remember that accessibility has to do with humans.
The examples mentioned in this annex are only inspirational and the standard can of course be used in many different ways and settings.
E.2 Overview
The present document consists of fourteen clauses (equivalent to chapters in a book) and six annexes.
Clauses 0 to 3 contain background information, the scope of the standard, links to references, definitions of terminology and explanations of abbreviations. These clauses have a lot of valuable information, but it can be hard to read the standard from A to Z.
Clause 4 covers functional performance statements, which are directly related to end-user needs. The clause explains what functionality is needed to enable end users to locate, identify and operate functions in technology, no matter of their abilities. This is an important clause where you can learn about what challenges accessibility requirements aim to solve.
Clauses 5 to 13 are the actual technical requirements. Most readers start here, but clause 4 can possibly be a better place to begin, to really understand how to use the detailed technical parts.
The technical requirements cover many different kinds of ICT divided into separate clauses, but it is always a good idea to have a look at clause 5, since this is where the general requirements are.
Clauses 9, 10 and 11 are the ones that are most relevant to the European Web Accessibility Directive [i.28]. They cover websites, documents and apps. However, requirements from other clauses apply, as listed in the tables in Annex A.
Clause 14 deals with conformance to EN 301 549 as a whole and to the individual requirements.
Annex A describes how the standard relates to the European Web Accessibility Directive [i.28]. Apart from the minimum requirements in clauses 9, 10 and 11, some of the requirements in clauses 5, 6, 7 and 12 can also be relevant to fulfill the Directive, in specific situations. The tables in Annex A show which of the requirements are important to look at.
Annex B describes how the functional performance statements of clause 4 relate to the technical requirements in clauses 5 to 13. This is a useful tool that will, for example, help you to use the standard in procurement to identify the impact that specific requirements have on end users when comparing proposals.
Annex C describes how you can test that each requirement of the standard is met. The annex does not provide a testing methodology and you still have to know quite a lot about functional performance statements and testing procedures to make use of it.
Annex D provides a link to further resources for cognitive accessibility.
Annex E is what you are reading right now.
Annex F provides a change history table.
E.3 Clause 4
Clause 4 is in a sense the heart of the standard. The end users, with their different needs, are the reason accessibility matters. The user needs behind each functional performance statement are also the reason for each of the requirements in the present document.
Clause 4 does not include any requirements in itself, just descriptions. This may make it seem less important but, in reality, it is the other way around. The aim of the whole standard is to ensure that end users with the varying abilities described in this clause can use products and services.
In this clause, ten functional performance statements based on variations of impairments are described, plus privacy. The impairments can be permanent, temporary or situational. End users with multiple impairments might need specific combinations of accessibility solutions. Therefore, it is necessary to consider all different functional performance statements as well as a combination of them.
The concept behind the standard is to let technology help compensate the challenges that end users can have. You can also look at accessibility as alternative ways to use technology. For example: if the end user cannot see, technology can provide sound. If the end user cannot hear, the technology can provide text. This is what clause 4 is describing for each user group, in detail.
After reading clause 4, you will understand the logic of the requirements in the standard much better.
E.4 How to use the standard
E.4.1 Self scoping requirements
The requirements in the present document are called self-scoping. This means that they consist of two parts; the first part is a precondition for the second part, which holds the actual requirement. If the first part is true, you need to meet the second part of the requirement. If the first part is not true, this means that the requirement is not applicable.
For example, a requirement saying "Where ICT hardware has speech output, it shall provide […]" can be met in two ways:
- If your product or service provides speech, you need to fulfill the second part of the requirement.
- If your product or service does not provide speech, you do not need to think about the second part of the requirement. The requirement is not applicable.
To meet the standard means that all applicable requirements in the standard are met.
To get an overview of the requirements in scope of your product or service, you can focus on the requirements with the same scoping statements. There are online tools that can help you filter out requirements that are automatically met.
E.4.2 Connection between requirements and functional performance statements
The table in Annex B helps you understand the connection between the requirements and the functional performance statements. There is an instruction on how to use the table under clause B.2.
Before making a decision about the most suitable solution, you also need to think about the context. Here are some examples:
- In what situation is the solution going to be used?
- Which failed requirements are possible to compensate with other alternatives, like for example a service desk?
- What would it cost to solve an issue with an alternative like that?
- Will the failed requirements be possible to fix in the next version of the solution?
Suppliers may show how their product or service addresses the functional performance statements in clause 4 in addition to meeting the requirements in clauses 5 to 13. This can help you choose which product or service is most suitable.
E.5 The European Web Accessibility Directive [i.28]
The European Web Accessibility Directive (Directive 2016/2102 [i.28]) is a minimum harmonisation Directive. This means that all EU member states and EFTA countries are required to at least comply with the minimum requirements referred to in the Directive. Each country can choose to go beyond these requirements in their national legislation when it comes to both requirements and scope.
The Directive covers, as a minimum, public sector bodies and some government owned, funded or led organizations.
NOTE: The definition of public sector body is referring to the Procurement Directive (Directive 2014/24/EU [i.40]) article 2(1) point 4, which defines "bodies governed by public law" as bodies that have all of the following characteristics:
- they are established for the specific purpose of meeting needs in the general interest, not having an industrial or commercial character;
- they have legal personality; and
- they are financed, for the most part, by the State, regional or local authorities, or by other bodies governed by public law; or are subject to management supervision by those authorities or bodies; or have an administrative, managerial or supervisory board, more than half of whose members are appointed by the State, regional or local authorities, or by other bodies governed by public law.
Most of the requirements that relate to the European Web Accessibility Directive are found in clauses 9, 10 and 11, which cover websites, documents and software. The complete list of requirements are listed in the tables in Annex A. The Directive also covers intranets and extranets, which are to meet the requirements of clause 9 for web content and clause 10 for documents.
There are different grace periods for different kinds of content and there are also exceptions to what content is covered by the Directive. For example, live video is not covered by the Directive. This means that requirements 9.1.2.4 for websites, 10.1.2.4 for documents and 11.1.2.4 for apps are not relevant to meeting the requirements of the Directive.
Please note that there are also other requirements in the Directive, for example on monitoring and accessibility statements. These are not covered in EN 301 549.
E.6 Annex D: Further resources for cognitive accessibility
Annex D provides a link to W3C resources that can be used as guidance to improve the inclusion of accessibility for people with limited cognitive, language and learning abilities when using ICT products and services.