An accessibility audit should confirm that a journey works. It should not be the first time the team checks it.
When accessibility is left until the end, even a small issue can send work back through design, content, engineering, and testing. I try to move those checks into the everyday delivery process.
Start with the journey
I check whether the journey still makes sense without relying on colour, position, or visual memory. Instructions need to say what action to take. Errors need to explain what happened and how to recover.
I also include interrupted and failed states. A clear happy path is not enough if someone gets stuck when information is missing or a check fails.
Define component behaviour
In Figma, I show focus, hover, error, disabled, and loading states where they matter. I annotate the expected focus order and identify labels that need to be announced by assistive technology.
For complex components, I review the coded version with engineers. We check keyboard use, visible focus, zoom, reflow, screen-reader labels, and error handling. A component can look correct in Figma and still behave badly in a browser.
Put it in the handover
Accessibility requirements are included in acceptance criteria, not kept in a separate design note. This gives engineering and testing the same definition of done.
Automated tests catch some issues, such as missing labels or invalid structure. Manual checks catch the rest. I tab through the journey, zoom the page, test errors, and use a screen reader for important flows.
When an audit happens, the team can focus on deeper issues instead of finding basic gaps. Accessibility becomes part of how the product is built, not a repair job at the end.