The EAA and third-party content: who is responsible?

Under the European Accessibility Act, third-party content is exempt only when it is "neither funded, developed by, or under the control of" the business providing the service. That is the wording of Article 2(4)(d) of Directive (EU) 2019/882. In practice the exemption is narrow. It fits content other people add to your pages without you choosing it: user comments, reviews, forum posts, dynamically inserted ads. It does not fit the components you picked, pay for and embed on purpose, like a payment form, a login provider, a chat widget or a booking engine. Those are part of the service you provide, and the directive says plainly that subcontracting part of a service does not reduce its accessibility obligations (recital 20). So the short answer to "who is responsible for EAA third-party content?" is: you are, for anything you chose to put in the user's path. The vendor may have to fix it. You're the one a market surveillance authority will ask about it. This post walks through the exact text, where the line sits for common embeds, and how to describe the parts you can't fully fix in your accessibility statement.

What does the EAA actually say about third-party content?

Article 2(4) lists five kinds of website and app content the directive does not apply to. Point (d) is the one this post is about: "third-party content that is neither funded, developed by, or under the control of, the economic operator concerned" (Directive (EU) 2019/882, Art. 2(4)).

Read the conditions carefully. The content has to be third-party, and it has to fail every one of the tests: you didn't pay for it, you didn't build it, and you don't control it. If any one of those is true, the exemption doesn't apply.

The EAA doesn't define "control" anywhere in its Article 3 definitions. The closest official text is in the older Web Accessibility Directive, which uses almost identical wording for public-sector sites. Its recital 30 names what lawmakers had in mind: comments on an article, user-contributed content, portals that aggregate content from many contributors, and sites where advertisements are inserted dynamically. The same recital says "embedded content, such as embedded images or videos, should be covered" (Directive (EU) 2016/2102, recital 30). That directive governs public bodies, not your shop, but it's the best signal of what the same phrase was meant to mean.

Can you hand the responsibility to your vendor?

No. The EAA puts the obligation on the service provider, which Article 3 defines as whoever "provides a service on the Union market or makes offers to provide such a service to consumers in the Union". Article 13(1) then says service providers "shall ensure that they design and provide services in accordance with the accessibility requirements" (Directive (EU) 2019/882).

Recital 20 closes the obvious loophole: "Even if a service, or part of a service, is subcontracted to a third party, the accessibility of that service should not be compromised and the service providers should comply with the obligations of this Directive" (Directive (EU) 2019/882, recital 20).

Your contract with the vendor is still worth writing well. You can require them to meet EN 301 549 (the harmonised standard, whose web clauses map to WCAG), to supply an accessibility conformance report, and to fix reported defects within a set time. That shifts the cost of the fix. It doesn't shift who answers to the regulator.

Which third-party components does the EAA single out?

For e-commerce, the directive names the parts most often supplied by someone else. Annex I, Section IV(g) requires online shops to make accessible "the functionality for identification, security and payment when delivered as part of a service", and to provide "identification methods, electronic signatures, and payment services which are perceivable, operable, understandable and robust" (Directive (EU) 2019/882, Annex I).

Almost nobody builds those in-house. The card form is a payment provider's iframe. The 3-D Secure challenge comes from the card issuer. Login might be a single sign-on button, and the CAPTCHA is someone else's script. The directive names them anyway, which tells you how it expects the "control" question to go for checkout.

WCAG points the same way. Section 5.2.3 on complete processes uses an online store as its example: every page from product selection to checkout must conform, or none of the process does (W3C WCAG 2.2, 5.2.3). An inaccessible payment step breaks the whole purchase flow, whoever wrote its code. We covered where those checkouts usually fail in checkout accessibility under the EAA.

Here's how I'd sort the usual suspects. It's a reading of the text, not legal advice, and a national authority could see an edge case differently.

What about user comments, reviews and ads?

This is where the exemption does its job. If a customer writes a review, you didn't fund it, develop it or control what it says. The same goes for a forum reply or an ad a network rotates in without your say.

Keep the container separate from the contents, though. The review text may be exempt. The review form, the rating widget, the "load more" button and the sort control are yours. So are product descriptions a marketplace seller uploads, to a point: Annex I, Section IV(g)(i) requires e-commerce services to pass on accessibility information about products "when this information is provided by the responsible economic operator". A marketplace doesn't write that information, but the text reads as a duty to pass it on when the seller supplies it.

WCAG has a mechanism for exactly this situation. Section 5.4 allows a "statement of partial conformance" for pages with uncontrolled content, worded as: "This page does not conform, but would conform to WCAG 2.2 at level X if the following parts from uncontrolled sources were removed." The alternative is to monitor the page and repair or remove non-conforming contributed content "within two business days" (W3C WCAG 2.2, 5.4). A daily moderation queue that checks new images for alt text is a reasonable way to live inside the second option.

How should third-party content appear in your accessibility statement?

Honestly, and by name. Article 13(2) requires service providers to explain "how the services meet the applicable accessibility requirements", following Annex V, and to keep that information available for as long as the service runs (Directive (EU) 2019/882, Art. 13).

For a third-party component that isn't fully accessible yet, a useful entry says what the component is, what fails, what you've done about it and what the user can do instead. For example: "The live chat widget is supplied by an external vendor. Its message field has no accessible name, so screen reader users may not know where to type. We have reported this to the vendor. Until it is fixed, you can reach the same support team by email or phone." That's specific enough to act on and honest about who owns the fix.

Don't list your payment step as "third-party content, not our responsibility". Given recital 20 and Annex I, Section IV(g), that line won't hold up, and it tells a reviewer you haven't read the directive. Our accessibility statement guide covers the full structure, and the statement generator gives you a starting draft to edit.

How do you check embeds you didn't build?

Start with a scan of the rendered page, not the source. Widgets load through JavaScript, so a check of your templates won't see them. Our free scan runs axe-core in a real browser after the page settles, and for issues inside an embedded iframe it reports the selector path through each frame. That makes it clear which findings live in the payment provider's code and which live in yours.

A scan only gets you part of the way. Deque's analysis of more than 2,000 audits found automated testing identified about 57% of issues by volume, and counting by WCAG success criteria gives a figure closer to 30% (Deque). A scanner can tell you a card-number field has no label. It can't tell you whether the 3-D Secure popup traps keyboard focus or whether a screen reader announces the "payment failed" message. For that you need a person with a keyboard and a screen reader going through the actual flow, which our WCAG checklist walks through.

Then ask the vendor for an accessibility conformance report, usually in VPAT format (what a VPAT is). If they don't have one and can't tell you how the widget behaves with a keyboard, you've learned something. My view: when a vendor can't answer that question, swap the widget. It costs less than spending the next year explaining in your statement why part of your checkout doesn't work.

Frequently asked questions

Is third-party content exempt from the EAA?

Only third-party content that is neither funded, developed by, nor under the control of the business providing the service, per Article 2(4)(d). User comments, reviews and dynamically inserted ads usually fit. Widgets and services you chose and embedded, such as payment, login or chat, generally do not.

Am I responsible for my payment provider's accessibility under the EAA?

Yes, as far as the regulator is concerned. Annex I, Section IV(g) names identification, security and payment functionality in e-commerce, and recital 20 says subcontracting part of a service doesn't reduce the provider's obligations. Your contract can require the vendor to fix defects, but the obligation stays with you.

Does the EAA cover embedded YouTube or Vimeo videos?

Usually yes, when they are your videos. You chose to publish them and you control whether they have captions. The Web Accessibility Directive's recital 30, which uses the same third-party wording, says embedded images and videos "should be covered".

How do I mention third-party content in my accessibility statement?

Name the component, describe what doesn't work, say what you've done about it and give users an alternative route. Don't use the third-party label to excuse parts of your core service, such as checkout.

Can a scanner find accessibility issues in third-party widgets?

Partly. A browser-based scan finds machine-detectable issues in rendered widgets, including inside iframes, but automated testing catches roughly 30–57% of issues depending on how you count. Keyboard and screen reader testing of the full flow is still needed.

See what your embeds look like to an auditor

If you're not sure which parts of your checkout or support flow belong to a vendor, a scan shows you quickly. Run a free scan on your product, cart and contact pages, check which findings sit inside third-party frames, and take the list to your vendors. Then write it up honestly in your statement.

Pavel Charkasau, founder, wcagc.com. Last updated 28 September 2026.

Sources

• Directive (EU) 2019/882 (European Accessibility Act), enacting terms, legislation.gov.uk — Art. 2(4)(d) third-party content exemption, Art. 3 definitions of "service provider" and "economic operator", Art. 13 obligations of service providers. Accessed 28 September 2026.
• Directive (EU) 2019/882, recitals, legislation.gov.uk — recital 20 on subcontracted services. Accessed 28 September 2026.
• Directive (EU) 2019/882, Annex I, legislation.gov.uk — Section IV(g) e-commerce requirements for identification, security and payment, and product accessibility information. Accessed 28 September 2026.
• Directive (EU) 2019/882 (official text), EUR-Lex — authoritative source for the above. Accessed 28 September 2026.
• Directive (EU) 2016/2102 (Web Accessibility Directive), recitals, legislation.gov.uk — recital 30 examples of third-party content and embedded content. Accessed 28 September 2026.
• Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation, 12 December 2024 — 5.2.3 complete processes, 5.4 statement of partial conformance for third-party content. Accessed 28 September 2026.
• Automated testing identifies 57% of accessibility issues, Deque — automated coverage figures. Accessed 28 September 2026.