Legal framework

BFSG inspection: What should you do if the market surveillance authority contacts you?

A BFSG warning letter and an official inspection are different procedures. For guidance on handling private claims, see [BFSG warning letter: What should you do?](/blog/bfsg-abmahnung-was-tun). This article explains how to assess a request from the market surveillance authority and what evidence you should have ready.

The short answer

First, check which authority sent the letter, which offering it concerns, what the authority is requesting, and the deadline stated in the letter. Preserve the request and assign someone internally to take responsibility. Gather the accessibility information you already have and examine the functions in question along the specific user journey. Respond factually and with supporting evidence; do not claim full compliance based solely on an automated scan. If the authority’s jurisdiction or the requirements are unclear, or if enforcement measures are threatened, a lawyer should assess the specific case.

Work from the letter, not from a general checklist. Does it concern information for consumers, use of a particular function, or an accessibility barrier that has already been identified? The answer determines which documents to gather first. An overview of all previous assessments may be helpful, but it does not replace answers to the specific questions asked.

Make a working copy of the letter and record who will prepare the response, who will verify technical statements, and who will approve them. Keep a traceable record of the state of the affected website or application, where possible. If a function changes while the response is being prepared, it should remain possible to identify which version a test or statement refers to.

An initial internal assessment may reveal gaps. What matters is not filling them with assumptions. Mark what has already been checked, what evidence is still missing, and when another assessment will be possible. This lets you prepare a well-supported response without prematurely presenting an open question as resolved.

Which authority examines compliance, and why?

The BFSG sets accessibility requirements for certain products and services. For market surveillance, the Market Surveillance Authority of the Federal States for the Accessibility of Products and Services, or MLBF, is relevant. Whether a particular website is covered depends on the service offered and the scope of the law. A website is not covered merely because it is publicly accessible.

The assessment therefore depends not only on the website’s address, but also on what users can actually do there. Describe the offering in question as precisely as possible: What service is offered, what steps are involved in using it, and which parts of the website or application are involved? A company blog, a product description and an online contract process may raise different questions. The mere existence of a page does not establish which requirements apply to each of its parts.

Also check to whom the letter is addressed and in what capacity your company is being contacted. Do you operate the service yourself, merely provide technical components, or does the inquiry concern a third party’s offering? Such distinctions may be significant for a substantive response. They should be clarified using contracts, product descriptions and actual processes, rather than inferred from the wording of an authority’s name.

If the connection to the BFSG is unclear to you, do not ignore the letter. Record the facts that support or weigh against the service being covered, and seek a legal assessment if necessary. A reasoned question about the service concerned is more helpful than a blanket assertion that the authority has no jurisdiction.

How to assess the letter

• Record the sender, reference number, and service concerned.
• Capture the requested information and deadline exactly as stated.
• Bring together the product, technical, and legal teams internally.

An inquiry does not automatically mean that a violation has been established. What matters is what the authority says in the specific letter and the grounds on which it requests documents.

Read the letter in full, then list each question separately. Distinguish requests for information, requests for documents, references to specific problems, and possible instructions to take action. For each point, note who can provide the facts and which file or assessment supports the response. This helps ensure that no question is overlooked between the legal assessment and the technical work.

Check whether the authority identifies a specific version, a particular step in the user journey, or a time period. For example, an error in the registration form cannot be addressed solely with a report on the homepage. Conversely, do not claim without grounds that a finding applies to the entire website if only one process was examined. State the scope of your investigation and its findings explicitly.

Preserve the original letter and its attachments, and document the date of receipt and the communication channel. Share it internally only with those who need it to handle the matter. If an external service provider is already working on the affected feature, request the relevant technical information from them. Simply forwarding the inquiry does not discharge your responsibility to provide an accurate response.

If it remains unclear whether a point is intended as a question, an instruction, or an official finding, clarify the wording before making far-reaching commitments. Record these follow-up questions and the answers received alongside the case file.

What the authority needs to be able to verify

Prepare a description of the service concerned and the key steps involved in using it. Have the accessibility information required under the BFSG and BFSGV available where those requirements apply to your offering. Use specific tests to show which barriers were found, resolved or remain open. A claim of compliance alone is no substitute for verifiable evidence.

Useful evidence identifies what it covers. Document, for example, the page or function tested, the test date, the version used and the steps performed. For an ordering or booking process, this may include selection, data entry, error correction and confirmation. This makes it clear whether a statement is based on the entire relevant process or only on an isolated screen.

Organize findings so that people outside the development team can understand them. Describe what users were trying to do, where they encountered difficulties, the conditions under which the problem occurred and what has changed since then. An internal ticket name or an unexplained screenshot is often not enough. Screenshots, test logs and tickets can support the account if they are clearly linked to the findings and are not used in place of an understandable explanation.

For issues that remain open, a clear status is more helpful than a blanket assurance. Distinguish between confirmed, under review, in progress and retested after a change. Present planned steps as commitments only if they have been agreed internally. Also check whether a documented fix has actually reached the affected environment in which the service is used; a closed development ticket alone does not establish that.

Compile only documents relevant to the request, and check them for confidential or personal information before sharing them. If you cannot provide required evidence, identify the gap explicitly and explain how you will investigate it. That is more credible than a general reference to existing quality processes.

Test and fix, don't just scan

Examine the affected user journeys with appropriate automated checks and manual tests, such as keyboard testing and testing with assistive technologies. For each finding, document the affected function, its impact, and the status of the fix. Inclaria can reveal issues that can be tested automatically; a complete accessibility assessment also requires manual testing.

Start with the journey addressed in the request. Can a key task be started and completed without a mouse? Is the focus visible during navigation, are controls understandable, and are error messages conveyed in a way that allows users to correct their entries? Test not only the normal flow but also common interruptions: a required field is left blank, a session expires, or a dialog opens.

Automated checks help identify certain technical issues consistently. But they cannot reliably assess whether instructions are understandable or evaluate every journey using assistive technologies. A scan that finds no issues is therefore not proof that a service can be used accessibly as a whole. Likewise, a reported error must be checked on the specific element before its impact is described.

For manual tests, define the task being tested and what counts as successful completion. Record the browsers, devices, and assistive tools used where they matter for reproducing the issue. Once a barrier has been removed, repeat the affected journey and check whether the change has created new problems elsewhere. With forms or multistep processes in particular, a fix in one place can affect the next step.

Prioritize fixes according to their impact on use and their relevance to the authority's request. A blocked core function deserves particular attention. Still, document less obvious findings rather than removing them from the test report. The purpose of documentation is not to produce a flawless-looking list, but to provide a status that can be verified.

Response and next steps

Answer the authority’s specific questions within the deadline, or contact it in good time if documents are missing. Distinguish established facts, work in progress and unresolved legal questions. Any further measures depend on the circumstances of the case and the statutory procedure. This article is for information only and does not constitute legal advice; consult a lawyer about your case.

Structure your response around the questions in the letter. Support each factual claim with the relevant description, assessment or attachment, and use the same term consistently for each part of the service. A short, well-organized response with clearly matched evidence is easier to follow than a collection of files without explanation.

Describe the status precisely: a barrier may be confirmed but still unresolved; a technical change may have been implemented but not yet retested. Do not present these situations as equivalent to a verified fix. If you could not reproduce an issue yourself, describe the steps you took and their limitations rather than rejecting the reported finding without further investigation.

If it becomes clear that you cannot prepare a complete response by the deadline, contact the office named in the letter before the deadline and clarify the next steps. Record what information is already available and what still needs to be gathered. Do not assume that a requested extension has been granted. Keep the response you sent, its attachments and any subsequent correspondence together with the case file.

Internal work should continue after you send the response. Bring unresolved findings into a trackable process, assign responsibilities and retest changes along the user journey. If the authority asks follow-up questions, you can then distinguish the status originally reported from later improvements. If measures are imminent, there is disagreement about the scope of the law, or a statement has significant legal implications, a lawyer should assist with the specific correspondence.