What’s new in the European EN-standard update from 2.1.2 to 3.2.1?

In the EU, the laws on digital accessibility for the public sector all point to a standard called EN 301 549. It’s been updated, and here in Europe a lot of people who work with web sites and apps are asking what this means for them.

European flag and an icon of a person in wheelchair waving a phone.

Most news are probably not relevant to you

If you work with web or apps – which most people who read this article probably do – I’d say about 95% of the update is completely irrelevant to you. Instead it affects other types of ICT (information and communication technologies), like:

  • Two-way voice communication, like intercoms
  • Software, like if you build Microsoft Word
  • Tactile buttons on physical devices, like ATM:s and ticketing machines

People generally forget that the EN-standard aims to cover all types of digital products, so just a part of it is relevant for web and apps.

If you work with the web

I’m not going to walk through all the changes that relate to things other than web or apps. You can read about those yourself in the documents linked in the end of this article.

So lo and behold! Here are the relevant news regarding the web!

PDF:s and other documents that users download are now covered

If you publish a pdf-file or other document as a downloadable file on your site, those now also need to be accessible according to the law.

“Is this really news?” you might ask yourself.

Yes, there seems to have been a loophole in the law, where the only types of documents covered were “documents that are web pages” and  “documents that are embedded in web pages”.

Now they’ve added “documents, including forms, that are downloadable from web pages but are neither embedded nor rendered together with the web page from which they are provided”.

So basically, everyone – including me – probably already thought the downloadable documents were covered. They were not. But now they are. Nothing really changed in practice, but a loophole was covered.

Come to think of it, it’s actually nice to have a clarification that documents include forms! So if you build forms in Word or pdf:s the law affects you too.

Subtitles need to be “styleable” and “speakable”, but not really..!

Two new requirements affect subtitles/captions. They are:

  • 7.1.4 Captions characteristics: “Where ICT displays captions, it shall provide a way for the user to adapt the displayed characteristics of captions to their individual requirements, except where the captions are displayed as unmodifiable characters. Defining the background and foreground colour of subtitles, font type, size opacity of the background box of subtitles, and the contour or border of the fonts can contribute to meeting this requirement.”
  • 7.1.5 Spoken subtitles: “Where ICT displays video with synchronized audio, it shall have a mode of operation to provide a spoken output of the available captions, except where the content of the displayed captions is not programmatically determinable.”

My first thought was: “Great! This means subtitles burned into the video are not allowed, because only subtitles created with the standard formats can be spoken and adapted.” But then I read the “except”-part a bit more closely. And the exceptions basically seem to say that if subtitles are burned in, these requirements don’t apply.

So to my understanding, nothing has changed for video creators. But if you build video players, or are deciding which video player to use on your site, you need to take this into account.

Very nitty-gritty-specific-cases

There are a lot of small additions to very specific cases relating to websites.

Let me take two examples:

  1. If your site has a way to activate specific accessibility features – which usually is a bad idea in the first place – you need to have a method of activating this feature “without relying on a method that does not support that need.” So my interpretation is that if you have a high contrast mode, that activation button needs to be high contrast. Or if you have a screen reader friendly mode, you need some kind of shortcut that’s announced to screen readers to activate it.
  2. If your site has two-way voice communication features – like support call embedded in the website – there are a bunch o requirements about having real-time texting, speaker identification and so on.

There are a few more like these.

If you’re interested in all these specific “edge-cases”, go to the heading “Requirments in EN 301 549 and relevant to the WAD, but not in WCAG 2.1” in this article:

Latest changes to accessibility standard (europa.eu)

Check out the documents

If you want to check out the updates for yourself, here are the two versions of the standard:

New version: EN 301 549 v3.2.1 (pdf on etsi.org)

Old version: EN 301 549 v2.1.2 (pdf on etsi.org)

Also, the article on europa.eu that I linked to earlier is a more formal summary than this article. Here it is again if you want to dive deeper:

Latest changes to accessibility standard (europa.eu)

I may have missed stuff

Here are some necessary disclaimers! I’ve done my best to compare the two versions, but I may have missed stuff. The document is around 200 pages long, and I’m not a lawyer. So don’t use this article in court. See it as a regular accessibility guy telling the world, in plain language, what he understands the updates to be.

If you find something I should add or change, get in touch and I’ll update the article: hampus@axesslab.com or @hampelusken on Twitter.

Thanks EU

Even though this update wasn’t a game changer, we in the a11y (short for accessibility) community are thankful for all the great work the EU does to lift this important topic!

Simba lifted by monkey in opening scene of Lion King. Text a11y by Simba and EU by monkey.

Get notified when we write new stuff

About once a month we write an article about accessibility or usability, that's just as awesome as this one! #HumbleBrag

Simply drop your email below.

We work world wide, if you need help send us an email!
hello@axesslab.com