Why Figma Annotations Are Critical for a Shift-Left Accessibility Approach

Accessibility annotations in Figma play a critical role in ensuring a smooth handover between designers and developers. In the design world, clear communication at this stage helps maintain momentum, reduces rework, and ensures the final product reflects the original design — especially when accessibility is a priority.

Design annotations in Figma are a powerful yet often underused tool. When done well, they bridge the gap between design and development, especially when accessibility is a priority.

What Are Accessibility Annotations in Figma?

Accessibility annotations in Figma are notes, labels, and specifications added to design files to communicate accessibility requirements clearly. These can include color contrast ratios, keyboard behavior, screen reader expectations, focus order, and error handling.

Embracing the Shift-Left Approach

Imagine identifying accessibility issues during the design phase, instead of discovering them during QA or after launch. That’s the core idea behind the shift-left approach.

By annotating designs early, designers can:

• Highlight accessibility expectations upfront
• Reduce back-and-forth with developers
• Save time and cost on late-stage fixes
• Enable developers to build accessibility into the foundation, not bolt it on later

Annotations help surface issues such as:

• Insufficient color contrast
• Missing or unclear structure
• Non-descriptive links
• Images without alternative text

This shared clarity sets teams up for success.

What to Annotate (and What Not To)

Annotating everything is rarely effective. Some accessibility checks will always require developer testing and assistive technology validation. The goal of annotations is to guide intent and priorities, not replace testing.

While Figma offers powerful annotation capabilities, over-documenting can overwhelm developers and obscure what’s truly important. Focus your efforts on these high-impact areas:

1. Color Contrast Issues

Emphasize the importance of color independence and minimum contrast ratios to ensure readability for users with visual impairments.

What to annotate

• Minimum contrast ratios
• Avoidance of color-only indicators

Example annotation
“Ensure a minimum contrast ratio of 4.5:1 for text and 3:1 for non-text elements, per WCAG 2.1 AA.”

2. Structure and Semantics

Heading Structure: Annotate the hierarchy of headings (H1-H6) to ensure clear information organization, not visual size.

Example
“Page title = H1. Section headings = H2. Subsections = H3.”

Landmarks: Indicate semantic regions so developers apply correct HTML elements.

Example

• <header> – branding and global navigation
• <nav> – primary navigation
• <main> – main content
• <aside> – complementary content
• <footer> – footer content

3. Image Descriptions (Alt Text)

Provide clear and concise alt text for images to enhance accessibility for screen readers.

What to annotate

• Intended alt text
• Whether an image is decorative

Example
Alt text: “A person using a laptop at a desk in a bright office.”

If decorative: “Decorative image — use empty alt attribute (alt=””).”

4. Link Text

Ensure link text clearly conveys the destination of the link or purpose without additional context.

Avoid
“Click here”
“Read more”

Preferred
“Learn more about our Accessibility services.”

5. UI Control Text

Buttons and controls must clearly describe what they do.

Example
Button label: “Add to cart”
Not just “Add”

This improves usability for screen reader and voice-control users

6. Forms

Forms are integral to most digital interactions, making their accessibility paramount. Here’s how to annotate forms effectively for better developer understanding and user experience:

6.1 Form Element Labels
Every form field must have a programmatically associated label. Visual proximity isn’t enough – screen readers need explicit associations.

Critical Requirements:

• Always visible: Labels must always be visible, never rely on placeholder text alone. Placeholder text disappears when users start typing, creating confusion and memory burden.
• Explicit association: Use <label> elements with for attributes matching input IDs
• Clear and descriptive: Label text should clearly indicate what information is expected

Example
“Email input field – Label: ‘Email Address’ (visible above field). Do NOT use placeholder as the only label. Associate label with input using for attribute.”

6.2 Informational Text and Instructions
Forms often require additional context beyond basic labels. Instructions, requirements, and error messages must be properly associated with their corresponding fields.

Types of informational text:

• Global instructions: General form guidance (e.g., “All fields marked with * are required”)
• Field-specific instructions: Requirements for individual fields (e.g., password complexity rules)
• Error messages: Specific, actionable feedback when validation fails
• Success messages: Confirmation that actions completed successfully

ARIA associations:

• aria-describedby: Links fields to instructions and error messages
• aria-live: Announces dynamic updates like error messages (use aria-live=”assertive” for errors)

Example
“Password field instructions: Display ‘Must be at least 8 characters with one uppercase letter and one number’ below the field. Associate with input using aria-describedby=‘password-requirements’”

“Error message: ‘Email address is invalid. Please enter a valid email (e.g., name@example.com)’ – Display in red text with error icon, associate with input using aria-describedby=‘email-error’, add aria-invalid=‘true’ to input”

6.3 Form Group Organization
Related form fields should be grouped together both visually and programmatically. This is especially important for radio buttons, checkboxes, and related text fields.

Implementation with fieldset and legend:

• <fieldset>: Wraps related form controls
• <legend>: Provides a title/description for the group (first child of fieldset)
• Screen readers announce the legend when users enter the group, providing essential context.

Example
“Group shipping address fields (Street, City, State, ZIP) using <fieldset> with <legend>Shipping Address</legend>. Group payment method radio buttons using <fieldset> with <legend>Payment Method</legend>.”

6.4 Additional Form Considerations
Beyond basic labels and structure, several HTML attributes enhance form accessibility:

• Required fields: Add required attribute and visual indicator (*)
• Autocomplete: Use autocomplete attribute to help browsers and assistive technology autofill fields (e.g., autocomplete=”email”, autocomplete=”tel”)
• Input types: Specify appropriate types (email, tel, number, date, etc.) for better validation and mobile keyboard support
• Input mode: Use inputmode attribute for fine-grained mobile keyboard control
• Focus management: Ensure logical tab order and visible focus indicators

Example Annotation:
“Email input: type=‘email’, required, autocomplete=‘email’, Label: ‘Email Address’ (visible). Add aria-describedby=‘email-requirements’ for instructions and aria-describedby=‘email-error’ when error is present (can have multiple IDs space-separated). Mark field as invalid using aria-invalid=‘true’ when error occurs.”

Best Practices for Form Annotations

• Consistency: Maintain consistent labeling and formatting throughout the form.
• Clarity: Use clear and concise language for labels and instructions.
• Visual Hierarchy: Consider the visual layout of form elements and their relationship to labels.
• Testing: Validate form accessibility using screen readers and assistive technologies.
• Document edge cases: Annotate behavior for unusual situations (e.g., multiple simultaneous errors, dynamic field additions)

By carefully annotating forms, designers and developers can create accessible experiences that cater to all users.

Evolve Your Annotation Workflow

Accessibility annotation isn’t a one-size-fits-all process.
Remember, your annotation strategy can evolve as you work. Continuous communication with developers helps refine the process to ensure maximum clarity and understanding.

Bonus Tip: Use Figma annotation plugins or shared annotation components to speed up documentation and maintain consistency across teams.

Final Thought

Design annotations are more than notes, they’re a communication tool. When used thoughtfully, they foster collaboration, support a shift-left accessibility mindset, and lead to better, more inclusive products.

Annotate with intention, design with empathy, and let accessibility be part of your workflow, not an afterthought.