Process

Design System Accessibility at the Component Level

By EZUD Published · Updated

Design System Accessibility at the Component Level

A design system is the most leveraged place to invest in accessibility. When a button, modal, form field, or data table in the design system is accessible, every product that uses it inherits that accessibility. When it is not, every product inherits the defect. Building accessibility into components at the design system level creates a multiplier effect that no amount of page-level remediation can match.

Why Component-Level Accessibility Matters

Most accessibility issues are component-level issues. Missing form labels, insufficient color contrast, keyboard-inaccessible dropdowns, and improperly announced modals are all component problems. The W3C ARIA Authoring Practices Guide catalogs dozens of common widget patterns and their expected keyboard, focus, and ARIA behaviors. A design system that implements these patterns correctly eliminates entire categories of defects before a product team writes a single line of feature code.

Organizations like Salesforce (Lightning Design System), IBM (Carbon Design System), and the U.S. government (USWDS) have demonstrated that accessible design systems dramatically reduce per-project accessibility effort.

Accessibility Requirements for Every Component

Each component in the design system should document and implement the following:

Semantic Structure

  • Use the correct HTML element for the component’s purpose. A button should be a <button>, not a <div> with a click handler. A navigation should be a <nav>. A list of items should be <ul> or <ol>.
  • Use headings, landmarks, and sectioning elements to communicate document structure.

Keyboard Interaction

  • Every interactive component must be operable with keyboard alone.
  • Follow the keyboard patterns defined in the W3C ARIA Authoring Practices Guide. For example: Tab moves between focusable elements, arrow keys navigate within composite widgets (tabs, menus, tree views), Escape closes overlays.
  • Focus must be visible at all times. Never suppress focus indicators.
  • Focus management must be handled for dynamic content: when a modal opens, focus moves to the modal; when it closes, focus returns to the trigger.

ARIA Attributes

  • Use ARIA only when native HTML semantics are insufficient. ARIA should supplement, not replace, semantic HTML.
  • Provide accessible names for all interactive elements (via visible labels, aria-label, or aria-labelledby).
  • Communicate state changes (aria-expanded, aria-selected, aria-checked, aria-disabled) so assistive technology can announce them.
  • Use live regions (aria-live) for dynamic content that updates without page reload (toast notifications, error messages, loading indicators).

Visual Design

  • Text contrast must meet WCAG 2.2 Level AA minimums: 4.5:1 for normal text, 3:1 for large text.
  • Non-text UI components (icons, form field borders, focus indicators) must meet 3:1 contrast against adjacent colors.
  • Do not convey information through color alone. Use icons, text labels, or patterns as secondary indicators.
  • Support forced colors mode (Windows High Contrast) by testing with it enabled.

Responsive and Reflow Behavior

  • Components must reflow at 400% zoom without horizontal scrolling or content loss (WCAG 1.4.10).
  • Touch targets must be at least 24x24 CSS pixels (WCAG 2.5.8, Level AA in WCAG 2.2).

Documentation Standards

Each component page in the design system should include:

  • Accessibility section. Describe keyboard interaction, ARIA usage, and any design constraints.
  • Do and do not examples. Show correct and incorrect implementations with code samples.
  • Testing guidance. Describe how to manually test the component with a screen reader and keyboard.
  • WCAG mapping. List which WCAG success criteria the component addresses.

See accessibility documentation best practices for broader documentation guidance.

Testing Design System Components

  • Run automated scans (axe-core, Deque) on every component in isolation and in composition.
  • Write unit tests that assert accessible names, roles, and states using testing-library’s accessibility queries.
  • Conduct manual testing with NVDA, JAWS, and VoiceOver for every component before release.
  • Include components in periodic accessibility audits.

Governance and Contribution

  • Define accessibility as a gating requirement for component release. No component ships without passing accessibility review.
  • Provide contribution guidelines that include accessibility requirements for community-submitted components.
  • Assign an accessibility reviewer to the design system team or establish an accessibility champions program that includes design system reviewers.

Integrating with Product Teams

A design system is only effective if product teams use it correctly.

Key Takeaways

  • Accessible design systems create a multiplier effect: fix once, benefit everywhere.
  • Every component needs documented keyboard interaction, ARIA behavior, contrast compliance, and reflow support.
  • Automated and manual testing should gate component releases.
  • Governance must make accessibility a requirement, not a suggestion, for design system contributions.
  • Training and clear documentation ensure product teams use components accessibly.

Sources

More in Process

Inclusive Design Process Guide: Building Accessibility Into Every Stage Guide Continuous Accessibility Monitoring Accessibility in Design Reviews Nothing About Us Without Us: The Principle That Shapes Inclusive Design

View all Process articles →