Accessibility widgets and the EAA: what they do and don't do

Last updated: 13 October 2026

If you run a website in Europe, you have probably been offered an accessibility widget, toolbar or "overlay" as a way to deal with the European Accessibility Act. This page explains what the law asks of a website, what a widget can and cannot do about it, and what to fix first.

We make an accessibility toolbar for WordPress, so weigh what we say with that in mind. Every fact below links to its source. This is general information, not legal advice: the rules that apply to you are in your country's law.

An accessibility toolbar helps some visitors; it does not make a website conform to WCAG or to the law. Fix your content and code first.

The short answer

• No widget, toolbar or overlay makes a website conform to the EAA or to WCAG. The European Disability Forum and the International Association of Accessibility Professionals say so plainly: overlays "do not make the website accessible or compliant with European accessibility legislation".
• A widget changes how your pages look for a visitor who chooses to use it. It does not add missing text alternatives, labels, keyboard access or structure, which is where most barriers are.
• The work that counts is in your theme and your content. A widget is, at most, a small extra on top of that work.

What the EAA asks of a website

The European Accessibility Act is Directive (EU) 2019/882. EU countries have turned it into national law, and those laws apply from 28 June 2025 (Article 31).

• Who it covers. Among other services, it covers consumer banking, e-books and e-commerce services (Article 2). If you sell to consumers online and you are not a microenterprise (next point), it concerns you.
• Who it does not cover. Microenterprises that provide services are exempt from its accessibility requirements (Article 4(5)). A microenterprise is a business with fewer than 10 people and an annual turnover or balance sheet total of no more than 2 million euros (Article 3(23)).
• What the website must be. Websites and apps used to provide the service must be accessible "by making them perceivable, operable, understandable and robust" (Annex I, Section IV). Those four words are the four principles of the Web Content Accessibility Guidelines (WCAG).
• What you must publish. The service provider must explain how the service meets the accessibility requirements, in its general terms and conditions or an equivalent document (Article 13(2) and Annex V).
• The standard. Meeting a harmonised standard cited in the Official Journal gives a presumption of conformity (Article 15). For websites that standard is EN 301 549. The version in use today, 3.2.1 (2021), is based on WCAG 2.1 level AA. Version 4.1.1, published online on 2 September 2026, moves to WCAG 2.2 level AA; once the European Commission cites it in the Official Journal, which Ireland's National Disability Authority expects on 16 December 2026, meeting it gives a presumption of conformity with the EAA.
• Penalties. Each country sets its own, which must be "effective, proportionate and dissuasive" (Article 30).

There are transition rules too: for example, service contracts agreed before 28 June 2025 may continue unchanged until they expire, for at most five years (Article 32). Check your national law for the details that apply to you.

What a widget does

An accessibility widget is a button on your pages that opens a panel of settings. Depending on the product, a visitor can make text bigger, add spacing between lines and letters, switch to high contrast or a different font, show a reading guide, stop animations or hide images. The changes apply to your website only, in that visitor's browser, while the setting is on.

That can help a visitor who does not know how to change these settings in their browser or system, or who is on a device they cannot set up, such as a shared computer. That is the honest case for a widget, and it is a narrow one.

The same changes are already built into browsers and operating systems, and those work on every website. The W3C's Web Accessibility Initiative explains how to change text size and colors in any browser, and answers the widget question directly: "Widgets change only the website they are on."

What a widget does not do

The barriers that stop people from using a website are mostly in its code and content, and a widget does not touch them. It does not:

• write text alternatives for your images, charts and icons;
• put labels on form fields, or make error messages clear;
• make menus, sliders, pop-ups and checkout steps work with a keyboard;
• give your pages a logical heading order;
• fix low contrast in your design for everyone who does not open the widget;
• add captions or transcripts to your videos;
• write the accessibility information the EAA asks you to publish.

Some overlays go further and try to repair the page automatically when it loads. The Overlay Fact Sheet, written and signed by accessibility practitioners, lists what that cannot do reliably: text alternatives for images, form labels and error handling, focus control and keyboard access.

Claiming otherwise can cost money. In 2025 accessiBe settled with the US Federal Trade Commission, whose complaint said the company had "represented that accessWidget could make any website compliant" with WCAG; the order requires the company to pay 1 million dollars (Federal Register notice, 6 January 2025).

Why many accessibility experts dislike widgets

The criticism is worth reading before you install anything, ours included:

• They can get in the way. "Users of assistive technology already have their devices and browsers configured to their preferred settings. The overlay technology can interfere with the user's assistive technology and override user settings" (EDF and IAAP, 17 May 2023).
• They repeat what people already have. The Overlay Fact Sheet calls the widget "at best—redundant functionality with what the user already has", because people who need these settings need them on every website.
• Practitioners rate them low. The Fact Sheet quotes a WebAIM survey of accessibility practitioners: 67% rated these tools not at all or not very effective, and 72% of respondents with disabilities did.
• Privacy. Some overlays detect that a visitor uses a screen reader, which reveals a disability, or carry a visitor's settings from one website to another with a cookie (Overlay Fact Sheet).

What to fix first

These checks find many of the barriers that matter, and most need no special tools:

1. Keyboard. Put the mouse away and use the Tab key to go through your main pages, menu and checkout. You should always see where you are, and reach and use everything.
2. Images. Every image that carries information needs a text alternative that says what it shows; decorative images need an empty one.
3. Forms. Every field needs a visible label, and errors must say what went wrong and how to fix it.
4. Headings. One main heading per page, then headings in order, so the structure makes sense without the design.
5. Contrast. Text needs enough contrast with its background, including on buttons and in your theme's light grey text.
6. Zoom. At 200% browser zoom nothing should be cut off or overlap, and on a phone-width screen the page should not scroll sideways.
7. Media. Videos with speech need captions.
8. Your information. Write down, honestly, how your service meets the requirements and what is not done yet, in your terms or an equivalent page.

Then ask people who use assistive technology to try your site, or hire an accessibility specialist for an audit against EN 301 549 or WCAG. In WordPress, choosing an accessibility-ready theme and testing each plugin you add with the keyboard saves a lot of later work.

If you still want a widget: what to check

A widget can be a small extra for some visitors once the basics are in place. Before you install one, check that it:

• makes no compliance promises. A product that says it makes your site "compliant", "EAA-ready" or "protected from lawsuits" is claiming something no widget can do;
• leaves the page alone until a visitor asks. Apart from its button, nothing should change for a visitor who never opens it;
• does not detect assistive technology or change how screen readers read your page;
• does not take over the keyboard on the rest of the page;
• sends nothing to outside servers and sets no tracking cookies. Otherwise you may need to name the vendor in your privacy notice;
• can be hidden by a visitor who does not want it.

We built Quicksloth Accessibility Toolbar for WordPress around that list: no account, no requests to other servers, no cookies, no detection of assistive technology, and visitors' choices stored only in their own browser. Besides its button, it adds a "Skip to content" link for keyboard users, which you can turn off. It is free and coming soon to the WordPress.org Plugin Directory; you can try it on our live demo page. It is still only a toolbar: it does none of the work in the section above.

Sources

All read on 13 October 2026.

• Directive (EU) 2019/882 (European Accessibility Act), EUR-Lex: Articles 2, 3(23), 4(5), 13, 30, 31 and 32, Annexes I and V.
• European Commission, European Accessibility Act: the services covered.
• National Disability Authority (Ireland), EN 301 549 V4.1.1 published: WCAG 2.2 baseline and the expected citation date. Deque expects it around 30 November 2026, so check the Official Journal.
• European Disability Forum and IAAP, joint statement on accessibility overlays (17 May 2023).
• Overlay Fact Sheet.
• W3C WAI, How to Change Text Size or Colors (updated 20 August 2025).
• Federal Register, accessiBe: analysis of proposed consent order (6 January 2025, FTC file 222-3156); the FTC approved the order in final form on 22 April 2025.

Found something out of date? Tell us at support@quicksloth.dev and we will correct this page.