About the accessibility directive
In October 2016 the EU parliament approved a directive on digital accessibility that had been worked on since 2012. The directive will become law in all EU-countries.
In this section, we’ll give an overview of the directive. In the next section, we will talk about what steps you need to take to comply.
The directive in a nutshell
If you work with web or apps in the public sector, the directive states that you must:
- Make sure your website, intranets and apps comply with accessibility standards (more on that later in “What are the actual rules”).
- Provide a feedback mechanism where anyone can notify you of failures to comply with the accessibility standards.
- Regularly provide a detailed accessibility statement on your compliance, using a template from the EU Commission.
Who is affected
The directive affects EU-countries, and its full name gives a good hint of what is covered: “Directive on the accessibility of the websites and mobile applications of public sector bodies”.
So you’re definitely affected if you – or your clients – fulfill the following criteria:
- Work with web, intranets or apps
- Work in a public sector body
- Work in an EU-country
Even if you’re not a government organization, you’re still affected by the directive if you:
Provide services that are essential to the public, or services that specifically address the needs of, or are meant for, persons with disabilities.
Exactly what’s considered essential to the public is not clear, but it will likely include companies in the transportation, food and finance industries, among others.
The directive lists some exceptions. The most prominent are:
- Broadcasters (TV, radio etc)
- Online maps
- Live video or audio content
There are a few other exceptions that you can read about in Article 1 Section 4 of the directive if you’re interested.
Will they audit me?
Yes. Here are some quotes from the directive:
Member States shall ensure the availability of an adequate and effective enforcement procedure to guarantee compliance with this Directive
Member States shall periodically monitor the compliance of websites and mobile applications of public sector bodies with the accessibility requirements
Member States shall ensure that public sector bodies provide and regularly update a detailed, comprehensive and clear accessibility statement on the compliance of their websites and mobile applications
So to cite George Orwell: “Big brother is watching you!”
What happens if I don’t comply
The most important problem if you don’t comply is that you’re making it difficult for your users to access your services, especially users with disabilities.
But also, since the directive will be made into a law in each EU country, not conforming to it will literally mean you’re breaking the law. Details about the actual consequences are decided by each country’s authorities and may differ between countries.
Deadlines – How long do I have to comply?
- 23 September 2018 – deadline for countries to have put laws and regulations in place to comply with the directive.
- 23 September 2019 – all new websites (created after 23 September 2018) need to be accessible
- 23 September 2020 – all websites (not just new ones) need to be accessible
- 23 June 2021 – all mobile apps need to be accessible
This does not mean you can wait until 2019 to address this. Accessibility is a team effort that involves developers, designers, publishers, executives…well basically everyone. If you’re not working actively with accessibility now, it will take time and energy to make accessibility part of your processes and increase the knowledge of your organization.
For most public sector bodies we’ve worked with, it takes about a year of calendar time to put the right strategies in place to become successful with accessibility. So get started in time!
What are the actual rules?
If you want to dive into the actual standard, you should! But be prepared to do some serious reading.
The directive is only 15 pages. But it doesn’t include the actual requirements for complying. Instead it references the EU standard for accessible public procurement which is 134 pages long. In turn, that standard points to WCAG 2.0, which is about 1 000 pages if you include techniques of how to comply with it.
If you are like most people, you don’t have nearly enough time to go through all that. So below we’ve put together a guide to what you need to do to comply with the directive.
Practical seven step guide to compliance
“Only seven steps!?” you might be thinking, but it gets even better:
- Apart from making your site or app accessible to people with disabilities, we guarantee it will become more usable for all your users. Win-win!
- You might be able to skip some steps, depending on what type of organization you are.
If you’re only going to procure apps or websites, you should focus on step 1, 3, 4 and 7.
If you’re only building the apps or websites, focus on step 1, 2, 5 and 6.
So here we go! Our guide for building accessible products that comply with the accessibility directive:
1. Educate yourself and colleagues
To succeed with accessibility, different roles need to have the right know-how. Like we said before, accessibility is not a one-man-show, it’s a team effort.
Here are some key roles and the competences they’ll need:
- Developers need to learn how to use techniques like WAI-ARIA to make their code accessible to assistive technologies.
- Testers and developers need to learn the basics of assistive technologies like screen readers, so they can validate the user experience of their interfaces.
- Designers need to learn how to create accessible user experience and design, like how to check the contrasts of their color schemes etc.
- Editors need to learn how to produce accessible content, like how to write alternative texts for images and create captions for videos.
- Managers need to know how to plan for accessibility and incorporate it into their requirements and agile processes.
Luckily, it doesn’t require weeks of education to get your team on track with accessibility. Most courses offered on accessibility are done in a day or two.
If you don’t have an accessibility professional to teach your team, here are some companies that offer accessibility training:
- Axess Lab (yes we shamelessly promote ourselves because we’re really good at this!)
- Paciello Group
- Simply Accessible
- Funka
A set up that we like to use is half a day of general training where people get to try out different assistive technologies, understand the users and learn the fundamentals of accessibility. Then we follow that up with half a day of specific accessibility training for different team roles. “Technical accessibility” for developers, “Accessible design” for the User Experience team etc.
2. User test
User testing is an absolute key task to succeeding with accessibility. If you’re not user testing on a regular basis right now, you should definitely start!
Trust us, we’ve worked with loads of clients who tried to make accessible products just by following different checklists. You will not succeed in building an accessible product unless you let actual users test it. Accessibility and usability are closely related. You can’t have one without the other.
If you’re user testing right now, great! Then all you need to do is start recruiting users with disabilities as test subjects as well. Check out our article on seven tips for user testing with people with disabilities.
3. Rework your style guide
I can’t even count the number of times an inaccessible style guide has caused problems in web projects. Since the style guide is the foundation that you build all your digital products from, an inaccessible style guide results in problems all across your interfaces.
Usually it’s because it specifies color combinations that have insufficient contrasts. A good tip is to have an accessibility expert work together with your designers to make sure your style guide complies to the accessibility standards.
Put in the effort to rework the style guide once and you’ll see so much fall into place automatically.
4. Feedback mechanism
The directive requires you to have a feedback mechanism that encourages users to comment on accessibility issues. You’ll also need to set up a strategy of how you handle issues that come in through the feedback mechanism.
For example, this can be a special email, like accessibility@yourcompany.com that you add to your contact or support pages of your sites and apps.
Many larger companies also have special social media accounts for accessibility, where they promote work they do on accessibility and encourage feedback and discussions. Get inspired by the following examples on Twitter: @fbaccess, @MSFTEnable and @BarcalaysAccess.
5. Automatic testing
There are plenty of tools out there that help you catch some accessibility issues automatically. However, I need to be really clear on this: automatic tools will not find the majority of accessibility issues in your interface. Accessibility guru Steve Faulkner put it clearly in this tweet:
📢Automated accessibility checking is great, but it needs to be clearly understood that you can only auto-check about 30% of #a11y issues pic.twitter.com/kAXYGqpiOg
— Steve Faulkner (@stevefaulkner) May 12, 2017
Here’s a great article from Gov.uk on automatic testing tools: What we found when we tested tools on the world’s least-accessible webpage. The overall gist of the article is:
It’s important that teams don’t rely on them too heavily.
Automatic testing tools are a good resource if used together with manual reviews and by a team with accessibility knowledge. But don’t count on them to fix all your problems.
Here are some automatic testing tools that you can compare:
6. Manual testing
You should complement your automatic testing with manual accessibility testing. In other words: let someone who knows about accessibility test your site or app.
Here, you can either work together with accessibility specialists or educate people in your testing or development teams to do the accessibility testing.
You will be required to do manual accessibility testing when you update the accessibility statement required by the directive. How often this needs to be done is not specified in the directive. It just says “regularly update a detailed, comprehensive and clear accessibility statement on the compliance of their websites and mobile applications”. A good guess is that it will be at least once a year.
A good way to succeed with this is to make accessibility testing part of your agile process. A lot of teams have a “definition-of-done” that specifies the criteria that need to be checked off before they release a new feature. Make both a manual and automatic accessibility test part of the definition-of-done.
7. Procurement and requirements
If you’re not developing your own sites or apps it will be crucial that you have clear accessibility requirements and that you follow up on those requirements.
Just pointing to a standard like WCAG and relying on your client to ship an accessible product is not a good way forward. WCAG is long, abstract and difficult to understand and it’s very likely your contractor didn’t even read it, knowing you probably wouldn’t either. But you are the one getting in trouble if the result is not accessible!
You need to make the requirements concrete and easy to understand. You need to decide how you will test the delivery and state what will happen if the requirements are not fulfilled. You wouldn’t imagine how often organizations fail with this. It’s not rocket science, but you need to be thorough and not take the easy road.
High five!
By following the web directive and creating accessible websites and apps you’re doing a great thing for democracy and people’s independence.
When focusing on the needs of users with disabilities you’ll make your products better for everyone. That’s called design for all and is what accessibility is really about.
On behalf of all users, we thank you for your commitment and wish you the best of luck with your accessibility journey. If you have any questions don’t hesitate to get in touch at hello@axesslab.com.