European Accessibility Act: how to respond to this new legislation
With the European Accessibility Act (EAA) now upon us, I have decided to take a little time to reflect on what my approach is, and to make some suggestions about what the good questions are that we should all be asking. This article is for any organsation in-scope, with over 10 members of staff. over €2 million in turnover, providing a service direvtly to the general public and trading from or into the EU from anywhere in the world.
Over the last 6 months there there has been so so much debate about this new legislation that doesn’t lean on guidelines like WCAG but instead takes a more Design for All approach, which begs many questions about what we mean by works like “accessibility” and “inclusion” and how this new act presents us with an opportunity to shake off the remnants of tick-box afterthought compliance and instead focus on giving everyone a designed experience.
In this article I solely focus on websites and mobile applications, and I will talk about what questions the act asks from us as accessibility professionals, designers and product managers, and I will offer up some thoughts about what a approach could be for this curious yet arguably quite brilliant piece of legislation. I find it is always good when trying to understand regulatory frameworks, is to start by getting out of the what what they are not.
First think to bank is that nowhere in the EAA does it mention the contents WCAG or any other guidelines, or checklists like VPATS, EN 301 549, EN 17161, although it does directly refer to any of them it does not discount them as being part of an approach and presumes they will be part of a process rather than as an outcome.
(74) In order to facilitate the assessment of conformity with the applicable accessibility requirements it is necessary to provide for a presumption of conformity for products and services which are in conformity with voluntary harmonised standards..
Instead of leaning into guidelines act it does something much cleverer and more meaningful from a customer experience perspective. Firstly it lists out things that should be expected to happen, which are unhelpfully found in three different parts of Annex 1, so I’ve listed them at the end of the article. Secondly it then identifies the audiences we should be focusing on and it shakes of the constraints of the medical model on accessibility, taking a more social model approach. And helpfully it then frames both of these in terms of WCAG’s POUR principles we all know and love, although arguably they focus on function only and not quality, but I will come back to that later when I look at Governance.
It is worth noting that this is the only way the act references anything to do with WCAG, so we can let go of the idea at this point that compliance to WCAG = Compliance with the EAA, because it does not. No matter what your AI slop bot tells you.
If you are not familiar with the principles, here’s a recap:
Perceivability, meaning that information and user interface components must be presentable to users in ways they can perceive.
Operability, meaning that user interface components and navigation must be operable.
Understandability, meaning that information and the operation of the user interface must be understandable.
Robustness, meaning that content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies.
Before you get into the weeks of the contents of Annex 1 of the EAA, and taking everything pointed out so far, would summarise this into 2 questions that any process for monitoring and reporting on the EAA:
1. What was the approach used to design and build the website?
2. How successful is the outcome of that approach for customers with disabilities?
For the rest of this article I will try to explain how I have reached that conclusion, then explore what that could mean and then suggest the types of tools and resources that could be used as part of an approach.
The EAA has four layers. It has principles, requirements, user groups and governance. The principles define both the approach and the outcomes, the requirements are specific contexts that are not open to too much interpretation, there are the different user groups for whom you should apply each desired outcome and there is the governance process by which each member state will require you to self-report on, and provide evidence for if they launch an investigation based on customer complaints.
Before you do anything, do this one task. If your organisation is in-scope for the EAA have you taken time out to read Annex 1?
If you are an Accessibility Manager carve this time out, maybe book out half a day, get some cakes and tea at the ready and read it. You don’t need to read the whole act, just this section, and it’s about three quarters of the way down. It’s dry, but try to take notes and then ask yourself some good questions about what you currently presume to be compliance, then have a chat with your compliance officers or commercial legal team to make sure you all have the same perspective.
Just to get you started on what to expect, you’ll notice that by listing the requirements in Annex 1 of the act, you’ll notice that several of these requirements go beyond the scope of WCAG 2.2 A, AA, or AAA, even though they share the same principles. See breakdown of EAA Annex 1
Governance
If like me you like to know what it is you are working towards? Before you start to make any decisions, you need to start with what we know about the governance model. The most helpful thing we know for sure is that what ever member state you are reporting to, the law is consistently applied. Regardless of existing domestic laws, the authority within the member start charged with regulating the act will require the same information as all the others, however because this isn’t a checklist there is no… checklist beyond what is in Annex 1.
This is all very well but without a template like a VPAT or a process to follow, how do we know what to capture and how to present it? This is where the art truly begins. I’ve was involved in regulatory as an advisory capacity to the BBC, YouView and ATVOD, as well as being a proactive part of the discussions for both the interpretation of policy, law and guidelines for over 20 years with various government departments. One thing I have learned is that this is unlikely to be a proactive engagement. Just because of the sheer scale they will not be testing anything beyond random samples.
The EAA will be monitored by government departments in a similar vein to other monitoring organisations such as OFCOM or OFGEM in the UK, and from what we currently understand, this monitoring comprises of two activities that cover both the approach and the outcome:
1. Self-Reporting. Because of the scale of the scope of the EAA, regulatory authorities are unlikely to implement any proactive monitoring frameworks beyond random samples, instead self-reporting will be required against the requirements outlined in sections I and IV of Annex 1, with some additional requirements in section VII, under Functional Performance Criteria.
The self-reporting has to cover each of the user groups outlined in section VII or Annex 1.
Accessibility auditing or automated WCAG testing alone are not acceptable as reports as the EAA is based more on a Design for All ethos rather than technical accessibility guidelines.
For more information about Design for All, read:
A Designed Experience for Everyone by A11yQuest
Understanding Design for All by Tetralogical
2. Customer Complaints. Similar to the way other regulatory bodies work in other sectors in the EU, most of the emphasis in monitoring will be placed on complaints raised by customers directly to the regulator.
It has already been estimated that is will be 80% of the process. This will be cross-referenced with the self-reporting to evaluate if work has or is being undertaken, with fines or website/app closure being distinct possibilities for business that do not engage properly. Fines are unlikely to happen without an engagement process so do get ahead of the game.
If there are no customer complaints then for a while at least it is highly unlikely there will be any action taken.
I mentioned earlier that Satisfaction or Quality were not requirements of the act, but curiously they are requirements os the process. There is a simple logic behind this that comes from my days as a brand manager.
Satisfied disabled customers do not complain, and with no customer complaints there is little or no risk.
Let that sink in for a moment. I asked at the start of this Governance section, “what it is you are working towards”, then ultimately this is it, and interestingly whether it is by design or not, by focusing more on the outcomes rather than the process, the EAA has connected the principles with customer experiences because no machine can tell you whether a disabled person could perceive, operate or understand something, and whether the service worked well with their technology.
You can estimate the likelihood of an outcome with a methodology, but you can’t measure it as a certainty.
Nothing about us without our data as customers.
As it is customers who will be doing the complaining then you need to get your data from customers. You will have disabled customers and you need to find them in statistically significant numbers. They will be there and segment them in terms of the EAA, not in medical terms. This data will enable two things to happen. Organisations can monitor customer satisfaction levels on an ongoing basis, for individual not only for key aspects of the user experience relating to the POUR principles, but also for this to be segmented and filtered using the different user groups outlined. And if the studies are used as part of your A/B testing process, the impact can be gathered from the audience about whether changes or new features improved the experiences of disabled customers or introduce potential issues.
Conclusion
As the EAA is both about approach and outcome, user data, in combination with things like investment in an inclusive design system, and ongoing automated accessibility testing, can form the basis of a robust and meaningful EAA compliance report, and provide evidence if there are complaints raised from customers.
EAA Design for All — Patterns, Practices and Outcomes (Annex 1: section I).
The following in italics are are all quoted verbatim from Annex 1 of the EAA, andI have added my notes about activities that can help with that aspect of compliance when it comes to website or mobile applications.
If you add features to support any of these, then make sure you also build in a way of tracking their usage. It will add detail to the conversation with reglatory authority if a challenge is made.
1. User Interface and Functionality Design
“The product, including its user interface, shall contain features, elements and functions, that allow persons with disabilities to access, perceive, operate, understand and control the product.”
There is only one reliale way to find out if this was achieved and that is to ask your disabled customers about their experiences.
2. Multi-Modality and Design Systems
“When the product provides for communication, operation, information, control and orientation, it shall do so via more than one sensory channel; this shall include providing alternatives to vision, auditory, speech and tactile elements.”
This is the basics of multi-modal design, so all UI and UX should be designed experiences including both design patterns and practices for inputs and outputs.
Everything, from components, pages and sites, should be measurable as designed outcomes for comparably usable experiences.
This could be done in QA or with UAT, but this is mostly the parts of accessibility that require manual testing. If your design system is WCAG AA compliant that does not fully meet what is requires. Look at each component in terms the following requirements, some of which are out of scope for WCAG but in scope for the EAA.
3. User Preference — Resizing/Zoom, Dark Mode & Forced Colour Modes
“When the product uses visual elements it shall provide for flexible magnification, brightness and contrast for communication, information and operation…”
Flexible brightness and contrast AKA forced colour modes, are not fully supported by WCAG, but are in scope of the EAA. This is almost always left out of the scope for accessible design systems and libraries, so is a great litmus test to find out of your library is EAA compliant or not.
4. Robustness, Assistive Technology
“…as well as ensure interoperability with programmes and assistive devices to navigate the interface.”
The measurement of navigability is a user outcome and it is not just about screen readers, although they are important. Make sure you are looking at all assistive technologies especially preferences and features built into the operating system.
5. Design Redundancy for Colour
“When the product uses colour to convey information, indicate an action, require a response or identify elements, it shall provide an alternative to colour.”
This is not saying that the colours have to be accessible, probably as there can be conflicting requirements, but rather than colour being a best endevour and there always being a fallback to usability without the presence of colour.
6. Design Redundancy for Sound
“When the product uses audible signals to convey information, indicate an action, require a response or identify elements, it shall provide an alternative to audible signals.”
Such an easy one to test, especially for videos. Test them all and make sure that captions aren’t just there, but they are meaningful. This guide from the BBC is probably the most comprehensive about closed caption quality.
7. Forced Colour Modes (inc. SVGs) and Replacement Fonts for Legibility
“When the product uses visual elements, it shall provide for flexible ways of improving vision clarity.”
Flexible vision clarity is an interesting wording of what is basically supporting the ability for users to zoom or resize text, replace the fonts or have control of the colours.
8. Audio Controls
“When the product uses audio, it shall provide for user control of volume and speed, and enhanced audio features including the reduction of interfering audio signals from surrounding products and audio clarity.”
This is great one for looking at products like BBC iplayer to see how they have designed their desktop media player. There is control and it is meaningful.
9. Keyboard, Switch, Voice and Pointing Controls
“When the product requires manual operation and control, it shall provide for sequential control and alternatives to fine motor control, avoiding the need for simultaneous controls for manipulation, and shall use tactile discernible parts.”
“…the product shall avoid modes of operation requiring extensive reach and great strength.”
I don’t think this is covered in its entirety in WCAG, especially the part about simultaneous controls. It is worth looking at your design system and component libraries and ensuring that they can be controlled with equivalent ease using any of these four modes of input. Tabbing is the most interesting and tricy one, and for complex components look at a hierarchy of need and not just visual orders when designing your tabbing journeys.
And remember that skio links can be used not just once at the top of the page, but can be added to get to or past different sections of very complex interfaces.
10. Flickering and Flashing Objects
“The product shall avoid triggering photosensitive seizures.”
That is an easy one. I’ve always used the Harding Test because of how reliable it is, especially for videos, but other tests are available.
11. Privacy
“The product shall protect the user’s privacy when he or she uses the accessibility features.”
This is an interesting requirement in terms of both overlays and user data profiling. Connecting the identification of user needs for quant research is vital for risk analysis using user data, so it should be gathered off-estate and aggregated at the point of collection.
12. Sign-in
“The product shall provide an alternative to biometrics identification and control.”
This is an interesting one and one where qualitative data can come to the rescue when reporting. Evidencing why decisions were made based on user data, but also making sure the users cover all the profiles listed in Annex 1.
13. Design Systems or Accessible Libraries
“The product shall ensure the consistency of the functionality.”
Only an accessible design system, code repository or component library guarantees consistency of application.
One issue with most accessible design systems is that they are benchmarked against WCAG 2.1 or 2.1, neither of which fiully meet all the EAA criteria.
“When the product uses visual elements, it shall provide for flexible ways of improving vision clarity.” For example, is not supported by most “accessible” design systems, and cognitive design is also out of scope for WCAG but in-scope for the EAA.
14. Timeouts
“…and shall provide enough, and flexible amounts of, time for interaction.”
So often forgotten. Look to the UK and US Gov guidance for these.
15. Technical Robustness
“The product shall provide software and hardware for interfacing with the assistive technologies.”
When it comes down to it, without robustness is the vehicle that underpins everything and luckily is the only principle that can be adequately monitored by a machine. If you use quant user data to monitor Perceivable, Operable and Understandable, then your AXE based monitoring tool and HTML validator can help you with Robust.
E-Commerce Requirements (Section IV)
Not all the requirements are contained in one section and if there is any transactional element to your service then you’ll need to consider the following:
Product Information
“Providing the information concerning accessibility of the products and services being sold when this information is provided by the responsible economic operator”
Functional User Outcomes
“Ensuring the accessibility of the functionality for identification, security and payment when delivered as part of a service instead of a product by making it perceivable, operable, understandable and robust” (see Section 1)
“Providing identification methods, electronic signatures, and payment services which are perceivable, operable, understandable and robust.”
Their use of POUR focuses on the list in Section 1 rather than WCAG
Functional Performance Criteria — Usable by All
Before you do any testing, remember that you have to consider all the user groups covered by the EAA equally. There is no hierarchy amongst the groups and they all need to have a comparably accessible experience.
“In order to maximise the foreseeable use by persons with disabilities, when the accessibility requirements, set out in Sections I to VI of this Annex, do not address one or more functions of the design and production of products or the provision of services those functions or means shall be accessible by complying with the related functional performance criteria.
Those functional performance criteria may only be used as an alternative to one or more specific technical requirements, when these are referred to in the accessibility requirements, if and only if the application of the relevant functional performance criteria complies with the accessibility requirements and it determines that the design and production of products and the provision of services results in equivalent or increased accessibility for the foreseeable use by persons with disabilities.”
Rolling quant user data that can be segmented using the following criteria, that focuses on POUR outcomes, will be able to demonstrate “equivalent or increased accessibility… by persons with disability”.
This might not be a mandatory form of reporting but could be an important part of self-reporting and risk evaluation.
The User Groups Under Consideration
One of the cleverest aspects of the EAA is the move towards the social model and away for segmentation using medical diagnoses. We are not talking about how people identify, but instead how they experience. Whilst this is broader terminology, it is better aligned to UX Design practices.
Something to be aware of is when you are recruiting for qualitative research you should use this criteria to be more aligned with the act, and the same goes for quantitative data, you should think about how you can segment and filter the data using this criteria rather than asking customers for their medical data, and never track or store that data as it would contradict the requirement for Privacy at the end of the list. The following is taken directly from the EAA:
a) Usage without vision
Where the product or service provides visual modes of operation, it shall provide at least one mode of operation that does not require vision.
b) Usage with limited vision
Where the product or service provides visual modes of operation, it shall provide at least one mode of operation that enables users to operate the product with limited vision.
c) Usage without perception of colour
Where the product or service provides visual modes of operation, it shall provide at least one mode of operation that does not require user perception of colour.
d) Usage without hearing
Where the product or service provides auditory modes of operation, it shall provide at least one mode of operation that does not require hearing.
e) Usage with limited hearing
Where the product or service provides auditory modes of operation, it shall provide at least one mode of operation with enhanced audio features that enables users with limited hearing to operate the product.
f) Usage without vocal capability
Where the product or service requires vocal input from users, it shall provide at least one mode of operation that does not require vocal input. Vocal input includes any orally-generated sounds like speech, whistles or clicks.
g) Usage with limited manipulation or strength
Where the product or service requires manual actions, it shall provide at least one mode of operation that enables users to make use of the product through alternative actions not requiring fine motor control and manipulation, hand strength or operation of more than one control at the same time.
h) Usage with limited reach
The operational elements of products shall be within reach of all users. Where the product or service provides a manual mode of operation, it shall provide at least one mode of operation that is operable with limited reach and limited strength.
i) Minimising the risk of triggering photosensitive seizures
Where the product provides visual modes of operation, it shall avoid modes of operation that trigger photosensitive seizures.
j) Usage with limited cognition
The product or service shall provide at least one mode of operation incorporating features that make it simpler and easier to use.
NOTE: This is a very tricky one, but it could be interpreted to be about Responsive Design. Having a button to switch to Mobile View would fix this, but there could also easy read issues too to consider.
k) Privacy
Where the product or service incorporates features that are provided for accessibility, it shall provide at least one mode of operation that maintains privacy when using those features that are provided for accessibility.
This could equally relate to data collection for any user with an account or the use of cookies. This could also apply to detecting preferences or assistive technologies. For data collection you need a platform that is fully accessible under the EAA and GDPR compliant.
European Accessibility Act: how to respond to this new legislation was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
This post first appeared on Read More