An accessibility audit should confirm that a journey works. It should not be the first time the team checks it.
I include accessibility while the journey and its shared components are being designed and built.
Check the journey during delivery
I start with the complete journey. It needs to work without relying on colour, position, or visual memory. Errors need to explain what happened and how to recover.
In Figma, I show focus, hover, error, disabled, and loading states. I also record the expected focus order and labels that assistive technology needs to announce.
Those checks go into the acceptance criteria. Engineers and testers then work from the same definition of done.
Automated tests catch some structural issues. I still test keyboard use, visible focus, zoom, reflow, errors, and screen-reader announcements in the coded version.
Fix repeated issues at the source
When an issue appears across products, I trace it back to the shared component or token.
For a contrast issue, I record the foreground token, background token, component state, and products using that combination. I check default, hover, focus, disabled, error, and selected states because a passing default can still hide a failing interaction.
When the source is shared, I update it in Figma, code, and documentation instead of asking every product team to create a local patch.
The formal audit can then focus on deeper journey problems. Product teams also inherit a better default the next time they use the component.