Germany’s Barrierefreiheitsstärkungsgesetz (in German), the Accessibility Strengthening Act or BFSG for short, has applied since June 28, 2025. According to the Bundesfachstelle Barrierefreiheit, the federal accessibility agency, it covers certain products and services placed on the market or provided after that day. Whether and how the law applies to your website is a legal question that I don’t answer here. You’ll find information and answers to frequently asked questions on the Bundesfachstelle’s page about the BFSG (in German).
This article is about the technology. I show what makes a website usable for people with disabilities and how to build and test it. I also describe what is implemented on this website.
The technical benchmark
The Web Content Accessibility Guidelines, WCAG for short, are the W3C standard for accessible web content. The current version is WCAG 2.2. It assigns every success criterion to one of three levels, from A through AA to AAA. The following sections cover criteria that matter in practice for almost every website. The Bundesfachstelle explains which standards are relevant for the BFSG on its page about standards (in German).
Contrast
Under criterion 1.4.3, text needs a contrast ratio of at least 4.5:1 against its background. For large text, 3:1 is enough, meaning 18 point and larger, or 14 point and larger in bold. Criterion 1.4.11 requires 3:1 for controls and for graphics needed to understand the content as well. Text in a logo is exempt from criterion 1.4.3.
Typical weak spots are light gray text, placeholders in forms and text on photos. For this website, we aimed for AA-level contrast in both the light and the dark theme. If you offer a dark theme, you should check both versions separately.
Keyboard use
Under criterion 2.1.1, every function must also work with the keyboard. Criterion 2.1.2 requires that focus can be moved away from every element using the keyboard. The order in which focus moves through the page with the Tab key must preserve its meaning under 2.4.3.
Typical mistakes are menus that only open when you hover over them with the mouse. Buttons built as plain areas without keyboard support also lock out people who don’t use a mouse.
On this website, the Escape key closes the services submenu. When the mobile menu opens, focus moves into it. After switching between the light and the dark theme, focus stays on a visible control.
Visible focus
Criterion 2.4.7 requires the keyboard focus to be visible. With 2.4.11, WCAG 2.2 adds that a focused element must not be entirely hidden by other content on the page. This easily happens with headers that stay at the top while scrolling.
On this website, every element in keyboard focus shows an outline in the accent color. When focus moves on, the page scrolls far enough for the element to sit below the sticky header.
Headings and landmarks
Criterion 1.3.1 requires visible structure to be recognizable in the code as well. A heading must therefore be marked up as a heading and must not merely look bold and large. Under 2.4.6, headings and labels describe their topic or purpose. Screen readers jump from heading to heading and between landmarks such as header, navigation, main content and footer.
Criterion 2.4.1 requires a way to skip blocks that repeat, such as the navigation. Under 3.1.1, the language of every page must be set in the code.
Every page of this website has exactly one main heading, and a test fails if there are more. A link to skip the navigation appears as soon as someone presses the Tab key. The navigation menus in the footer have their own names, so a screen reader can tell them apart. The language is set in the code on every page.
Forms and error messages
Under criterion 3.3.2, every input field needs a label or instructions. A placeholder in the field doesn’t replace a label, because it disappears while you type. Criterion 3.3.1 requires a detected error to be described in text. Where a correction is known, the message should suggest it under 3.3.3.
In the contact form on this website, every field has a visible label, and required fields are marked. Every error message is linked to its field, so a screen reader reads it out together with the field. Invalid fields are marked as invalid, and the first of them receives the focus. Messages after submitting appear in an area that screen readers announce automatically.
Text alternatives
Criterion 1.1.1 requires a text alternative with the same purpose for all content that is not text. A photo of the team needs a description, and an icon used as a link needs a name. Purely decorative graphics get an empty alternative text, so screen readers skip them.
On this website, the greater-than sign after links is hidden from screen readers, because it’s only decoration. No screen reader reads out the dot grid in the background either.
Less motion
Under criterion 2.2.2, users must be able to pause or hide motion that starts automatically and lasts longer than five seconds. Criterion 2.3.3 at level AAA requires that animations triggered by an interaction can be turned off. For this, the W3C names the CSS query prefers-reduced-motion as a suitable technique. It detects whether reduced motion is set in the operating system.
On this website, this setting makes all animations and transitions instant. Scrolling then also jumps straight to the target instead of gliding.
Testing
Automated tools find only some of the problems. Of its Easy Checks, the W3C writes that a page can pass even these simple checks and still have significant barriers. A tool can detect, for example, that an alternative text is missing. Whether an existing alternative text fits the image has to be judged by a person who sees the image in context.
For this website we require the full score of 100 in the Lighthouse accessibility category on every page. Such a score doesn’t replace testing by hand, though, and a few steps are enough for that.
- Use every page with only Tab, Enter and Escape.
- Watch whether the focus is always visible and not hidden.
- Zoom the page to 200 percent in the browser, because under criterion 1.4.4 no content may be lost.
- Turn on reduced motion in the operating system and reload the page.
- Listen to the page with a screen reader, such as VoiceOver on the Mac or NVDA on Windows.
- Submit every form once with errors.
Check with the Bundesfachstelle Barrierefreiheit or a lawyer whether the BFSG applies to your offering and what it requires. The article The new Ruxiom describes how this website came about.
If you want it or the law requires it, we build your website to be accessible, from keyboard use to labeled form fields. The websites page shows how we plan and build a new site. Tell us which pages and forms your website needs, and we’ll work through the requirements with you.