Accessibility Act: Compliant Websites for Businesses

The most common misreading is that every website has to be accessible from now on. That is not the case. The BFSG addresses services in electronic commerce, meaning websites through which consumers can enter into a contract: purchases, bookings, appointment scheduling, contract signing, account opening. A purely informational site with no transaction usually stays outside the scope, as does an offer aimed exclusively at business customers. Public sector bodies, by contrast, have been subject to their own and in parts stricter rulebook for years. The boundary is blurrier than it sounds, though: a trade business with online appointment booking, a restaurant with table reservations or a medical practice with prescription requests moves into scope very quickly. If you are unsure, walk through the functions of your own site one at a time. The overview of how a XICflow site is assembled helps you place your own requirements.

Regardless of the legal classification, the sheer scale makes the case. Germany is home to around 7.9 million people with a recognised severe disability (Federal Statistical Office of Germany), roughly nine percent of the population. Across the European Union the Commission estimates around 87 million people with some form of disability (European Commission). Add temporary and situational limitations: a broken arm, harsh sunlight on a display, a noisy environment without headphones. Accessibility is therefore a question of reach rather than a fringe concern. The side effect is measurable, too: clean heading structures, descriptive link text and robust forms improve operation for everyone and make a page easier for machines to interpret. If a new site is on the agenda anyway, both can be handled in one pass – the article on building a website with AI shows how that plays out.

Contrast is by far the most frequent defect: around 79 percent of the home pages analysed contain text with insufficient contrast (WebAIM Million). The rule is unspectacular and consequential all the same. Regular text needs a ratio of 4.5:1 against its background; large text from 24 pixels, or from 18.66 pixels in bold, gets by with 3:1. Since WCAG 2.1 a minimum ratio of 3:1 also applies to user interface components and meaningful graphics. In practice the usual offenders are pale grey on white, placeholder text inside form fields, buttons that look disabled, and copy set over photographs without a darkening layer. The second perennial issue is focus. Many designs strip the browser default focus indicator without supplying a replacement, which leaves the page effectively unusable for anyone navigating by keyboard. The example sites in the demo gallery show how a clean baseline looks in practice.

The keyboard check takes two minutes and replaces no audit, yet it surfaces a great deal: load the page, press the Tab key and move through every element without touching the mouse. At any moment it has to be visible where the focus sits. Menus should open with Enter or Space and close with the Escape key. Dialogs trap the focus while open and hand it back to the triggering element when closed. Carousels, disclosure panels and filters need reachable controls instead of mouse-only logic. WCAG 2.2 sharpened this area: the additions include criteria on focus that must not be obscured, on alternatives to dragging movements and on minimum target sizes. It also matters that the page structure holds up when heavy scripting does not run. Static delivery has structural advantages here, as the article on PageSpeed 100 and static delivery explains.

The BFSG requires providers of covered services to explain how the service meets the accessibility requirements (BFSG Section 14). That information belongs in the terms and conditions or in a comparably findable place, and it has to be accessible itself. In the public sector the accessibility statement under the German accessible information technology ordinance has been established for years and serves as a practical template: it states the degree of conformity, lists content that is not accessible, gives reasons, records the date of creation and of the last review, and provides a feedback mechanism with a contact route. Private providers are well served by the same structure, because it documents in a comprehensible way what was actually tested. Honesty matters here: declaring a site fully conformant while known gaps exist creates more risk than an open list with a schedule attached. The German Federal Agency for Accessibility publishes practical guidance on this (Bundesfachstelle Barrierefreiheit).

Retrofitting is the most laborious route. When contrast values, focus indicators and form patterns are adjusted only after launch, every change touches all subpages and usually the design system as well. XICflow works the other way round: pages are assembled from a catalogue of reviewed blocks whose contrast values, focus indicators, heading hierarchy, labels and status messages rest on a WCAG 2.2 AA foundation. Interactive building blocks such as tab panels, process steps or sliders ship with the matching ARIA patterns and keyboard handling. Output is static HTML, so the page structure holds up even when scripts do not run. Legal pages and the accessibility statement are generated alongside and can be extended with project-specific details. None of this replaces a review of your own content – alternative text for your own photographs and plain language remain editorial tasks – but it shifts the effort from repairing to maintaining. The pricing overview shows what the build costs.

Accessibility is closely tied to other foundational decisions. A multilingual site needs correct language declarations so that screen readers pick the right pronunciation – the article on multilingual sites and hreflang covers the technical side. A consent banner has to be keyboard operable itself and must not lock the focus in place. And fast delivery helps precisely those people who work with magnification software or older devices. Handling these topics separately builds contradictions into the project; planning them together saves rounds of coordination and duplicated corrections. Further articles on structure, law and technology are collected in the XICflow blog.