BFSG Warning Letters: Securing Accessibility in 2026

Why the warnings arrive a year after the BFSG

The BFSG transposes the European Accessibility Act into German law and requires affected products and services to meet recognized standards. For websites and apps this means in practice: WCAG 2.1 Level AA as the benchmark, anchored technically in the harmonized standard EN 301 549 (BFSG). Affected are, among others, online shops, banking and payment services, passenger transport, telecommunications and e-books – that is, a large share of consumer e-commerce. The obligation has applied since 28 June 2025 (BFSG); what many operators mistook for a year of leniency was merely the phase in which enforcement was still ramping up.

Now two levers act at once. The first is official market surveillance: the market surveillance body of the federal states for the accessibility of products and services took up active enforcement in 2026 and can pursue violations on its own (barrierefreie-agenturen.de). The second is the competition-law route: several law firms take the view that BFSG duties qualify as a market-conduct rule under section 3a of the German Act Against Unfair Competition (UWG), so competitors and entitled associations can issue chargeable warnings (UWG). Whether every individual case is actionable has not been settled conclusively in court – yet even the risk of a warning is enough to force operators to act. For a structured checklist, the piece on a website's cease-and-desist risk goes deeper.

A missing accessibility statement: the easiest proof

Not every violation is equally easy to prove. Some WCAG criteria require human judgment – for instance, whether an alternative text truly describes an image in a meaningful way. Other violations can be detected by machine in seconds and are therefore especially well suited as a hook for a warning or an official complaint. Four points stand out because they are visible or automatically testable without expert knowledge:

The order is no accident. Anyone probing a website for violations starts with the points that can be proven without manual analysis – and those very points can also be monitored continuously. The piece on continuous accessibility monitoring to WCAG goes deeper into which criteria can be automated technically and which need a human review.

How widespread the shortcomings really are

The scale is larger than most operators assume. The annual analysis of the one million most visited home pages provides a sobering snapshot: on 94.8% of pages, automated tools find WCAG 2 failures at levels A and AA (WebAIM Million 2025). On average that is 51 detectable errors per page (WebAIM Million 2025) – and those are only the machine-detectable ones; the true number including the manually testable criteria is higher. In parallel, page complexity keeps rising, to an average of 1,257 elements per home page (WebAIM Million 2025), which creates new sources of error with every rebuild.

The core message: accessibility shortcomings are not a fringe phenomenon of a few careless pages but the normal state of the web. For operators that is both good and bad news. Bad, because the probability of being affected yourself is high. Good, because a large share of the errors falls on a few, recurring patterns – and those patterns can be tracked down and fixed systematically.

What a violation costs: fine and warning letter

The financial consequences run through two separate channels. One is the official fine: for formal shortcomings the range typically reaches into the low five figures, while for serious violations the law provides for fines of up to 100,000 euros (BFSG). The other is the competition-law warning: here costs arise from lawyer and procedural fees, a possible cease-and-desist declaration with a contractual penalty, and the effort of fixing the shortcomings under time pressure. According to law-firm reports, a single warning generally runs into several thousand euros, and considerably more on repetition (barrierefreie-agenturen.de).

On top of the direct costs comes the outage: a cease-and-desist declaration can force you to switch off or rebuild features at short notice, which is expensive precisely during selling seasons. And unlike a silent data-protection flaw, accessibility is visible to every visitor – the radius of suspicion is correspondingly large. Anyone with further legal duties still open in parallel, for instance around GDPR compliance for their website or the consent-required embedding of tag managers, accumulates attack surface that can be bundled into a single warning.

Why one-off audits are not enough

The most common mistake in dealing with the BFSG is the idea that accessibility is a project with an end date. A one-off audit describes the state on a single day – yet a living website changes with every deploy. A new theme, an updated plugin, a landing page built by drag-and-drop or an embedded third-party widget can break criteria that were met yesterday. This very pattern of creeping regression after a release is also described in the piece on monitoring internet-exposed services: what was checked once stays fine only with ongoing control.

There is also an important caveat: automated checking does not cover everything. By volume, an established engine like axe-core finds around 57% of errors (Deque); measured against the number of WCAG success criteria, roughly 30% are fully automatable depending on how you count (Deque). The rest requires human judgment. But that does not devalue automation – on the contrary: it takes over precisely the common, formally provable violations such as contrast, missing labels or missing alternative texts that are warned about first, and keeps an eye on them after every change. Manual in-depth review complements it but does not replace it.

Continuous accessibility monitoring with XICTRAQ

XICTRAQ checks the automatically testable WCAG criteria continuously rather than once. The accessibility check runs on the open engine axe-core against WCAG 2.1 and 2.2 Level AA, compares each run with the previous state and reports new violations. A snapshot thus becomes an early-warning system that surfaces a regression in the next check interval – not weeks later through a complaint. Among the things monitored are:

• Text contrast (WCAG 1.4.3): contrast ratios are checked by calculation so a color deploy does not slip below the threshold unnoticed.
• Alternative texts (1.1.1): missing or empty alt attributes on images and graphics are flagged.
• Form labels (1.3.1, 4.1.2): input fields without a programmatically associated label stand out immediately – especially in search, login and checkout.
• Keyboard operation and focus (2.4.7): visible focus and reachable controls are verified.
• Document structure and page language (1.3.1, 3.1.1): correct heading hierarchy and a set language attribute.
• Presence of the accessibility statement: the page is checked for a reachable link to the statement.

When a new violation is detected, XICTRAQ triggers multi-channel alerting – by email, Slack, Teams or webhook, straight to the team that owns the last deploy. Because accessibility sits in the same dashboard next to uptime, performance and security, a weight or contrast jump can be attributed to the triggering release immediately, instead of being laboriously reconstructed.

Maintaining the accessibility statement soundly

The accessibility statement is the most visible proof of compliance – and at the same time the point where many fail, because the statement is either missing or outdated. A robust statement names the state of conformity with the requirements, openly lists known content that is not yet accessible, provides a feedback mechanism for affected users and is updated on every significant change. That currency is exactly the problem: after a larger rebuild the statement often no longer matches the actual state.

• Link it reachably: from the footer and ideally from the help area, with a descriptive anchor text.
• Document honestly: name known limitations instead of claiming completeness – an open, maintained statement is more credible than a whitewashed one.
• Provide a feedback channel: a contact option for barrier reports whose delivery can be monitored.
• Keep it current: review it after every significant change and carry forward the date of the last review.

Proof of diligence over time comes from reports and status pages: they document when checks ran and how the state developed. If a complaint does arrive, this shows that accessibility was controlled continuously and not ignored – a difference that carries weight when a violation is assessed.

Becoming warning-proof in five steps

1. Clarify whether you are affected: check whether your offering falls under the BFSG and whether the micro-enterprise exemption applies at all – legally when in doubt, and with the result documented.
2. Take stock: have the most important pages – home, category, product, cart, checkout – checked against WCAG 2.1 AA and fix the common violations such as contrast, labels and alternative texts first.
3. Publish the statement: create a complete, findable accessibility statement with a feedback channel and thereby close the easiest violation to prove.
4. Set up monitoring: enable a continuous check of the testable criteria with an alert on every new regression, instead of relying on occasional spot checks.
5. Watch the trend: evaluate the trajectory over weeks, treat a new barrier as a priority bug and keep the statement current after every larger deploy.

Securing accessibility for the long run

The wave of BFSG warnings hits above all operators who ticked accessibility off as a one-time task. Those who instead understand it as a state that applies anew after every deploy flip the risk around: a looming warning becomes a controlled process. The key is the combination of a current, honest accessibility statement and a continuous check of the testable WCAG criteria that reports new violations before they catch the eye of someone who sends a warning. What the BFSG demands of website operators in detail is summed up in the overview of BFSG duties for websites.

Start with a free trial and have your most important pages checked against WCAG 2.1 AA – in minutes you will see where the common, actionable violations lie. Or book a personal demo to see deploy alerting and the documentation of the statement in action.