BFSG 2026: A Website Accessibility Checklist for German Businesses
The law kicked in June 2025. The audits started January 2026. If your website still isn't accessible, this is your 'okay, let's actually fix this' checklist.
Web Accessibility Specialist
The law kicked in June 2025. The audits started January 2026. If your website still isn't accessible, this is your "okay, let's actually fix this" checklist.
The BarrierefreiheitsstƤrkungsgesetz (yes, that's one word) has been live since June 28, 2025. But here's what changed in 2026: the MarktĆ¼berwachungsstelle der LƤnder (MLBF) is now actively auditing. Not "planning to audit." Not "considering enforcement." Actively requesting documentation, running spot checks, and handing out deadlines.
If you've been treating the BFSG like a soft suggestion, the grace period is over.
The good news? Most of what makes a website BFSG-compliant isn't mysterious. It's practical stuff: things that also happen to make your site work better for everyone. This checklist covers the fixes that deliver the biggest gains fastest, so you can stop guessing and start doing.
Wait: Does This Even Apply to Me?
Probably. If you sell anything to consumers (B2C) through a website, you're almost certainly in scope. The BFSG covers:
- Online shops and e-commerce (this is the big one: it catches most businesses)
- Banking and financial services
- Booking and ticketing platforms
- Telecom and messaging services
- E-book platforms
Purely B2B services? You're off the hook (if it's genuinely B2B only). The moment a consumer can buy from your site, you're in.
Micro-enterprises (fewer than 10 employees, under ā¬2 million turnover) get an exemption for services, but not products. And "micro" is a tight definition. Don't assume you qualify without checking.
The fines go up to ā¬100,000 per violation, and competitors can come after you through unfair competition law (UWG). That second part catches a lot of people off guard.
The Quick Wins: Biggest Impact, Least Pain
You don't need to redesign your entire site to make meaningful progress. These are the things that fix the most problems the fastest.
Keyboard Navigation
Put your mouse in a drawer. Open your own website. Hit Tab.
Can you reach every link, button, and form field? Can you tell where you are on the page? Can you open menus, close modals, submit forms, all without touching the mouse?
If the answer to any of that is no, you've found your first problem. A huge number of people (not just screen reader users) navigate by keyboard. People with motor impairments, power users, anyone with a broken trackpad on a Thursday afternoon.
The fix is usually about using proper HTML elements (<button> instead of a styled <div>), making sure custom components handle keyboard events, and ensuring focus isn't trapped inside elements users can't escape from.
Visible Focus States
When someone tabs through your site, there needs to be a clear visual indicator showing which element is currently selected. Browsers give you one for free: it's usually a blue or black outline.
Here's the problem: designers remove it. Somewhere in your CSS, there's probably an outline: none or outline: 0 that's killing the default focus ring because someone thought it looked ugly. That one line of CSS is an accessibility violation.
Either keep the browser default or replace it with something equally visible: a solid 2px outline in a color that contrasts with your background. This is a five-minute fix on most sites.
Color Contrast
WCAG 2.1 Level AA requires a contrast ratio of at least 4.5:1 for regular text and 3:1 for large text (18px bold or 24px regular).
That light gray text on your white background? Probably fails. Those pastel buttons with white labels? Almost certainly fail. Placeholder text that's barely distinguishable from the background? Fails.
Grab the WebAIM Contrast Checker, punch in your color combinations, and find out where you stand. This is one of those things where 20 minutes of checking can save you a lot of headaches.
Form Labels and Error Handling
Every form input needs a proper <label> element linked to it via for and id attributes. Placeholder text isn't a label; it vanishes when someone starts typing, and screen readers handle it inconsistently.
Error messages need to be specific and connected to the field they belong to. "An error occurred" tells nobody anything. "Please enter a valid email address" does the job. Use aria-describedby to connect error messages to their fields so assistive tech can announce them in context.
If you have a checkout flow, this one matters a lot. A form that can't be completed with assistive technology is a form that's losing you money and breaking the law.
Image Alt Text
Meaningful images need descriptive alt text. Decorative images need alt="" so screen readers skip them.
Skip the lazy stuff. "Image," "photo," "banner.jpg" are not alt text. Describe what the image actually communicates: "Team brainstorming at whiteboard in Hamburg office" is useful. "IMG_2847.jpg" is not.
For product images in e-commerce, this matters double. If someone using a screen reader can't tell what your product looks like, they're not buying it.
Content and PDFs: The Part Everyone Forgets
Your website might be technically accessible, but if you're serving PDFs that are just scanned images of text (terms and conditions, product catalogs, invoices), those are invisible to screen readers. Under the BFSG, PDFs integrated into your site after June 28, 2025, need to be accessible too.
An accessible PDF has tagged structure (headings, lists, tables), a logical reading order, alt text on images, and a defined language. If you're generating PDFs from Word or InDesign, build the accessibility in there; retrofitting is painful.
For web content generally: use a real heading hierarchy (H1 ā H2 ā H3, no skipping), write link text that makes sense out of context ("Download our pricing guide" not "click here"), and keep your language straightforward.
One thing worth noting: the updated harmonized standard (EN 301 549, expected to reference WCAG 2.2) is scheduled for publication around mid-2026. PDF accessibility guidance under the BFSG is still somewhat ambiguous, but that's not a reason to wait. The requirements are coming, and WCAG gives you a solid baseline now.
How to Test (Without Spending a Fortune)
Automated tools are great for catching the obvious stuff: missing alt text, contrast failures, unlabeled form fields. They'll find roughly 30ā40% of accessibility issues, which is a solid start.
Free tools that actually work:
- axe DevTools (browser extension): industry standard, clear reporting
- WAVE (WebAIM): shows issues as a visual overlay on your page
- Lighthouse (built into Chrome DevTools): quick accessibility audit, already on your machine
What automated tools miss (which is a lot):
- Whether your keyboard navigation makes logical sense
- Whether custom widgets actually work with assistive technology
- Whether your content structure makes sense when read linearly
- Whether dynamic content changes (cart updates, toast notifications) are announced to screen readers
For the stuff tools can't catch, you need manual testing. Tab through your site. Try it with a screen reader. NVDA is free on Windows, VoiceOver comes with macOS. Zoom your text to 200% and see if the layout survives. It's not glamorous, but it's where the real issues surface.
Mistakes That Keep Showing Up
After looking at plenty of sites, the same patterns come up over and over:
"We added ARIA everywhere." ARIA is powerful when used correctly and actively harmful when used wrong. Putting role="button" on a <div> that doesn't respond to keyboard events creates something that looks like a button to assistive tech but doesn't work like one. Use native HTML elements first. Always.
Ignoring dynamic content. Your site probably updates things without a full page reload: cart item counts, search suggestions, notification banners. Screen reader users won't know about any of it unless you use ARIA live regions to announce changes. This is one of the most common gaps we see.
Buying an overlay widget. Those JavaScript plugins that promise one-click accessibility compliance? They don't work. The accessibility community has been vocal about this for years, and they're not recognized as a valid compliance path under the BFSG. There's no shortcut.
Treating accessibility as a one-time project. Every new page, every content update, every feature release can introduce new issues. If accessibility isn't part of your development workflow, you'll be patching forever.
Frequently Asked Questions
What standard does the BFSG actually require?
The BFSG references the European standard EN 301 549, which incorporates WCAG 2.1 Level AA for web content. The updated version referencing WCAG 2.2 is expected around mid-2026. In practice, WCAG 2.1 AA is your compliance baseline right now.
What are the real consequences of non-compliance?
Fines from ā¬10,000 to ā¬100,000 depending on severity. But the bigger risk for many businesses is competitors filing unfair competition claims under the UWG. That can happen without waiting for a government audit. Market surveillance authorities can also order you to stop providing a non-compliant service entirely.
Do I have to fix everything at once?
Start with the pages that matter most: homepage, product pages, checkout, contact forms. The user journey is what authorities and auditors will look at first. But yes, the expectation is full compliance. "We're working on it" isn't a legal defense.
My site was built before June 2025. Do I get a pass?
No. The BFSG applies to services provided after June 28, 2025. If your website is still live and serving customers, it needs to comply. Some transitional rules exist for existing service contracts (valid until they expire, but no later than June 2030), but the website itself needs to meet the requirements now.
Are accessibility overlay tools enough for compliance?
No. Overlay tools don't meaningfully fix underlying accessibility issues, and they're not recognized as a compliance solution. They sometimes make things worse by interfering with how assistive technology interacts with your site.
Not Sure Where Your Site Stands?
We offer a free accessibility audit. We'll look at your site, flag the critical issues, and give you a clear picture of what needs fixing and in what order. No sales pitch, just an honest assessment.