European Accessibility Act

I've been looking into the imminent European Accessibility Act (EAA) at work, and I've found it baffling at just how little there is out there that attempts to cover what the implications of the legislation actually are. The majority of the dialogue around it is very surface-level, and seemingly dominated by legal firms and overlay vendors who are trying to peddle their wares, so avoid giving firm answers or advice.

Most of what I can find basically says "meet WCAG 2.1 AA and go from there", and then invariably follows that statement with a disclaimer that the EAA goes beyond the normal scope of WCAG, but never says how that scope varies. So, I sat down and read through the latest version of the technical spec behind the EAA – the catchily named EN 301 549 version 3.2.1 – to try and work it out. Having done that, I figured I'd write up an overview of the impact of the EAA for the web^[1], mainly so I never have to read it all again 😂

DISCLAIMER: I am not a lawyer. Nor am I a certified accessibility professional (though I have worked in the field for some time). I have not been involved in the drafting or consultation around this legislation. I am not affiliated or associated with the IAAP, W3C/WAI, or any of the many branches of the European Union that have been involved. I'm just some guy on the internet trying to work out how the EAA will affect me, personally, as a web developer, based on the information at hand. So, if you need legal advice, hire a lawyer. If you want to ensure your service is accessible, hire an accessibility expert (or better yet, a team of them). But if you're just interested, or in a similar boat, read on.

Also, if you are a lawyer or expert and notice something blatantly wrong or misleading in what I've written here, please reach out. You can find me easily on Mastodon at https://indieweb.social/@theadhocracy or send me a Webmention (though Mastodon will be a lot quicker). I will endeavour to update this page with corrections.

Finally, as mentioned above, this is all based on version 3.2.1 of the specification. If a new version is released, I'll try to update things and will then change the bold text in this paragraph; so if a new version is released, until that number gets updated, consider the below out-of-date.

Background

With that out of the way, let's quickly cover what the EAA is and what the various terms floating around mean.

The European Accessibility Act is a piece of legislation that complements the existing Web Accessibility Directive (WAD), which itself became law in 2016 throughout the European Union (EU). The EAA officially took effect in April 2019, but was designed to have a fairly long onboarding process.

Member states within the EU had until June 2022 to implement any necessary local laws (or amend existing ones), which has now happened. These laws do not go into full effect until June 28, 2025, at which point all covered services must be in compliance and breaches can be litigated against. Crucially, the EAA does not supersede existing accessibility laws within member states, it just sets a baseline that all countries within the EU must uphold. Some countries, including France and Germany, have preexisting laws which must still be considered alongside the EAA.

The EAA applies to all public and private sector businesses that operate in any capacity within the EU. Obviously, if you are a European company you are covered by the EAA, but even if you are headquartered elsewhere, so long as you employ people within the EU, sell goods or services within the EU, or interface in almost any way with the public sector within the EU, you must still be compliant with the EAA.

So what does the EAA try and do? Broadly speaking, it provides a unified set of regulations that seek to ensure that all people are treated equally when it comes to accessing "IT based", well, anything. Websites? Covered. eBooks? Covered. ATMs? Covered. In fact, here's everything the legislation seeks to standardise and ensure equal access to:

• Websites, web apps, eCommerce stores, digital services, and mobile apps;
• Operating systems and offline software;
• Computers;
• eBooks (both the files and the hardware);
• Digital banking services (including in-store);
• Transportation services (air travel, buses, ferries, etc.);
• Telephony equipment and services;
• TV equipment, specifically related to digital broadcasts;
• Audio-visual services, mainly TV broadcasts but also equivalent consumer services and equipment (I'm assuming set-top boxes, remotes, streaming services, that kind of thing);
• Smartphones;
• ATMs, ticketing, and check-in machines.

In short, anything that a person might need to interact with that has a digital element, whether that be on the web, on a computer or phone, or at a physical location, such as a bank or transport terminal.

To make (my) life easier, I will use the term "digital service" as a catchall for the various tools and technologies that the EAA covers. It's important to understand that the EAA covers more than websites and mobile apps, unlike other accessibility standards such as the WCAG, though this article is primarily focused on how this affects web development – I just don't want to have to list them out each time 😅

What Preparations Are Needed? (the tl;dr version)

For the most part, the simple answer here is this: make sure you comply with the WCAG 2.1 standard to a minimum of AA rating in all categories. Obviously, AAA is preferable if possible, and there are many AAA criteria that can easily be met with minimal additional work, but from a legal perspective, AA is the baseline that the EAA is after.

However, as many places are quick to point out, the EU has explicitly stated that the goals of the EAA go beyond the remit that the WCAG spec is intended to cover, so depending on your business and the technologies in use, there are additional requirements that may be needed.

If you want to know the full details, then keep reading below but, as I understand it, here's what a website or mobile application must do to be compliant:

• WCAG 2.1 AA rating across the board, including emails, downloadable content (e.g. media files or PDFs), and documentation;
• Make interfaces useable with a variety of input methods;
• Do not restrict input methods or use of peripherals (software or hardware) e.g. blocking headphones or restricting access to the UI for assistive technology. If this is required, then alternative functionality must be provided that covers the same needs as the prevented software or hardware e.g. if you block screenreaders, you must have your own, in-built capabilities to allow text-to-audio functionality;
• Do not override user preferences (e.g. contrast levels, text size, etc.);
• Do not strip out accessibility metadata or features from files during upload or conversion;
• Never rely on a single form of biometric data alone, always offer alternatives;
• Media players should handle captions and audio descriptions, as well as provide user customisation of both features;
• Media should keep all channels in sync, with a minimum 100ms tolerance; this covers audio/video and video/text (captions or descriptions);
• Video used for communication (i.e. telephony or VOIP) must be received with clear audio good enough for lip-reading, a minimum resolution of 320p, and a minimum framerate of 20fps (480p/30fps preferred);
• Real-time video communication must provide text-based alternatives (i.e. a chat interface), which is both concurrent and does not interfere with the video stream;
• If you use key repeat patterns (sticky keys, shortcodes, etc.) then you must provide users with control over the time delay between keystrokes.
  

What Is Accessibility In This Context?

The EAA contains eleven "functional performance statements", which describe the requirements that are necessary for a digital service to be considered "accessible" under the EAA. To quote the current standard:

The intent of clause 4.2 is to describe the ICT performance in enabling users to access the full functionality and documentation of the product or the service with or without the use of assistive technologies.

These statements cover:

1. Usage without vision;
   
2. Usage with limited vision;
3. Usage without perception of colour;
4. Usage without hearing;
5. Usage with limited hearing;
6. Usage without or with limited vocal capability;
7. Usage with limited manipulation or strength;
8. Usage with limited reach;
9. Usage with minimised photosensitive seizure triggers;
10. Usage with limited cognition, language, or learning;
11. Privacy.

These can be roughly grouped into five categories: vision (1-3, and 9); hearing (4-5); input (6-8); understanding (10); and privacy (11).

Vision

All digital services must be as useable to a user using non-visual methods as those using visual ones. This broadly translates to ensuring that blind, low-vision, and colour-blind individuals can use your service as easily as sighted users.

In most cases, supporting common assistive technologies should ensure that this is covered – that means tools like screen readers and braille displays.

For websites, stick to common accessibility best practices:

• Use semantic HTML to markup your documents, including:
  
  • A clear document outline using ARIA landmarks;
  • A valid and consistent heading order;
  • Correctly labelled navigation elements and menus;
  • Accessible forms and interactive elements.
• Provide descriptive text (alt text) for images and animations;
• Ensure that videos have appropriate audio descriptions;
• Maintain a consistent tabbing order for keyboard navigation;
  
• Provide common navigation shortcuts, such as skip links;
• Allow users to magnify the screen or use a larger font size, without content overlapping, disappearing, or breaking;
• Use colour combinations with a good minimum colour contrast, so that text is easily readable;
• Relatedly, ensure that interfaces never solely rely on colour to convey meaning (e.g. a red/green indicator) and test colours to ensure various colourblindness conditions are catered for;
  
• Avoid, or provide alternatives to, interfaces that rely on depth perception;
• Support tools like high-contrast modes;
• Similarly, whilst not explicitly mentioned, supporting dark and light themes (and allowing user control over which is used) will help avoid edge cases.

Critically, to cover the issues around seizure triggers:

• Ensure that motion in interfaces can be disabled completely and/or reduced if wanted;
• Avoid or provide methods to disable flashing images or rapidly changing colours;
• Be generally careful around auto-playing video or animated images, such as GIFs, and respect motion preferences here as well.
  

Most of this would translate to non-web services in the same way, just with different implementation requirements. So images should have descriptive captions, video should have audio equivalents, and text should be clear and follow the logical reading order. Documents should be available in audio-only, mixed, and tactile (e.g. braille) formats as well.

Hearing

All digital services must be useable without audio, so that deaf and hard-of-hearing users, or those simply in environments where audio is not appropriate, are not disadvantaged.

For the most part, unless you are doing something very fancy with sound, this can be covered with a few easy affordances:

• Provide transcripts for any audio-only content;
• Provide closed captions and/or transcripts and/or sign language overlays for video content that has an audio element;
• Ensure that interfaces that are using/making sounds make that clear;
• Ensure there is an easy method to mute all sounds;
• Do not block the use of audio devices such as headphones.

There are some other suggestions noted in the standard which are also worth covering, mainly for people with limited hearing:

• Always use stereo (dual-channel) audio and make sure both channels get the same sounds, or provide the ability for a user to prioritise one channel (for users with partial deafness);
• Consider allowing balance adjustments on audio channels;
• Ensure audio content is as clear as possible (reduce background noise or static; boosting volume in higher frequency ranges can help);

Of course, providing text variations of audio content will mitigate pretty much all of the issues above as well.

Input

This covers quite a broad range of circumstances, but can be generally thought of as: if a user needs to interact with your digital service, make sure there are various methods to complete that interaction, and never presume specific physical attributes as requirements.

The scenarios covered by this category are the most likely to go beyond WCAG in terms of implementation considerations, but for the web, there isn't too much to keep in mind here.

• Provide consistent and simple keyboard navigation methods;
• Ensure that your interfaces work with mouse, keyboard, and touch input devices, as well as common assistive technologies;
• Confirm that voice-controlled tools can correctly navigate and understand your interface.
  

All of these will largely be covered by using valid, semantic HTML, as per the Vision section above.

You also need to consider whether your interface can be easily used in a variety of physical scenarios, which is likely to affect mobile interfaces more, including:

• Make sure all controls can be interacted with using a single hand (or ideally, a single finger);
• Again, ensure that controls that require fine motor precision or grip strength have alternative methods of interaction e.g. pinch to zoom also has corresponding buttons.
  

Beyond the typical use-cases of the web, two large considerations would be voice assistants or voice-activated interfaces, and biometrics. In brief:

• Never rely solely on voice-activated commands or vocal input, provide alternative interaction methods where these are used;
• Never rely solely on one form of biometric input, particularly as a method of authorisation or validation.

The final consideration is that physical interfaces must be easy to access regardless of a person's height, reach, stature, etc. Do not force people to stoop, or place things too high up or too deep within a space. This is unlikely to ever affect websites or apps, but worth being aware of.

Understanding

Rather than covering a broad range of circumstances that a person may find themselves in, this category instead highlights a broad range of cognitive needs that digital services should consider. It covers requirements around language use (both in terms of localisation and complexity), distractions and focus, reading ability, and various cognitive conditions that may hinder a person in certain scenarios.

Whilst this section can feel the most nebulas in some ways, a lot of it is covered by the solutions above. For example:

• Ensure a logical focus order in digital documents: this will (most likely) be automatically catered for by using semantic markup and meaningful landmarks;
• Make content accessible to those with limited or reduced reading capabilities: providing audio output and ensuring text can be understood by assistive tech like screen readers will cover you here;
• Avoid distracting animations: if you respect user preferences around motion, this should be covered already.
  

Some of the big ones are also standard WCAG requirements, such as:

• Keep error messages and other notifications on screen rather than letting them timeout, so users have time to read and understand them;
• Make error messages and other notifications clear, obvious, and simple to understand in general;
• Give clear guidance on input requirements (and do not hide that guidance, for example when a user focuses an input).

Basically, keep your interfaces simple.

The rest can largely be covered by thoughtful content guidelines:

• Keep jargon to a minimum and always expand/explain new or technical terms and abbreviations;
• Keep validation as flexible as possible – if you can offload some of the validation rules on to back-end logic, do so. A good example is complaining about leading or trailing spaces; just strip them out automatically, rather than force these arbitrary technicalities on the user;
• Provide assistance with user input where appropriate, such as text autocompletion or predictive suggestions based on existing input;
• Do not block the ability to paste or automatically enter content into fields, for example with password managers or hotkeys;
  
• Break tasks into small, discrete steps that users can complete at their own pace.

Privacy

And finally, don't force people using accessibility features to give up additional personal information that you otherwise wouldn't be asking for. This covers two main scenarios:

• Ensure existing privacy features are consistent across all access and interaction methods, and;
• Don't force some users to accept additional data gathering or other invasive requirements (and if you have controls around privacy settings, obviously make sure these are accessible and easy to understand).

The second can largely be covered by common sense, but does have some interesting implications around the (already deeply problematic) "accessibility overlay" industry, which practically can't help but capture additional sensitive information about users using or attempting to use their tools.

The first is a little harder to understand, but some examples can provide a good baseline:

• If you mask text in sensitive inputs, such as when typing in a password, make sure that the text is also masked when read out by a voice assistant, or printed in Braille, or anything else;
• Do not block the use of headphones, so that users relying on audio can do so in private^[2];
• Give users control over when and how they receive sensitive notifications, so they aren't inadvertently shared with other people.

How Does This Affect Web Development?

I've covered most of the details (and the why behind them) above, but the EAA does have a dedicated section explicitly for the web, section nine (note: the term "web" here includes websites, web apps, and mobile apps, and practically anything that is served via HTTP, not just your typical homepage).

Section nine goes into further detail on the specific requirements a website should meet. Luckily, nothing in this section differs or adds to WCAG 2.1, so as long as you meet AA requirements for the WCAG 2.1 specification, you will meet these needs 🎉

However, there are quite a few other sections of the EAA dedicated to specific technologies or digital service categories, and some of them will overlap with the work done by web developers. I've stuck a summary at the end of each section (if appropriate), just so you can see the most relevant information at a glance.

Section 5: Generic Requirements

The most open-ended of the specific sections, section five is a bit of a cabinet of curiosities, filled with miscellanea that clearly didn't fit anywhere else. Unfortunately, this means it overlaps with web development in some unexpected ways.

The big one is biometrics, which basically states: do not rely on one method of biometric identification alone. Always provide alternative methods for verification, identification, or whatever else you're using the biometric data for. This is fairly self-explanatory, but for instance, a person without fingerprints cannot use a "touch to unlock" method of verification, so they must have other options available. You are allowed to use multiple forms of biometrics; you don't have to use passwords, pass keys, verification codes etc., but I'd say it is likely easiest to do so.

You are also required to preserve accessibility information during conversion. Whilst less likely to come up on the web, it is something to consider if you are using file uploads or forms. Any user data input needs to be preserved, and that would include accessibility metadata encoded into media files or digital documents.

If you are ever adding a key repeat pattern to an app you are working on, this must be made adjustable so that someone can type the second or third repetition up to two seconds after the previous keystroke. Similarly, auto-repeating characters must be adjustable to only provide a character every two seconds. For example, if you have a text input that automatically converts three dashed lines typed in quick succession into a horizontal rule, you must allow for at least six seconds to pass from the first character being entered. This helps people with reduced motor skills, those who are easily distracted, or those who are "typing" via non-keyboard interfaces, where selecting characters may take additional time. Similarly, the enhanced delay would allow a person with reduced cognitive speed to stop the repeater when optimal. These patterns are not common in web interfaces, but they do sometimes occur, and would therefore be covered.

Most of the other regulations simply do not apply to the web, or if they do, are already covered elsewhere (e.g. providing keyboard control). The only time they may come up is if you end up developing for some kind of adaptive surface, such as tactile feedback on touch screens, at which point you may benefit from diving a little deeper to see how they could apply. Or if you choose to restrict the use of certain tools on your website (for example, blocking the use of headphones or screen readers), you would need to consider the regulations in 5.1: Closed Functionality.

tl;dr:

• Always provide more than one method of biometric authentication;
• Do not strip out accessibility metadata stored in uploaded files or content;
• Key repeat patterns must be adjustable to allow for up to 2 seconds delay, both on input and output;
• If you are doing anything particularly exotic on the web (e.g. blocking headphones, using haptic feedback mechanisms, overriding control of the keyboard) then you will need to do further research into the subclauses in this section.

Section 6: Two-Way Voice Communication

If you are working on VOIP or chat tools of any kind (voice chat, conferencing, in-game group chat etc.) then I believe this section applies, but the technical needs are not something I have any background in, so I'd basically recommend doing your own research here if you think it might overlap with your service or site.

Broadly, it covers:

• Ensuring that the decoded frequency range of any audio is optimal for clear understanding;
• Voice communication must also allow for text communication that mirrors the voice-based functionality (e.g. if you build a Zoom-style app, it must have text chat as well as voice chat);
• Voice and text communication must be able to be concurrent, but should not interfere with one another;
• Text communication must meet typical requirements for clarity and ease of reading (font sizes, line spacing, contrast etc.);
• There is a visual indicator of audio when it is playing;
• Video supports a high enough quality to make sign language and lip-reading possible;
• Video is a minimum of QVGA (320p) resolution and 20fps (VGA or 480p with 30fps is specified as preferable);
• Video and associated audio must be in sync, with a maximum delay of 100ms^[3];
  
• And communication is responsive and interoperable where appropriate (there are specific technical requirements here that I do not understand, sorry 😅).

Section 7: Video

Most of this section is covered already by WCAG video requirements, but there are some interesting additional needs for video players i.e. the actual interfaces used to control media on the web.

Video players must have closed caption capabilities, including being able to understand and transmit timestamps, caption positioning, and at least a limited range of colour (enough for speaker identification). Closed captions should be synchronised with the audio with a minimum of 100ms variance allowed (unless the video is live, in which case it's 100ms from the moment the player has received the caption information). A user should be able to alter the size, font, and colour of captions. They must also work with Braille devices, allowing the captions to be transmitted to the device for conversion.

As with Section 5 above, if you are processing video files, do not remove accessibility metadata such as captions, time encodings, or audio descriptions.

If the video player can output audio, then it should have the ability to understand and deliver audio descriptions as well. So if someone provides a video with the ability to enable descriptive subtitles (which provide additional context or actively describe the scene occurring for people that cannot see the video), the video player must have a way for a user to make use of that functionality. This should also be distinct from regular captions or subtitles.

Similar to captions, audio descriptions should remain in sync with the video.

tl;dr:

• Only focuses on video players or media UIs;
• These must provide functionality for closed captions and audio description;
• Captions and audio description should have user customisation, including text size, colour, and font;
• Captions and additional audio must stay in sync with video (100ms delay maximum);
• Do not strip caption metadata or audio descriptions from uploaded video or audio content.

Section 10: Non-Web Documents

Section ten covers any digital documents that are not web pages or embedded in web pages. However, if a web page allows a person to download a document, such as a PDF, spreadsheet, or word processing file, that document is covered by these requirements. That means hosted whitepapers or downloadable guides, for instance, are covered here.

This section also covers emails and media files that can be downloaded from the web and viewed on a digital interface, such as an email client or audio-visual software like iTunes or VLC.

Finally, there are special rules for documents that contain some kind of protection or DRM, including password protection and any level of encryption.

So what does this mean for files hosted and accessed from websites? Basically, they also have to meet WCAG 2.1 AA standards. It's also strongly advised that documents are given metadata that explains what accessibility options are available; the WebSchemas/Accessibility 2.0^[4] standard is referenced here. Oh, and captions should not obscure relevant text or information on videos, nor should audio description clash with the audio of content (I feel like both of these are covered by WCAG but they're given non-WCAG sections, so worth mentioning).

It should be noted that there are quite a few caveats carved out to help content authors meet these requirements. For example, a video file does not have to contain a full-text transcript baked in, so long as one can be easily found by a person who wants it (though, obviously, baked-in captions and other affordances are preferred and may be easier). The key here is that the files themselves do not need to meet all accessibility requirements, so long as an alternative version of the content exists which does meet these criteria.

There are some minor language changes to WCAG rules that the EAA adopts here as well. For example, the "Reflow" requirement has had to redefine the minimum widths from web-based dimension units (pixels), and therefore needs to alter some of the rules, but effectively the meaning remains the same. Similarly, the "On Input" requirements mention that "consistent navigation" makes little sense within a fixed document, so instead this applies to "sets of documents" (and notes this will be rare). Basically, they've thought of where language doesn't quite work and updated it, but if you stick to the WCAG spec and just use common sense to translate to fixed, offline document formats, you'll be fine.

The main takeaway here is that any downloadable content has to conform to the same standards as a web page. In many cases, therefore, this will likely be easier to achieve by actually using a web page in the first place. Converting PDFs to web pages, for example, may be a lot simpler to ensure conformance than trying to work out concepts like motion preferences, focus order, and magnification affordances within a more restrictive and proprietary medium. Something to consider, at least.

tl;dr:

• Any downloadable files on a website or content sent via email (including attachments) needs to meet WCAG 2.1 AA standard or have an alternative version available that does, which is "as easy" to find.
  
• Video captions and audio descriptions must not interfere with the content they are describing i.e. captions should not appear over text, and audio descriptions should not overlap pre-existing audio.

Section 11: Software

Section eleven explicitly covers mobile applications, but really doesn't stray much from the web guidance. Broadly speaking, if a mobile app conforms with WCAG 2.1 AA criteria, then it conforms with the EAA.

The main exception is where an app chooses to block access by assistive technologies (such as screen readers) or peripherals (such as headphones). In these scenarios, there are additional criteria that must be met, which can be broadly summed up as: provide in-built functionality that meets the same needs as the software or hardware that you are blocking.

So if you block screenreaders, you need to provide audio descriptions of all of the content on the page. If navigation is required, then you need to provide audio navigation prompts. If you block headphones, then you must provide some other method for audio navigation and allow users to mute any noises the app is making. If you are blocking certain technologies (for any reason) it is worth reading over this section yourself to understand the implications.

Similarly, mobile app developers should make use of (and neither override nor ignore) platform-level accessibility features. This is also similar to the requirements for websites, but goes a step further on mobile with the additional accessibility APIs that most mobile operating systems provide. Basically, don't block OS-level accessibility features, such as high contrast modes, voice controls, font overrides, etc. Plus, if there are platform-specific accessibility guidelines, you should conform to them. If there are platform-specific accessibility best practices, then these are encouraged (e.g. if there are standardised keyboard shortcuts for certain functions, then do not remap these to something unexpected), and this extends to general design practices such as font sizes, navigation positioning, colour use etc.

tl;dr:

• Mobile applications must meet WCAG 2.1 AA standards;
• If you block assistive tools or peripherals, you must provide comparable functionality within your app to meet accessibility needs;
• Otherwise, make sure your app works with assistive technologies;
  
• Do not override system-level accessibility APIs or user preferences;
• Stick to platform guidelines around navigation, accessibility, and shortcuts.

Section 12: Documentation & Support

Generally, the EAA here references the WebSchemas/Accessibility 2.0 specification, and encourages the use of accessibility metadata and generally documenting accessibility features within any digital services. That documentation should also meet WCAG 2.1 AA standard itself, of course.

For websites and mobile applications, this will most likely be covered by ensuring that accessibility statements are up-to-date and easily located, and that any specific accessibility tools or user controls are well-documented and easy to use.

As for support services (which covers call centres, help desks, training material, and general tech support), these must provide help with accessibility features and should be able to deliver access to information in a broad spectrum of ways, to cater for various access needs. So support staff should be able to answer using text, audio, or other methods; they should be able to cope with varying cognitive and physical needs; and they should be able to support people with a wide range of technical abilities.

tl;dr:

• Documentation should meet WCAG 2.1 AA criteria;
• Accessibility features should be well-documented and easy to find;
• Support staff or services should be accessible and provide support in a variety of ways.

And That's That (For Now)

If you've made it this far, congratulations, have a cookie 🍪

Hopefully I've covered most of the requirements under the new EAA. As mentioned at the top, if you've noticed anything missing, wrong, or misleading, please let me know and I'll get a correction made ASAP.

Of course, the EAA is just one of many accessibility laws around the world, but if you're a business operating in the EU, it will soon be the most critical one to get right. Good luck!

Further Reading & Sources

• EN 301 549 v.3.2.1 ETSI

  ⮬ Currently, the latest version of the underlying technical specification that the EAA is based on.

• Official guidance for compliance ETSI

  ⮬ The official guidance report for complying with the EAA.

• European accessibility act European Commission

  ⮬ An overview and introduction to the EAA direct from the source of the legislation.

• Latest changes to the EAA EC Digital Strategy

  ⮬ An up-to-date article on any changes to the EAA and the specific reasoning behind them.

• Web Accessibility Directive standards and harmonisation EC Digital Strategy

  ⮬ Full details on the harmonisation process for the WAD and current standards across the EU.

• Accessibility compliance Deque

  ⮬ A good overview of current accessibility laws and requirements around the world.

• Everything you need to know about the EAA Forbes

  ⮬ A decent overview of the EAA from a business/economic perspective.

• A small business guide to EAA compliance European Business Review

  ⮬ Another decent overview of the regulations from a business perspective.

• Schema.org accessibility properties Schema.org

  ⮬ The current home of the standard formerly known as "WebSchemas/Accessibility 2.0"