Accessibility (BFSG/EAA) for apps and websites: a checklist

Since 28 June 2025, the German Accessibility Strengthening Act (Barrierefreiheitsstärkungsgesetz, BFSG) has applied. It implements the European Accessibility Act (EAA) and requires many digital products and services to be usable by people with disabilities. For companies that sell online to consumers, accessibility is no longer a nice-to-have.

This article explains who is affected, which standard to follow, and what to check in practice.

This article is general information, not legal advice.

Who is affected?

The BFSG covers certain products (for example computers, smartphones, self-service terminals and e-readers) and certain services for consumers. For websites and apps, the most important group is services in electronic commerce: everything that leads a consumer to a contract online, such as online shops, booking systems and online contract conclusion. Banking services, telecommunications, e-books and passenger transport services are also covered.

Exemptions and limits:

• Microenterprises that provide services, meaning companies with fewer than 10 employees and an annual turnover or balance sheet total of no more than 2 million euros, are exempt from the service requirements. There is no such exemption for products.
• Pure B2B offers that are not directed at consumers are generally not covered. But public clients have their own accessibility rules (BITV 2.0), and more and more companies require accessibility in tenders and contracts.
• Where full compliance would be a disproportionate burden or would fundamentally change the service, exceptions are possible, but they must be assessed and documented.

Enforcement: the federal states have set up a joint market surveillance authority for accessibility (MLBF) in Magdeburg. Violations can lead to orders, the withdrawal of a service from the market and fines of up to 100,000 euros. Competitors and associations may also take action.

Which standard applies?

In practice, the harmonised European standard EN 301 549 is the reference. For websites and apps it largely refers to the Web Content Accessibility Guidelines (WCAG) 2.1, level AA. If your website or app meets WCAG 2.1 AA, you have met the core technical requirements.

In addition, covered services must publish information on how they meet the accessibility requirements, typically as an accessibility statement on the website or in the terms.

Checklist: design

• Contrast: normal text at least 4.5:1 against the background, large text and UI elements at least 3:1.
• Not colour alone: errors, required fields and statuses are not shown by colour alone, but also with text or icons.
• Focus visible: every interactive element has a clearly visible focus indicator for keyboard users.
• Touch targets are large enough and not too close together.
• Zoom and reflow: the page works at 200% zoom and on narrow screens without horizontal scrolling.
• Motion: animations can be paused or are reduced when the user prefers reduced motion.

Checklist: content

• Headings form a logical structure (one H1, then H2, H3 in order).
• Images have meaningful alternative text; purely decorative images are marked as such.
• Links describe their target ("Download price list", not "click here").
• Language is set correctly, including for passages in another language.
• Plain language: short sentences, explained terms, clear instructions in forms.
• Videos have captions; audio content has a transcript.
• PDFs that are part of the service are accessible too, or offered in an accessible alternative.

Checklist: development

• Semantic HTML: real buttons, links, lists and landmarks instead of styled divs.
• Keyboard: everything works with the keyboard alone, in a logical order, without keyboard traps. Menus and dialogs can be closed with Escape.
• Forms: every field has a visible label, errors are announced and explained, and the user can correct them easily.
• Dynamic content: status messages and changes (for example "added to cart") are announced to screen readers.
• Dialogs and overlays move focus correctly and return it when closed, including the cookie banner.
• Skip link to jump to the main content.
• Mobile apps: use the accessibility features of iOS and Android (labels, dynamic font sizes, VoiceOver and TalkBack support).

Checklist: testing

1. Automated checks with tools such as Lighthouse or axe catch a part of the problems, roughly the obvious ones.
2. Keyboard test: go through the most important journeys without a mouse.
3. Screen reader test with NVDA or VoiceOver on the key pages and forms.
4. Zoom and mobile test at 200% and on a small phone.
5. Users with disabilities: where possible, test with real users. They find what tools miss.
6. Document the results and publish the accessibility statement.

Accessibility pays off beyond the law

Accessible websites and apps are easier to use for everyone: in bright sunlight, on a small screen, with a broken arm or simply in a hurry. Clean structure and semantic HTML also help search engines understand your pages. And for many public and corporate clients, accessibility is becoming a requirement in tenders.

How we work

We design and develop websites and apps with accessibility built in from the first wireframe: contrast-checked design systems, semantic components, keyboard and screen reader support, and testing before launch. Retrofitting is possible, but building it in from the start is much cheaper. See our UI/UX design and web development pages.

Check your website or app