Is an accessibility plugin enough to ensure your online shop complies with the EAA?

Accessibility widgets hold an attractive promise: one click and your shop is accessible. But is that really the case? A practical analysis for shop owners and e-commerce managers in 2026 

Illustration of an accessibility widget in an online shop — an analysis of whether the accessibility overlay meets the requirements of the European Accessibility Act (EAA) 2026
Blog 24.05.2026

In a nutshell

Situation: The
European Accessibility Act comes into force on 28 June 2025. Poland’s Act on Ensuring Accessibility for People with Special Needs also covers the private sector in certain cases. Online shop owners are looking for the cheapest solution — and many opt for an accessibility widget costing 80–120 PLN per month. 

Problem: The
widget can improve contrast, enlarge the font or add a text-to-speech reader — but it won’t fix the HTML structure, fill in alt text, correct PDF invoices or secure forms. For a medium-sized or larger shop, this isn’t enough. 

What really protects you: A
combination of three elements: a robust CMS with native accessibility support (TYPO3 CMS, dedicated templates), a technical audit (manual + automated) and continuous monitoring (e.g. EYE-ABLE Audit/Report). 

Who can make do with a widget: Small shops, low transaction volumes, no complex forms. A first step, not a silver bullet. 

Who it isn’t enough for: Medium and large shops, B2B transactions, invoices and confirmations in PDF format, multi-step shopping baskets, payment integrations (Tpay, Przelewy24, PayU). 

Installing an accessibility plugin is simple — and for online shop owners, it sounds like a dream come true: one tool, one widget, a few clicks, and you’re done. But if you really want your shop to be inclusive and compliant with the European Accessibility Act, you’ll soon realise that a single app won’t do the work of an entire team for you. 

This article offers an honest look at what the widget can do, where its limitations lie, and what you actually need to do to ensure your shop complies with the law and is usable for all customers. We’re not selling a one-size-fits-all solution here. We’re showing you the reality. 

What does the e-commerce platform support? And where does it end?

Regardless of which platform your shop runs on — Shoper, IdoSell, PrestaShop, WooCommerce, a shop built on TYPO3 with an e-commerce module, or even a solution like Shopify — the principle is the same. The platform controls its own part. You control the rest. 

Most modern e-commerce platforms in 2026 prioritise accessibility. Default templates usually feature semantic HTML, basic ARIA regions and support for keyboard navigation. The checkout page on most platforms is maintained in accordance with WCAG 2.1 AA – which is important, because it is precisely at the payment stage that accessibility errors are most costly. 

But this is where a key difference arises. Every modification you make, every application you add and every piece of content you upload falls outside the scope of what the platform can audit or maintain on your behalf. 

That is to say: 

• Template modifications — a colour scheme that does not meet contrast requirements, a modified menu that disrupts the keyboard focus order, and a product page that disrupts the screen reader’s flow. All of this happens at the customisation layer, and the platform won’t detect it. 

• Third-party applications — review tools, loyalty programmes, live chats, upsell pop-ups, delivery calculators. They inject code directly into your shop, and many of them aren’t designed with accessibility in mind. Some even break what was working correctly in the template. It’s still your shop and your legal responsibility. 

• Product content — the platform provides an alt text field. It does not fill it in for you. A shop with hundreds of products lacking alt text is not accessible, regardless of how clean the template’s code is. 

• Dynamic components — product image galleries, side-panel shopping baskets, quick-view modals, live stock updates, category filters. If implemented carelessly, these create keyboard traps and dead ends for screen readers. This is where problems most frequently arise during audits. 

• Invoices and confirmations in PDF format — every online shop in Poland sends customers invoices, order confirmations and dispatch information. For someone using a screen reader, an inaccessible PDF is a headache at best, and completely unreadable at worst. An accessibility widget on the shop’s website does not solve this problem. 

When a plugin steps in to help, it enters an already complex environment — one that may have gaps the widget simply cannot reach. 

Where accessibility plug-ins hit a brick wall

Who actually checks whether your shop is accessible? Who will notice if a template update has suddenly broken something, or if a new campaign page has gone live with images lacking alt text? 

WebAIM Million reports show just how common accessibility errors are: on average, several dozen detectable errors per homepage across a million websites tested. And let’s not forget — these are only the errors that a machine detects automatically. They don’t even cover what a real person experiences when trying to navigate your shop. 

For every error detected by a machine, there is often another hidden in the user experience that only a human can find — a blind person testing the shopping basket, or someone with a mobility impairment trying to fill in a delivery address form. 

There’s also something that’s often overlooked: most plugins rely on your website having a solid technical foundation. A widget that adjusts contrast or font sizes can only do its job if the underlying code is clean. If the HTML structure is a mess, assistive technologies — such as screen readers or keyboard navigation — will struggle regardless. You can polish the surface as much as you like, but what lies beneath determines whether it actually works. 

Legal requirements 2026 Why has the rate gone up?

The Polish Act on Ensuring Accessibility for People with Special Needs of 19 July 2019 and the Act on Digital Accessibility of 4 April 2019 set out obligations primarily for public bodies. However, for many online shops, the turning point came on 28 June 2025 — with the full entry into force of the European Accessibility Act (EAA). 

An overview of the 2026 legal requirements for digital accessibility — the Digital Accessibility Act and the EAA: obligations for online shops and public bodies

The EAA covers specific categories of products and services — including e-commerce. If you sell products or services to consumers in the EU, and you are a medium-sized or large business (with more than 10 employees or an annual turnover of more than €2 million), your website, mobile app and the entire purchasing journey must meet accessibility requirements. 

For many online retailers, this means that accessibility is no longer a ‘nice-to-have’ or a moral choice — it is a legal requirement. What’s more, it’s not enough for a shop to simply appear accessible. What matters is whether someone can actually complete a purchase — find a product, use filters, add it to their basket, fill in their address details, choose a payment method (Tpay, Przelewy24, PayU, BLIK), confirm the order and receive a clear confirmation. 

On top of that, you must be able to prove it. What barriers have been identified? What has been fixed? And what happens when a software update changes the rules of the game? A plugin won’t answer these questions. It’s a good first step, but it’s no substitute for a thorough technical audit, continuous monitoring or documentation that stands up to scrutiny.


Plugins will become increasingly sophisticated, but they will never replace the experience of a person with a disability navigating your website in real time. 

What larger shops really need

For a small shop just starting out, the plugin can be a decent starting point. But for medium-sized businesses and enterprise-level teams, there are simply too many touchpoints that the widget doesn’t cover. 

An often-overlooked example: order confirmations, VAT invoices and dispatch details sent as PDFs via email. A Polish shop issues hundreds, sometimes thousands, of invoices every month. For someone using a screen reader, an inaccessible PDF is a headache at best, and completely unreadable at worst. This is something the widget on the shop’s website simply isn’t designed for — it requires PDF/UA tags generated automatically by the system. 

The same applies to complex product filters, pages with multiple variants, product builders and forms that look clean on the surface but are a technical mess underneath. Accessibility doesn’t end at the product page. 

Comparison table of e-commerce solutions in terms of EAA compliance requirements — a summary of features for medium and large online shops

What larger teams really need is a bird’s-eye view:

Where are the current barriers? 

Which of these are critical to the customer journey? 

Who is responsible — an in-house employee or an agency? 

How can we prevent a new update from undoing all the work done so far? 

Any solution worth its salt must work in a busy, day-to-day environment — without every team member having to become a WCAG expert first. It should bridge the gap between automated testing and the real human experience. Because you’ll never really know whether your checkout works for a blind customer until someone actually tries to use it. 

What really protects your shop? three pillars

Our experience shows that reliable e-commerce accessibility in 2026 rests on three pillars. None of them is sufficient on its own. Together, they form a coherent system. 

The human element

It’s easy to get lost in the technical details, but behind every error lies a moment when someone got stuck. They got stuck trying to pay, got stuck reading an invoice, or got stuck simply trying to find a product. 

We work closely with people who navigate digital spaces every day whilst living with visual impairments. They know exactly where the friction lies. Seeing the internet through their eyes changes our perspective on what accessibility should and can be. 


In a few years’ time, accessibility will be just as much a given as mobile optimisation. Starting now isn’t about gaining ‘extra’ status — it’s about catching up with what will soon be the norm. 

  • Step 1
    A solid technical foundation

    It starts with a CMS and a template that natively support accessibility — semantic HTML, a correct heading hierarchy, ARIA regions, form labels, ‘focus visible’, and colour contrast compliant with WCAG 2.1 AA. In TYPO3, we achieve this using Fluid templates with dedicated accessibility components. For online shops on other platforms, we do this by customising the template with accessibility in mind from the outset, rather than as an afterthought.

  • Step 2
    Technical and manual audit

    Automated tools (Lighthouse, aXe, WAVE) detect around 30–40% of accessibility issues. The rest require manual testing — keyboard navigation, screen readers (NVDA for Windows, VoiceOver for macOS and iOS), and testing with people with various disabilities. A technical audit should cover the entire purchasing journey: the homepage, categories, product page, shopping basket, checkout, order confirmation, welcome email and PDF invoice. 

  • Step 3
    Continuous monitoring and a widget to assist

    This is where tools such as EYE-ABLE come in. Not as the sole solution, but as a complement. EYE-ABLE Assist is an accessibility widget that offers users over 25 settings (zoom, contrast, font, text-to-speech, focus highlight) — this is the first layer of support. EYE-ABLE Audit and Report monitor the website continuously: they automatically scan for changes, detect new errors, generate an accessibility statement and alert the team when compliance is lost. Together, these three elements provide what the widget alone cannot: control over the whole picture. 

The true cost of the plug

An accessibility widget costing 80–150 PLN a month sounds like a bargain. That works out at 960–1800 PLN a year. It seems like a sensible investment in legal compliance. But this equation often overlooks what happens when you really need to know where your shop stands. 

Suddenly, you need a proper audit. You realise there are structural issues that need fixing — which means developer time and agency costs. Your accessibility statement has to be maintained manually. And after every major update, the whole verification process starts all over again. 

On top of that, most plugins don’t offer any support. There’s no one to tell you what to prioritise and which barriers have the greatest impact on your customers. You know there are problems, but you’ve no idea where to start fixing them. 

Ultimately, you often find that you’re paying more than you expected — it’s just that not everything appears on a single invoice. 

Frequently Asked Questions

The EAA covers businesses engaged in e-commerce within the EU, excluding micro-enterprises (fewer than 10 employees and an annual turnover of less than €2 million). If you exceed both thresholds, you are covered. Micro-enterprises are exempt from some of the requirements, but are still subject to the general rules on non-discrimination. 

The widget on its own — no. The EAA requires that the consumer be able to complete the transaction — find a product, add it to their basket, pay, and receive confirmation. A widget improves the visual aspect, but it won’t fix an unclear payment process, inaccessible forms or PDF invoices. You need an audit, structural improvements and monitoring — a widget can be part of the puzzle, but not the whole picture.

The level of fines is determined by each Member State. In Poland, under the Accessibility Act, public bodies are liable to fines of up to 10,000 PLN. For the private sector, in the context of the EAA, the Polish legislator sets out the level of fines in the implementing regulations — it is worth keeping an eye on updates from the Ministry of Funds and Regional Policy.

Yes, if the shop has complex product logic, requires multilingual support, or needs to integrate with external systems. TYPO3 offers native support for semantic HTML, control over every template element, and full customisation in line with WCAG 2.1 AA. For simpler online shops, other platforms also work well — it’s the implementation that matters, not the platform itself. 

No, but it is a valuable part of the solution. EYE-ABLE Assist gives the user the ability to customise the interface instantly (contrast, font, screen reader). EYE-ABLE Audit and Report complement this with continuous monitoring and the generation of accessibility statements. Together, they provide robust support — but they still require a solid technical foundation, which must be provided by the development team.

Starting with an assessment of the current situation. A manual and automated audit reveals where the barriers lie, which ones are critical, and what the most logical next step is. Without this assessment, any investment is a shot in the dark. With it, you can work methodically, prioritising what has the greatest impact on the customer. 

A plug-in or a reliable solution? Verdict

A plugin can be a sensible starting point — it’s a visible first step and sends a positive signal to customers. But anyone who takes long-term accessibility seriously will sooner or later learn that the widget itself isn’t the end goal. It’s not that the tools are bad — it’s because accessibility is a journey that must evolve alongside the growth and changes of your shop. 

The honest first step is often the hardest: determining exactly where you are right now. What are the actual barriers? Which of them are critical? And what is the most logical next move? 

Let’s take a look together at what stage your shop is at — this is the first step towards genuine EAA compliance that will stand up to scrutiny and act as a support rather than a burden. 

Telephone: 12 333 44 01. Email: [email protected].

About the author
Krzysztof Napora
Krzysztof Napora
Krzysztof Napora