Designing
for everyone,
by default.
Baked in, not bolted on
Accessibility starts at the design token level. When colors, spacing, and type scale are defined with inclusivity in mind, every component built from them inherits that foundation automatically.
Perceivable and operable
Every interaction must be reachable by keyboard, every image must carry meaningful alt text, and every state — focus, hover, error, disabled — must be visually and semantically distinct.
Shared language with engineers
Accessibility starts at the design token level. When colors, spacing, and type scale are defined with inclusivity in mind, every component built from them inherits that foundation automatically.
Tested, not assumed
Automated tools like Axe catch around 30–40% of issues. The rest requires keyboard walkthroughs, screen reader testing, and real user feedback — all part of the validation process.
Token architecture with contrast in mind
Before a single component exists, I define semantic color tokens — text/primary, surface/default, interactive/focus — with verified contrast ratios baked in. Figma variables let me test both light and dark themes simultaneously. No token reaches the system below a 4.5:1 text contrast or 3:1 UI component contrast.
WCAG 2.1 AA
Figma Variables
Semantic Tokens
Color audit
States, focus rings, and semantic HTML
Every component is designed with all interactive states: default, hover, focus, active, disabled, and error. Focus indicators meet a minimum 2px offset and 3:1 contrast against adjacent colors. Component specs include the expected HTML element and ARIA attributes engineers should implement, so nothing is left to interpretation.
Focus management
ARIA roles
All states documented
Keyboard order
Accessibility specs inside Figma
Rather than relying on a separate document, I annotate components directly in Figma using a consistent notation system: tab order numbers, landmark regions, reading order, button vs. link intent, and live region hints. Engineers can inspect and implement from a single source of truth without cross-referencing external specs.
Figma annotations
Reading order
Landmark regions
Notion docs
Audits, tools, and real device testing
Before release, components go through a combination of automated scanning (Axe, Storybook a11y addon), manual keyboard testing, and VoiceOver review on macOS. I track accessibility issues in the same backlog as visual bugs — not in a separate stream — which keeps the team accountable and prevents drift over time.
Storybook a11y
Keyboard testing
Primary text on dark
text/primary · surface/dark
12.4:1 — AAA
Primary text on light
text/primary · surface/light
12.4:1 — AAA
Interactive / info state
text/info · surface/info-subtle
5.6:1 — AA
Warning tate label
text/warning · surface/warning-subtle
5.2:1 — AA
Success state label
text/success · surface/success-subtle
6.1:1 — AA
Error state label
text/danger · surface/danger-subtle
5.8:1 — AA
Visible focus state
Every interactive element has a clearly visible focus indicator. Minimum 2px outline, 3:1 contrast ratio against surrounding background.
Keyboard fully navigable
All actions achievable by mouse are also achievable by keyboard alone. Tab, Enter, Space, and arrow keys behave as expected per ARIA patterns.
Correct semantic element
Buttons are <button>, not <div>. Links go somewhere. Headings follow a logical hierarchy. Landmarks define the page structure.
ARIA roles and labels
Complex widgets declare their role. Icon-only buttons have aria-label. Dynamic content uses live regions. Disabled states use the correct attribute.
Color is not the only signal
Error states include an icon, not just red color. Links are underlined, not just a different hue. Charts include labels or patterns alongside color.
Minimum touch target size
Interactive elements are at least 44×44px to accommodate motor impairments and touch input. This applies to small controls like checkboxes and toggles.
Motion and animation
All transitions respect prefers-reduced-motion. No component auto-plays animation or relies on motion to convey meaning.
Text scalability
UI stays functional and readable when browser text size is set to 200%. No horizontal scrolling, no clipped labels, no broken layouts.
Figma + A11y Annotations
Accessibility annotation kit embedded in component specs. Contrast plugin for real-time token auditing.
Color Contrast Analyser
Pixel-level contrast measurement for components in real browser context. Handles semi-transparent tokens.
Storybook + Confluence / Notion
Living documentation with a11y addon providing per-component audit reports directly in the component sandbox.
WCAG 2.1 / ARIA Patterns
W3C ARIA authoring practices guide keyboard interaction and role expectations for all interactive widget types.
Working on a product that needs to be accessible?
Let's talk about design systems, token architecture, or WCAG compliance.