a11y in Design Systems — Integrating Accessibility into System Workflows

In this tutorial, you will learn about a11y in design systems. We cover key concepts, practical examples, and best practices to help you master this topic.

Integrating a11y into design systems means embedding Accessibility into governance, component creation, review processes, documentation standards, and testing pipelines so every component is accessible by default.

What You'll Learn

You will learn how to integrate accessibility into design system workflows, including governance, component lifecycle, review criteria, and documentation requirements.

Why It Matters

Accessibility that is not integrated into the workflow will be forgotten. When accessibility is part of every step from design through review and release, it becomes a habit not an afterthought.

Real-World Use

DodaKit's component lifecycle includes an accessibility review gate. No component is released until it passes automated checks, manual keyboard testing, and screen reader verification.

flowchart TD
  A[Component Lifecycle] --> B[Design]
  A --> C[Develop]
  A --> D[Review]
  A --> E[Release]
  A --> F[Maintain]
  B --> B1[a11y annotations]
  C --> C1[Semantic HTML, ARIA]
  D --> D1[Keyboard, screen reader]
  E --> E1[a11y pass required]
  F --> F1[Regression testing]

Governance

Create an accessibility governance group within the design system team. This group reviews new components, updates existing ones, and sets accessibility standards.

Component Lifecycle

Design Phase

Designers annotate components with accessibility requirements: expected ARIA roles, keyboard interactions, focus behavior, and color contrast validation.

Development Phase

Developers implement components using semantic HTML first, adding ARIA only when necessary. Keyboard support is built in from the start.

Review Phase

Each component undergoes automated testing (axe-core, contrast checks), manual keyboard testing, and screen reader testing before release.

Release Phase

Accessibility review is a release gate. No component can be released without passing all accessibility checks.

// Design system component accessibility gate
class ComponentAccessibilityGate {
  constructor() {
    this.components = [];
  }

  registerComponent(name, version) {
    this.components.push({
      name: name,
      version: version,
      checks: { automated: false, keyboard: false, screenReader: false, documentation: false },
      released: false
    });
  }

  passCheck(componentName, checkName) {
    const component = this.components.find(c => c.name === componentName);
    if (!component) return { error: 'Component not found' };

    component.checks[checkName] = true;
    component.released = Object.values(component.checks).every(v => v === true);

    return {
      component: componentName,
      checkPassed: checkName,
      allPassed: component.released,
      remainingChecks: Object.entries(component.checks)
        .filter(([key, value]) => !value)
        .map(([key]) => key)
    };
  }

  getComponentStatus(name) {
    const component = this.components.find(c => c.name === name);
    if (!component) return null;

    const checks = component.checks;
    return {
      name: component.name,
      version: component.version,
      released: component.released,
      automatedChecked: checks.automated,
      keyboardTested: checks.keyboard,
      screenReaderTested: checks.screenReader,
      documented: checks.documentation,
      progress: Math.round(Object.values(checks).filter(v => v).length / 4 * 100) + '%'
    };
  }
}

const gate = new ComponentAccessibilityGate();
gate.registerComponent('Button', '2.1.0');
gate.registerComponent('TextField', '2.1.0');

console.log(gate.passCheck('Button', 'automated'));
console.log(gate.passCheck('Button', 'keyboard'));
console.log(gate.passCheck('Button', 'screenReader'));
console.log(gate.passCheck('Button', 'documentation'));
console.log('Button status:', gate.getComponentStatus('Button'));

Expected output:

{ component: 'Button', checkPassed: 'automated', allPassed: false, remainingChecks: ['keyboard', 'screenReader', 'documentation'] }
{ component: 'Button', checkPassed: 'keyboard', allPassed: false, remainingChecks: ['screenReader', 'documentation'] }
{ component: 'Button', checkPassed: 'screenReader', allPassed: false, remainingChecks: ['documentation'] }
{ component: 'Button', checkPassed: 'documentation', allPassed: true, remainingChecks: [] }
Button status: { name: 'Button', version: '2.1.0', released: true, automatedChecked: true, keyboardTested: true, screenReaderTested: true, documented: true, progress: '100%' }

Documentation Standards

Every component must include accessibility documentation covering: ARIA roles and properties used, keyboard interactions, focus behavior, color contrast validation, known issues, and testing results.

<!-- Accessibility documentation template -->
<section aria-label="Button component accessibility">
  <h2>Button — Accessibility</h2>

  <h3>ARIA</h3>
  <p>Native button element. No ARIA required unless used as a toggle (aria-pressed).</p>

  <h3>Keyboard</h3>
  <ul>
    <li>Enter or Space: activates the button</li>
    <li>Tab: moves focus to the button</li>
    <li>Shift+Tab: moves focus away</li>
  </ul>

  <h3>Focus</h3>
  <p>Visible focus indicator using CSS :focus-visible. Outline color: var(--ds-focus-ring).</p>

  <h3>Testing</h3>
  <ul>
    <li>Automated: axe-core — Pass</li>
    <li>Keyboard: Chrome 125 — Pass</li>
    <li>Screen reader: NVDA 2024 — Pass</li>
  </ul>
</section>

Common Mistakes

1. No Accessibility Gate in Release Process

Without a gate, components can be released without accessibility verification. Make accessibility a hard requirement.

2. Designers Not Trained in Accessibility

Designers create inaccessible components when they do not understand a11y. Train the entire design team.

3. Developers Not Testing with Screen Readers

Developers should test their own components with screen readers before submitting for review.

4. Accessibility Added After Development

When accessibility is added after the component is built, it is harder and less integrated.

5. No Accessibility Regression Testing

When components are updated, new accessibility issues can be introduced. Add a11y regression tests.

6. Incomplete Documentation

Documentation that only covers how to use the component but not its accessibility requirements leads to misuse.

7. No Accessibility Champion on the Team

Every design system team needs an accessibility champion who advocates for and reviews accessibility.

Practice Questions

1. What are the four phases of the component lifecycle with accessibility gates?

Design, develop, review, and release. Each has specific accessibility requirements.

2. Why should accessibility be a release gate?

Without a gate, components can ship without passing accessibility checks. It ensures accessibility is never optional.

3. What should accessibility documentation for a component include?

ARIA roles, keyboard interactions, focus behavior, contrast validation, known issues, and testing results.

4. Who needs accessibility training in a design system team?

Both designers and developers. Accessibility is a cross-disciplinary skill.

5. Challenge: Design an accessibility governance workflow for a design system team of 10 people. Include roles, review stages, and escalation paths.

FAQ

Mini Project

Create an accessibility checklist for adding a new component to a design system. Include checks for design, development, review, and release phases.

What's Next

Learn about Accessible Design Tokens and how tokens ensure accessibility at the foundation level. Then explore Accessible Color Systems.