Design systems help with accessibility, but they’re not the full solution.
On June 28, 2025, the European Accessibility Act (EAA) makes digital accessibility a legal requirement for any product or service used within the EU. The WCAG 2.2 regulation also affects companies outside Europe serving EU users.
The upcoming regulations introduce new success criteria, increased focus on cognitive accessibility, and stricter Level AA standards. With the deadline of WCAG 2.2 approaching, companies have limited time to align with these updated requirements. Falling short of compliance after June 28, 2025, may lead to legal risks and affect your brand’s reputation. Starting now helps to plan effectively and prioritize key accessibility improvements.
Architecture-First Accessibility: Building Compliance into Your Design System
Design systems offer a powerful approach to accessibility compliance by embedding accessible patterns directly into reusable components. When accessibility is built into components at the system level, it provides a strong foundation for products to meet WCAG compliance more efficiently. However, this alone isn’t enough to fully achieve accessibility and it's important to understand both the capabilities and limitations of this approach.
Component-Level Enforcement
Component-Level Enforcement Each UI element should help ensure accessibility is built in by using consistent, reusable solutions from the design system. For instance:
Semantic HTML enforcement: Inputs should have labels. This could be the markup for your form field component, while you link all components together in the background:
<FormField>
<FormFieldLabel>
Label
</FormFieldLabel>
<FormFieldHelperText>
Helper text
</FormFieldHelperText>
<TextInput />
</FormField>HTML output:
<div class="form-field">
<label
class="form-field-label"
id=":r2r:"
for=":r2q:"
>
Label
</label>
<p
class="form-field-helper-text"
id=":r2s:"
>
Helper text
</p>
<input
class="text-inpu"
id=":r2q:"
aria-describedby=":r2s:"
>
</div>As you can see, all fields have been linked properly without the implementor having to worry about that. This improves DX and UX at the same time, which is nice.
Programmatic validation: Some aspects of accessibility can—and should—be baked into your system and validated automatically. For example image components require alt text props with TypeScript interfaces that enforce descriptive content, or color palette tokens are validated against WCAG contrast ratios at build time.
Standardized interaction patterns: Complex widgets like dropdowns, modals, and date pickers implement consistent keyboard navigation, focus management, and ARIA patterns that have been tested against assistive technologies. Using ‘headless components’, like the ones from HeadlessUI or React Aria, could help you with setting this up correctly, as they often have accessibility baked-in (be sure to always double-check that though).
Expose Internal Accessibility Tools
When dealing with edge cases, implementors benefit from access to the same lower-level utilities that power the design system’s own components. In a Button component, a live region could be used for announcing loading states. What if we expose the utilities used for this, so higher level components (like dynamic lists) can benefit from this too?
import { addMessage, getContainerEl } from '@design-system/shared';
export const useLiveRegion = () => {
return {
announce(message: string, assertiveness: 'assertive' | 'polite' = 'polite') {
const containerEl = getContainerEl();
addMessage(containerEl, message, assertiveness);
},
};
};
Limits and Realistic Expectations
A well-designed system can lay a strong foundation for accessibility, but on its own, it’s not enough. True accessibility requires human judgment and a broader understanding of context. Consider these examples:
- Content and labeling remain critical human responsibilities; the system can enforce required alt text props, but ensuring clarity, specificity, and meaningfulness can only be achieved by content creators and developers.
- Dynamic interactions and state management often require custom solutions informed by specific application logic and user flows, such as dynamic lists or tables that change content based on filters.
- Component composition matters; even if individual components are accessible, their combination can create confusing or exclusionary patterns for users.
This is why we say that our design systems enable accessibility - they don't guarantee it. Achieving accessible outcomes depends on collaboration across design, development, content, and QA teams.
Practical Steps to Get Ready
With the EAA deadline approaching, here's what we recommend for businesses:
- Audit your current design system against WCAG 2.2 AA criteria. Check color contrast ratios, form element associations, focus states, and keyboard navigation patterns. But don't stop there—test with actual users of assistive technologies to understand real-world usage patterns.
- Create standardized patterns for common accessibility needs like focus management, live regions for dynamic content, and error message associations. Document not just how to use these patterns, but when and why to use them.
- Invest in comprehensive documentation that includes accessibility guidance for each component, showing developers exactly how to implement accessible patterns. Include anti-patterns and common mistakes to avoid.
- Build accessibility expertise across your organization through training, regular reviews, and open communication channels for accessibility questions and feedback. Consider having advocates available to teams who can bridge the gap between design system capabilities and specific use cases.
- Integrate automated accessibility checks into your development workflow. Use tools like axe-core, Lighthouse CI or pa11y in your continuous integration (CI) pipeline to catch issues early and consistently. These checks help maintain a baseline of accessibility.
Ready for a second opinion on your website's accessibility?
Our Accessibility Review helps you make your website usable for everyone, regardless of ability, device or situation. With expert analysis, hands-on improvements and clear guidance, we ensure your site meets legal standards and delivers a better experience for all users.
