Accessible website and the BFSG: what small and medium-sized businesses should check and what an overlay does not deliver

The enquiry does not arrive, and nobody notices. A visitor tabs through the contact form, reaches the “Subject” field, and suddenly the focus jumps into nothing: the dropdown is a custom-built element that only responds to mouse clicks. They give up. In the analytics this moment appears nowhere; it looks like any other drop-off.

Suppose this was the starting point of a small service provider with a well-kept, visually appealing website. The design comes from a good template, the copy is careful, the load time is fine. That the site is barely usable for people with visual impairments, with a tremor, with only one hand or simply without a mouse appears in no report. Anyone who tried it would probably have fixed it long ago.

Accessibility is therefore less a question of morals than of perception: you do not see the barriers until you experience them yourself. On top of that, the group is larger than you think. Permanent impairments are part of it, but so are a broken arm, glaring sunlight on a smartphone, eyesight that weakens with age or a poor laptop monitor in the office.

For small businesses there is a sober additional thought: every enquiry counts. Where a company receives only a few contacts per week, a form that excludes part of the visitors is not a fringe technical issue but a lost job. How large that share is cannot be stated in general terms. All that is certain is that it does not show itself and only becomes visible through deliberate testing.

The failure patterns repeat so strongly that they are easy to sort. Grey text on a light grey background that looks elegant and is barely legible in practice. A menu that opens when hovering with the mouse and cannot be reached by keyboard. A focus outline that a designer removed via CSS “for a clean look”. Images without a description or with the file name as the description. Form fields explained only by placeholder text that disappears as you type.

Then there are structural errors that cannot be seen visually. Headings are chosen by font size rather than meaning, buttons are in reality clickable blocks of text with no role and no keyboard function. A screen reader then reads “group, group, group” or skips the most important part. For sighted visitors this stays invisible because the eye derives meaning from layout and color that the code does not provide.

Why does it stay undiscovered for so long? Because the usual quality controls do not catch it. A design review checks the impression, a test checks whether the button triggers a click, and analytics shows drop-offs without a cause. Accessibility requires a perspective that nobody takes in daily work: using the page without a mouse, without telling colors apart or without images. Anyone who has trained this perspective once finds results surprisingly quickly.

The Web Content Accessibility Guidelines, WCAG for short, are organized into four principles. Content must be perceivable, operation must be possible, content and operation must remain understandable, and the code must be robust enough for different technologies to interpret it. The principles give rise to guidelines and testable success criteria, which are divided into three levels: A, AA and AAA. In practice, level AA is the one that matters most.

The value of the principles lies in the way they structure questions. “Perceivable” asks whether someone can take in the content through at least one sensory channel. “Operable” asks whether every function can be used without fine mouse control, without time pressure and without gestures. “Understandable” concerns language, predictability and help with input errors. “Robust” means clean markup so that screen readers and other assistive technologies do not have to guess.

An example makes it tangible. A tab menu for services is visually clear, but without roles and states a screen reader does not know which tab is active (robust), the arrow keys do nothing (operable), the active tab differs only by a shade of color (perceivable), and the labels are abbreviations that nobody explains (understandable). A single component violates all four principles at once.

We use this framework as an aid to thinking and not as a tick-box list. A checklist tempts you to handle each criterion in isolation and lose sight of the whole. Better is the question per page type: who could fail here, and how would you notice? This produces a check based on real use that treats the criteria as a yardstick.

The most tempting route is an overlay: a script that displays an icon at the edge of the page and promises to make the website accessible with one line of code. For small businesses this is appealing because it is cheap, quick and sounds like a solution. The problem lies in the mechanism. A script that changes properties in the browser at runtime can only guess at missing labels and wrong structure, not add them reliably.

There is also a practical conflict. Users of screen readers and keyboards have already set up their assistive technologies, and an additional overlay can interfere rather than help. That overlays do not fix faulty code is widely known among experts, and a number of disability organizations reject them. A badge saying “accessible” on the website also does not replace a check and does not prove conformity.

That does not mean every adjustment toolbar is useless. A function for increasing font size or switching contrast can add comfort. But it is an addition, not a foundation. What matters is that the page is built cleanly without any extra tool. We therefore recommend fixing the cause in the source code and the design, which is usually also more cost-effective than a permanent subscription solution that changes nothing about the foundation.

Before you use such a product, three questions to the vendor are worthwhile: what exactly is changed, and where does the source code remain untouched? Who is liable if the page contains barriers despite the badge? And what happens to your page if you cancel the contract? If the answers are evasive, that in itself is useful information.

The Barrierefreiheitsstärkungsgesetz, BFSG for short, implements a European directive and has applied in Germany since summer 2025. It does not target all websites but certain products and services offered to consumers. The focus is on, for example, online shops and other offerings where consumers can conclude a contract online. Exceptions are provided for very small enterprises, depending on the type of service and the size of the business.

Whether your business is affected therefore depends on what you offer and not on the mere existence of a website. A trades business whose site presents services and accepts enquiries is in a different position from a provider that concludes contracts with consumers online. This classification is not legal advice. For binding statements on whether you are affected, on deadlines, obligations and consequences, ask a legal advisor who knows your offering.

Regardless of legal applicability, the technical yardstick is useful. The European standard on which the law is based follows the WCAG for web content. Anyone who aligns their website with WCAG 2.x level AA is working to a widely recognized standard and doing something for all visitors at the same time. We deliberately separate the two questions: the legal assessment belongs in other hands, while technical quality can be improved independently of it.

Automatic testing tools such as Lighthouse or axe reliably find some of the errors: missing alt text, insufficient contrast, form fields without labels, duplicate IDs, missing language attribute. But they cover only a portion of all possible problems. Whether alt text is meaningful, whether the focus order is logical or whether an error message is understandable is something a script cannot judge. A green score therefore does not mean “accessible” but “no automatically detectable errors”.

The second layer is manual testing, which is less effort than it sounds. Put the mouse aside and work through the page using Tab, Shift+Tab, Enter, Space and Escape. Does the focus move logically? Is it visible at all times? Can every menu and every dialog be operated and exited again? Then zoom the view to 200 percent and check whether content is cut off or overlaps.

The third layer is a spot check with a screen reader, such as NVDA on Windows or VoiceOver on Mac and iPhone. The effort is worthwhile for a few key paths: the home page, a service page, the contact form. Anyone who has heard their own business read aloud once understands heading structure and link text differently. The spot check does not replace testing with affected users, but it reliably reveals gross errors that no tool reports.

An example of how the layers interact: a tool reports “image has alt text”, and the manual check finds that the text is the file name “IMG_2043”. Formally satisfied, practically worthless. Conversely, the tool finds a contrast value of 3.2 to 1 on grey body text that the eye still reads well in the office. On a smartphone outdoors it becomes an obstacle.

For contrast, the WCAG guideline values are a ratio of at least 4.5 to 1 for normal text and 3 to 1 for large text as well as for important controls and graphics. This can be checked with color tools and the browser's developer tools. The fix usually sits in the design variables, not on the individual page: if a grey value is darkened in the color system, all places improve at once. This is an argument for maintaining colors centrally.

For keyboard and focus, a simple rule applies: use native elements wherever possible. A real button element, a real link and a real select field bring keyboard operation, role and state with them. Self-built constructs made of div elements have to retrofit everything and often fail. The focus outline should never be removed without a replacement. A clear, high-contrast outline costs little and makes the page easier to operate for everyone, including those who simply prefer to type.

For image text, function is what counts. Informative images get a brief description of what they convey, decorative images an empty alt attribute so that they are skipped. A logo that serves as a link to the home page needs the name of the destination, not a description of the image. Link texts should be understandable on their own: “Services at a glance” instead of “more”. For forms, every field needs a visible label connected to the field, and errors are named in text, not just marked in red.

Among the trickiest spots are elements supplied by third parties. A cookie banner that overlays the page but does not manage focus can leave keyboard users trapped or let them keep tabbing behind it. It must be operable by keyboard, set the focus sensibly and return it on closing. The same applies to embedded maps: an interactive map is often barely usable by keyboard, so the address belongs next to it as text as well.

Videos and audio content need subtitles or a transcript so that deaf and hard-of-hearing people can use them, and a description where information is purely visual. Automatically starting media should be stoppable. PDF documents such as price lists, forms or brochures are an underestimated area: a scan without a text layer is empty for a screen reader. Where possible, a page with real text is the better form, with the PDF remaining as a supplement.

Another special case is animation and motion. People who are sensitive to motion need a way to reduce effects. Modern browsers report the system setting “reduce motion”, and the design can respond by dropping parallax effects and automatically running sliders. The same goes for content that changes by itself: a carousel that keeps running without a pause takes away people's time to read.

Finally, third-party widgets such as appointment booking, chat or review displays. They are part of your offering, but not your code. Here it is worth checking before embedding whether the vendor documents accessibility, and, if in doubt, offering an alternative such as a phone number or a simple form. That is inconvenient, but more honest than hiding an obstacle behind a badge.

Improving accessibility first achieves one thing: more people can use your site. Whether that translates into more enquiries cannot be said in general terms and depends on how many visitors have failed so far. What is clear is that a robust structure, readable contrasts and well-labeled forms also help visitors without impairments, because pages become clearer and quicker to use. That is a side benefit, but not a quantifiable promise.

Progress can be measured with indicators close to the defect. These include the number of violations reported by testing tools per page type, the number of key paths that can be completed entirely by keyboard, and the results of the screen reader spot check, each before and after the rework. The share of form abandonments on the contact form is also meaningful, provided there are enough visitors to withstand fluctuations.

An important limit: an audit shows what was found on a particular date, not lasting conformity. New content, an update or a plugin can bring barriers back. Nor can a technical audit tell you that there is no legal risk. That is a statement we cannot make, and so we do not make it. What is realistic is a documented status with clearly listed open items and a routine for keeping it up to date.

A practical yardstick for the effect: after the rework, a person who does not know the site should be able to submit the contact form using only the keyboard and be able to see where they are at all times. If that works, the most important goal of this phase has been reached, even if further items remain open.

Accessibility is cheapest when it is considered from the start. A colour palette with verified contrasts, native controls and a sensible heading structure cost almost nothing during the build, but cost time and nerves when retrofitted. Anyone setting up or reworking a website should therefore build the criteria into the design rather than checking them at the end. For existing sites the rule is: templates first, individual pages afterwards.

A second point concerns editorial work. Technology creates the conditions, but alt texts, link texts and clear language come about in day-to-day operation. A short handout for everyone who maintains content often achieves more than another round of audits. Three rules are enough to start with: describe images, explain links, set headings by meaning.

Third, it helps to be honest about conflicting goals. A very subtle, light-grey design and high contrast do not go well together, and a carousel on the home page is rarely what visitors are looking for. Such trade-offs should be decided visibly: where the design gives way, readability wins, and where a compromise remains, it is documented so that the next rework does not repeat it unnoticed.

The next step is small and needs no prior knowledge. Open your contact form, put the mouse aside and try to submit an enquiry using only the keyboard. If you fail, you have a concrete finding. If it works, check the contrast of your body text and then run Lighthouse. If you would like an assessment afterwards, we will look at your site and tell you openly where the biggest lever is and what cannot be answered in general terms.