--- title: "One year of BFSG: Accessibility as a quality feature" lang: en type: blog canonical: https://www.arocom.de/en/blog/bfsg-accessibility-practice alternate: https://www.arocom.de/blog/barrierefreiheit-bfsg-praxis author: "Axel Roth" published: 2026-02-17 last_updated: 2026-10-31 --- # One year of BFSG: Accessibility as a quality feature One year after the BFSG (German Accessibility Act) came into force for private companies, our projects show: whoever treats accessibility as a pure compliance checklist pays twice. Whoever understands it as a quality feature gains better usability for all users, more robust HTML, better SEO/GEO signals and legal safety as a side effect. The most effective first steps: semantic HTML, keyboard operability, contrast and maintained alt texts, measurable with automated tests in CI. A 30-day plan has proven itself for getting started: check core journeys, implement quick wins, prioritise components by reach, automate checks. ## One year of BFSG: Accessibility as a quality feature, not a checklist Since June 2025, the BFSG (German Accessibility Act) has applied to many private companies. The first reaction we observed was the same as with the GDPR: panic, checklists, overlay vendors with hundred-percent promises. One year and several accessibility projects later we can say: the checklist reflex leads astray. The companies that approach it properly get back more than legal safety. ## Accessibility is usability with a tailwind The most effective accessibility measures are general quality measures at the same time. A clear heading hierarchy helps screen reader users and everyone who skims pages. Sufficient contrast helps people with visual impairments and anyone looking at their phone in the sun. Keyboard operability helps users with motor impairments and power users. Plain language helps people with cognitive impairments and your conversion rates. There is another beneficiary nobody should ignore in 2026: AI systems. Semantic HTML, described images and clear structure are exactly what language models need to capture content correctly. Accessibility and [GEO](https://www.arocom.de/en/blog/geo-visibility-ai-search) share the same technical foundation: one budget, double effect. This is rarely cleanly isolatable in numbers, but the direction is consistent in our projects: after accessibility rebuilds, abandonment in form journeys drops, and support requests of the kind "I can't find the submit button" disappear. Nobody complains about a website that is easier to use. ## Learning 1: Overlays fail the real-world test Purchased "accessibility widgets" do not repair broken HTML, they only put a layer on top. In tests with real screen reader users they fail regularly, and as the sole measure they do not hold up legally. A test in a client project showed us what that looks like in practice (anonymised, the pattern is typical): a mid-sized company had licensed an overlay and considered the topic done. We walked through the website together with a screen reader user. The widget announced itself verbosely, then came the actual problem. In the contact form, the fields were only audible as "input" because labels were missing, and the submit button was unreachable by keyboard. The overlay's "screen reader mode" changed nothing, because the missing information simply was not in the HTML. The user gave up after four minutes. Every affected person who wants to inquire there experiences those four minutes. The consequence in that project: the overlay was cancelled and the budget went into repairing forms and navigation. That sounds like more effort, but it was the more sustainable investment. The problems are fixed rather than covered up, and the recurring widget fee is gone. ## Learning 2: Fixing one component heals a hundred pages The inventory is usually bigger than expected, the effort smaller. Most problems concentrate in a few reused components: navigation, forms, teaser cards. If you work component-based (in Drupal as in any modern frontend), you fix one component and heal a hundred pages. A typical example from one of our projects is the main navigation. Before: menu items as clickable div elements, submenus reachable only by mouse hover, no visible focus. For keyboard users, half the website was out of reach. After: real buttons with aria-expanded, submenus that open and close by keyboard, a clear focus ring. The rebuild affected a single component and took a few development days. It was effective on several hundred pages at once, because they all embed the same navigation. Forms and teaser cards followed the same pattern. Important for planning: count components, not pages. An audit report with two thousand individual findings often shrinks to 15 to 20 component tickets, and only that number works as the basis for an effort estimate. ## Learning 3: Without automated checks, it slides back Accessibility checks belong in the CI pipeline, otherwise the state is gone again six releases later. At arocom, axe-core runs in Playwright tests against representative page types: homepage, service page, article, form journey. The checks cover, among other things, contrast, form labels, alt texts, ARIA roles and the heading hierarchy. This is what a catch looks like: a new teaser card variant came out of design alignment with light text on a light background. The pipeline reported the contrast error right on the pull request, and it was fixed before the merge. Without the check it would have surfaced months later in an audit, spread across dozens of pages. Setting up such checks is manageable: ours were running after a few days, and since then every check costs only compute time. The automatable third of the WCAG criteria catches exactly these frequent regressions. For the rest, you need periodic manual audits, ideally with people who use assistive technologies every day. ### Does the BFSG also apply to our B2B website? The BFSG targets consumer services; pure B2B offerings are often exempt. But beware of mixed forms: a web shop, booking or application journeys can trigger the obligation. Independent of the obligation, the quality argument applies. We clarify the classification in a first conversation. ### Is an automated test sufficient as proof? No. Automated tools check only 30–50 % of the WCAG requirements, depending on the criterion. A reliable assessment needs manual review, ideally with the participation of people who use assistive technologies daily. ### What does market surveillance actually check? The market surveillance authorities of the German federal states are responsible. From our observation and reports in the industry, they have so far worked mostly case-based, that is, in response to complaints, and initially request a statement and remediation rather than immediate sanctions. The law does give them sharper instruments, up to fines and, in extreme cases, prohibiting the service. Do not rely on the authorities alone: associations can also pursue violations. This assessment is not legal advice. ### Do PDFs have to be accessible too? If a PDF is part of a service that falls under the BFSG, such as contract terms or product information in an ordering journey, the requirements apply to it as well. For pure legacy archives this generally does not apply; in case of doubt, the demarcation belongs in a legal review. Pragmatically, this has proven itself: create new, relevant documents accessibly (keyword PDF/UA) and, where possible, offer content as an HTML page instead of a PDF. HTML is easier to keep accessible and easier to find along the way. ### What does getting started realistically cost? A solid audit of a mid-sized company website sits in the low five-figure range; remediation depends on the state of the components. The reverse path is considerably more expensive: squeezing accessibility into a running relaunch after the fact. ## The first 30 days: a pragmatic start If you start today and have not had an audit yet, this order has proven itself in our projects: - **Week 1: survey the inventory.** Do not check all pages, but page types and core journeys: homepage, most important service page, contact or ordering journey. An automated scan plus one manual pass using only the keyboard reveals the most serious barriers. - **Week 2: implement quick wins.** Form labels, alt texts for content-bearing images, visible focus states, contrast via central design variables. These points affect most users and are feasible without a redesign. - **Week 3: prioritise components.** Map the remaining findings to components and sort by reach: navigation and forms first, rarely used elements later. - **Week 4: lock it in.** Add automated checks to the deployment pipeline and, if your offering falls under the BFSG, set up the accessibility statement. For the budget, as an order of magnitude from our projects: the audit sits in the low five-figure range, the quick wins usually below that, and the component rebuild depends on the state of the frontend. Also name a responsible person from the start who prioritises findings and schedules follow-up work. Without a clear owner, the topic stalls again after week 4. The very first step costs nothing: put the mouse away and try to submit an inquiry on your own website using only the Tab key. What you experience doing that is your starting point.