Skip to main content
Screen reader specs document how assistive technologies should announce and interact with your component across iOS (VoiceOver), Android (TalkBack), and Web (ARIA).
create-voice now renders from the Component Markdown source of truth. Run create-component-md first to produce components/<slug>.md; this skill reads its Voice section + render-meta and renders the Figma frame. It no longer re-extracts from Figma, and it fails fast if the .md is missing.

​
What you need

  • A component .md produced by create-component-md (run it first — create-component-md needs a _base.json from the uSpec Extract plugin). Tell the skill where this .md lives — components/<slug>.md is only create-component-md’s default output path; the file can live anywhere. Without it this skill aborts.
  • Figma MCP connected (Console MCP with Desktop Bridge, or native Figma MCP) — used only to render the frame.
  • A description of states/behaviors is captured upstream by create-component-md; nothing extra is needed here.
Describe all interactive parts and how they relate. For example: “The label and hint merge into the input’s announcement, but the trailing clear button is a separate focus stop.” This helps the agent determine focus order accurately.

​
How to use

Reference the skill and pass the component .md. Add a render destination or any extra context the spec can’t carry:

​
What it generates

The agent analyzes your component’s visual parts, determines which are independent focus stops vs. merged into another element’s announcement, and renders per-platform documentation directly in your Figma file.

​
Simple vs. compound components

Components where all parts merge into a single focusable element.Examples: Button, Checkbox with label, Switch, ToggleThe output documents one focus stop per state, with platform-specific properties for each.

​
Platform properties

Each focus stop is documented with platform-specific properties:

​
Merge analysis

The agent determines how visual parts combine for accessibility:

​
How it works

The screen reader skill is heavily AI-driven — the agent determines merge behavior, focus order, and platform-specific properties, while deterministic scripts handle template rendering and layout. 30% Deterministic 70% AI Reasoning
1

Require the .md

The skill requires components/<slug>.md (produced by create-component-md) and fails fast if it is missing — it does not re-extract from Figma.
2

Parse the Voice section

The skill parses the .md’s Voice section (guidelines, focus order, per-state platform tables) plus the render-meta block and the hidden voice-render-meta focus-stop layer-name carry.
3

Build render inputs

Sections, focus stops (by Figma layer name), variant props, boolean defs, and slot insertions are assembled directly from the parsed .md — no live extraction walk.
4

Import template

The screen reader documentation template is imported from the library, instantiated, and detached into an editable frame.
5

Render

The skill fills header fields, builds focus order diagrams, state tables, and per-platform property sections, placing markers by name-match + live bbox on the rendered instance.
6

Validate

A screenshot is captured and checked for completeness, including that every documented focus stop resolved a marker. Issues are fixed automatically for up to 3 iterations.
The skill renders programmatically, so the output is consistent and repeatable. Running it on the same component produces identical results.

​
Tips for better output

  • List all states: enabled, disabled, selected, expanded, loading. The agent can’t infer states it can’t see in Figma
  • Describe interactive parts and merge behavior: explain which elements are tappable, which are decorative, and which should merge into another element’s announcement. For example: “The label and hint merge into the input’s announcement, but the trailing clear button is a separate focus stop”
  • Mention reactive elements: error messages, status updates, and toasts are announced as live regions, not focus stops. Call them out if they’re part of your component
  • Note focus order preferences: if the traversal order matters (e.g., input before clear button), describe it
  • Describe state-specific announcements: if the announcement changes based on state (e.g., a switch announcing “on” vs “off”), mention it