Accessibility in Snap Studio¶

Audience: Everyone / assistive-technology users · Tags: studio, accessibility, keyboard, screen-reader

Snap Studio is built to be fully usable with a keyboard alone or with a screen reader — not as an afterthought bolted on afterward, but as part of how every stage works. This page documents exactly what to expect.

The keyboard path¶

Every interactive element in Studio — every button, text box, and textarea — is a real HTML <button>, <input>, or <textarea>. That means the whole builder is reachable with Tab (and Shift+Tab to go back), with no custom widgets that trap or skip focus, and every focused element shows a visible focus outline so you always know where you are.

Roughly, tabbing through Studio looks like this:

Stage 1 — Describe it: the description textarea, the three example-prompt buttons, the Quick Send toggle (and its own fields if you open it), then the submit button.
Stage 2 — Review & edit: each step card's fields in order, top to bottom, then the Check my flow button.
Stage 3 — Save & test: the Save & test it button, and — once it finishes — either the Flows link and Build another button (success), or the Go back and edit button (failure).

Every clickable target — buttons, fields, links — measures at least 44 pixels, so it's easy to hit accurately even without fine pointer control, and all body text is at least 16 pixels, so nothing depends on zooming in to be legible.

Studio uses a single, shared aria-live="polite" status region for everything the assistant "says" — its messages, its stage transitions, its confirmations. That means you don't have to go hunting around the page for what just happened; it's announced to you as it happens, in one predictable place.

One subtlety: sometimes the assistant needs to say the same thing twice in a row — for example, if you click Check my flow twice without changing anything and get the same "still needs fixing" result both times. Screen readers normally stay quiet the second time, since the text on screen didn't change. Studio works around this with a tiny, invisible character it toggles in and out of the message on each announcement, so your screen reader treats it as new text and reads it again, even though nothing visible changed.

How focus moves¶

Two rules govern focus in Studio, and they're consistent everywhere:

On every stage change, keyboard focus moves programmatically to that stage's <h2> heading. Land on Stage 2, and your screen reader announces "Review & edit" (or similar) immediately, with focus sitting right at the top — so you can tab straight down through the new content instead of hunting for where the page moved.
On a validation problem, focus moves to the first invalid field so you can fix it immediately. If a problem isn't tied to one specific field (it's about the flow as a whole), focus moves to the problems list instead.

How errors are surfaced¶

Every field has a real <label for="..."> connected to its input, so a screen reader always announces what a field is for, not just that it exists. Help text is wired up with aria-describedby, so it's read along with the label rather than sitting silently on the page.

When Check my flow finds a problem, the problem list is marked role="alert", so it's announced immediately through the shared status region. The specific field it points to gets aria-invalid="true" plus its own inline error message, right next to the field itself — so the announcement, the visual flag, and the fix are all in the same place.

Status is never color alone¶

Every status Studio shows you — done, failed, running, waiting — pairs a distinct icon with the word itself. You never have to distinguish "succeeded" from "failed" by shade of green versus red alone; the word is always there too, and it's what a screen reader reads.

Reduced motion¶

Stage 3's step-by-step narration normally reveals one step roughly every 700 milliseconds, for a readable pace. If your operating system is set to reduce motion, Studio detects the prefers-reduced-motion: reduce setting and skips the animation — every step appears at once instead of one at a time.

Studio doesn't have its own separate "reduce motion" toggle; it simply respects the setting your operating system already provides:

Windows: Settings → Accessibility → Visual effects → turn off "Animation effects."
macOS: System Settings → Accessibility → Display → turn on "Reduce motion."
iOS: Settings → Accessibility → Motion → turn on "Reduce Motion."
Android: Settings → Accessibility → turn on "Remove animations" (exact naming varies by device and manufacturer).

Turn it on once at the OS level, and every app that respects it — Studio included — picks it up automatically.

Plain language throughout¶

Alongside all of the above, Studio avoids unexplained jargon. Where a technical term is unavoidable (like "webhook"), it's explained in plain words the first time it appears, not assumed.

If something goes wrong¶

See Snap Studio problems. If you hit an accessibility issue specifically — something not announced, a focus trap, anything above that doesn't hold up in practice — please report it; it's a defect, not expected behavior.

Related: Snap Studio overview · Review & edit · Save & test