Accessibility Annotation Kits Are More Than Just Notes

An accessibility annotation kit is a set of ready-made labels, stamps, and notes that designers place on a design file, usually in Figma, to explain how a page works for people using a keyboard, screen reader, or zoom. Annotations record focus order, accessible names, roles, states, headings, landmarks, and alt text, so developers build accessibility in from the start instead of guessing.

Too often, the accessibility conversation starts after the designs are finished. Annotations get added late, if at all. Developers are left to guess what was intended, or accessibility gets bolted on after launch. This is a pattern I've seen, and disrupted, time and time again.

I serve as the accessibility specialist for Howard Hughes Medical Institute's (HHMI) BioInteractive team, working side by side with their designers and content leads. Together, we've shaped an approach to born-accessible design that starts in Figma and ends in clean, user-centered code that meets WCAG 2.2 AA.

What is an accessibility annotation kit?

A kit is a library of reusable components for your design tool. Instead of writing free-form sticky notes, designers drop in a numbered stamp, such as "Heading level 2," "Focus stop 3," or "Button: Close dialog," and link it to a short description. Every designer on the team uses the same vocabulary, so developers always know where to look and what each mark means.

Most kits are free Figma community files. Some also cover Sketch, Penpot, iOS, or Android. Plugins can speed things up by checking contrast or generating annotation layers for you, but the kit is the shared language underneath.

Why do accessibility annotations matter?

Annotations move accessibility from an audit afterthought into a built-in step. They help you:

• Reduce guesswork in developer handoff
• Align design and development on how interactive parts behave
• Keep components consistent across pages and projects
• Build a design system that holds up as it grows

Good annotations don't clutter a design. They clarify it. Done well, they become a living record of accessibility decisions: who each decision helps, what the requirement is, and why it matters.

A kit has limits, too. Eric Bailey's essay Accessibility annotation kits only annotate makes the point well: a stamp can record a decision, but it can't make that decision correct. Annotations work best when the person placing them understands the patterns behind them, and when the build is tested with a keyboard and assistive technology afterward.

What should you annotate?

Use this checklist on every screen or component before handoff. Each item maps to WCAG 2.2.

• Focus order: the order keyboard users move through links, buttons, and fields, and where focus goes when a dialog opens or closes (2.4.3 Focus Order).
• Accessible names: what a screen reader announces for each control, especially icon-only buttons like "Search" or "Close menu" (4.1.2 Name, Role, Value).
• Roles: what each interactive element is, such as a button, link, tab, or disclosure (4.1.2 Name, Role, Value).
• States: expanded or collapsed, selected, checked, current page, and disabled (4.1.2 Name, Role, Value).
• Headings: the heading level for each heading, regardless of how big it looks (1.3.1 Info and Relationships).
• Landmarks: header, navigation, main, complementary, and footer regions, with labels when there is more than one of a kind (1.3.1 Info and Relationships).
• Alt text decisions: whether each image is decorative or informative, and the alt text for informative ones (1.1.1 Non-text Content).
• Error messages: the exact wording of each error, where it appears, and how it is connected to its field (3.3.1 Error Identification, 3.3.3 Error Suggestion).
• Reading order: the order content is read by a screen reader when the visual layout uses columns, cards, or overlapping elements (1.3.2 Meaningful Sequence).

How do we annotate at HHMI BioInteractive?

At HHMI, the design process has grown into a deeply collaborative, well-documented accessibility workflow. Here is how I support each new interactive:

• An Accessibility Annotation Repository in Figma, filled with guidance written for both designers and developers.
• A project-specific annotation kit, aligned with WCAG 2.2, that covers common patterns, components, and content behaviors.
• Detailed walkthrough documents for each project that explain:
  • The purpose of the interactive
  • The expected user flow and behavior
  • How it works with a keyboard and assistive technology

This documentation gets designers, developers, content leads, and auditors on the same page before any code is written.

How does annotation grow into a design system?

The long-term goal is an annotated design system for HHMI BioInteractive, built with WCAG 2.2 and Figma best practices. Each annotated component is designed to:

• Be reused across future interactive projects
• Spell out expected behavior, not just appearance
• Support consistent, born-accessible builds

When accessibility behavior is documented once at the component level, every new project starts from a tested pattern instead of a blank page.

Who are annotations for?

Annotations aren't only for designers. They serve developers, content strategists, QA testers, and auditors. Good annotations:

• Give context the visuals can't show
• Anticipate edge cases, like long names, empty states, and errors
• Describe behavior, not just looks

We see the cost of skipping this step in our own work. When we remediate a Webflow site, many of the issues we fix, like missing headings, unlabeled icon buttons, and confusing focus order, trace back to decisions nobody wrote down during design. Annotations are the cheapest place to catch them.

Which Figma plugins help with accessibility annotations?

In Figma, we lean on plugins like these:

• Able: checks color contrast between selected layers and previews how colors look with different types of color blindness.
• eBay Include: a free plugin that walks designers through accessibility steps and adds the results to the file as accessibility annotation layers.

Figma is our hub, but accessibility is the thread that runs through every file.

How does GitHub use accessibility annotations?

In this talk, GitHub accessibility designers Alexis Lucio and Jan Maarten show how GitHub uses Figma and annotation kits to train designers. They walk through bootcamps, embedded design practices, and real Figma annotation strategies, built on the idea that accessibility training only works if people want to use it.

Watch the full video with transcript: Putting theory into practice: How GitHub uses Figma for its a11y annotation kit and training.

For more background, read GitHub's post Celebrating 1 year of A11y Design Bootcamp. In 2025, GitHub also open sourced its Annotation Toolkit, so you can use the same kit its team uses.

Which accessibility annotation kits are worth exploring?

• Web Accessibility Annotation Kit by CVS Health: a free, open-source Figma kit from the CVS Health Inclusive Design team, with numbered stamps for documenting design intent. There is also a companion kit for iOS.
• GitHub Annotation Toolkit: GitHub's open-source Figma library, built on the CVS Health kit, with annotation stamps, design checkpoints, and tutorials for each annotation type.
• Stephanie Walter's Web Accessibility Toolkit for Designers: a paid bundle with a WCAG 2.2 checklist for designers, a printable poster, and annotation kits for Figma, Penpot, and Sketch.
• Accessibility Bluelines from GitLab: a free Figma community file of blueline annotations, a lightweight style of markup layered over a mockup to note structure and behavior.

Before you pick a kit, it helps to know how the finished build will be tested. Our accessibility toolkit of testing tools we actually use covers the checks we run after handoff.

Frequently asked questions

Do I need a paid tool to annotate for accessibility?

No. The CVS Health and GitHub kits are free in the Figma community, and many plugins are free too. Paid kits can add checklists and training material, but a free kit used consistently is far better than none.

Who should add accessibility annotations, the designer or the developer?

The designer adds them, ideally with help from an accessibility specialist. Developers review them before building and ask questions early. The goal is to settle decisions while they are still cheap to change.

Do annotations replace accessibility testing?

No. Annotations document what should happen. Testing with a keyboard, a screen reader, and zoom confirms that it did. You need both.

Can annotations help with an existing website, not just new designs?

Yes. During remediation, we annotate the problem areas of a live site so fixes are clear, consistent, and easy to check off. Those notes then become the starting point for a design system.

Get help building accessibility into your design process

If your team wants handoffs that developers can build right the first time, we can help you set up annotations or fix the accessibility issues already on your site. Learn about our Webflow accessibility remediation and consulting service, or request a free project quote.

Sources

• CVS Health: Accessibility Annotations (GitHub)
• GitHub: Annotation Toolkit
• GitHub Changelog: Open sourcing the GitHub Annotation Toolkit
• eBay Playbook: Include plugin
• Figma: Design for everyone with these accessibility-focused plugins
• Eric Bailey: Accessibility annotation kits only annotate

Written by Crystal Scott, founder of Graceful Web Studio. Crystal is a Certified Professional in Web Accessibility (CPWA), a Section 508 Trusted Tester, and a Certified Webflow Expert with over a decade of front-end experience.