Accessibility
Accessibility is part of the baseline for this UI system, not a polish step at the end. The goal is to build components that work well for keyboard users, screen readers, and different motion/contrast preferences.
Principles
Section titled “Principles”- Prefer semantic HTML over ARIA
- Keep focus states visible and consistent
- Support keyboard navigation by default
- Respect user preferences like reduced motion
- Aim for WCAG AA contrast in both themes
Checklist
Section titled “Checklist”Structure
Section titled “Structure”- Use headings in a logical order
- Use landmark elements (
header,nav,main,footer) where appropriate - Don’t skip heading levels for styling
Keyboard + focus
Section titled “Keyboard + focus”- Everything interactive is reachable via
Tab - Focus styles are visible and not removed
- Modals/menus trap focus when open (and restore it on close)
- Escape closes dialogs and menus when applicable
Labels and names
Section titled “Labels and names”- Inputs have associated labels
- Icon buttons include
aria-label - Links have descriptive text (avoid “click here”)
Motion + feedback
Section titled “Motion + feedback”- Animations respect
prefers-reduced-motion - Loading states don’t rely on color alone
- Errors are communicated clearly and consistently
When possible, I test components with keyboard-only navigation and basic screen reader checks to catch issues early.