What is the EN 301 549?
The easiest way to explain it is to say that it’s a common European standard for procurement of accessible ICT. The European standardization bodies were asked by the European commission to produce a harmonized standard for ICT and accessibility.
The goal was to set a common ground for public procurement in Europe but the aim is of course to gradually make an impact in all sectors.
Persons with disabilities have the same right to digital information and services no matter where they live. When all countries use the same requirements, more equal access is possible.
But the EN standard is also important to support the inner market. Expert companies should have the possibility to sell their services throughout Europe.
WCAG is part of EN 301 549
When it comes to the web, the Web Content Accessibility Guidelines or WCAG, which is the international standard developed by the W3C, is the common denominator.
The WCAG standard is included in full in the EN standard, but the EN 301 549 covers more than that. It covers all ICT. The EN standard will be implemented in procurement regulations in all European member states starting in 2016.
The hope is that the private sector will follow more or less automatically since suppliers will learn accessibility when selling to the public and then keep delivering the right way to other clients as well.
In the private sector suppliers that sell ICT to government will be incentivized to make the ICT accessible in order to compete. Suppliers that do not sell to the government will be able to leverage on the standard to do what the government does in terms of procurement but on a voluntary basis.
The structure of EN 301 549
In standards, chapters are usually called clauses but to make it all a little easier, we use the word chapter here.
The standard begins with some background information, the scope of the standard and some references and definitions in the first three chapters.
In chapter 4, you will find the so called functional performance statements. This means that the chapter contains explanations on what functionality is required to enable users to locate, identify, and operate functions in the ICT, no matter of their abilities. This is an important chapter.
The technical requirements starts in chapter 5 where you will find the generic requirements that goes for all ICT. In chapter 6, you will find requirements on ICT with two-way voice communication. In chapter 7, there are requirements on ICT with video capabilities.
Chapter 8 contains requirements on hardware and chapter 9 has requirements on web content. In chapter 10, you have requirements on documents. In chapter 11, you find the requirements on non-web software.
Chapter 12 contains requirements on documentation and support services. In chapter 13, there are requirements on relay and emergency services.
The standard also has 3 annexes:
- Annex A contains the Web Content Accessibility Guidelines 2.0.
- Annex B gives information on the relationship between the technical requirements and functional performance statements, and how they work together.
- Annex C contains information on how to test, which is also called determination of compliance.
Now let’s take a closer look at the different chapters:
Chapter 4: Functional performance
Chapter 4 contains functional performance statements. These statements specify how the solution should cater for different user needs. Chapter 4 is in a sense the core of the EN-standard. The users and their different needs are why we work with accessibility. The user needs are also the reason for each of the requirements in this standard.
Do not be fooled by the fact that chapter 4 does not include any requirements but just descriptions. The goal with the whole standard is that users with the varying abilities described in chapter 4 can use the product or service.
If you have problems finding a solution that meets the accessibility requirements, you must assess the implications for the user groups in chapter 4. That gives you an idea of the impact a specific accessibility issue might have and that is essential for you to make an initiated decision on what solution to buy.
Annex B contains a table, mapping the different requirements in the standard with the functional performance statements in chapter 4. There is also one table mapping success criteria in WCAG with the functional performance statements in chapter 4.
Here you can see for whom each requirement is important. This table is a key instrument for you to make assessments of what impact different accessibility problems might have for the end users.
Chapter 5: Generic requirements
Now let´s take a quick look at the generic requirements in chapter 5. Generic requirements cover among other things requirements on closed functionality.
Closed functionality means that the user can’t attach personal assistive technology, like a screen reader with headphones for a person that cannot read text. This could, for example, be in information kiosks, and ticket machines. For devices with closed functionality to work for all users, the system must provide ways for the user to interact, and perceive information that caters to different user needs. That means that the system itself must work as assistive technology.
To keep the analogy with screen reader and headphones, that would mean that the system should provide sound in some way. But of course, not only sound.
Chapter 5 also says that the system should not require users to be able to perform two actions at the same time. There are requirements on Biometrics, for example when you use your finger or eye to verify who you are. This should not be the only way of identifying yourself.
And finally in this chapter, there are also requirements on how to keep information accessible when it is converted. For example, when you have a document in one format and want to save it in another format. All accessibility information, like headings, should be preserved during that conversion.
Chapter 6: ICT with 2-way voice communication
In chapter, 6 there are specific requirements for solutions with two way voice communication. This could for example be a door entry phones where one person speaks and another one answers or digital communication, or meeting systems, where many users can speak with each other.
Some of the requirements in chapter 6 cover the ability to use real-time text communication, or RTT, as an alternative way of communication, which is essentially a chat function where you can read the text at the same time as it is being written.
The chapter also include technical requirements for video communication such as frame rate and resolution during a call.
Chapter 7: ICT with video capabilities
Chapter 7 covers ICT solutions that feature video. The requirements in this chapter specify that the user should be able to get captioning of audio content in synchronized video, which means a video with image and sound at the same time.
It also specifies that visual information provided in the video should have an audio description providing equal information to users that cannot see the content.
Chapter 8: Hardware
EN 301 549 deals with requirements on hardware in chapter 8. This includes requirements targeted on hardware with speech output, like phones for example, or audio guides.
You will also find requirements on the physical environment. For example, how to place an ATM in terms of for example floor space and the path to the machine.
The requirements in this chapter ensure that all users, no matter of abilities, can use the hardware.
Chapter 9: Web content
This is done by pointing to the Web Content Accessibility Guidelines 2.0 level AA. The Web Content Accessibility Guidelines were created by the World Wide Web Consortium or W3C in 2008. These guidelines are the common denominator for much of what is done in accessibility in the web-based domain. They are quite complex but if you are dealing with the web, you probably already know them. If you don’t, you definitely should.
For now, it´s enough to know that there are a total of 61 success criteria in WCAG and that 38 of these need to be met if you want to comply with level AA, which is what the EN 301 549 requires.
A success criterion in WCAG is a measurable requirement that is technology-independent. This means that it can be used regardless of what technology you are using. It is as relevant for HTML as it is for documents in different formats or any other web technology you are using.
Annex A: Web Content Accessibility Guidelines 2.0
Annex A is a copy of WCAG 2.0. Since the WCAG is a separate set of guidelines, this annex is only informative. But you still need to meet the success criteria in WCAG to meet the requirements of chapter 9 in the EN 301 549.
This means you really need to get to know the WCAG guidelines if you have an ICT product or service with any kind of web content, documents or software that the user gets in contact with including the documentation and help surrounding the actual product or service.
To really make a web based interface accessible, you might need to include more requirements than the success criteria in WCAG and you might need to specify how some of these success criteria should be met to avoid misinterpretations and mistakes.
Chapter 10: Documents
WCAG is also used in chapter 10 in the EN standard. Chapter 10 covers non-web documents. Although much of WCAG is relevant for documents outside of the web, some success criteria are not relevant.
In the EN standard, there is a table to help you understand how to use WCAG in the context of non-web documents.
Chapter 11: Non-web software
This could be software in a check-in machine at an airport, or a vending machine or any hardware with a user interface.
Also for non-web software, WCAG is used as a base. So in this chapter you will find a table explaining how to use WCAG in a non-web context but here are other requirements as well. Requirements to ensure that the software can be used with assistive technology or that it caters for the user needs in other ways to make it possible to use the service.
One important thing here is that there are also some requirements on authoring tools. If you have a software where users can create content for other users, these authoring tools need to be accessible and the output from these tools need to be accessible as well. In that way, the content remains accessible.
Chapter 12: Documentation and support services
To meet the requirements of the EN-standard, it is not enough that the service in itself is accessible. The documentation and support services also need to be accessible. This is covered in chapter 12.
Support services could, among other things, be help desks, call centers and training services. In reality, what this chapter says is that documentation and support services need to follow the requirements in the other chapters of EN 301 549.
Chapter 13: Relay and emergency services
Relay services makes it possible for individuals with different communication abilities to communicate with each other remotely using ICT for text, sign language or lip reading.
This chapter covers requirements on how to provide conversion between the modes of communication normally by a human operator.
Now we have gone through all the chapters of EN 301 549.
Of course, not all requirements are relevant in all procurement situations so you need to pick the requirements that apply to your situation.
But there is more to it! The standard also contains 3 annexes, to help you understand the requirements.
We have already talked about Annex A, and Annex B. In Annex C, you will find information on how to verify compliance with the requirements. Note that this annex is quite complex and that the actual testing requires a lot of skills and experience.
Like every other profession, you need training and experience to work with accessibility. If you don´t have that training and experience, you need to involve experts.
Hopefully, you have a general understanding of the structure of the EN 301 549, and what’s in there.
Add Comment