Good intentions in design do not automatically turn into accessible products in code. You might be using a design system and perhaps it has accessible components, but the final layout, content, states and interactions can still break accessibility if nobody spells out the details.
These details are what we call accessibility annotations. They're there to reduce translation errors between design and development. QA can use them too to check if what the dev team did is what the design team meant. Without these annotations, they're left to guess things like focus order, error messaging, keyboard behavior or whether an image is decorative or informative. And that's where problems slip through.
Accessibility annotations matter because they turn "we need to make sure this is accessible" into clear instructions the dev team can use at handoff, where a lot of accessibility gets lost.
If I had one gripe with these annotations is that they're misunderstood. I've seen teams use these as decorations sitting next to their designs. The goal is to use them to document the parts of a design that are easy to miss and hard to fix later. For me, that usually includes semantics, structure, keyboard interactions, error handling and anything on the page that changes depending on what the user does.
There's a fine line between too much and too little. Think of it like this. The goal is not to flood the designs with lots of notes, but to capture the decisions that will matter later for implementation and testing. Developers are smart, but will rarely be able to infer meaning from the design alone. If a requirement matters, write it down.
Over time, these annotations become a shared language that designers, developers and QA can all understand.
The three biggest mistakes I've seen is people over-annotating everything, under-annotating the things that matter and annotating only the happy path.
Accessibility issues often show up in error states, loading states, empty states and disabled states. Those need attention too.
You don't even need a fancy system to start. If you already use Figma, stick with it. If you prefer Sketch or Adobe XD, use that. There's probably a plugin in all of these you can use. And if all else fails, drop down to a simple document that accompanies your design files. Then use numbered callouts in the design file and a short companion note for each one in the document.
The best tool is the one your team will keep using.
I only have one rule. Use the same format every time. You need to build the habit and grow it before the documentation gets elaborate.
Remember the premise of making the invisible visible? These design annotations make accessibility visible early, when changes are still cheap and before decisions get buried in the code.