When we relate the Web Content Accessibility Guidelines (WCAG) to the European Accessibility Act (EAA), the relevant EAA sections are Article 2, Scope, and Annex 1 & 2 towards the bottom of the Directive.
The scope tells us which products and services are covered by the EAA.
Annex 1 tells us the actual technical accessibility requirements and Annex 2 gives us helpful examples of most of those technical requirements.
Web Assets
What you need to know is WCAG is specifically for web-based assets (e.g., websites, web apps) which means any assets that can be accessed by a web browser.
The takeaway here is that if you’re dealing with web-based assets, WCAG will tell you the exact things you can take into account for accessibility. Keep in mind that the EAA did not incorporate or adopt WCAG, but you can still use WCAG as a guide when working through the technical requirements.
Non-Web Assets
When it comes to non-web digital assets (e.g, software, native mobile apps), WCAG still largely applies, it just might not apply perfectly. If a WCAG success criterion doesn’t sync up exactly with a non-web asset, then it is either not applicable (and gets a default “pass”), and/or we look to the general principles underlying the success criteria for what we need to do.
The W3C actually has a WCAG 2 ICT Overview page that specifically provides:
Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies (WCAG2ICT) describes how the Web Content Accessibility Guidelines (WCAG) can be applied to non-web information and communications technologies (ICT), including documents and software.
So, in plain English, what this all means is WCAG is an extremely helpful reference for digital assets covered under the EAA. For example, mobile applications, websites, e-books, software, e-commerce services, etc.
By the way, WCAG 2.1 AA was incorporated into the EN 301 549 technical standard.
EN 301 549
EN 301 549 “Accessibility requirements for ICT products and services” is a European Standard. It defines the requirements that products and services based on information and communication technologies (ICT) should meet to enable their use by persons with disabilities.
EN 301 549 is a harmonised standard, that supports the European Directive 2016/2102 on the accessibility of the websites and mobile applications of public sector bodies (the Web Accessibility Directive). Therefore, it can be used to demonstrate compliance with that Directive.
However, hold this thought because there’s an update that we’re waiting on. We’ll explain more in a moment.
For now, note that EN 301 549 can be applied to any type of ICT-based products and services. This includes software (web pages, mobile applications, desktop applications…), hardware (smartphones, personal computers, information kiosks…) and any combination of hardware and software.
Physical Accessibility
We’ve talked about WCAG is an excellent reference for digital accessibility.
However, what you have to keep in mind is the EAA also covers hardware and other purely physical items as well as hybrid items (items that are combine both physical and digital).
That’s when we extend beyond the friendly confines of WCAG and need to account for other accessibility considerations.
The great news is for physical accessibility, we have Annex 1 which tells us the technical requirement and Annex 2 which gives us examples (for the most part) of what to do.
The other good news is EN 301 549 is still a worthy reference point and a new version, v 4.1.1, is being created right now (drafts are already finished in 2025) and once it’s harmonized, conformance with the new version, will create a presumption of conformity with the EAA’s digital accessibility requirements.
EN 301 549 version 4.1.1 is expected in 2025, but we don’t know exactly when (it’s already practically behind schedule since the deadline for EAA compliance is June 28, 2025). However, you might be able to nab an advance copy of the draft if you ask someone within the standards organization.
Still, the current version of EN 301 549 is a solid reference point.
Now, let’s go back to WCAG for a moment. What’s convenient like a Christmas sweater that just so happens to be sitting on your bed right before the big Christmas party is that the EAA gives away some of the applicable success criteria.
WCAG Principles
You see, the Web Content Accessibility Guidelines are built on 4 principles, commonly referred to as POUR which divide the success criteria by:
- Perceivable
- Operable
- Understandable
- Robust
Now look at what Annex 1 starts off with:
- Requirements on the provision of information: (a) the information on the use of the product provided on the product itself (labelling, instructions and warning) shall be:
(i) made available via more than one sensory channel;
(ii) presented in an understandable way;
(iii) presented to users in ways they can perceive;
(iv) presented in fonts of adequate size and suitable shape, taking into account foreseeable conditions of use, and using sufficient contrast, as well as adjustable spacing between letters, lines and paragraphs;
Look at letters (ii) and (iii):
- presented in an understandable way
- presented to users in ways they can perceive
Now let’s look at Section III (b)(viii) and (c) of Annex 1:
providing electronic information needed in the provision of the service in a consistent and adequate way by making it perceivable, operable, understandable and robust;
(c) making websites, including the related online applications, and mobile device-based services, including mobile applications, accessible in a consistent and adequate way by making them perceivable, operable, understandable and robust;
This is layup for us when it comes to digital assets. This means we can not only look to the principles, but entire WCAG versions as references. And we just so happen to have a very helpful link to the WCAG 2.1 documentation structured with the principles.
And looking at some of the other specific requirements (e.g., contrast and spacing), they’re fairly intuitive and it wouldn’t be overly difficult to map them to their associated success criteria.
Thus, for EAA technical requirements, WCAG – and more specifically, WCAG 2.1 AA and potentially 2.2 AA are great references.
And the good news is this reading allows for deviations from conformance because the EAA didn’t wholesale incorporate WCAG.
Summary
Your intuition is right, WCAG can help you stick the landing on a number of accessibility considerations for digital assets. Just connect the applicable requirements and examples and then tether them to WCAG success criteria and you’re off to the races.
For hybrid and purely physical accessibility, refer to the technical standards and examples as well as EN 301 549. Also, you can always try to get an advance copy of the version 4.1.1 draft.
Do you need help with EAA compliance? We’d love to help – just send us a message and we’ll get back to you ASAP.
In the meantime, we highly recommend our WCAG Course as advance training for your team. It’s incredibly helpful now and while continue to be going forward as you maintain EAA compliance.
