Custom controls without semantics
A div with a click handler looks like a button, but keyboard users cannot reach it and screen readers do not announce it as one. Homegrown dropdowns, tabs and date pickers are a frequent source of these errors.
All services
Accessibility under the BFSG and WCAG 2.2
BFSG compliance in code: accessible web apps, portals and online shops
We test your application against WCAG 2.2 AA with automated and manual checks, rank the findings by their impact on users and fix them where they originate: in the source code. Much of this experience comes from Komplify, a BFSG and WCAG testing platform we built for Prevision UG.
- Audits against WCAG 2.2 AA
- Fixes directly in code
- Regression checks in CI
Background
What Germany's Accessibility Act has required since June 28, 2025
The Barrierefreiheitsstärkungsgesetz (BFSG) transposes the European Accessibility Act (Directive (EU) 2019/882) into German law and has applied since June 28, 2025. It covers services provided to consumers after that date, including e-commerce services: websites and apps through which consumers conclude a contract, such as online shops, booking flows or sign-ups in a customer portal. Consumer banking, telecommunications and e-books are also covered.
The detailed requirements are in the BFSG regulation (BFSGV): websites and mobile apps must be perceivable, operable, understandable and robust, explicitly including identification, authentication and payment functions in e-commerce. Harmonized standards whose references are published in the Official Journal of the EU carry a presumption of conformity (Section 4 BFSG). EN 301 549 version 4.1.1 was published in September 2026; it references WCAG 2.2 and, for the first time, maps its requirements to the European Accessibility Act. Until harmonized standards are announced in the Official Journal, Germany's Federal Accessibility Agency names EN 301 549 and WCAG as the authoritative reference.
Microenterprises that provide services are exempt. The German states' joint market surveillance authority (MLBF) in Magdeburg investigates on suspicion and by random sampling, sets correction deadlines and, as a last resort, can prohibit a non-compliant service. This overview does not replace legal advice.
- Microenterprise under the act: fewer than ten employees and annual turnover or balance sheet total of no more than 2 million euros (Section 2 No. 17, Section 3(3) BFSG)
- Accessibility information in the terms and conditions or another clearly visible place: what the service is, how it meets the requirements, and the responsible authority (Section 14 BFSG, Annex 3)
- Exemptions include prerecorded media and office files published before June 28, 2025, third-party content outside the provider's control, and archives that are no longer updated (Section 1(4) BFSG)
- Anyone claiming a disproportionate burden must document that assessment and keep it for five years (Section 17 BFSG)
- Fines of up to 100,000 euros for offering or providing a service in breach of Section 14 BFSG (Section 37 BFSG)
Typical starting points
Where accessibility breaks down in established web applications
Most findings are not caused by a lack of goodwill but by components nobody ever used with a keyboard or a screen reader.
Dialogs that lose focus
When a modal opens, keyboard focus often stays on the page behind it or disappears after the modal closes. For keyboard users, checkout ends right there.
Forms without labels or error text
Fields without an associated label, required fields marked only by color, error messages that appear on screen but are never announced. The BFSGV explicitly names identification, authentication and payment in e-commerce.
A good score is not proof
A scanner can tell that alt text is missing, but not whether existing alt text matches the image. Only a person can judge whether the focus order makes sense.
What we build
What we deliver for your BFSG compliance
We work on your codebase. An overlay script cannot reliably repair missing semantics or broken focus handling, because the cause sits in the source code.
Audit with prioritized findings
Automated testing with axe-core and in-browser behavioral checks, plus manual testing with keyboard, screen reader and zoom. Each finding names the WCAG criterion, the affected element, its impact and a fix.
Fixes in the source code
Semantic HTML, full keyboard operation, focus management in dialogs and menus, sufficient contrast, labeled forms with clear error messages, and ARIA where native HTML is not enough.
Accessible components
We build critical components such as dialogs, menus, tabs, comboboxes and date pickers properly once, then replace the broken variants across the application.
New applications accessible from day one
For new builds, WCAG 2.2 AA is part of the acceptance criteria for every component. So no interface needs retrofitting later.
Technical input for your accessibility information
You get an inventory of which user journeys were tested against which criteria, what is met and what remains open. The legal wording stays with you and your counsel.
Regression protection in CI
Automated checks run on every pull request and flag new code that reintroduces known classes of errors.
Approach
From audit to an application that stays accessible
We organize the work around the user journeys that lead to a contract, not around the number of pages.
- 01
Define the critical user journeys
Together we identify the flows that matter: sign-up, login, search, cart, payment, contact, plus the page templates the rest of the application is built from.
- 02
Test automatically and manually
A scan across the whole application finds the clear-cut errors. Manual testing of the critical journeys covers the rest: keyboard operation, focus, screen reader output and layout at 400 percent zoom.
- 03
Prioritize by impact and fix
Anything that blocks users completely comes first, such as a payment step that cannot be operated. We fix root causes in shared components, so one correction works in many places at once.
- 04
Retest and safeguard
A second test run confirms the fixes. Automated checks in CI and a short checklist for new components keep that level in future releases.
Technology
Testing tools and standards for accessible web applications
Our benchmark is WCAG 2.2 at level AA, which the current EN 301 549 also references. For automated testing we run axe-core in a headless browser. In Komplify we extended that foundation with heuristic, behavioral and cross-page checks, for example for keyboard traps, focus order and visible focus, and reported ambiguous results as hints for manual review, not as violations.
We implement fixes in your application's stack, often React, Next.js and TypeScript. We use ARIA sparingly: a native button element is more robust than a rebuilt one with three ARIA attributes.
Typical stack
- WCAG 2.2 AA
- EN 301 549
- axe-core
- Puppeteer
- Playwright
- WAI-ARIA
- React
- Next.js
- TypeScript
- GitHub Actions
Case studies
Komplify: automated BFSG and WCAG testing for Prevision UG
Komplify is our client Prevision UG's product; we built the platform, including its testing engine. It taught us exactly which errors automated checks catch reliably and where manual review remains essential.
Frequently asked questions
Frequently asked questions about BFSG compliance
The act mainly covers consumer services provided after June 28, 2025, including websites and apps through which consumers conclude a contract. Microenterprises (fewer than ten employees, no more than 2 million euros in turnover or balance sheet total) are exempt for services. Whether your specific offering is covered is a legal question: we provide the technical assessment, not the legal one.
No. Automated checks reliably find clear-cut errors such as missing labels or insufficient contrast. Many WCAG criteria can only be judged by a person, such as whether alt text matches the image or the focus order makes sense. So we combine both.
Under Section 14 BFSG and Annex 3, you describe your service in an accessible format, explain how it meets the requirements and name the responsible market surveillance authority. The information belongs in your terms and conditions or another clearly visible place. We provide the technical basis; your legal counsel should review the wording.
No, we neither certify nor give legal advice. You receive a traceable test report: which user journeys were tested against which WCAG criteria, what we fixed and what remains open. That is a solid basis for your accessibility information and for questions from the authorities.
The effort depends on the size of the application, the number of critical user journeys, the state of the existing components and your technology stack. In a free 30-minute initial call, we assess whether an audit, targeted fixes or rebuilding specific components makes sense. You then receive a transparent proposal covering approach, milestones and billing.
Initial consultation
Have your application checked against BFSG requirements
Send us a link to your application or describe its key user journeys. In a free 30-minute call with the founders, we identify the biggest barriers and how to fix them in code. We reply to every inquiry within 24 hours.
More services
What else we build for businesses.
Web apps & business software
Internal tools, dashboards and SaaS products that follow your processes instead of bending them. Designed and coded by the founders themselves.
Learn moreCustomer & service portals
Protected portals for customers, dealers and members: orders, bookings and documents as self-service, with clear roles and permissions.
Learn moreIntegrations & automation
API integrations, ERP and accounting connections, PDF imports and automated jobs that move data reliably between your systems.
Learn moreHealthcare software
Backend experience from Germany's ePA, an appointment platform for a practice network, and architectures that account for GDPR Article 9 and Section 393 SGB V.
Learn more