Insights · Trend · Accessibility

An accessibility widget is just the start. How to approach WCAG compliance?

The EAA directive forces companies to adapt their websites quickly, and external overlays seem like the easiest fix. While they improve comfort for many users, they aren't a magic button for all code errors. Here is what's changing and what you can do better.

An accessibility widget is just the start. How to approach WCAG compliance?

What's changing right now

The market is moving away from ignoring digital barriers toward rapid implementations (Quick Fixes). Companies are installing widgets en masse to avoid legal risks, yet regulators are increasingly checking the actual source code accessibility, not just visual overlays.

What's changing right now

What you can do better

Concretely, starting today

  • Treat the widget as a UX enhancement (contrast, scaling), not as a full 'check-the-box' for WCAG.
  • Ensure proper heading structure (H1-H6) – no widget can fix this automatically.
  • Check if your site is navigable by keyboard alone (Tab key) before adding an overlay.
  • Add alternative texts to images in your CMS – it's a foundation for screen reader accessibility.

Proof from our work

We built such a widget for ourselves and released it for free — one file, 14 kB, no dependencies. Download and host it yourself, or attach it with a single tag; it runs on any engine, being an ordinary script. It offers contrast, text scaling, a readable typeface, link highlighting, a large cursor and paused animations, in Polish and English. We keep it switched on across all of dtl.pl — the very page you are reading. Which is precisely why we know where its limits are: none of those features will fix heading structure, keyboard navigation or missing image descriptions. A widget serves comfort of reading, not quality of code — it is a first step and that is the only way we describe it.

Proof from our work

Frequently asked questions

Is a widget enough to satisfy EAA requirements?

No, a widget is a supporting tool. Full compliance requires proper HTML semantics and content accessibility, which a script cannot fully generate on its own.

How do I install an accessibility widget on WordPress?

The same way as on any other engine — it is a plain script, not a plugin. Paste one line before the closing body tag: <script src="https://dtl.pl/a11y.js" defer></script>. On WordPress do it through a child theme’s footer.php or any plugin that injects code into the footer. We do recommend downloading the file and hosting it yourself, so your site does not depend on someone else’s server. Appearance is set with the data-lang, data-position and data-accent attributes. Our widget is free, and the guide covering both installation paths sits on the tool page.

Need an accessibility audit?

Contact us to verify if your site actually meets EAA and WCAG requirements, or download our free widget.