Accessibility

Live Wires provides accessible defaults. Here’s what’s built in and how to maintain accessibility in your prototypes.

Built-in accessibility

Live Wires includes accessibility features by default:

  • Color contrast—Default color tokens meet WCAG AA standards
  • Focus indicators—Visible focus rings on interactive elements
  • Reduced motion—Respects prefers-reduced-motion
  • Logical properties—RTL language support via CSS logical properties
  • Semantic defaults—Base styles enhance, not replace, semantic meaning
  • Skip links—Ready-to-use skip navigation patterns

To top

Color contrast

Live Wires' color system is designed for accessibility:

Default contrast

The default --color-fg and --color-bg tokens provide sufficient contrast for WCAG AA compliance (4.5:1 for normal text, 3:1 for large text).

Color schemes

Built-in color schemes (.scheme-warm, .scheme-cool, .scheme-dark) maintain accessible contrast ratios:

<section class="scheme-dark">
  <!-- Text automatically has sufficient contrast -->
</section>

Testing contrast

When customizing colors, verify contrast with:

Custom color tokens

When defining custom colors in 1_tokens/color.css, ensure:

  • Body text: 4.5:1 contrast ratio minimum
  • Large text (18px+ or 14px+ bold): 3:1 minimum
  • UI components: 3:1 for boundaries

To top

Focus indicators

Live Wires provides visible focus states for keyboard navigation:

Default focus styles

Interactive elements receive a visible outline on focus. The reset preserves the browser’s default focus ring unless you define custom styles.

Custom focus styles

When styling focus states, ensure they are:

  • Visible—Clear visual change from unfocused state
  • Sufficient contrast—3:1 against adjacent colors
  • Not color-only—Use outline, border, or other indicators
/* Good: High-visibility focus */
.button:focus-visible {
  outline: 2px solid var(--color-accent);
  outline-offset: 2px;
}

/* Avoid: Removing focus without replacement */
*:focus {
  outline: none; /* Don't do this! */
}

Focus-visible

Use :focus-visible for keyboard-only focus styles (hides focus ring for mouse clicks):

.link:focus-visible {
  outline: 2px solid currentColor;
  outline-offset: 2px;
}

To top

Keyboard navigation

Ensure all interactive elements are keyboard accessible:

Tab order

  • Interactive elements should be reachable via Tab key
  • Avoid tabindex values greater than 0
  • Use tabindex="0" to make custom elements focusable
  • Use tabindex="-1" for programmatically focused elements

Skip links

Add a skip link for keyboard users to bypass navigation:

<body>
  <a href="#main" class="sr-only focus:not-sr-only">
    Skip to main content
  </a>
  <header>...</header>
  <main id="main">...</main>
</body>

Screen reader only content

Use .sr-only to hide content visually while keeping it accessible to screen readers:

<button>
  <svg>...</svg>
  <span class="sr-only">Close menu</span>
</button>

To top

Reduced motion

Live Wires respects the prefers-reduced-motion media query:

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
  }
}

This is included in the reset. Users who have enabled “reduce motion” in their system preferences will not see animations or transitions.

When adding animations

Wrap custom animations in a motion-safe query:

@media (prefers-reduced-motion: no-preference) {
  .fade-in {
    animation: fadeIn 0.3s ease-out;
  }
}

To top

Semantic HTML

Live Wires enhances semantic HTML. Use the right elements:

Document structure

  • <header> for site/section headers
  • <nav> for navigation
  • <main> for primary content (one per page)
  • <article> for self-contained content
  • <section> for thematic groupings
  • <aside> for tangentially related content
  • <footer> for site/section footers

Headings

  • Use one <h1> per page
  • Don’t skip heading levels (h1 → h3)
  • Headings create document outline for screen readers

Links vs buttons

  • <a> for navigation (goes somewhere)
  • <button> for actions (does something)

Forms

  • Always use <label> with form inputs
  • Use fieldset and legend for related inputs
  • Provide clear error messages

To top

Testing accessibility

Test your prototypes for accessibility:

Automated testing

  • WAVE—Browser extension for accessibility evaluation
  • axe DevTools—Browser extension with detailed reports
  • Lighthouse (built into Chrome DevTools)

Manual testing

  • Keyboard only—Navigate using only Tab, Enter, Space, Arrow keys
  • Screen reader—VoiceOver (Mac), NVDA (Windows), or JAWS
  • Zoom—Test at 200% and 400% zoom
  • Color blindness—Use browser dev tools to simulate

WCAG checklist

Reference the WCAG 2.2 Quick Reference for comprehensive criteria.

Key checkpoints

  1. All images have alt text (or empty alt="" for decorative)
  2. Color is not the only way to convey information
  3. All functionality works with keyboard only
  4. Focus order is logical
  5. Form inputs have visible labels
  6. Error messages identify the problem and suggest fixes
  7. Page has a descriptive title
  8. Links have descriptive text (not “click here”)

To top

Resources

To top