Alternative Text in Figma: Designing Accessible UI with WCAG in Mind

“Alternative text in Figma” is a common search because designers want to do the right thing—yet Figma doesn’t have a single, universally enforced “alt text” field that automatically becomes HTML alt attributes. Still, you can document text alternatives clearly in Figma so developers, content authors, and QA can implement them correctly and consistently.

This matters for digital accessibility and WCAG compliance: missing or poor text alternatives can block users of screen readers, voice control, braille displays, and even users on slow connections where images don’t load. Good alt text also improves clarity for everyone by forcing teams to articulate what an image contributes to the user’s task.

What WCAG requires (and what “alt text” really means)

WCAG’s core requirement for non-text content is WCAG 2.2 Success Criterion 1.1.1 Non-text Content: provide a text alternative that serves an equivalent purpose. In practice, “alt text” can mean different things depending on the UI element:

• Informative images: need a concise description of what users must know.
• Decorative images: should be ignored by assistive tech (e.g., empty alt="" in HTML, or marked decorative in the implementation).
• Icons used as controls: often need an accessible name (like an aria-label or visible text), not a traditional image alt.
• Complex images (charts, infographics): require a short alt plus a longer text alternative nearby (caption, summary, table, or link).

Figma’s role is to help you define intent: what is decorative, what conveys meaning, and what label a control should expose to assistive technology.

Where to specify alternative text in Figma (practical options)

Because handoff varies (Dev Mode, plugins, design tokens, component libraries), the best approach is to use repeatable patterns your team agrees on. Here are reliable methods that work across many workflows:

1) Use component properties and naming conventions

For reusable components (buttons with icons, cards with images), define a property or variant guidance like:

• Image role: Decorative / Informative / Functional
• Accessible name: e.g., “Search”, “Close dialog”, “Download invoice”
• Alt text (if image): concise description

Even if Figma isn’t exporting alt attributes, these properties become a single source of truth for developers implementing accessible names and alternatives.

2) Add “Accessibility notes” directly on frames

Create a consistent annotation style (sticky notes, callouts, or a dedicated “A11y” layer) that includes:

• What the image communicates and why it’s needed
• The proposed alt text (or “Decorative: ignore”)
• If complex, where the long description will live (e.g., “Add data table below chart”)

This works especially well when paired with a team checklist or design review ritual.

3) Include alt text in a content/spec panel

Many teams maintain a “Content specs” page in the same Figma file. Add a table-like structure for each screen:

• Element ID / layer name
• Type (image, icon, control)
• Text alternative (alt / label)
• Notes (decorative, long description link, localization)

This reduces ambiguity when a single screen contains many images or repeated icon buttons.

How to write alt text that supports inclusive design

Alt text quality is often the difference between “technically present” and “actually helpful.” Use these guidelines:

Keep it task-focused, not pixel-focused

• Good: “Customer support agent smiling while wearing a headset.” (if the intent is to signal friendly support)
• Too literal: “A person sitting at a desk with a computer and phone.”

Avoid repeating nearby text

If an image caption already says “2026 Pricing,” don’t write alt text that repeats the caption. Instead, describe what’s not already conveyed.

Skip “image of” and “photo of” in most cases

Screen readers already announce the element type. Start with the content: “Map showing store locations in Austin,” not “Image of a map…”

For icons, prioritize the accessible name of the control

If a magnifying glass icon is a button that triggers search, the key is the control name: “Search.” If it’s purely decorative next to a “Search” label, it may be decorative and ignored.

Plan for localization

If your product is multilingual, treat alt text as translatable content. In Figma, flag alt strings that must go through localization so they don’t get hard-coded in English.

Common UI scenarios in Figma (and what to specify)

Hero banners and marketing images

Ask: does the image convey information needed to understand the page? If yes, add meaningful alt. If it’s purely mood-setting, mark decorative.

• Decorative hero: alt=""
• Informative hero: “Person using a screen reader on a smartphone” (if the page is about accessibility features)

Cards with thumbnails

If the thumbnail helps identify content (e.g., news article image), alt should summarize what’s relevant. If the card already includes a clear title that uniquely identifies the content, you may not need detailed alt—sometimes decorative is acceptable depending on context.

Charts and dashboards

Charts are rarely accessible with alt text alone. In Figma, specify both:

• Short alt: “Line chart of monthly signups, Jan–Jun.”
• Long alternative: “Provide a data table under the chart and a 2–3 sentence trend summary.”

Form field icons and status indicators

A green check icon that indicates “Valid” must be conveyed to non-visual users. Specify the text alternative via helper text or an accessible status message, not just an icon. This also supports WCAG requirements beyond 1.1.1, like ensuring status messages are programmatically determinable.

Handoff: making sure design intent becomes accessible code

The biggest failure mode is that alt text exists in Figma annotations but never makes it into production. Reduce that risk with a handoff routine:

• Layer naming: Use predictable names like “IMG_product-hero_alt=…” for quick reference (or store alt in a structured spec table).
• Dev checklist: Every PR that adds images confirms: decorative vs informative vs functional handled correctly.
• QA with assistive tech: Spot-check with a screen reader (NVDA/JAWS/VoiceOver) and keyboard navigation.

If you’re unsure where to start on auditing what’s already shipped, see Is Your Website Accessible? Here’s How to Find Out for a practical baseline.

Why this matters for compliance (and risk)

Text alternatives are one of the most frequently cited accessibility failures because they’re easy to miss and highly visible to assistive technology users. Accessibility enforcement also applies across industries: retail brands have faced real consequences (for context, read Fashion Nova’s $5.15 Million Web Accessibility Settlement: What It Means for WCAG Compliance), and public-sector sites aren’t exempt either (Louisiana Website Accessibility Case: Government Sites Are Not Exempt).

For organizations with constrained resources—like NGOs—building accessibility into design artifacts (including alt text specs) can prevent costly rework. See Digital Accessibility for NGOs & Non-Profit Organizations for strategies that scale.

If you operate in or sell into the EU, accessibility requirements may also be driven by the European Accessibility Act. A structured process that starts in Figma and continues through testing supports those obligations; Free EAA Audit: How to Check Website Accessibility for the European Accessibility Act can help you understand what to validate.

How Corpowid fits into an alt-text workflow

Even with strong Figma specs, teams need verification in the live product. Corpowid (corpowid.ai) can help by running automated accessibility audits and ongoing monitoring to flag missing or suspicious text alternatives (like redundant alt, filename-based alt, or unlabeled icon buttons) so issues don’t quietly reappear after releases.

A simple “Alternative text in Figma” checklist

• Mark every image as decorative, informative, functional, or complex.
• Provide alt text only when the image conveys necessary information.
• For icon-only controls, specify the accessible name (label) the control should expose.
• For charts/infographics, include a long text alternative plan (summary + data table or equivalent).
• Ensure alt text is unique, concise, and not duplicated by nearby text.
• During handoff, confirm developers know where to implement (alt attribute vs aria-label vs visible text).

When your team treats alternative text as a design deliverable—captured clearly in Figma and validated in production—you reduce friction for developers, improve usability for assistive technology users, and move closer to consistent WCAG compliance. Tools like Corpowid (corpowid.ai) complement this by helping you continuously verify that what you designed is what users actually experience.