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 94.8 percent (WebAIM Million, 2025) of the world's most-visited home pages show that the bolt-on strategy rarely works out.
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. 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; only about one third (Aktion Mensch, 2025) met basic requirements, and two of three shops were not 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 Federal Monitoring Agency for Accessibility notes that barely a third of sites meet the central criterion of keyboard operability (Federal Monitoring Agency for Accessibility, 2025).
These numbers explain why bolting on is so expensive. 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 costs a fraction of correcting it in many places later (project experience). 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: planning accessibility from the start of a project is almost always significantly easier, less expensive and more effective than fixing an existing site later as a separate project (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. This group is above-average active online: people with disabilities use online shops more frequently on average than people without disabilities (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
The most 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 Hundreds of 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 typically capture only 30 to 40 percent (Deque, 2021) of barriers. 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 are almost always more expensive to fix than they would have been in the concept phase (project experience).
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.
That this path pays off is also shown by the growing demand for guidance: initial consultation requests to the Federal Monitoring Agency for Accessibility rose 9 percent in 2023, and website visits grew 29 percent (Federal Monitoring Agency for Accessibility, 2023), with particular interest in digital accessibility. Early integration also serves goals beyond compliance: better search engine optimization, reduced legal risk and higher customer loyalty (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