Zoomed-in view of the design system's Accessibility guidelines documentation page, showing dark tooltip callouts for touch target size, line height, focus outline and color contrast requirements over a textured blue background
Design SystemAccessibility

Embedding Accessibility into the Core of a Design System to promote inclusive design

During my time spent as a Design System Designer, I've tackled different challenges, such as implementing design tokens, creating, documenting and improving components. Nonetheless, the most complex and meaningful challenge has been without a doubt tackling the topic of Accessibility.

TIMELINE

Aug 2022 - June 2025

TEAM

3 designers, 1 engineer, 1 product owner

ROLE

  • Accessibility expert
  • Implemented WCAG principles into design system components and foundations
  • Drafted accessibility guidelines for the components documentation.

One-Minute Project Overview

PROBLEM

The company design system has never tackled seriously the topic of Accessibility before: elements do not comply with WCAG principles in many cases, and documentation is lacking accessibility guidelines.

SOLUTION

Conducted an accessibility audit to spot incompliances. Changed inaccessible color matches, revised font sizes and line heights, and added accessibility guidelines to the documentation.

OUTCOME

  • Boosted accessibility awareness throughout the company
  • 100% of color matches in components passing minimum contrast requirements.
  • Added accessibility guidelines to documentation of all components and foundations.
Accessibility & Design System

Embedding accessibility principles into Design System components

The challenge

Accessibility gap: The existing design system did not meet accessibility standards, creating barriers for users with visual, motor, and cognitive impairments.

Inconsistent UI Components: Color contrast, typography, and interactive elements were inconsistent, leading to usability issues and poor design scalability.

Legal and cultural shift: 2025 legislation required WCAG 2.1 AA compliance, while stakeholders needed greater awareness of inclusive design's value.

The solution

As a Design System Designer, together with the Lead Designer, I've played a major role in embedding WCAG principles across foundations, components, and documentation. Key areas of improvements to which I contributed include:

  • Color contrast: Adjusted palette to meet minimum contrast ratios (4.5:1 for text, 3:1 for UI elements).
  • Typography: Increased font sizes and line heights for readability; ensured scalable units for responsive design.
  • Touch targets: Enlarged interactive elements to meet the 44x44px minimum for touch devices.
  • Focus states: Added clear, visible focus indicators for keyboard navigation.
  • ARIA Support: Documented semantic roles and attributes for assistive technologies.
  • Documentation: Created accessibility guidelines to ensure developers and designers could apply best practices consistently.

Results and Measurable Impact

WCAG 2.1 Compliance: Design system now meets WCAG 2.1 AA standards across all components.

Inclusive experiences: an accessible design system is the base for fostering inclusive design throughout the company.

Reduced design inconsistencies: following WCAG guidelines turned out to improve the design system quality and efficiency.

Future-Proofing: Teams are equipped with knowledge and tools to maintain accessibility in new features.

The process

Embedding WCAG 2.1 Principles into Components & Foundations

Colors

Ensuring WCAG-compliant contrast and clear status indicators beyond color alone

I've adjusted palette to meet minimum contrast ratios (4.5:1 for text, 3:1 for UI elements).

WCAG Success Criteria:

Screenshot of button components with insufficient color contrast

Before

❌ Insufficient color contrast between background and text

❌ Insufficient color contrast between focus ring and most palette background colors

❌ Insufficient communication of state changes

Screenshot of button components with compliant color contrast

After

βœ… Meeting sufficient color contrast between background and foreground (4.5:1)

βœ… Improved contrast of the focus ring against the component and the underlying background

βœ… State changes communicated clearly (e.g. shadow effect on hover, instead of only color change)

Focus states

Adding consistent, high-contrast focus rings to all keyboard-navigable elements

Focus state was not only missing for most of the interactive components; it was also inaccessible for the ones that had one - not passing color contrast AA ratio on certain background colors.

WCAG Success Criteria:

Screenshot of checkbox component states missing a focus ring

Before

❌ Missing focus state for most components

❌ Insufficient color contrast

Screenshot of checkbox component states with a defined focus ring

After

βœ… Defined consistent focus ring styles across all components

βœ… Added focus state as a component variant in Figma to all interactive elements.

βœ… Ensured high contrast focus indicators (1.4.11)

βœ… Fixed other accessibility incompliances such as color contrasts

Typography

Standardizing line height, spacing, and scalable text to meet WCAG accessibility requirements

Increased font sizes and line heights for readability; ensured scalable units for responsive design.

WCAG Success Criteria:

Side-by-side comparison of insufficient vs. appropriate line height on a paragraph of body text

Before

❌ Size: 18; Line height: 24 β†’ insufficient line height

❌ Components breaking at 200% text zoom.

After

βœ… Size: 18; Line height: 150% β†’ appropriate line height

βœ… Components behaving responsively at 200% text zoom.

βœ… Contrast-safe font sizes and weights

βœ… Readable defaults for body text, headings, and labels

Touch targets

Adjusting touch target to ensure accessibility for users with motor impairments

Enlarged interactive elements to meet the 44x44px minimum for touch devices.

WCAG Success Criteria:

Annotated diagram of Chip and Action Button components at small (S) and extra-small (XS) sizes with touch-target measurement lines

Before

❌ Insufficient touch targets: Less than 24px

After

βœ… Increased tap target sizes or spacing to > 24 px

βœ… Increased tap target sizes or spacing to > 24 px

βœ… Standardized minimum interactive dimensions

Documentation

Accessibility guidelines beyond built-in component behavior

While accessible defaults were built directly into components, documentation plays a critical role in ensuring accessibility is applied consistently across projects where accessibility cannot be fully enforced by the component alone, such as for custom layouts, content density, or contextual variations.

As part of my tasks, I worked on introducing dedicated accessibility guidelines for every component and foundation, covering color usage, focus behavior, touch targets, typography, and ARIA roles for developers.

Screenshot of a component's documentation page showing its dedicated Accessibility guidelines tab
Key learnings

What I learned

  • Accessibility is not an "add on": it's a fundamental part of good, inclusive design, and now also a legal requirement in many regions.
  • Start with foundations: Color tokens, typography, and spacing rules are the backbone of accessibility. Fixing these early simplifies component-level improvements.
  • Testing with real users matters: Automated tools catch many issues, but usability testing with assistive technologies and diverse users ensures true inclusivity.
  • Accessibility scales: Once embedded in a design system, accessibility improvements propagate across products, reducing future effort and increasing impact.