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
In 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.
In sprint planning and refinement. I add accessibility acceptance criteria 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 must be announced by screen readers on validation failure.” 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 optional 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.
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 the exception.
Formats
Embedded accessibility work can be structured in several ways depending on what your team needs:
- A fixed number of days per sprint (typically two to four days per two-week sprint)
- Sprint-by-sprint review and availability without being counted into velocity
- A defined three-month engagement with a close-out review and documentation of patterns for the team to continue independently