The most efficient place to fix an accessibility problem is the design file, before a developer writes a single line of code. A missing focus state caught in Figma takes five minutes to add. The same problem found after six sprints of development, a WCAG audit, and a backlog refinement session takes considerably longer.
I work directly in Figma with design teams to fix accessibility issues at the source, and annotate designs so developers understand the accessible intent without needing to interpret or guess. This is called shifting-left, making it apply at the start, earlier in the process,
What I look at in a Figma file
Colour contrast across all states
I check every text layer, icon, and interactive component in default, hover, focus, active, selected, visited, disabled, and error states. Not just the main artboard — every state variant. I use the exact WCAG contrast ratio formula, not a rounded approximation. Where contrast fails I find the nearest accessible value that still respects the design language and update the token or layer directly.
Focus indicators
Designs that do not include focus states are incomplete, I add them. For each interactive component I check that the focus indicator meets WCAG 2.2 success criterion 2.4.11 (minimum 2px offset, 3:1 contrast against adjacent colours) and make the indicator visible and on-brand.
Touch target sizing
Interactive elements that are too small for reliable touch input get flagged and resized. WCAG 2.5.8 requires a minimum 24x24 CSS pixel target. Good practice is 44x44px where possible. I update component sizing in the design file so this does not need to be negotiated with developers later.
Typography decisions
Text size, line height, paragraph width, and letter spacing all affect readability for users with low vision or cognitive disabilities.
Heading hierarchy implied by the design
Visual hierarchy and semantic hierarchy are different things. I annotate designs with the intended heading levels so developers implement the correct DOM structure, not the one that happens to look right.
Annotation for developer handoff
The gap between a design file and an accessible implementation is usually not bad intent. It is missing information, developers who receive a polished design file without accessibility annotations have to make dozens of decisions, reading order, focus behaviour, and alternative text. They often get it wrong, not because they are careless, but because the design did not tell them. There were bugs or gaps in the Design.
My annotations cover
- Accessible names for icon-only buttons, images, and form controls
- Reading order where it differs from visual order
- ARIA roles and states for custom interactive components
- Focus order and tab sequence
- Error message copy and association with form fields
- States that need announcing to screen reader users (expanded, selected, loading)
These annotations go in the Figma file alongside the design, in whatever annotation format your team uses (sticky notes, the A11y Annotation Kit, or your own system). Developers who pick up the file know exactly what to build.
I speak designer
I have worked extensively with product designers and I understand the tension between brand constraints and accessibility requirements. I do not come in and tell you your brand palette is wrong. I find the accessible solution within your design language. Dark mode, high contrast themes, illustration-heavy interfaces, these all have accessible solutions, they just require more nuance than “increase the contrast ratio.”
When I am reviewing a design I talk about visual weight, spatial relationships, and interaction patterns. I understand why a designer chose a particular shade or treatment. I work with that rather than against it.