2026-02-11 · Baduno Editorial Team · 6 blog.readMin · Blog & Knowledge
Barrier-Free Accessibility Act: What websites must comply with now
Since June 2025, the BFSG applies — and many corporate websites fall under it. The obligations, clearly sorted, without panic.
Who is affected
The law covers consumer-oriented electronic services — including online shops and many booking and contact routes. Pure B2B offerings and micro-enterprises are partially exempt; classification should be legally reviewed if in doubt.
What is required
In practice, the requirements are based on WCAG: perceivable (contrasts, alt texts), operable (keyboard, focus), understandable (clear language, error messages), and robust (clean HTML for assistive technologies).
The good news
Accessible websites are almost always faster, better structured, and more search-engine-friendly. The obligation pays into quality that is worthwhile anyway — and opens up a large, often ignored user group.
Start pragmatically
First test (automated plus manual), then prioritize by impact: contrasts, alt texts, forms, and keyboard operation fix the majority of everyday barriers. An accessibility statement honestly documents the status.
Hreflang and Accessibility: An Often Overlooked Interaction
Multilingual websites face an additional challenge: accessibility requirements apply to each language version separately. The hreflang attribute, which signals language and regional targeting to search engines, must be implemented so that screen readers and other assistive technologies correctly detect language switches. If hreflang is incorrectly set or missing, it can significantly hinder navigation for visually impaired users—for example, when a page unexpectedly loads in a different language without the user's expectation. Practically, this means that each language variant must provide not only translations but also fully accessible structures. This includes correct language declarations in HTML (lang attribute) and consistent alternative texts in all languages. Therefore, the hreflang configuration should be included in accessibility testing from the outset.
Automated testing tools: Strengths and limitations
Tools like axe, Wave, or Lighthouse can automatically detect many technical barriers, such as missing alternative texts, insufficient contrasts, or faulty ARIA attributes. However, they do not replace manual testing, as factors like text comprehensibility, logical order of content, or usability of forms with assistive technologies can only be captured through real user tests. Automated checks provide a quick initial error analysis and are well-suited for continuous testing in CI/CD pipelines. However, the results must always be evaluated by a human, as tools produce both false positives and false negatives. A pragmatic workflow: first automated tests, then a manual sample using a screen reader and keyboard, and finally a concluding usability test with affected users.
Legal consequences and transition periods
The BFSG provides for fines and warnings if websites do not meet the requirements. For products that were put into operation before June 28, 2025, there is a transition period until June 28, 2030 – but only for those that were already accessible before the deadline or can demonstrably show progress. Anyone launching a new website or relaunch after June 28, 2025, must immediately meet the full requirements. Note: The law applies to all newly created content; older content (e.g., archive pages) may require more extensive adjustments. In practice, it is advisable to maintain written documentation of progress in order to prove, in case of complaints, that accessibility is being implemented step by step. An accessibility statement on the website is mandatory anyway.
Since June 2025, the BFSG applies — and many corporate websites fall under it. The obligations, clearly sorted, without panic.
Accessibility as part of an international SEO strategy
Accessible websites not only fulfill legal requirements but also meet many criteria that search engines evaluate positively: semantic HTML structure, clear heading hierarchies, meaningful alt texts, and fast loading times. These factors are relevant for SEO in all languages. Additionally, search engines can explicitly penalize barriers such as unlabeled buttons or missing headings, as they complicate indexing. By making your website accessible to all users, you automatically improve user experience and thereby indirectly enhance ranking signals. Especially for multilingual websites, it is worth integrating accessibility into localization workflows from the start – for example, through checklists for translators to create accessible alternative texts.
Testing with real users: Why it is indispensable
Automated tools only detect some barriers. It is only through testing with people who actually rely on assistive technologies that you can see whether your website works in everyday use. Blind users use screen readers differently than automated checks simulate; deaf users have different requirements for sign language videos; people with motor impairments navigate without a mouse. A structured test with three to five participants from different disability groups uncovers issues that no tool finds – such as illogical focus orders, missing context information in ARIA labels, or unclear error messages. Ideally, schedule such tests during the development phase, not just shortly before going live. Document the results in the accessibility statement as part of your quality assurance. Remember: the tests must be carried out separately for each language version, as translations can create new barriers – for example, when alternative texts do not match the target language or form instructions are grammatically incorrect.
Content management systems and accessibility: Pitfalls with plugins
Many websites rely on CMS like WordPress, TYPO3, or Drupal. These systems offer plugins or extensions promising accessibility – such as overlay tools that adjust contrasts or insert ARIA attributes retroactively. Such solutions are often insufficient and can even create new barriers by overriding existing semantic structures. Instead, implement accessibility directly in the theme or template: clean HTML structure, correct heading hierarchies, native form elements. When selecting plugins, ensure they are WCAG-compliant and regularly updated. Another issue: Many editors add content via the visual editor while ignoring alt texts or heading formats. Train your editors or use workflows that enforce accessible input – such as mandatory alt text fields for images. The choice of CMS template also affects accessibility: test each template before deployment with an automated tool and a manual sample.
Testing with People with Disabilities: The Indispensable Step
Automated tools and manual checklists reveal many technical barriers, but they do not replace testing with real users. People with disabilities use various assistive technologies – screen readers like JAWS, NVDA, or VoiceOver, magnification software, voice control, or specialized keyboards. Each of these combinations behaves differently, so even a formally compliant page may be unusable for a blind user. Therefore, schedule regular user tests with a heterogeneous group: visually impaired, motor-impaired, and cognitively impaired individuals. Have them perform defined tasks on your website, such as purchasing a product or filling out a contact form. Document the issues precisely: where does navigation stall, which announcements are unclear, which elements are not reachable? The insights from these tests are invaluable, as they reveal not only barriers but also optimization potential for all users. Be sure to conduct the tests separately for each language version, as translations and nested sentences affect comprehension differently. Integrate the results into your continuous improvement process – accessibility is not a one-time project but an ongoing task.
Embedding Accessibility in the Content Management System
Many accessibility issues already arise during content creation: editors forget alt texts, do not use headings hierarchically, or link meaningless words like “click here”. To avoid this, embed accessibility directly in your Content Management System (CMS). Train your editorial teams in the basics of WCAG – separately for each language team to ensure that requirements are not undermined by cultural differences in text design. Use CMS plugins or extensions that enforce mandatory alt text fields when inserting images or visually display heading hierarchy. Integrate automated checks into the approval workflow that flag common errors such as missing labels or insufficient contrast before publication. Also ensure that the CMS templates and themes you use are already accessible – with correct ARIA landmarks, keyboard focus management, and semantic HTML. For multilingual websites, it is essential that the CMS supports the localization of accessible structures, for example by automatically setting correct hreflang attributes and language declarations. A well-integrated accessibility process within the CMS reduces rework effort and ensures consistent quality across all language versions.
blog.faqT
What happens if my website violates the BFSG?
Violations of the BFSG can result in fines. Additionally, warnings from competitors or consumer protection associations are to be expected. The amount of the fine depends on the severity of the violation and can be up to 100,000 euros. An accessibility statement detailing the scope and status of measures is mandatory and serves as proof.
Must translations of my website also be accessible?
Yes, each language version must individually meet the accessibility requirements. This includes correct language attributes (lang), translated alternative texts, and barrier-free navigation. The hreflang attribute must be set so that search engines and assistive technologies correctly recognize language changes. Translation agencies should therefore also ensure the accessibility of their deliverables.
