Web Accessibility: Building Inclusive Apps from Day One

In short: Web accessibility means people can fully use an application with a screen reader, with only a keyboard, with zoom or with limited color vision. The benchmark is the Web Content Accessibility Guidelines (WCAG), usually at level AA. Since June 2025, Germany's Accessibility Strengthening Act (BFSG), which implements the European Accessibility Act, requires many businesses that sell products or services to consumers online to be accessible. Planning for it from the start costs far less than retrofitting it later.

What the European Accessibility Act requires in Germany

The BFSG transposes the European Accessibility Act into German law and has applied since 28 June 2025. It covers, among other things, online shops and other e-commerce services for consumers, banking services, e-books and parts of passenger transport. Microenterprises providing services are exempt, meaning companies with fewer than ten employees and an annual turnover or balance sheet of no more than two million euros. Pure B2B offerings generally fall outside the law.

On the technical side, the law refers to the harmonized standard EN 301 549, which in turn builds on WCAG. The BFSG also requires an accessibility statement that describes how the requirements are met. Whether your offering is covered should be checked legally for your specific case. This post is not legal advice.

Accessibility pays off regardless of the legal duty. It improves usability for everyone, for example on a phone in bright sunlight or for older users, and semantically clean HTML helps search engines too.

The basics of accessible web development

Semantic HTML

The most important step costs almost nothing: use the right HTML elements. A button is a <button>, not a <div> with a click handler. Headings follow a logical hierarchy, navigation sits in <nav>, the main content in <main>. Screen readers use this structure to find their way around the page. ARIA attributes supplement HTML for cases it does not cover. They do not replace it, and used wrongly they tend to make things worse.

Keyboard access and focus

Everything you can do with a mouse must also work with a keyboard. Focus must be visible at all times, and the tab order should follow the reading order. Dialogs, dropdown menus and custom components like date pickers are especially critical. When a modal opens, focus moves into it, and when it closes, focus returns to the element that opened it.

Contrast, color and text

WCAG AA requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text. Information must not be conveyed by color alone, such as a form field marked red without an error message. Text should scale to twice its size without content being cut off. Our post on the psychology of color in digital products covers how color choices work.

Images, media and forms

Informative images need alternative text that describes their content, and decorative images an empty alt attribute. Videos need captions. Every form field needs a visible, correctly associated label, and error messages must say clearly what is wrong and how to fix it.

Building accessibility into the development process

Accessibility is cheapest when it lives in the building blocks. A design system with tested, accessible components means every new screen inherits the basics automatically. In React projects, libraries like Radix UI or React Aria already implement correct keyboard handling and ARIA behavior for complex components.

Testing can be largely automated as well. The ESLint plugin jsx-a11y catches errors in the editor, axe-core checks pages in unit and end-to-end tests, and Lighthouse gives a quick overview. Our article on testing strategies for React applications shows how these tests fit into a wider strategy. Automated tools only find part of the problems, though. Add manual testing with a keyboard and with screen readers such as NVDA on Windows or VoiceOver on macOS and iOS.

Frequently asked questions (FAQ)

Is my website covered by the accessibility law?

If you sell products or services to consumers through the website, for example in an online shop or with online booking, it probably is. Microenterprises providing services are exempt. Have your specific case reviewed by a legal advisor.

Which WCAG level should we aim for?

Level AA is the usual benchmark and the basis of the European standard. Level AAA is hardly achievable for an entire website and is recommended only for specific content.

Is an accessibility overlay or plugin enough?

No. Overlays that add features through a script after the fact do not fix the underlying problems in the code, and many people with disabilities find them disruptive. Accessibility has to be built into the HTML, the design and the components.

What does it cost to make an existing website accessible?

That depends heavily on the state of the code. A WCAG audit shows which problems exist and how much effort fixing them takes. For new builds the extra effort is small when accessibility is part of the requirements from the start.

Conclusion

Accessibility is first a matter of solid basics: semantic HTML, keyboard access, sufficient contrast and accessible components. Building these into your design system and tests from the start meets the legal requirements without expensive rework. If you are planning an accessible web application or want an existing one reviewed, talk to us about accessible web development.