Accessibility problems typically start in design and become permanent in code. A consultant who can only audit the live product is working at the end of the pipeline, where fixes are expensive. A consultant who can work in Figma and in the codebase can interrupt the failure at every stage.
That is how I work. I can review a design file and fix the contrast tokens, add the focus states, and annotate the ARIA intent, and then review the implementation in the PR and verify the annotations were followed. No relay race. No lost translation between one specialist handing off findings to another.
What most teams’ accessibility process looks like
The typical pattern at a product team without embedded accessibility input: a designer creates screens in Figma, a developer implements them, then an internal or external audit finds accessibility failures. Those findings go into the backlog. The backlog grows. Repeat.
The audit is useful but it is late. The failures found in that third step were decisions made in the first. The cost of fixing them in step four is always higher than the cost of making the right decision in step one.
Talking design to designers
Designers care about visual craft. They care about consistency, hierarchy, brand, and the integrity of the design system. An accessibility consultant who walks into a design review and says “your brand blue does not pass WCAG AA” is not wrong. But if that is all they say, the designer has a problem and no solution.
What I do instead: I bring the accessible alternative. I find the shade within your brand palette that passes 4.5:1 against your background. I show how the focus state can reinforce the brand rather than clashing with it. I demonstrate that the accessible version of the interaction pattern often has better usability metrics for all users, not just disabled ones.
Designers change things when they understand why and when the accessible option looks good. I have learned how to have that conversation.
Talking tech to developers
Developers respond to specificity. “This component is not keyboard accessible” is not useful. “This combobox is missing aria-activedescendant on the input and is not announcing the highlighted option to NVDA — here is the attribute and the event handler you need” is useful.
I know the frameworks. I know when a focus management problem is a React render timing issue and needs useEffect rather than a direct DOM call. I know what eslint-plugin-jsx-a11y catches and why it misses the things it misses. I can look at your styled-components or Tailwind setup and tell you where the focus styles are being suppressed three specificity levels down.
The conversation with a developer should feel like a peer review from someone who knows the stack, not a compliance briefing from someone who read the WCAG spec.
What a full-pipeline engagement covers
When I work across design and engineering on a product team:
- Design phase: Figma review, contrast and focus state fixes, component annotation for developer handoff
- Build phase: PR review on UI components, ARIA pattern guidance, keyboard interaction testing during development
- Pre-launch: Final keyboard and screen reader check, conformance position assessment
- Post-launch: Accessibility statement drafting, response to user-reported barriers
The result is a product that ships accessible, with a team that increasingly does not need me for the standard patterns because they have learned them.
Get in touch to discuss working across design and engineering