Annotate headings, landmarks, focus order, accessible names and states so accessibility is designed, not left to chance.
Why it matters
Many accessibility problems are decided before a single line of code: a reading order that jumps around, an icon-only button with no name, a modal with no defined focus behaviour, an error shown only in red. If the design does not specify these things, developers have to guess, and guesses are often wrong. Accessibility annotations make the invisible parts of a design explicit, so assistive technology users get the experience you intended. You covered the principles in Accessible & Responsive Interfaces; this lesson is about writing them down for handoff.
The core idea: annotate what sighted mouse users never see
Screen reader and keyboard users experience a page as a structure and a sequence, not a picture. Annotations describe that structure and sequence. The most common categories are:
1. Headings. Mark each heading's level (H1, H2, H3) based on structure, not visual size. One H1 per page; do not skip levels.
2. Landmarks. Mark regions: header (banner), navigation, main, complementary (aside), footer (contentinfo), and search or form regions where helpful. Screen reader users jump between landmarks.
3. Focus order. Number every interactive element in the order the Tab key should reach it. Normally this follows visual reading order (left to right, top to bottom in English). Note anything unusual, such as a skip link first.
4. Accessible names. Every control needs a name a screen reader can announce. Visible labels are best. For icon-only buttons, write the name ("Close dialog", "Search"). For links, make sure the text makes sense out of context ("View invoice 1042", not "Click here").
5. Images. Mark each image as meaningful (write the alt text) or decorative (empty alt, ignored).
6. States and announcements. Specify expanded/collapsed, selected, checked, current page and error states, and what is announced when something changes without a page load ("3 results found", "Saved").
7. Focus management. Where focus goes when a modal opens (into the dialog, usually its heading or first control), where it returns when it closes (the button that opened it), and where it moves after an error on submit (the first invalid field or an error summary).
8. Interaction and other details. Keyboard behaviour for custom widgets (arrow keys in tabs), touch target sizes, reduced-motion alternatives, and text that must not be in images.
How to annotate
Use a consistent visual language: coloured markers off to the side of the design with a numbered legend. Free annotation kits are available in the Figma Community; some, such as kits published by large companies' accessibility teams, include ready-made stamps for headings, focus order and names. Paper works too: print the screen and mark it up.
Worked example: a search results page
Landmarks: banner (logo + nav) | search (form) | main (results) | contentinfo (footer)
Headings: H1 "Search results for 'desk'" H2 per result title H2 "Filters" (visually small)
Focus order:
1 Skip to results (visible on focus)
2 Logo link "Home"
3-5 Nav links
6 Search field (label "Search products")
7 Search button (icon-only; name "Search")
8 Filters toggle (button; aria-expanded true/false)
9+ Result title links, in visual order; then Pagination
Names: Heart icon on each result: "Save Oak desk to favourites" (includes product name)
Images: Product photos: alt = product name; decorative divider: empty alt
Announce: After filters change: "24 results" in a polite live region
Errors: Empty search -> message under field, linked to it; focus stays in field
Two details are worth noticing. The heading "Filters" is visually small, but structurally it is an H2, so it is marked H2. And the heart icon's name includes the product name; ten identical "Save" buttons would be useless to a screen reader user listing all buttons.
Working with developers
- Hand off annotations with the visual design, not after it.
- Agree on terms: use HTML and ARIA words developers know (button, link,
aria-expanded), but prefer native HTML over ARIA when it does the job. - Test the build with a keyboard (Tab, Shift+Tab, Enter, Space, Esc) and a free screen reader (NVDA on Windows, VoiceOver on Mac and iOS, TalkBack on Android) and compare with your annotations.
Common mistakes
- Heading levels by visual size. Structure, not style, decides the level.
- Focus order that ignores layout changes at mobile widths, where columns stack.
- "Button" as a name. Every icon-only control needs a specific name.
- Colour-only errors. Add text and an icon, and link the message to its field.
- No focus plan for modals and menus. Focus gets lost behind the overlay.
- Annotating after build. By then, fixing structure is expensive.
Quick recap
- Accessibility annotations describe structure and sequence: headings, landmarks, focus order, names, images, states and focus management.
- Mark heading levels by structure, give every control a specific accessible name, and plan focus for modals and errors.
- Use a consistent legend, hand off with the design, and verify with a keyboard and a screen reader.
Try it
On the Do tab you will annotate a screen for focus order, headings, landmarks and accessible names.