The European Accessibility Act and the widgets on your site
Since 28 June 2025 the widget somebody else wrote is your accessibility problem.
Last updated
What changed
Directive (EU) 2019/882 — the European Accessibility Act — had to be applied by Member States from 28 June 2025. It covers e-commerce among other services, and it is written about the service a customer meets rather than about the code behind it. The harmonised standard for the web half of that is EN 301 549, which takes its web content requirements from WCAG 2.1 level AA. So the practical question stopped being whether your site is accessible and became whether everything on your page is.
Why the widget is yours and not its vendor's
A visitor does not know which part of your page came from where. They meet one page, and the obligation attaches to the service you are offering on it. A chat bubble, a cookie bar, a sign-up box and a review carousel are four suppliers' code and one liability, and it is yours. That is uncomfortable and it is also the only reading that makes sense: nobody can be expected to audit a page by asking each vendor whose fault a keyboard trap is.
What you can actually evidence
The awkward part of answering a questionnaire is not the claim, it is the proof. Most widget vendors can tell you their product is accessible. Very few can tell you that this widget — the one you configured on Tuesday, in your colours, with your fields — was checked, because their check was run against the product and yours is a configuration of it. Kestero runs axe-core 4.10 against each widget's exact specification, in both colour schemes, inside the real shadow root the visitor will meet. The tag set is wcag2a, wcag2aa, wcag21a and wcag21aa, which adds up to WCAG 2.1 AA, and the result is kept with the date it ran on.
Why the record expires by itself
A result is stored against a fingerprint of the widget it ran on, and the record is rebuilt from scratch every time the widget is saved. If the fingerprint on the stored result no longer matches what is being written, the result is discarded rather than carried forward — so changing a colour, adding a field or rewording a button returns that widget to unchecked. Nobody decides this and nobody can forget to do it. It matters because the failure worth designing against is not an inaccurate badge, it is an accurate one from March still being shown in November against a widget that has changed four times since. A widget nobody has checked reads as unchecked and never as passed, and the record leaves with the widget through the same public endpoint your page already calls, so what a reviewer reads is what your site is serving rather than what a sales deck says.
What we do not claim
This is our reading, not legal advice. We are not your lawyers, the Act is applied by Member States and enforced nationally, and whether any of it applies to you depends on what you sell and where. Nor is an automated check a clean bill of health: axe finds a subset of failures, and no automated tool decides whether your alt text is honest or your reading order makes sense. What we will say is narrower and checkable — the check runs per widget, against that widget, and the result is dated.
What this is evidence from
- Directive (EU) 2019/882 (European Accessibility Act), from
- the date Member States had to apply the measures from
app/builder/lib/a11y.ts- the axe-core tag set the check actually runs, which is what the standard named above is short for
- WCAG 2.1 AA
- the standard that tag set adds up to, taken from the tags rather than from a claim
- 4.10 (axe-core)
- the version installed, read out of package.json by a test rather than written down here
lib/schemas/widget-guarantee.ts- the record, the fingerprint a stored check has to match, and the line that discards a check run before the last edit
tests/embed-widgets-guarantee.test.ts- that the record is served from the public endpoint a customer's page reads, so it reaches whoever is looking rather than staying in a dashboard