The most expensive accessibility is the kind you bolt on afterwards. Build a digital product to completion and only then check whether screen reader, keyboard and contrast cooperate, and you open construction sites in code and design that everyone else considers finished. Accessibility by Design reverses that order: access is anchored in the concept, in the design tokens and in the first components, not in a remediation project just before launch. This article explains why early integration is cheaper, which roles UX, development and editorial take on, how a Definition of Done makes accessibility binding, and which mistakes keep recurring in late-stage remediation. Since the German Accessibility Strengthening Act, conformance is no longer optional, and detectable WCAG failures still appeared on 94.8 percent (WebAIM Million, 2025) of the world's most-visited home pages.
Key takeaways
- Barriers are widespread: 94.8 percent of the most-visited home pages showed detectable WCAG failures, averaging 51 errors per page (WebAIM Million, 2025), and only 20 of 65 tested online shops worked by keyboard alone (Aktion Mensch, 2025).
- Fixing accessibility after launch often means paying twice - once for the inaccessible build, once for the rework - plus regression risk in mature code. The W3C Web Accessibility Initiative considers it most efficient and effective to build accessibility in from the very beginning of a project.
- Ownership is shared: UX supplies contrast and focus tokens, development writes semantic, keyboard-operable HTML with correct ARIA states, editorial handles structure and alt text, product and QA enforce acceptance against WCAG criteria.
- Design tokens for contrast, focus, typography and target size put accessibility at the source. A contrast token that permanently holds at least 4.5:1 for body text helps prevent contrast failures in every component instead of chasing them one by one.
- In the Definition of Done a task is finished only when it is keyboard operable, shows visible focus, meets contrast thresholds and reports form errors understandably. Automated tests found only around 57 percent of issues in one analysis (Deque, 2021).
- Recurring remediation traps are bought-in overlay scripts, missing semantics, focus added as an afterthought and years of content debt. The sequence requirements, tokens, components, Definition of Done, training and monitoring helps prevent them.
Why Bolting It On Gets Expensive
The state of the web speaks plainly. The annual WebAIM Million analysis of the one million most-visited home pages found detectable WCAG failures on 94.8 percent (WebAIM Million, 2025) of pages in 2025, an average of roughly 51 errors per home page (WebAIM Million, 2025). The figure improves only slowly; in 2024 it was still 95.9 percent (WebAIM Million, 2024). And these are only machine-detectable defects: the harder-to-find barriers in keyboard operation, focus order and understandable error messages come on top.
In Germany the same picture appears where revenue is directly at stake. A test by Aktion Mensch and Google examined 65 online shops in 2025; according to the test report, only about one third (Aktion Mensch, 2025) of the shops examined were accessible. Keyboard operability was especially poor: only 20 of 65 (Aktion Mensch, 2025) tested sites could be operated by keyboard alone without a mouse. The test report calls keyboard operability the basis of digital accessibility (Aktion Mensch, 2025).
Why bolting on gets expensive is shown by the path a defect takes through the project: a barrier overlooked in the concept travels through design, development and editorial until it ends up in dozens of templates, components and pieces of content at once. Getting it right once at the source spares correcting it in many places later. This is exactly where the shift-left idea comes in: testing and quality assurance move forward, to the start of the process, instead of fighting fires at the end.
Bolting On Often Means Paying Twice
What Accessibility by Design Means
The W3C Web Accessibility Initiative sums up the principle in one sentence: it is most efficient and effective to incorporate accessibility from the very beginning of projects, so work does not have to be redone (W3C Web Accessibility Initiative). Accessibility by Design turns that principle into a way of working: access is not a final checkpoint but a thread that runs through every phase.
In practice this means every discipline carries its share of the same requirement. The concept phase defines audiences and usage scenarios including assistive technology. Design sets contrast, focus states and spacing as reusable tokens. Development builds on semantic HTML and testable components. Editorial delivers structured, understandable content. And operations hold the achieved level through monitoring and fixed routines. The following six building blocks form this continuous foundation.
Concept
Audiences, usage scenarios and requirements are considered with assistive technology from the outset. WCAG 2.2 AA is written down as a measurable project goal, not a vague statement of intent.
Design Tokens
Contrast, focus, typography and spacing live as central design tokens in the system. Access is created once at the source and delivered automatically in every component.
Semantic Components
Buttons, forms, menus and dialogs are built with correct HTML, a sensible focus order and ARIA only where needed. Accessibility lives in the component, not in an afterthought.
Editorial and Content
Heading hierarchy, alt text, link text and plain language are created in the editorial process. Whoever adds content knows the criteria and the right tools.
Definition of Done
Accessibility is part of the acceptance criteria of every ticket. A task counts as finished only when it is keyboard operable, high in contrast and semantically correct.
Operations and Monitoring
After launch, automated checks, sampling and a fixed editorial routine hold the level. Every new feature passes the same criteria as the first.
Clear Roles: UX, Development, Editorial
Accessibility rarely fails on lack of knowledge and often on unclear ownership. When no one feels responsible, the topic falls between the disciplines. Accessibility by Design therefore distributes responsibility explicitly rather than loading it onto a single person. The overview below shows who contributes what and what happens when a role stays vacant.
| Role | Contribution in the Process | If the Role Is Missing |
|---|---|---|
| UX and Design | Contrast and focus tokens, operable states, clear labels and a logical order | insufficient contrast and invisible focus that must be adjusted laboriously later |
| Development | Semantic HTML, keyboard operability, correct ARIA states, testable components | div soup without semantics that excludes screen reader and keyboard |
| Editorial | Heading structure, alt text, understandable link and error text | content barriers that make even technically clean pages unusable |
| Product and QA | Definition of Done, prioritization, acceptance against WCAG criteria | accessibility without an acceptance criterion that quietly drops under deadline pressure |
This division of roles has a concrete audience. At the end of 2023, around 7.9 million (Federal Statistical Office, 2024) severely disabled people lived in Germany, equal to 9.3 percent (Federal Statistical Office, 2024) of the population. People with impairments also use online shops more frequently on average than people without impairments (Aktion Mensch, 2025). Involving editorial ensures that good engineering does not fail on hard-to-understand content; how that works is described in the article on training the editorial team for accessible content. The same principle applies beyond the website, for example to accessible newsletters and email marketing.
Design Tokens: Writing Accessibility Into the System
A particularly effective lever for early accessibility sits in the design system. When contrast, focus states and spacing are defined as central tokens, no one has to reinvent or forget them in each component. A contrast token that permanently holds the WCAG ratio of at least 4.5:1 for normal text makes contrast errors unlikely at the root, instead of hunting them one by one later. How to set and check contrast correctly is explored in the article on color contrast in accessibility.
- Contrast tokens: Text, border and status colors meet the WCAG thresholds and are maintained centrally rather than per page.
- Focus tokens: A visible, consistent focus ring applies to all interactive elements so keyboard use always remains traceable.
- Typography tokens: Font size, line height and line length are designed for readability and scalability, as described in the article on accessible typography.
- Spacing and target-size tokens: Touch targets and click areas are large enough and sufficiently separated so users with motor impairments can hit them reliably.
One Token Saves Many Individual Fixes
Definition of Done: Accessible Means Finished
So that accessibility does not vanish under deadline pressure, it needs a binding acceptance criterion. The Definition of Done sets out when a task is truly complete. Anchor access there, and a feature is finished only when it also works with keyboard and screen reader, not already when it looks operable with a mouse. That moves testing from the expensive end to the place where the work happens anyway.
It is important not to rely on tools alone. Automated testing tools found only around 57 percent (Deque, 2021) of issues in one analysis. Criteria such as a sensible focus order, understandable error messages or genuine operability can only be assessed manually. A workable Definition of Done therefore combines an automated check with a short manual keyboard and screen reader test.
- The feature is fully operable by keyboard and the focus order is logical.
- Focus is visible at all times and no element is focused without feedback.
- Text and controls meet the WCAG contrast thresholds from the token system.
- Headings, labels and alt text are present and semantically correct.
- Form errors are reported understandably and announced programmatically, as described in the article on accessible forms and validation.
- An automated check plus a short manual keyboard and screen reader test were carried out.
The One Sentence That Makes the Difference
Typical Mistakes in Late Remediation
Those who remediate late keep hitting the same patterns. Knowing them helps avoid them from the start. The following six failure sources appear regularly in remediation projects and can usually be avoided in the concept phase with less effort than it takes to fix them later.
The Overlay Illusion
A purchased overlay script promises a quick fix but does not remove the underlying barriers. Why this is not a BFSG solution is shown in the article on accessibility overlays.
Missing Semantics
If everything was built from generic containers, the structure screen readers rely on is missing. Retrofitting semantics often means rewriting components.
Focus as an Afterthought
Without a focus token, every interaction has to be fixed individually. Keyboard navigation becomes a patchwork instead of one consistent behavior.
Color System Without Contrast
A grown color palette without contrast rules forces later compromises between brand and readability that a token system would have prevented from the start.
Content Legacy
Missing alt text, muddled headings and inaccessible PDF documents pile up over years. Reworking them later ties up considerable editorial time.
No One Is Responsible
Without clear roles and a Definition of Done, accessibility remains a special project that starts over after the next relaunch instead of being part of daily work.
From Concept to Operation: the Roadmap
Moving to Accessibility by Design works step by step and need not be a mega-project. Following the order below anchors access where it originates and turns it into a habit rather than an exception. Accessible web development from the ground up follows exactly this path.
- Write down the requirements: Add WCAG 2.2 AA and the relevant BFSG requirements as a measurable goal in the concept and backlog.
- Define design tokens: Set contrast, focus, typography and target sizes centrally in the design system before components are built.
- Build components accessibly: Put semantics, keyboard operation and tested states into the building blocks all pages are made from.
- Extend the Definition of Done: Add accessibility as an acceptance criterion to every ticket, including a short manual test.
- Enable editorial: Equip the team through accessibility training with criteria and tools so content is created accessibly.
- Secure operations: After launch, prove the level with a WCAG audit and hold it permanently through monitoring.
Germany's Federal Accessibility Agency (Bundesfachstelle Barrierefreiheit) shows how great the need for guidance is: its initial consultations rose 9 percent in 2023, website visits grew 29 percent, and digital accessibility was the most frequent topic of initial consultation requests (Bundesfachstelle Barrierefreiheit, 2023). Accessibility also serves goals beyond compliance: according to the W3C Web Accessibility Initiative, accessible design often improves the overall customer experience and loyalty and helps minimize legal risk (W3C Web Accessibility Initiative).
Accessibility from the start is not an extra task but a better order of work. You build the same thing right once, instead of paying for it twice.
Distributing access across the whole process turns BFSG conformance from a remediation project into a property of your own system. Which steps make sense for your project and where your team should begin, we are happy to clarify without obligation via the contact page or as part of our digital accessibility services.
Sources and Studies
Related Articles
Accessible AI Chatbots: WCAG-Compliant Voice Bots
When AI chatbots and voice assistants fall under the BFSG and how conversational UI becomes WCAG-compliant with ARIA live regions and focus management.
Which Website Content the BFSG Leaves Out
Section 1(4) BFSG exempts five types of content. How to split a grown document stock - and how the exemption quietly comes to an end.
Keeping Accessibility: Review Cadence After Go-live
The duty does not end at acceptance. Which events trigger a re-test, which sample size holds up and how long the evidence has to stay on file.