// BFSG 2026
Have an Accessible Website Built — BFSG-Compliant (WCAG 2.1 AA)_
Since 28 June 2025, the German Barrierefreiheitsstärkungsgesetz (BFSG) — implementing the EU Accessibility Act — applies to companies offering digital products or services to consumers. Acting now avoids fines, reduces legal risk, and opens your product to a wider audience. As a web developer based in Hannover, I implement accessibility properly in code — not with superficial overlay plugins, but structurally and sustainably.
What is the BFSG — and who is affected?
The Barrierefreiheitsstärkungsgesetz (BFSG) transposes EU Directive 2019/882 (the European Accessibility Act) into German law. From 28 June 2025, companies offering digital products or services to consumers must comply with WCAG 2.1 Level AA. This affects online shops, banking portals, booking platforms, Software-as-a-Service providers and many other digital offerings. Micro-enterprises with fewer than ten employees and an annual turnover below two million euros may qualify for an exemption under certain conditions — but this must be documented. Non-compliance can result in regulatory fines and cease-and-desist letters under competition law. This text is general information and not legal advice; for specific legal questions please consult a qualified lawyer.
What WCAG 2.1 AA means in practice
The Web Content Accessibility Guidelines (WCAG) 2.1 define four core principles: perceivable, operable, understandable, robust. At Level AA, key requirements include: colour contrast of at least 4.5:1 for normal text and 3:1 for large text; full keyboard operability without a mouse; compatible semantics for screen readers (ARIA labels, landmarks, roles); accessible forms with clearly associated labels and meaningful error messages; no time-dependent content without controls; and captions for pre-recorded video. With Next.js and React, these requirements can be implemented consistently and maintainably, because semantic HTML, ARIA, and focus management are built directly into the code — not patched on afterwards.
New build vs. retrofit: what suits your situation?
For many businesses the question is: retrofit an existing website for accessibility, or build anew? Both are viable — the right choice depends on the state of the existing codebase and the scope of requirements. For a retrofit, we start with a structured accessibility audit: I check contrast, keyboard navigation, screen-reader compatibility, and form logic using real tools (axe, Lighthouse, manual testing), then produce a prioritised action plan. The identified gaps are then closed in the existing codebase. For a new build, accessibility is integrated from the start as a design principle — with Next.js, TypeScript, and Tailwind CSS, all of which support semantic HTML and solid ARIA out of the box. The result is more robust and cheaper in the long run than retrofitting.
Process: Audit → Action plan → Implementation → Statement
A typical accessibility project follows four phases. First, the audit: automated scans with axe-core and Lighthouse, supplemented by manual keyboard and screen-reader testing with NVDA or VoiceOver. Second, the action plan: a prioritised list of all findings ranked by severity and implementation effort. Third, implementation: fixing the issues in code — from contrast adjustments to semantic markup and full keyboard navigation. Fourth, the accessibility statement: the BFSG requires a publicly accessible statement documenting the conformance status. This is drafted after implementation is complete and published on the website. For standard websites this process typically takes two to four weeks; more complex projects take longer accordingly.
Why real code beats an overlay plugin
Accessibility overlays and widget plugins claim to retrofit accessibility with a single line of JavaScript. It sounds appealing — but it does not work. Studies and real-world testing show that such overlays frequently impede genuine screen-reader users more than they help, and that they do not establish legally compliant WCAG conformance. Multiple lawsuits against overlay vendors in the US underline this. Accessibility must be anchored in the code: in the HTML semantics, in focus management, in ARIA implementation, and in visual design. As a developer I build this from the ground up or retrofit it precisely — for a website that is not just formally compliant, but that actually works for people with disabilities.
- WCAG 2.1 AA: contrast, keyboard, screen readers, forms, focus management
- Next.js + TypeScript: semantic HTML and ARIA built into the component design
- Accessibility audit with axe-core, Lighthouse, and manual testing
- Accessibility statement per BFSG requirements
- Retrofit of existing websites or accessible new build from scratch
- Based in Hannover — remote across Germany, Austria, and Switzerland
Frequently Asked Questions
Everything you want to know before getting started.
Ready for an accessible website?
Get in touch now — I will respond within one working day. The free 30-minute intro call is an opportunity to discuss your specific needs and get a first overview of scope and approach.
// Free 30-min intro call · Hannover & remote (DACH)