In short and in plain language
This is about third party tools on your website. These are things like calendars, chats or payment windows.
The code comes from another company. But the BFSG duty stays with you. This applies to tools that are part of your service. A plain link does not count.
Ask the vendor for a report on accessibility. Also check the tools yourself, and do it often. The code can change without you doing anything.
If the vendor does not deliver, offer another way to reach the goal. Or replace the tool.
We keep an eye on these tools for you.
A booking calendar, a chat window, review stars, a map module, a payment iframe, an embedded job board and, in front of everything else, the consent banner: the very components that carry visitors closest to a purchase, an appointment or an application often do not come from your own repository. For the BFSG, that changes little about attribution. The duty sits with the service provider, and it covers the service as users experience it (BFSG, Section 14). How justified the focus on third-party code is becomes clear from an analysis of one million home pages in February 2026: 95.9 percent (WebAIM Million 2026, Utah State University) of them showed automatically detectable WCAG failures, and pages with embedded reCAPTCHA carried 7.7 more errors (WebAIM Million 2026) than average.
Key takeaways
- The duty sits with the service provider for the service as the user experiences it (BFSG, Section 14; BFSGV, Section 12 no. 3). The law grants no exception for supplied components; contracts shift the commercial risk only.
- A link to someone else's site creates no testing duty. Once a component becomes a step in your own booking, ordering or application flow, such as a calendar, chat, payment iframe or consent banner, it belongs to your service.
- Recurring failure points: calendars that ignore arrow keys, chat buttons without an accessible name, payment iframes without a frame title. The most frequent detected issue remains low text contrast on 83.9 percent of home pages (WebAIM Million 2026).
- Useful evidence is an Accessibility Conformance Report based on VPAT 2.5Rev of April 2025 (Information Technology Industry Council), naming product version, test date, method and standard version; EN 301 549 maps WCAG 2.1 AA in version V3.2.1 and WCAG 2.2 AA in version V4.1.1 of September 2026.
- A vendor report describes the shipped state, your own check describes reality: keyboard entry and exit, frame titles and status messages on the revenue-critical paths, repeated quarterly because embedded scripts change without your release.
- If the vendor does not deliver, the options are a visible accessible alternative route, wrapping the component in your own document, or replacing it; the disproportionate burden clause of Section 17 BFSG does not cover a procurement problem.
Attribution: third-party code, your own service
The starting point is unspectacular and therefore easy to overlook. Section 14 BFSG obliges the service provider to design services so that they meet the accessibility requirements of the implementing ordinance, to maintain those requirements throughout provision, to publish the information required by Annex 3, to report non-conformities to market surveillance and to provide information on justified request (BFSG, Section 14). The addressee is the provider of the service, not the supplier of a single component.
The ordinance gets specific. For services to be provided accessibly, websites including their associated online applications and services offered on mobile devices including mobile applications must be designed in a consistent and adequate way that is perceivable, operable, understandable and robust (BFSGV, Section 12 no. 3). The provision contains no exemption for parts supplied by third parties. The same rule also requires that the products used to provide the service meet the applicable requirements themselves (BFSGV, Section 12 no. 1). The logic is simple: whatever you deploy is attributed to you.
What the law does not provide for
For online shops and booking flows the picture is sharper still. For services in electronic commerce the ordinance explicitly requires that identification methods, electronic signatures and security and payment services be perceivable, operable, understandable and robust (BFSGV, Section 19). In practice these functions often run through third-party components, usually as a payment provider iframe or an embedded authentication window. What that means at the point of purchase is described in our article on the accessible checkout; the wider shop requirements are summarised on the page about accessible e-commerce.
Linked or embedded: where attribution ends
Not every piece of third-party content belongs to your service. The workable dividing line does not run between your code and someone else's, but between reference and embedding: does the component become a step in your own ordering, booking, application or contact process, or does the user leave your service and enter a separate offering with its own set of duties? A link to another company's website creates no testing duty for that company's design. A calendar without which no appointment happens, by contrast, is part of the service you offer yourself.
| Scenario | Part of your own service? | Classification |
|---|---|---|
| Text link to another company's offering | not included | Separate service with its own duties |
| Booking calendar as an iframe in your appointment flow | included | Operating step within your service |
| Chat window as a support channel | included | Support service (BFSGV, Section 12 no. 4) |
| Payment iframe at checkout | included | Payment service (BFSGV, Section 19) |
| Redirect to the payment provider's portal | Partly | Handover, return path and status remain attributable |
| Consent banner in front of the first content | included | Upstream operating step of your own page |
| Embedded job board with application form | included | Form flow within your service |
| Review stars pulled from an external portal | included | Displayed content on your own page |
The borderline case is the redirect. Anyone sending users to an external domain for payment or identification gives up control of the design there, but retains the transition: announcing the change of context, returning into the original process and reporting success or cancellation. Settled case law on the reach of attribution does not yet exist. The cautious reading treats a functionally mandatory redirect as part of your own flow and documents the vendor selection decision accordingly.
The consent banner comes before everything else
Where embedded components break
The failure patterns repeat across vendors and industries because they follow from the same construction principle: a widget is built to be embedded in arbitrary pages, it brings its own markup, its own focus logic and its own colours, and whether it was tested with assistive technology cannot be seen from the outside. Six patterns are typical.
Booking calendar
The date grid responds to clicks but not to arrow keys, and focus jumps back to the top of the page when the month changes. This affects keyboard operability (W3C, WCAG 2.2, 2.1.1) and often the minimum target size of 24 by 24 CSS pixels as well (W3C, WCAG 2.2, 2.5.8).
Chat window
The launcher is a graphic without an accessible name, incoming messages are not announced, and focus does not move into the dialogue when it opens. The relevant criteria are name, role and value (W3C, WCAG 2.2, 4.1.2) and status messages (W3C, WCAG 2.2, 4.1.3).
Review stars
The rating exists only in five graphics or in a CSS width value. Without a text alternative it stays unknown to screen reader users (W3C, WCAG 2.2, 1.1.1). Interactive stars for submitting a rating frequently cannot be reached by keyboard at all.
Map module
The interactive map traps keyboard focus inside its canvas, zoom controls carry no names, and a text alternative with address and directions is missing. What was meant as orientation becomes a dead end in the middle of the contact area.
Payment iframe
The frame has no meaningful title, card number errors appear only inside the iframe, and in some cases focus cannot be moved back out. The requirement for payment services is explicit (BFSGV, Section 19).
Job board
Multi-step application forms without associated labels, required-field errors without a link to the field, and a file upload that works by dragging only. The latter calls for an alternative without a dragging movement (W3C, WCAG 2.2, 2.5.7).
The distribution of detected failures fits these patterns. Across one million home pages the most frequent issues were low contrast text at 83.9 percent (WebAIM Million 2026), missing alternative text at 53.1 percent, missing form input labels at 51 percent and empty links at 46.3 percent (WebAIM Million 2026, Utah State University). Empty buttons, a typical widget pattern of icon graphics without labels, reached 30.6 percent (WebAIM Million 2026, Utah State University).
Absence of detected errors does not indicate that a page is accessible or conformant.
The correlation between added technology and error counts is measurable too. Pages using ARIA averaged 59.1 errors, pages without ARIA 42 errors (WebAIM Million 2026, Utah State University); on average 133 ARIA attributes were counted per home page, an increase of 27 percent year on year (WebAIM Million 2026, Utah State University). Widgets ship exactly these attributes, often combining generic roles with missing names. The CAPTCHA service reCAPTCHA appeared on 9.6 percent (WebAIM Million 2026) of home pages, embedded YouTube videos on 6.2 percent; pages with YouTube videos had 9.4 more errors than average (WebAIM Million 2026, Utah State University). For conversational components it is worth reading the requirements for accessible chatbots and voice interfaces as well.
Step 1: the widget inventory
Before anything can be tested, you need to know what is embedded. In practice this often fails because components are loaded through a tag container, because marketing and HR commissioned their own embeds, and because campaign pages carry scripts that do not appear in the main template. A reliable inventory draws on three sources: the source code of the main page types, the list of third-party domains in the browser network log, and the contracts held by procurement.
- Component and purpose in one sentence, so the business case remains assessable later.
- Embedding method: script in the head, iframe, web component, tag container or server-side include.
- Position in the user path: ahead of content, inside the ordering or booking flow, within a form, in the footer.
- Internal owner by name, not by department code.
- Contract reference: contract number, term, notice period, vendor contact.
- Evidence status: is there an Accessibility Conformance Report, with which date and which standard version?
- Own test status: date of the last keyboard and screen reader pass, blockers found, status.
- Replacement strategy: accessible alternative route, encapsulation or replacement, with a rough effort estimate.
The blind spot: tag containers
Step 2: evidence instead of assurances
The statement "our widget is accessible" is not evidence. What helps is an Accessibility Conformance Report, meaning a completed report based on the current VPAT template. The template is maintained by the Information Technology Industry Council; the current edition VPAT 2.5Rev dates from April 2025 and comes in four editions covering Section 508, the EU standard, WCAG and a combined international edition (Information Technology Industry Council). The WCAG and international editions incorporate WCAG 2.2, while the EU edition refers to EN 301 549 (Information Technology Industry Council). For buyers in Germany, the EU or international edition is therefore the right thing to ask for.
- Product name and version of the component tested, not just the company name.
- Test date and a statement on whether testing was manual, automated or combined.
- Test environment: browser, operating system and assistive technology with version numbers.
- Assessment per criterion as Supports, Partially Supports, Does Not Support or Not Applicable, each with remarks.
- Named standard version including the conformance level, for example WCAG 2.2 Level AA.
- Contact person for follow-up questions and a note on when the report is refreshed.
Watch the standard version
Three answers should raise an eyebrow. First, a reference to an accessibility overlay instead of a test report; why that does not amount to compliance is explained in our article on accessibility overlays. Second, a report without a date or version number, often years older than the script actually deployed. Third, the phrase that a product is "WCAG compliant" without a version and without a level. Anyone who asks in writing and files the answer holds something useful even when the vendor delivers nothing: documented effort.
Step 3: your own counter-check
A vendor report describes the product as shipped. On your site it runs in a particular configuration, with a particular colour scheme, in a particular language, often overridden by your own CSS and embedded in a process the vendor knows nothing about. The report therefore does not replace your own testing, it narrows it down. Testing happens where the component actually sits, along the paths that produce revenue, appointments or applications.
- Complete keyboard path: entry into the component, full operation, orderly exit without a trap (W3C, WCAG 2.2, 2.1.1 and 2.1.2).
- Focus visible and free: focus indicator perceivable and not obscured by sticky bars or banners (W3C, WCAG 2.2, 2.4.7 and 2.4.11).
- Frames named: every iframe carries a title describing its purpose, not the vendor's brand name.
- Screen reader pass: role, name and state of every control are announced (W3C, WCAG 2.2, 4.1.2).
- Dynamics announced: new messages, loading states and errors are conveyed as status messages (W3C, WCAG 2.2, 4.1.3).
- Time limits: session and payment windows can be extended or are announced in advance (W3C, WCAG 2.2, 2.2.1).
- Contrast in the widget theme: text and controls reach the required ratios, in dark mode as well.
- Magnification: at 200 percent zoom and 320 CSS pixels width the component stays operable without forcing horizontal scrolling.
- Without a pointing device: dragging movements have an alternative and targets are large enough (W3C, WCAG 2.2, 2.5.7 and 2.5.8).
The effort stays manageable when testing is limited to the critical paths. A structured screen reader test of the core flows narrows down the findings, and a full WCAG audit then produces the clause-by-clause documentation for the file. What matters is the separation in the findings: which deviation sits in your own code, which in the embedded component, and which only arises from the interaction of both? Only the third category can be solved neither by the vendor alone nor in house alone.
Not every deviation weighs the same
Step 4: contracts and procurement
The strongest lever sits before the embed. Raise accessibility only after rollout and you negotiate without leverage; write it into the specification and you either get a suitable product or an early refusal. Seven points belong in procurement documents and contracts.
- Assurance with a reference point: conformance with a named standard version and level, for example EN 301 549 in its harmonised version, alternatively WCAG 2.2 Level AA.
- Evidence obligation: an Accessibility Conformance Report on signing and again after every major version jump.
- Remediation deadlines by severity: a short deadline for blockers in the critical path, a longer one for minor defects, each starting from written notification.
- Notification duty: changes to markup, interaction logic or focus behaviour are announced in advance rather than rolled out silently.
- Cooperation with authorities: supply of the information needed so that the duty to inform market surveillance can be met (BFSG, Section 14(5)).
- Test access: access to a staging environment so new versions can be checked before going live.
- Legal consequences: price reduction, extraordinary termination or substitute performance if remediation fails to materialise.
Procurement beats remediation
Public bodies face tighter rules anyway; the structure of accessibility requirements in tenders is described in our article on accessibility in public procurement. It is worth a look for companies too, because the wording used there works well as a template. Anyone distributing digital content in several formats meets the same evidence logic with accessible EPUB e-books: whoever distributes is answerable for what is distributed.
When the vendor does not deliver
Besides refusal there is delay: the vendor confirms the finding, points to the roadmap and names no date. For both situations you need a response that does not depend on their agreement. Three routes are available, and they are not mutually exclusive.
Accessible alternative route
Offer the same function through a second, tested path: a call-back request instead of the calendar widget, an accessible contact form instead of chat, an address with written directions instead of the map. The alternative belongs visibly next to the component, not in a footnote, and it has to lead to the same outcome.
Encapsulate
Whatever sits in your own document can be improved: set iframe titles, manage focus before and after the component, add headings and labels, correct contrast through your own style rules. The limit is clear: content inside a cross-origin iframe cannot be modified from outside.
Replace
For blockers in the critical path, replacement is often the shorter route. An appointment picker or a rating display is manageable as an in-house component, and effort and risk drop when requirements feed into accessible web development from the start.
No way out through the burden clause
An alternative route is a defensible interim state, not a target state. It keeps access open while remediation runs, and it belongs in the documentation with a date and a planned end. What it cannot deliver is equivalent participation in the same interface. Making the interim state permanent shifts the effort onto exactly the group of users the law is meant to relieve.
Operational risk: silent updates
The difference between your own code and someone else's shows most clearly in operations. Your own code changes with a release that is planned, tested and logged. An embedded script changes when the vendor ships it, which may be tonight. Accessibility in a booking flow can therefore regress without a single line changing in house and without anyone finding out.
The trend works against operators. The average home page recently contained 1,437 elements, an increase of 14.3 percent within a year, and the number of detected errors rose to 56.1 per page, up 10.1 percent year on year (WebAIM Million 2026, Utah State University). More embedded technology means more movement in the markup and therefore more opportunities for regressions. A one-off audit before the deadline describes a state that can be outdated a few weeks later.
- Quarterly sampling across all components in the critical path, with a fixed checklist and a documented result.
- Event-driven checks after every detectable vendor update, after theme changes and after modifications to the tag container.
- Automated regression checks of the core flows as part of the delivery pipeline, complemented by a manual keyboard pass.
- Change log per component: detected version, date, finding, notification to the vendor, deadline set.
- Escalation template for vendor conversations covering finding, criterion reference, user impact and deadline.
- Updating the statement as soon as a known limitation appears or disappears.
This documentation has two audiences. The first is your own accessibility statement, which names known limitations openly together with the alternative route and the planned timeframe; how the accompanying feedback channel should be built is described in our article on the feedback mechanism. The second is market surveillance. For services, authorities carry out sample checks to an appropriate extent even without a specific trigger (BFSG, Section 28); the federal states have set up the market surveillance body for the accessibility of products and services (MLBF) in Magdeburg for this purpose, which according to its own statement began its nationwide work in September 2025 (MLBF). If a non-conformity persists after a formal request, the scale runs from a renewed request through prohibition to fines of up to 100,000 euros for offering or providing a non-conforming service; other breaches, such as failing to provide requested information, can be fined up to 10,000 euros (BFSG, Section 37). The available enforcement routes are set out in our article on enforcement and legal risks.
What belongs in the file
How we bring third-party components into documented shape
We start with the inventory, because it sorts the discussion: it shows which components sit in the critical path and can block completion there, and which only affect peripheral areas. Then come the evidence request to the vendor, our own counter-check along the core flows, and the decision between encapsulation, alternative route and replacement.
- Inventory of every embedded component including embedding method, position in the user path and contract reference.
- Evidence request to vendors with a prepared letter, a deadline and filing of the responses.
- Counter-check of the critical paths by keyboard and in the screen reader output, findings separated into own code, third-party code and interaction.
- Contract and procurement clauses with a standard reference, remediation deadlines and cooperation duties.
- Fallback concept per component with alternative route, encapsulation or replacement plan and a rough effort estimate.
- Recurring sample checks including a change log and maintenance of the statement.
How these building blocks fit together is shown in our service overview; where editorial and marketing teams own embeds themselves, we anchor the testing routine in accessibility training. And once testing reaches filter and search components in a shop, the same logic applies as for accessible product search in an online shop: the path first, the tool second.
Sources and studies
Related Articles
Keeping Accessibility: Review Cadence After Go-live
The duty does not end at acceptance. Which events trigger a re-test, which sample size holds up and how long the evidence has to stay on file.
Accessible CMS Backends: ATAG for Authoring Tools
ATAG 2.0 audits the tool, not just the website: Part A covers the editing interface, Part B the guardrails that make accessible content the likely outcome.
Accessible E-Learning: Platforms, Courses and Quizzes
Paid online courses fall under the BFSG, universities under BITV 2.0. How to make the learning journey from booking to certificate genuinely accessible.