Design systems are no longer just about visual consistency. They’re a critical foundation for preventing accessibility failures, reducing remediation costs, and supporting compliance with ADA, EAA, and WCAG standards.
Accessible design systems address a pressing need: in 2025, 94.8% of home pages had detectable WCAG violations, many stemming from repeated component errors like buttons without focus indicators, modals that trap keyboard users, and forms without proper error messaging. Fix these issues once in your design system, and you prevent them from propagating across every page, product, and team.
Important: An accessible design system provides essential building blocks, but doesn’t guarantee full application accessibility. Even with accessible components, implementation issues can still create barriers. Developers can misuse components, create problematic page layouts, omit required labels, or break keyboard navigation through custom code. Your design system creates the foundation: governance, training, and comprehensive testing ensure compliance at the application level.
This guide helps product owners, developers, and design leads build an accessibility-first design system using Figma, component libraries, and automated testing.
Why Accessibility Must Be Built Into Your Design System
One fix equals global compliance
Update a single button component and instantly fix hundreds of instances across your app.
Faster QA and fewer bugs in production
Automated testing using tools like axe-core can help catch accessibility issues early. Research shows that automated tools found 57% of issues by volume in Deque’s analysis of 13,000+ pages, though manual testing remains essential for comprehensive coverage.
Stronger RFPs and enterprise contracts
Deliver VPAT-ready documentation that proves compliance at the component level.
Improved SEO and user experience
Semantic structure, proper labeling, and keyboard support help search engines and all users.
What Your Design System Can’t Fix
Design systems alone cannot prevent every accessibility issue. They can’t address:
- Content-level decisions: Writing meaningful alt text, creating logical heading hierarchies, and providing clear labels
- Page structure: Navigation flows, skip links, landmark regions, and reading order
- Component usage context: The same image may require different descriptions depending on context; forms need specific error messages based on their purpose
- Layout and responsive design: How components adapt to different zoom levels, viewport sizes, and screen orientations
- Third-party integrations: External widgets and embedded content
Having accessible components doesn’t guarantee an accessible page—always test complete pages and user journeys.
Step 1: Figma – Design with Accessibility Tokens from the Start
Don’t leave accessibility to developers. Embed it in your design tokens during the earliest phase.
Essential Accessibility Tokens to Define:
Token: focus/ring-color
Value: #0066FF
WCAG Reference: 2.4.7 Focus Visible
Token: focus/ring-width
Value: 3px
WCAG Reference: Non-text contrast ratio of 3:1 or higher
Token: spacing/touch-target
Value: 44px minimum
WCAG Reference: 2.5.5 Target Size
Token: color/aa-large
Value: #1A1A1A on #FFFFFF
WCAG Reference: 1.4.3 Contrast for large text
Figma Accessibility Audit Checklist
- Focus indicators clearly visible in high-contrast mode
- All interactive elements meet 44×44 px touch target minimum
- All text and icon combinations pass AA contrast (or AAA for enterprise)
- Image components include required alt text placeholders
- Keyboard navigation order matches logical reading flow
Recommended Figma Plugin: A11y – Color Contrast Checker (free)
Step 2: Build Accessible Components That Scale
Focus on the four most common problem areas: buttons, modals, forms, and data tables.
Key Principles for Every Component
- Use semantic HTML elements (never <div> for buttons or links)
- Include visible focus indicators that meet WCAG 2.4.7
- Ensure touch targets are at least 44px tall and wide
- Add proper ARIA labels and roles for screen readers when necessary
- Support full keyboard navigation (Tab, Enter, Escape)
WCAG Success Criteria Covered:
- 1.3.1 Info and Relationships
- 2.1.1 Keyboard
- 2.4.7 Focus Visible
- 2.5.5 Target Size
- 4.1.2 Name, Role, Value
Remember: Page-Level Concerns
Semantic HTML and ARIA in components are starting points. Implementation must address heading hierarchy, skip links, landmarks, and content reading order.
Step 3: Automate Accessibility Testing in CI/CD
Catch issues before they ship. Add accessibility testing to your GitHub Actions, GitLab CI, or Jenkins pipeline.
Recommended Tools
- Storybook + Chromatic – Visual regression with a11y snapshots
- axe-core – Catches 57% of WCAG issues automatically
- pa11y – Full-page accessibility reports
Understanding Automated Testing Limits
According to Accessible.org’s analysis, roughly 13% of WCAG 2.2 AA criteria can be flagged with mostly accurate results, while approximately 45% can be partially detected with varying reliability. The remaining 42% cannot be detected at all by automated tools.
In practical terms, the UK Government Digital Service found that the best performing automated tool detected 40% of known accessibility barriers, while the worst performing tool only picked up 13%. These tools excel at finding technical violations but cannot evaluate subjective qualities like whether alt text accurately describes an image or if content is clear and understandable.
Critical gaps automated tools miss:
- Context-dependent alt text quality
- Logical reading order and heading structure
- Full keyboard navigation patterns
- Screen reader user experience
- Cognitive accessibility issues
Run automated tests on every pull request and fail builds for critical issues, but always supplement with manual testing.
Step 4: Document Components for VPAT and Compliance Reporting
Create a living accessibility compliance report for your design system.
Example Documentation Format
Component: Primary Button
WCAG 2.2 AA Success Criteria: 1.4.3, 2.4.7, 2.5.5
Tested With: axe DevTools, NVDA screen reader
Notes: 3px focus ring, 44px min height, semantic <button> element
Component: Modal Dialog
WCAG 2.2 AA Success Criteria: 2.1.2, 4.1.2
Tested With: Keyboard navigation, VoiceOver
Notes: Focus trap enabled, aria-modal="true", Escape to close
Export this report as a PDF and attach it to VPAT/ACR requests. Learn more in our guide: What Is a VPAT and Do I Need One?
Final Checklist: Is Your Design System Truly Accessible?
- All interactive elements have visible focus indicators
- Touch targets meet 44px minimum in mobile and desktop
- Color contrast tokens are enforced across all themes
- ARIA roles and labels are documented and consistent
- Automated accessibility tests run in CI/CD
- Component library includes WCAG compliance mapping
FAQ: Accessbility in Design Systems
How do I ensure focus indicators are visible across all themes?
Define a focus/ring-color token with a contrast ratio of at least 3:1 against both light and dark backgrounds . Test in Figma using the A11y Color Contrast Checker plugin, and enforce the same rule in CSS with focus-visible:ring.
How do I scale accessibility audits when my design system has 50+ components?
Prioritize high-impact components first: buttons, forms, modals, navigation, and data tables. Use Storybook to isolate them, run axe-core in Chromatic, and create a shared compliance report. Audit new components during design review, not after release..
How should I handle dark mode accessibility?
Test color contrast in both light and dark themes. Use the CSS prefers-contrast: high media query to support Windows High Contrast mode users .
My team uses Sketch, not Figma. Does this still apply?
Absolutely. Use the Stark plugin for contrast checking, focus order, and alt text (the same principles apply across tools).
Should I document ARIA roles in Figma or only in code?
Do both. In Figma, add ARIA labels as component descriptions or comments. In code, include them in your documentation file (e.g., components.md). This ensures designers and developers stay aligned and supports VPAT reporting.
Can automated tools like axe-core catch all component issues?
No. axe-core catches about 57% of WCAG violations . Use it in CI/CD for fast feedback, but always follow up with manual testing using screen readers (NVDA, VoiceOver) and keyboard navigation.
Ready to Make Your Design System Accessibility-Compliant?
Stop fixing the same WCAG errors across every sprint. Let us audit one of your core components live and show you exactly what’s missing.
Book a Free 15-Minute Accessibility Audit
We’ll review your button, modal, or form (and give you a compliance score on the spot).