The European Accessibility Act risks becoming just a box-ticking exercise

With the compliance deadline for the European Accessibility Act (EAA) fast approaching, companies are urgently trying to ensure their websites meet the requirements of the EU directive. 

One appealing solution is accessibility widgets — small add-ons with features like text resizing, contrast adjustments, and text-to-speech functions.

However, while these widgets promise fast and inexpensive compliance, they often fail to address the real issues of accessibility. In fact, they can even make websites harder for people with disabilities to navigate. 

Here’s why relying on widgets is a short-sighted solution and what web developers should focus on instead to create truly accessible digital spaces.

What does the European Accessibility Act mean for developers?

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!

The EAA, enacted in 2019, requires major e-commerce sites and private businesses to comply with a range of accessibility standards by June 28, 2025 (the deadline for public sector institutions has already passed). The rules apply to any company that conducts business in the EU, except for microenterprises with fewer than 10 employees or under €2mn in annual turnover.

These regulations are designed to make websites more accessible to users with disabilities, covering aspects such as text alternatives for images, keyboard navigation, and screen reader compatibility. While the EAA primarily impacts large enterprises, it has also raised general awareness of accessibility, encouraging smaller businesses to review the accessibility of their sites. 

As the deadline nears, the pressure to comply with the EAA has led some companies to pursue quick solutions. Accessibility widgets appear to offer an easy way to check the boxes. 

Unfortunately, these tools often lead companies down the wrong path, creating a false sense of security and missing the opportunity to fix the underlying accessibility issues of their sites.

Why widgets are seen as a suitable solution

This is not to say that accessibility widgets are bad by default. Their appeal is easy to understand. They are low-cost, fast to implement, and, in many cases, do address common accessibility needs, such as the options to adjust font sizes and contrast settings.

As a result, these tools can often be enough for websites that feature relatively few elements, don’t handle high traffic volumes, or don’t require visitors to perform important actions — entering your bank account information, for example. For such websites, widgets can provide a layer of accessibility without requiring significant overhauls to existing design and code.

For some businesses, especially those with limited resources, the promise of a widget is hard to resist. Adding a widget to your site will be considerably less expensive than ongoing testing, fixing, and maintenance processes. However, the reliance on widgets can not only delay fixing underlying issues with the site but can even lead to additional accessibility issues caused by the widgets themselves.

Widgets can cause more issues than they solve

A significant issue with widgets is that they tend to operate as overlays – they function as layers on top of the original website content rather than making structural improvements to the code. This layering can interfere with existing site functionality, causing problems with navigation, interactive features, or screen readers, which many users with disabilities rely on. 

For example, my team at TestDevLab looked at the major fashion retailer Zara, which uses accessibility widgets on its website. We identified several issues caused by these tools. To name a few:

• Site visitors who only use their keyboard for navigation cannot move to all elements after tapping the “Login” button because the focus jumps to the accessibility widget shortcut links. 
• If you select the dark, high-contrast option in the accessibility widget, the hamburger menu button and page logo are no longer visible. 
• A number of issues were detected with text adjustment and visibility when increasing the font size through the widget. 

Because widgets typically only address surface-level issues, they fail to engage with underlying accessibility requirements like keyboard navigation and properly labelled images. Instead of solving these deeper problems, widgets often become long-term crutches that prevent real progress, allowing companies to overlook the foundational changes needed for meaningful accessibility.

Whether a widget works is often determined by how the original site has been built and structured. If there are issues in the site’s HTML code, layering a widget on top of that may not make a difference in terms of accessibility or, even worse, break other elements that make the site more challenging to navigate than it is without the widget. Other factors affecting widget performance include each site visitor’s browser and operating system. While the widget may work for some, it may fail for others. 

Building accessibility from the ground up

True web accessibility requires investing in long-term, site-wide improvements rather than superficial fixes. Developers should consider accessibility a core part of the design and development process, not an afterthought. This means building accessibility into every stage of a website’s lifecycle, from design to testing. 

Elements like keyboard navigation, text alternatives, logical heading structures, and responsive design should be considered from the start, making the website accessible at its foundation rather than through add-ons. 

Testing is essential in this process. Accessibility is a continuous effort — it requires periodic audits and adjustments to ensure ongoing compliance as technology and accessibility standards evolve.