Usability must be part of the functions
A customer has found a product and entered their details. At the final step, they cannot continue because the button cannot be reached with the keyboard. Another person hears only button through their screen reader, without knowing its purpose.
The application may look flawless on the developers' screens, yet neither person can use it fully.
This example shows why accessibility is not additional decoration. It concerns whether people can complete a task independently.
Larger text or a reading-aloud option may help in particular places, but neither automatically makes an inaccessible ordering process usable.
Good usability must be built into functions, not just their appearance.
Why the subject also matters legally
Since 28 June 2025, key requirements of Germany's Accessibility Strengthening Act, the BFSG, have applied to specified products and services. These include covered e-commerce services, consumer banking services, and e-books with associated software. The precise scope is set out in section 1. [1]
This does not mean that every website and internal business application is automatically subject to identical requirements.
For e-commerce services, a particular consideration is whether a service is provided electronically at a consumer's individual request with a view to concluding a consumer contract. The Federal Accessibility Agency explains typical cases in its FAQ, dated May 2025. [1] [2]
An important exemption concerns microenterprises offering or providing services. The statutory definition requires fewer than ten employees and either annual turnover or an annual balance sheet total not exceeding two million euros. This is not a blanket exemption for small businesses covering every product and activity. [1]
Transitional provisions also require careful reading. Section 38 provides specified arrangements for products already used to provide services and existing service contracts. It does not grant every older website a general postponement until 2030. [1]
For a particular offer, I would first determine the applicable scope. Accessible operation remains a quality concern regardless.
Accessibility is about more than sight
The BFSG describes accessibility in terms of finding, accessing and using products and services generally independently and without particular difficulty. For covered websites and apps, the associated regulation requires information and interfaces to be perceivable, operable, understandable and robust. [1] [3]
In development, this leads to practical questions:
Perception: is information understandable without relying solely on colour differences?
Operation: can the necessary functions be reached and used with the keyboard?
Understanding: do labels and error messages explain what to do?
Technical reliability: can assistive software identify what a control means?
A screen reader can present content through speech or a Braille display. Successful operation requires the application to expose the meaning of its controls. A visually striking button without an understandable name is insufficient. W3C guidance addresses control names, roles and states. [4]
For me, the implication is clear: reviewing a page only under the conditions in which it was designed is not enough.
Technical guidelines help, but are not the entire law
The Web Content Accessibility Guidelines, WCAG, provide important guidance. The W3C Recommendation WCAG 2.2 used here is dated 12 December 2024. It includes testable requirements for keyboard operation, contrast, visible focus and support for input. [4]
These criteria help with development and evaluation. Passing a WCAG evaluation does not automatically establish compliance with every BFSG and BFSGV duty. The legislation also addresses matters such as information about the service and certain support arrangements. [3]
I would therefore document two questions separately: which legal requirements apply to our offer, and which technical criteria will we use to evaluate implementation?
That prevents a general report from promising more than was actually assessed.
For developers: Shared components rather than isolated fixes
If every form has its own buttons, dialogues and error messages, their usability must also be checked repeatedly.
For a new application, I would build a small collection of shared interface components: clearly labelled inputs, reachable buttons and dialogues with defined keyboard behaviour.
Use existing browser functionality where appropriate. In its ARIA guide, checked on 10 October 2026, W3C emphasises that assigning a role does not create keyboard behaviour. Labelling an ordinary element as a button still requires its expected operation to be implemented correctly. [6]
In practice, not every visual element needs to be reinvented technically.
Shared components do not replace evaluation of the complete workflow. An individually usable dialogue can still appear at the wrong point or block subsequent access.
Forms determine whether people can continue
Forms reveal whether an application has been developed clearly.
The W3C accessible forms tutorial, updated on 27 March 2026, covers clear labels, logical grouping, understandable instructions and useful error feedback. [5]
For example, submitting a form produces only invalid input. The person does not know which field is affected or how to correct it.
A specific response would be better: please include the area code in the telephone number. Associate the message with the field and make it perceptible to assistive technology.
I would preserve information already entered correctly. Nobody should have to complete a long form again because one detail is missing.
Time limits also deserve attention. W3C recommends avoiding unnecessary limits and enabling required limits to be disabled or extended under the specified conditions. Security requirements must still be taken into account. [5]
Architecturally, error handling and session workflows need early consideration. They are not merely a matter of wording added later.
Include sign-in and payment in evaluation
An accessible home page offers little benefit if sign-in or payment confirmation cannot be operated afterwards.
Section 19 of the BFSGV expressly addresses identification, authentication, security and payment functions in covered e-commerce services. These must also be accessible. [3]
When selecting external components, I would ask more than whether integration is technically possible. I want to know whether they work under the intended conditions of use.
Examples include appointments, payment windows and delivery-date selection. To the person ordering, the component's technical origin does not change its place in the process.
Before release, I would test the complete route: initial access, entering data, correcting an error where necessary and receiving confirmation.
Automated checks help, but are not enough
Automated tools can flag certain problems. They cannot independently establish whether a website meets accessibility requirements. In its evaluation overview, checked on 10 October 2026, W3C stresses the need for knowledgeable human assessment. [7]
For me, a clean report would therefore form part of quality assurance rather than mark its end.
I would also complete typical tasks with the keyboard, try magnification and examine output with suitable assistive technology. What matters is completing the task, not merely opening a menu somewhere.
W3C recommends involving people with disabilities in evaluation. Their use adds experience that an automated check cannot fully represent. [7]
Such testing does not replace every requirement either. One person cannot represent all possible conditions of use.
Retrofitting: Start with essential workflows
For an existing application, I would first identify barriers that directly prevent use.
Can people sign in? Can required fields be completed? Can an order be finalised? I would prioritise these problems over a purely visual redesign.
Then I would look for shared causes. If the same inaccessible selection control appears throughout the application, correcting that component is more useful than many inconsistent local fixes.
Each change still needs evaluation in context. A new presentation may help in one place while concealing keyboard focus elsewhere.
I would not accept an added accessibility menu alone as evidence of sufficient accessibility. The relevant question is whether the application itself supports the required tasks accessibly.
Clear content remains an editorial responsibility
Technology cannot guarantee an understandable guide.
When a button says next, its destination should be apparent. The consequences of a binding action should be clear beforehand. Help belongs near the point where it is needed.
I would not put important information exclusively into a graphic. WCAG explicitly addresses text alternatives and limiting the use of images of text. [4]
For a blog, a title illustration can complement the article, but the heading and essential information should also be available as ordinary text.
Accessibility therefore requires collaboration between development, design and editorial work. Unclear content can make a technically correct interface unnecessarily difficult to use.
What people can report when something fails
Someone unable to use an application need not provide a complete technical diagnosis.
A short description helps: what task were they trying to complete, where could they no longer continue, and which input method or assistive technology did they use?
Personal details should preferably be concealed in screenshots. An understandable account of the problem matters more than sharing an entire customer account.
For providers, an accessible feedback route belongs in ongoing support. I would treat such reports not as special requests, but as concrete information about a function that cannot be used under certain conditions.
My conclusion: Accessibility is part of software quality
For me, accessibility does not begin with a badge or end with a one-off test.
It starts by deciding who should be able to use an application independently. That creates requirements for structure, operation, language and quality assurance.
Not every problem can be resolved immediately. It should nevertheless be clear which barriers exist, who is addressing them and how new functions are evaluated.
An application is not good merely because its developers can operate it. It must work for the people it is intended to serve.
Scope and research
Research date: 10 October 2026. General information, not a legal assessment of a particular offer or a complete technical accessibility evaluation. BFSG exemptions and transitional provisions require case-specific consideration; WCAG criteria alone do not cover every statutory duty.
Sources and further reading
Original sources checked on 10 October 2026. Publication and access dates are distinct.
Official source
Read source ↗
Official source
Read source ↗
Official source
Read source ↗
Official source
Read source ↗
Official source
Read source ↗
Official source
Read source ↗
Official source
Read source ↗
Official source
Read source ↗
Official source
Read source ↗
Official source
Read source ↗
Official source
Read source ↗