EN301549 requirements that go beyond WCAG
Responses to questions we didn’t have time to answer live during the webinar 26 November 2024.
Questions in the Q&A
Do we consider bold text preference, dark mode theme, enhanced contrast to be a part of Chapter 11.7 User Preferences? The requirement says: “Where software is not designed to be isolated from its platform, and provides a user interface, that user interface shall follow the values of the user preferences for platform settings for: units of measurement, colour, contrast, font type, font size, and focus cursor except where they are overridden by the user.”
Malin: I would think bold text definitely falls under: “font type”. There is ongoing discussion and division across Europe whether dark mode theme is part of “colour”, but I think it should be. Enhanced contrast, I would say, falls under “contrast”.
Where could I find a list of those 60 requirements that go beyond WCAG?
Follow up question, you said EN spreading to Australia, Mexico etc, does that mean these countries are legally required to follow it? And if so, can you provide some sources of info on the countries affected please?
Susanna: Not to my knowledge, but I am not an expert in legislation outside of the EU.
Is there a planned name or concept for the formal document? What keyword should one keep an eye out to monitor this question?
Susanna: Not yet. But if you have registered for this webinar, we will let you know as soon as it has a “home”.
Is there a standard accessibility conformance report for private organizations in the EU similar to what is required of the public administrations under WAD ? And how can we expect a homogenous application of the common requirements of the EN 301 549 when each country has their own template for reporting?
Susanna: The EAA points to the common EU declaration of conformity. There may be differences in implementation between member states, but so far we haven’t seen major differences.
How should emails be assessed during an accessibility review to ensure they meet WCAG standards?
Susanna: Out of scope of this webinar, but in general, newsletters are tricky because you cannot control exactly how the content is rendered. We recommend to always provide an html-version to make sure you have at least one interface where you can ensure accessibility.
And will there be more detailed guidelines specific to email accessibility in future revisions of EN 301 549?
Susanna: Not in the version currently being revised.
Will WCAG adapt to take on these additional requirements to create consistent testing and user experiences?
Susanna: That question should be posed to someone responsible within W3C, but I haven’t heard anything about it.
Are the controls for displaying captions and/or audio descriptions on YouTube offered at the same level of accessibility and ease of use as the playback controls (e.g., play, pause, volume)? If not, can you recommend a player that meets these requirements?
Wilco: As far as I’m aware YouTube does not support audio description. The best solution for it is to ensure the video is sufficiently narrated so that audio description isn’t necessary. Another solution people often recommend is to publish a separate video with audio description. To me, a separate video seems like a failure of the “same level” requirement, so I would advice against that. The player YouTube uses when embedded into separate websites also doesn’t allow enabling the closed captions before playing the video. This is more of an edge case for the requirement, but I would lean to saying this is sufficient since once the video is playing the close caption controls are immediately available.
The two other video players for web that I’m aware of that fully meet this requirement are OzPlayer and AblePlayer. These both support audio description, and have these accessibility controls at the same interaction level as the primary controls.
Hi! From what I hear, are there some existing testing guidelines for the monitoring agencies?
Susanna: Yes, several member states have developed their own monitoring methodology of the “EN beyond” requirements. That is part of the reason we have started this work – as it already leads to fragmentation.
What are the testing methods recommended by EN 301 549 for evaluating ICT accessibility?
Susanna: Annex C is the only testing method in EN301549.
So, you can put the Captions and AD controls at player level but they can be expanded with all features (colour, font…) and activated, true?
Wilco: A close captions and audio description button that expands into an options menu seems to me like it would pass the requirement. EN 301 549 doesn’t explain this further though, so this is a question that is open to interpretation. The effort this group is working on is to propose how to interpret these requirements, in the hope that monitoring / surveillance authorities will test these requirements consistently, instead of having each come with their own interpretation.
You can define accessibility by asking this question: is it usable by a disabled person?
Susanna: That is not how the EN requirements are created. Not WAD or EAA either.
Do you have any knowledge how national web accessibility supervisory authorities have reacted to these flaws? …in the video player, that is.
Susanna: The WAD requirements in Annex A have led to confusion and frustration. Several monitoring agencies have created their own testing methodology, which is already creating fragmentation and is part of the reason we started this work.
Are the 60 addition requirements specific to web only?
Peter: The 64 requirements that are not in WCAG are for web and mobile apps. 42 of them are applicable to web content, and all are applicable to mobile applications, according to Annex A of the EN301549.
What about PLYR player, do you know?
Wilco: I’m not familiar with PLYR. At first glance it does seem the close captions button is where it needs to be, but it does not support audio descriptions. If you’re using this player, the best solution for it is to ensure the video is sufficiently narrated so that audio description isn’t necessary. Another solution people often recommend is to publish a separate video with audio description. To me, a separate video seems like a failure of the “same level” requirement, so I would advise against that.
The two other video players for web that I’m aware of that fully meet this requirement are OzPlayer and AblePlayer. These both support audio description, and have these accessibility controls at the same interaction level as the primary controls.
What was the source of the stats on font size and dark mode again?
Malin: From appt.org
On Android:
- Adjust text size: 37%
- Dark mode: 24%
On iOS:
- Adjust text size: 35%
- Dark mode: 38%
Some sources:
A guide for making apps accessible, opens in new window
Let there be darkness!, opens in new window
Dark Mode Usage Statistics, opens in new window
Dark Mode Central, opens in new window
Improving Dynamic Type Support, opens in new window
For 11.7: what are the really required features, a website must have to pass this criterion?
E.g. changing font type is not possible with a custom font set first in Chrome and challenging in Firefox.
How should a user manage this?
Malin: Not entirely sure what the question is. The requirement is that websites should listen to the user settings in the browser for: “units of measurement, colour, contrast, font type, font size, and focus cursor”. What exactly is included in for instance colour and contrast is not clear, and therefore there is a discussion what these actually entail. Not all settings are possible to do in browsers, for instance focus marker. Text size and dark mode are, however, possible to set in several browsers.
Here is the procedure to increase text size in different browsers.
- Change font size in Chrome: Settings > Appearance > Change font size
- Change font size in Safari: Preferences > Advanced tab > tick the checkbox for Accessibility.
- Change font size in Edge: Settings and more > Settings > Appearance > Fonts, choose a font size.
- Change font size in Firefox: View > Zoom > select Zoom Text Only.
How this requirement could or should be met in web content (i.e. not in mobile apps that have a direct link to the platforms’ accessibility settings)?
Malin: This should be met so the website listened to the user settings done in the browser settings.
How one can make dark mode in the OS to affect the appropriate website?
Malin: I’m not a developer, but as far as I know to make a website respond to the user’s OS-level dark mode settings, developers can use the prefers-colour-scheme media query in CSS. This media query detects whether the user has enabled a light or dark theme in their operating system or browser and applies corresponding styles automatically. It’s supported in most browsers.
If you want, you can read more about the media query on Mozilla’s website, opens in new window
Some browsers are beginning to ignore device / OS settings, and are implementing their own settings. Is this something that has been taken into consideration?
Malin: In my view, the question of whether browsers override OS settings doesn’t necessarily impact how we interpret the requirements for websites and apps. The key principle is that websites and apps should respect and respond to the user’s preferences—whether those preferences are set at the OS level or configured directly in the browser.
If a user chooses a browser and customises settings within it, those browser settings effectively become the user’s expressed preferences. From a compliance perspective, if the website or app listens to and honours those settings, and the result is accessible, then the requirement is met. Web developers have no control over how browsers handle OS-level settings, but they do have control over whether their websites accommodate user preferences appropriately. As long as the user’s needs are addressed, the origin of the settings (OS or browser) is less relevant. Or am I misunderstanding this question.
Susanna: The current version of the EN301549 was published in 2019, so no.
What is the range of font sizes, from the smallest to the largest, that I should test to ensure compliance with requirement 11.7?
Malin: Based on the discussions so far, there is a consensus that the requirement should be that it is possible to enlarge font to at least 200% and that it fulfils 9.1.4.4 Resize Text. For decreasing font maybe just the possibility to do it is enough.
How does EN 301 549 address accessibility for mobile applications?
Peter: Table A.2 in Annex A lists the requirements that are applicable for mobile applications (including requirements for documents in apps), as required by the Web Accessibility Directive (WAD). These requirements are detailed in Clauses 5-7 and Clauses 10-12 of the standard. Some of the requirements in Clause 11 (Software) refer to WCAG 2.1.
It’s important to remember that the requirement of captions for live content (in Clause 11) is not listed in Annex A, as it is excluded from the WAD. Nevertheless, it is a requirement in the standard that can improve the accessibility of mobile applications.
There are more permutations/combinations of preference settings in an iphone than there are atoms in the universe so how can you legislate for ‘preferences’?
Malin: Based on the discussions, we would argue that settings are important and create a true benefit for end users that should be possible to do. The discussions are meant to result in a recommendation on what should be considered good enough, but we are not there yet.
On which background do you conclude that listing a requirement in annex A1 overrules the self-scoping part of 11.7? I.e. how can it be relevant for web when the clause starts with “Where software…”? 🙂
Malin: This is not something we conclude – it is what the European Commission has decided. Annex A contains the presumed conformance to WAD. It is unconditional that websites must fulfil 11.7, which means that all websites should listen to user preferences.
Thank you for a great webinar! Is this the first of many, seeing as you can only tackle a few requirements at a time?
Susanna: Since this webinar was so popular, it sounds like a good idea to continue doing them, like a series. The plan has always been to combine the workshops with editorial discussions in a smaller group and then presenting the results to the rest of the world for validation. We are also susceptible to flattery.
Does the requirement mean that the web or app does not hinder the user’s preferred settings at the OS or web browser level?
Malin: Exactly.
What types of fonts should I test? Should I focus on whether the website can display these fonts properly, or should I ensure that the layout does not break when using them?
Malin: I would say both, if you can adjust the font, but doing so means you can’t read all the text the requirement becomes rather useless.
Since websites are software, why are requirements 11.5 and 11.6 not included in the additional requirements?
Susanna: Parts of 11.5 and 11.6 are included in Annex A.
In Spain, Chapter 5 of EN 301 549, specifically requirements 5.4 onwards, does not apply to websites. Is this the same in other countries? Why is that?
Peter: Annex A (more specifically, Table A.1) lists only requirements 5.2, 5.3 and 5.4 to be applied for websites, when it comes to complying with the Web Accessibility Directive (WAD).
Unfortunately, some member states have been testing only a limited set of requirements. During the first reporting period, some member states didn’t have resources or knowledge to test the “EN beyond” requirements, but that is improving fast.
You can read more about it in the 2022 study supporting the review of the WAD, opens in new window
“Is the requirement for support documentation for ICT devices only? For example, if there is safety or usage instructions for a container of lubricant, would this apply?”
Peter: EN 301 549 contains accessibility requirements for ICT products and services, as well as requirements for documentation and support services linked to those. It does not cover the usage instructions for the product in the example.
What about e.g. the editor backend of a CMS and its related documentation? Are there cases the backend UI must be fully accessible?
Peter: As the CMS backend is ICT, I would say that the requirements in the standard can be used also for backend, although not specified. Neither WAD nor EAA covers the backend.
What’s the relationship between 11.7 (focus cursor) and WCAG 2.4.7? Does the former preclude creating your own focus indicator?
Malin: I think focus curser is the hardest one. Requirement 11.7 emphasises that users should be able to control how the focus marker appears, WCAG 2.4.7 mandates that focus indicators exist and are visible. So, I don’t think these are related.
However, currently the ability to customise the focus marker is very limited in practice. In most browsers, users cannot easily adjust the focus indicator’s appearance without resorting to technical workarounds, such as custom stylesheets or extensions. On mobile operating systems like iOS and Android, there are accessibility settings that enhance focus visibility, but these typically override all app or website styles rather than offering granular control.
Given this lack of practical implementation, I personally believe that “focus cursor” should be removed, since it is not technically feasible today.
Questions/Remarks in the Chat
This seems to be a list of requirements in EN 301549 not in WCAG 2.1 (but I think not the list mentioned, I cannot see 60 requirements listed in it)?
Requirements in EN 301 549 and relevant to the WAD, but not in WCAG 2.1, opens in new window
Peter: The EC page only lists requirements that are applicable for websites. More detailed answer in the Q&A: The 64 requirements that are not in WCAG are for web and mobile apps. 42 of them are applicable to web content, and all are applicable to mobile applications, according to Annex A of the EN 301 549.
I hardly see any audio described videos today on YouTube and those have AD are usually a separate video. Do we know how easy it is going to be to incorporate AD into the same video so it can be turned on and off?
Wilco: As far as I’m aware YouTube does not support audio description. The best solution for it is to ensure the video is sufficiently narrated so that audio description isn’t necessary. Another solution people often recommend is to publish a separate video with audio description. To me, a separate video seems like a failure of the “same level” requirement, so I would advise against that. The player YouTube uses when embedded into separate websites also doesn’t allow enabling the closed captions before playing the video. This is more of an edge case for the requirement, but I would lean to saying this is sufficient since once the video is playing the close caption controls are immediately available.
The two other video players for web (that I’m aware of) that fully meet this requirement are OzPlayer and AblePlayer. These both support audio description, and have these accessibility controls at the same interaction level as the primary controls.
Will EN301549 include WCAG 2.2?
Susanna: Yes, the current update includes WCAG 2.2 AA.
And do we know when that will be published?
Susanna: According to the mandate, 15 September 2025. However, it looks more likely to be February 2026.
12.2.4 – Accessible documentation – If the organization provides electronic documents, should these files be accessible? As accessible PDFs?
Peter: In general, electronic documents in scope of the legislation have to be accessible. (Those are: downloadable documents from websites and apps if related to the products and services in the EAA scope, or belonging to a public sector body.) As regards to requirement 12.2.4, documentation provided by a support service (to the question of the user), must also be accessible. It can be done by publishing it as an accessible webpage or by sending an accessible document. The format is not specified, it can be Word, PDF, etc., as long as it is accessible, which means in this case that they follow the requirements in the standard.
EN301549 requirements that go beyond WCAG
IAAP Nordic webinar 26 November 2024
Recording of the webinar with Wilco Fiers, Malin Hammarberg, Peter Kemeny and Susanna Laurin.