Have a website audited for accessibility and you often get back a report with dozens of findings - only to notice that the same errors repeat on every subpage. The button with no visible focus, the form field without a label, the modal that traps the keyboard: these defects are not created page by page but come from a handful of building blocks reused everywhere. This is exactly where the most effective lever sits. The WebAIM Million Report 2025 shows that 96% (WebAIM Million, 2025) of all automatically detectable errors come from just six recurring patterns - all of them properties of components, not of individual pages. Build these blocks correctly once, and you stop the same violation from multiplying across hundreds of pages. This guide shows how an accessible design system takes shape: from focus and keyboard operation through ARIA to testing - and how a tested component library becomes the core of accessible web development.
Key takeaways
- Errors originate in building blocks, not on pages: 94.8% (WebAIM Million, 2025) of home pages carry automatically detectable WCAG failures - on average 51 (WebAIM Million, 2025) per page, because the same faulty component is reused many times.
- Six patterns are enough: insufficient contrast, missing alt text, unlabeled form fields, empty links, empty buttons and missing page language make up 96% (WebAIM Million, 2025) of all errors - each of them a component or token problem.
- A visible focus indicator, anchored once as a token in the design system, satisfies WCAG 2.4.7 on every interactive component at once.
- Keyboard operation is a property of the component: if menu, modal and slider are operable with Tab, Enter and Escape from the start, the problem never appears on any page.
- ARIA belongs encapsulated in the component, not in editorial hands: roles and states set correctly once prevent the common trap that wrong ARIA is worse than none.
- An audit of the component library prioritizes by reuse: the button that sits on every page is checked before the special case that occurs only once - the greatest effect per unit of effort.
Why the Same Error Multiplies
Modern websites are made of reused building blocks. The average home page contained around 1,257 (WebAIM Million, 2025) HTML elements in February 2025, and very few of them are hand-written - they come from templates, components and libraries that produce the same markup in many places. That is why a single faulty component runs through an entire website: a button without an accessible label creates not one error but as many as it has appearances. The WebAIM Million Report counted on average 51 (WebAIM Million, 2025) errors per home page - a number that only makes sense if a few causes repeat many times over.
The analysis confirms exactly this. The six most common error types account for 96% (WebAIM Million, 2025) of all findings, and none of them is a one-off content issue: insufficient text contrast affected 79.1% (WebAIM Million, 2025) of pages, missing alt text 55.5% (WebAIM Million, 2025), unlabeled form fields 48.2% (WebAIM Million, 2025), empty links 45.4% (WebAIM Million, 2025), empty buttons 29.6% (WebAIM Million, 2025) and a missing page language 15.8% (WebAIM Million, 2025). Each of these points maps to a component or a design token - and can therefore be fixed in one place instead of on every page again.
One error, a hundred instances
The Six Most Common Errors Are Component Errors
It pays to read the six patterns from the WebAIM Million Report consistently as component questions. Once you map them to building blocks, a long list of defects becomes a short task list for the design system. Five of the six patterns disappear once five blocks are built correctly; the sixth is a single line in the base scaffold.
Contrast token
79.1% (WebAIM Million, 2025) of pages fall below the contrast threshold. Define text and surface colours as tested design tokens and every component satisfies WCAG 1.4.3 automatically.
Image component
55.5% (WebAIM Million, 2025) have images without alt text. An image component that enforces an alt attribute and marks decorative images as such closes the gap.
Form field
48.2% (WebAIM Million, 2025) contain fields without a label. A field component that couples label and input inseparably makes the unlabeled field impossible.
Link and icon button
45.4% (WebAIM Million, 2025) have links with no discernible text. An icon button that will not render without an accessible label enforces WCAG 2.4.4 at the root.
Button component
29.6% (WebAIM Million, 2025) contain buttons without a label. A button component with a mandatory label - visible or via aria-label - never lets the empty button happen in the first place.
Page language
15.8% (WebAIM Million, 2025) declare no page language. A base scaffold that sets the lang attribute centrally handles WCAG 3.1.1 for all pages at once.
Looking at the percentages makes the leverage tangible: with image, form field, link, button and the colour system built correctly, five of the six patterns disappear; the sixth, page language, is a single declaration in the base scaffold. Thus the bulk of the machine-detectable barriers is not a question of editing but of architecture. Automated testing, however, only covers part of it; keyboard operation, focus order and meaningful ARIA states only show up in a WCAG audit with manual testing.
Making Focus Visible - Once, in the System
The visible focus is the textbook example of the component approach. WCAG 2.4.7 requires that the currently focused element be clearly recognizable - indispensable for everyone navigating by keyboard. In practice the default focus ring is often removed wholesale via CSS because it is felt to be distracting, and not replaced. This makes every interactive component unusable for keyboard users in one stroke. The solution lies not in editing but in the system: a single, clearly visible focus style - defined as a design token with sufficient contrast and a distinct outline - applies to every button, every link and every field at once.
WCAG 2.2 added two criteria that further secure focus: 2.4.11 requires that the focused element not be fully obscured by other content such as sticky headers, and 2.4.13 sets minimum requirements for the size and contrast of the focus indicator. Both can be solved centrally - through the token for the focus style and the scroll behaviour of the layout. Which criteria WCAG 2.2 newly introduced is explained in the article on the new WCAG 2.2 criteria.
One token, every component
Keyboard Operation as a Property of the Component
Everything that works with the mouse must also work with the keyboard - that is how WCAG 2.1.1 sums up the requirement. For simple elements such as native links and buttons this comes for free, because the browser brings the operation with it. It gets critical with composite components: menus with sublevels, modals, tabs, accordions, sliders and custom select fields. Built from generic div elements without keyboard logic, they are operable with the mouse but dead to the keyboard. And a modal that does not capture and release focus violates WCAG 2.1.2 - the user stays trapped.
The decisive point: this operating logic belongs in the component, not in each individual use. A modal block that captures Tab navigation, closes on Escape and returns focus to the triggering button afterwards solves the problem for every use across the whole project. How to steer focus cleanly in dynamic interfaces and single-page applications is explored in the article on focus management in single-page apps; the concrete patterns for overlapping layers are covered in the article on accessible modals and overlays.
- All interactive elements are reachable with the Tab key in a meaningful order
- Enter and Space activate buttons; arrow keys steer menus, tabs and sliders
- Escape reliably closes modals, overlays and expanded menus
- No element traps focus permanently - the way in and out stays free
- A skip link leads directly to the main content ahead of the navigation
- Focus order follows the visible arrangement, not the source-code order
These points are not an add-on but part of the definition of what makes a finished component. A deeper treatment of keyboard patterns - from logical order to expected key bindings - is offered in the article on keyboard navigation in web development.
Encapsulate ARIA Sparingly and Correctly
The first rule for ARIA sounds paradoxical: use no ARIA if you can. A native button element brings role, focusability and keyboard operation with it; a div with role=button has to rebuild all of that laboriously. The W3C's WAI-ARIA practice explicitly warns that wrongly set ARIA degrades accessibility rather than improving it - a state that does not match reality leads screen reader users astray. For a design system this means: wherever a native HTML element suffices, it takes precedence.
Cases remain in which ARIA is indispensable: tabs, accordions, custom select fields or live regions for dynamic status messages. The right place for it is the inside of the component, not the editorial surface. Once the roles, states and relationships are set correctly and tested by specialists, no one can use them wrongly by accident. How roles, states and live regions interact and where the common mistakes lie is covered in the article on ARIA roles, states and live regions. For status and error output, the article on accessible error and status messages adds the matching patterns.
| Pattern | Fragile (heavy ARIA) | Robust (native first) |
|---|---|---|
| Button | div with role=button and keyboard script | button element |
| Dropdown menu | nested divs with aria attributes | details and summary or a tested menu component |
| Required-field hint | colour alone signals the error | label, aria-describedby and text message coupled |
| Status message | silent change in the DOM | role=status in an encapsulated live region |
Build Accessibility Into the Component
The economic core of the component approach is timing. Accessibility built into the blocks costs, in our experience, a fraction of what a retrofit across hundreds of pages devours. Each component is thought through, tested and documented once - after that, accessibility arises as a by-product of ordinary work. This shift forward, often described as accessibility by design, prevents defects from accumulating in the first place. Why the early build pays off against late retrofitting is explored in the article on accessibility by design.
An accessible design system, however, consists of more than code. Each component comes with short documentation that records how to use it: which alt text is needed, which heading level fits, when a live region makes sense. This keeps the knowledge available even as teams change. In addition, fundamentals such as tested colour values and readable typography secure the visual layer - explored in the articles on colour contrast in accessibility and on accessible typography and readability. And because even the best system only works if editors use it correctly, training for content teams is a firm part of it.
Not every piece of content comes from the system
Testing Components: Automated and Manual
A design system has a further advantage: it can be tested at a central, manageable point. Instead of checking a thousand pages, you check a few dozen components in their variants. Automated tools reliably cover the machine-detectable errors here - missing labels, insufficient contrast, invalid ARIA combinations - and can be built into the development pipeline so that a violation surfaces before the component goes into circulation. Automated checks, however, only capture part of the criteria; the rest only shows in manual testing.
- Automated component test on every change, right in the development pipeline
- Manual keyboard test of every interactive component without a mouse
- Test with at least one screen reader per platform
- Check of focus order and the visible focus indicator
- Control of states such as error, loading and selection
- Regression test so that a change does not break existing accessibility
The effort of this testing arises once per component and amortizes across every use. Especially valuable is feedback from people who work with assistive technology every day - it uncovers hurdles no checklist foresees. For a running system, a recurring check as provided by accessibility monitoring is also advisable, so that later changes do not quietly undermine the quality achieved.
Audit an Existing System or Build a New One
In practice, businesses face two situations. Either a component library already exists, then it is about a targeted audit: which blocks violate WCAG, and in what order is repair worthwhile? Priority follows from reuse - the button and the form field that sit on every page are checked before the special case that occurs in only one place. This yields the greatest effect per hour invested. Or there is no system yet, then it is worth building the central blocks to be accessible from the start rather than laboriously patching them later.
Both paths run over the same substance: clearly defined components with documented accessibility, tested with automated and manual means. In our reference projects we start exactly here - the blocks first, the surface second. Which offerings fall under the German Accessibility Act and which deadlines apply is explained in the BFSG requirements. Related building blocks also benefit from the system mindset: understandable content, covered in the article on plain language for understandable web texts, and moving elements as in the article on accessible sliders and carousels.
An accessible website does not come from repairing a thousand pages but from building fifty components correctly. The rest follows on its own.
The path through the design system inverts the logic of accessibility. Instead of fighting errors where they become visible - on the individual page - it addresses the source they come from. Because 96% (WebAIM Million, 2025) of all machine-detectable errors come from six patterns and each of them maps to a component, a library that is clean once turns the bulk of the BFSG obligation into a question of architecture. This not only saves effort, it also keeps the quality achieved stable: every new page built from tested blocks is operable from the very first line - for people with disabilities as well as everyone else.