Must Third-Party-Content be accessible?

This article addresses the question of whether third-party content must be accessible and how this can be ensured. Please note that I cannot provide a legally binding assessment here, and that many questions, especially regarding the European Accessibility Act, still have to be discussed.

What is third-party content?

The topic of third-party content seems complex at first glance. It refers to content that originates from external providers but is integrated in such a way that it appears to users as an integral part of the website or application itself. This includes, for example, embedded social media content, but also functional elements such as chatbots, forms, or calculators. The range of examples is very broad.

To clarify: Third-party content is generally content that was not created in-house but is obtained and integrated from external providers. Users often cannot tell that an external service provider is supplying the content. A very common example of this is chatbots. While such systems were sometimes developed in-house in the past, today third-party-solutions are purchased. These are usually more robust, better supported, and significantly more cost-effective, as in-house development would involve considerable time and expense.

A typical example is integrated payment service providers, which are often integrated via frames or iframes. These services must be fully accessible, as they are an essential component of the service offered. If the payment process is not accessible, the consumer contract cannot be concluded.

The same applies, for example, to package tracking services. These, too, must be designed to be accessible so that users can actually track their packages.

Special Case: Advertising

The situation becomes more complex with content sourced from third parties over which the website operator has little or no control. A typical example is advertising. Advertising content is usually integrated via specialized service providers who purchase, display, and technically provide the ads. The website operator can typically only make general specifications, such as excluding certain advertisements for specific products. They have no direct influence on the content itself.

For example, it is not possible to pause animations or make content adjustments, as this would often violate the terms and conditions of the respective advertising service provider. Regardless, in practice, the website operator lacks control anyway, since the advertising content is merely integrated, and it is often not known in advance which specific ads will be displayed. In many cases, the selection of advertisements even occurs in real time during the page load. Accordingly, website operators generally have little to no influence on the accessibility of this content. To my knowledge, there is currently no clear legal ruling on whether such advertising content from private providers—such as online shops or platforms like Amazon or eBay—must be accessible. There is strong evidence to suggest that this is not currently required, as such an obligation would represent a significant infringement on entrepreneurial freedom.

If a provider were no longer allowed to display advertising at all or were required to display only accessible advertising, this would likely fundamentally challenge the business model of many providers. Against this backdrop, it can be assumed that advertising content generally does not have to be accessible. However, exceptions are conceivable, for example, if advertising is directly linked to the conclusion of a consumer contract. An example of this would be vouchers or discount-related advertising elements that directly influence the conclusion of the contract. In such cases, accessible design or at least accessible integration would be necessary. A binding legal clarification on this matter is still pending, and it is questionable whether clear guidance will be available in the foreseeable future.

Embedded content must not create barriers

It is essential to ensure that embedded content itself does not create barriers. For example, advertising must not lead to a so-called keyboard trap or cause other usability problems. The moment advertising content impairs or blocks the use of the website, it constitutes a barrier and thus becomes clearly relevant within the meaning of the German Federal Data Protection Act (BDSG). The same applies to the use of so-called Accessibility Overlays, which you should avoid anyway. Overlays often create barriers, such as keyboard traps.

Currently, it is not clear what exactly must be considered accessible within the scope of the EAA. The question remains, in particular, whether the requirements apply to the entire website or only to those parts that directly serve the conclusion of a consumer contract. In the latter case, the risk would be lower, as the actual forms and order processing sections typically do not contain advertising.

The situation is different under the EU Directive 2016-2102: In the public sector, content that is part of the website must generally be accessible. Exceptions are conceivable for content that is neither relevant to the use of the website nor under the control of the website operator.

A typical example of this is embedded external content such as PDFs, YouTube videos, or Instagram posts from third parties. There is generally no content-related or technical influence over such content. For example, it is not possible to add subtitles or audio descriptions to an external YouTube video or to make structural adjustments to an externally provided PDF. Provided that this content is not essential for the use of the website but merely supplementary, its lack of accessibility is generally acceptable in the public sector.

In the private sector, the distinction is narrower. Third-party content may also be integrated here, but it must always be checked whether it is relevant to the conclusion or use of a consumer contract. If so, it must be accessible.

Ensuring the accessibility of third-party services

A structured approach is recommended for practical application. A first step is to check whether the third-party services used are accessible. Particularly when awarding new contracts or when existing framework agreements expire, a targeted search should be made for accessible providers. A positive indicator is an independent accessibility audit, which should also be up-to-date, ideally no more than 1-2 year old. With existing providers, the issue of accessibility should be actively addressed. Most service providers are likely familiar with the relevant requirements by now and should be able to clearly state whether their service is accessible or not. If not, they should provide a transparent explanation of whether and by when accessibility is planned. If there is no binding commitment, it may be necessary to end the partnership.

This makes it clear that responsibility for third-party content cannot be completely outsourced but must be considered along the entire value chain.

In general, there is no direct technical control over third-party content. It is usually not possible to add ARIA attributes, control keyboard navigation, or make other accessibility adjustments. This is due to the way it is embedded: The content is often loaded via frames, iframes, or JavaScript and is effectively "streamed" from external systems. Accordingly, the responsibility for the technical accessibility of this content initially lies with the respective third-party provider. If the platform isn't inherently accessible, the platform operator has very limited influence.

Test and Ensure

However, what the operator can do is conduct their own accessibility audit of the specific implementation. A test or demo integration in a development or test environment is recommended for this purpose. This allows for verification of the actual accessibility of the integrated service, such as whether full keyboard navigation is possible, whether sufficient contrast is present, or whether forms are correctly labeled. These are established, fundamental testing criteria.

If the organization possesses the necessary expertise, a few targeted tests are often sufficient to obtain an initial assessment of accessibility. Such a review is also advisable if the provider submits a test report. It is not necessary to systematically work through the entire test catalog with all success criteria, especially without in-depth expertise. Instead, a few key test steps can be used to determine whether basic accessibility requirements are met.

``If issues are identified, the provider should be specifically contacted and asked for a statement. If they cannot provide a comprehensible or reliable answer, this can become problematic.

In general, the platform operator is responsible for accessibility. However, this responsibility can be partially transferred to the third-party provider by contract. It is therefore a viable and advisable approach to contractually stipulate corresponding obligations, such as the requirement that embedded content be provided in an accessible format. It should also be stipulated that the third-party provider is liable if false or misleading statements regarding accessibility are made.

I cannot definitively assess the specific legal details. However, as a non-lawyer, I assume that there are corresponding contractual and liability provisions. Regardless, this is a step I would strongly recommend: to protect yourself by providing verifiable proof that accessibility has been taken into account. This includes ensuring that your own applications are fundamentally designed to be accessible and that any identified deficiencies are rectified.

If, however, an integrated service is completely or largely inaccessible, a significantly higher escalation level would be necessary. Ultimately, the responsibility and any potential legal repercussions lie with the platform operator, not the third-party provider. For external third parties, it is irrelevant which external service provider is involved in the background. Accordingly, it is crucial to protect oneself and ensure that the content used is accessible.

There are several approaches: Firstly, an audit report can be requested from the third-party service provider. Especially with larger platforms, it can be advisable to insist on an independent audit report or to seek additional external consultation. Secondly, an internal audit should be conducted to assess the actual accessibility of the specific implementation.

It is recommended to combine both approaches: requesting an audit report from the third-party provider and conducting an additional internal audit. The audit report should be as up-to-date as possible, ideally no more than one to two years old, originate from a reputable and independent body, and include both automated and manual tests. In addition, it should be verified whether the specific integration of the service into your own platform has been implemented in an accessible manner.