A one off accessibility audit tells you what is wrong with what you have built. An embedded accessibility consultant helps you not build the problem in the first place.
I work with product teams as an embedded specialist — joining your sprint cycle, reviewing work in progress, and acting as the accessibility voice in the room when design and engineering decisions are being made. The goal is accessible features shipped first time, not an ever-growing backlog of remediation work.
What embedded accessibility work looks like in practice
Design review
I join design critiques or review Figma files during the sprint before development starts. I flag issues while they are cheap, a missing focus state here, a contrast failure there, a custom component pattern that will need specific ARIA behaviour. Designers get specific, actionable feedback they can act on before handoff. Designers might not understand, they might pushback and this is where the education comes in.
In sprint planning and refinement
I add accessibility acceptance criteria (AC) to tickets before they are sized. Not vague criteria like “must be accessible” - specific ones like “focus must return to the trigger button when the modal is dismissed” or “error message come before the input” Developers know what done means before they start.
During development
I am available on Slack or your equivalent for questions as work is built. A developer spending twenty minutes trying to recall the correct aria pattern for a combobox component is a normal situation. Being able to ask a specialist and get the answer in five minutes, with a code example, is the difference between accessible work going in and a TODO comment going in.
In pull request review
I can be added as an reviewer on frontend PRs touching interactive UI. I review the implementation against the design intent and acceptance criteria and flag accessibility issues before they merge. This is earlier and cheaper than catching them in QA or in a post-launch audit. Developers get in-context review, they get resources, feedback.
In sprint demo
I can join sprint demos and do a quick keyboard and screen reader check of what has been built. Catching issues in demo is cheaper than catching them after release.
What changes when accessibility is embedded
The first sprint feels slow, developers ask more questions, designs go back for revision. By the third sprint, the patterns are becoming familiar. By the sixth, the team is catching their own issues before I do.
That is the intended outcome, an embedded engagement is not about creating a dependency on me. It is about raising the team’s baseline so that accessible UI is the default rather than something that needs to be bolted on.
