Accessibility
European Accessibility Act: why a widget won't save your site and what you really need
The European Accessibility Act now applies throughout the EU. Why paid accessibility widgets don't solve compliance and what you really need. Oksigenia Access: a FOSS panel with no tracking, in three channels (WP, npm, Moodle).
Published 4 min read
The European Accessibility Act (Directive 2019/882) has applied throughout the European Union since 28 June 2025. If you have an online shop, an e-learning platform, a mobile app or a digital banking service, it affects you. In Spain, it was transposed through Real Decreto-ley 6/2023 and Ley 11/2023, which extend the obligations of the former RD 1112/2018 to the private sector for companies with a turnover above 2 million euros or more than ten employees.
This has given rise to a very specific commercial trend: dozens of companies selling “accessibility widgets” with the implicit promise that pasting a script into the <head> makes the site compliant. It doesn't work like that. And European and US courts have been pointing this out for years.
1. What the EAA actually requires
The directive does not ask for a floating button. It requires digital content to be perceivable, operable, understandable and robust according to WCAG 2.2 level AA. That means:
- Images whose
altdescribes information, not decoration. - Correct hierarchical headings (
<h1>,<h2>,<h3>) that reflect the real structure. - Sufficient contrast between text and background.
- Forms labelled with
<label>and clear error messages. - Compatibility with screen readers (NVDA, JAWS, VoiceOver).
- Full keyboard navigation.
- Videos with subtitles and, where appropriate, audio description.
No external script can fix that after the fact. If an h1 is really a <div class="titulo-grande"> with font-size: 32px, no widget is going to turn it into a heading for a screen reader. Structural accessibility is editorial work.
2. Why commercial widgets are problematic
accessiBe, UserWay and the like sell for between 49 and 490 euros a month, depending on traffic. In return, they offer a panel with settings (text size, high contrast, dyslexia mode, etc.) and a supposed “AI engine” that rewrites the DOM in real time.
Three specific problems:
They come loaded with covert compliance advertising. In 2023 the US Federal Trade Commission challenged accessiBe over misleading claims: it promised automatic WCAG conformance that was not real. In 2021 the National Federation of the Blind issued a resolution advising against these products. In the EU, specialist bodies have been repeating for years that an overlay is not the same as compliance.
It is traffic to a third party. These scripts are loaded from the vendor's own servers, with cookies and telemetry. If the reason you are complying with the EAA is that you care about your visitors with disabilities having a good experience, it hardly seems consistent for the first resource you send them to to be a tracker.
It is perpetual rental. The day you stop paying, the panel disappears. Your site goes back to square one.
3. The alternative: Oksigenia Access
We have released Oksigenia Access, an accessibility panel with 17 controls (text, dyslexia, contrast, colour blindness, reading guide and reading mask, large clickable areas, animation pause, visible focus…) and 4 preset profiles that group the usual settings for low vision, dyslexia, motor difficulties and reducing distractions. Translated into 8 languages, including Guarani. No dependencies, no cookies, no pings to third parties. Open source.
Three installation channels, depending on where your site lives:
- WordPress: the
oksigenia-accessplugin (GPLv2+), installable from the official WordPress.org repository. - Any modern stack (Astro, React, Vue, Svelte, plain HTML): the npm package
@oksigenia/access-panel(MIT). 37 KB. Zero dependencies. - Moodle 4.5 LTS or later: the
local_oksigeniaaccessplugin, downloadable from the repository releases.
The panel is the same in all three cases. All of the project's open source code lives in the OksigeniaSL organisation on GitHub.
4. What the panel does not do (and what we do offer separately)
To be clear, in line with what we said in point 1: this panel helps people with specific needs while they browse your site, but it does not audit your content or give you a certificate of conformance. If your organisation falls within the scope of the EAA and needs to demonstrate compliance, what has to be done is a structural review of your real pages against WCAG 2.2.
We offer a technical assessment as a one-off product: automated checks (axe-core, Lighthouse, WAVE) on your pages + manual review of the typical issues + a technical report with prioritised findings and an actionable remediation plan. The service covers the operational technical side: detecting, prioritising and remediating. Formal accreditation before the inspection authority under EAA 2025 or RD 1112/2018 is handled separately with ENAC-accredited bodies.
5. How to get started
If you run a WordPress site, install the plugin and forget about it. If you build with Astro or React, pnpm add @oksigenia/access-panel and an <oksigenia-access-panel> in your layout. If you run Moodle, download the ZIP from the repository release and install it as a local plugin.
If what you need is the technical assessment, or you would like to sponsor the project's development (universities, city councils, EU companies), you will find all the details at sponsor.oksigenia.com.
The EAA is already applicable law. Better to have your site in order than to rely on a script nobody has audited.
