Walk the product the way assistive-tech users do — keyboard only, then with a screen reader — and find every place that path breaks.
Free & open · no signup · read-only — it ends by asking · nothing leaves your machine
You are working inside this repo. Mission: go past the automated accessibility checks and walk the real interaction paths — operate everything by keyboard, then trace what a screen reader would announce — and find where a non-mouse, non-sighted user gets stuck.
This is the deep assistive-tech walk. For the broad end-to-end accessibility pass along the core journey, run 08 first.
Read-only pass. Drive the UI, read the components and markup; change nothing. Your only write is the report file.
Phase 2 sweeps the codebase through every one of these, citing file and line for each finding.
every interactive control operable without a mouse; no keyboard traps
logical tab order, a visible focus ring, focus moved on route and modal changes
real landmarks, headings, lists, and buttons instead of div-soup
controls that announce what they are and their state (pressed, expanded, selected)
async updates, toasts, and errors announced rather than silent
labels tied to inputs; errors announced and associated with the field
captions and alt text present; prefers-reduced-motion honored
One structured report at the repo root — or in reports/, if you keep one — the same shape every time, ready for a teammate — or the optional Studio — to act on.
Every Goal Prompt follows the same four steps, so results are consistent and repeatable — no matter which one you run.
Pick the product's main journeys and operate each using only the keyboard — no mouse at all.
Cite the component or screen for every finding.
Rank by how completely a finding blocks the task.
Create A11Y-DEEP.md at repo root.
Copy it and paste it into your agent inside the repo you want checked.
Install the goal plugin once — two commands — then just type /goal:keyboard-screenreader-flow.
/plugin marketplace add GhostlyGawd/goal-prompts/plugin install goal@goal-promptsOr install only this Goal Prompt as /goal-keyboard-screenreader-flow:
curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=86 shLet an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.
https://goal-prompts.vercel.app/raw/86.mdNothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.
# Goal: Keyboard & Screen-Reader Flow You are working inside this repo. Mission: go past the automated accessibility checks and walk the real interaction paths — operate everything by keyboard, then trace what a screen reader would announce — and find where a non-mouse, non-sighted user gets stuck. This is the deep assistive-tech walk. For the broad end-to-end accessibility pass along the core journey, run 08 first. Read-only pass. Drive the UI, read the components and markup; change nothing. Your only write is the report file. ## Phase 1 — Walk the core flows - Pick the product's main journeys and operate each using only the keyboard — no mouse at all. - For the same flows, trace the accessibility tree: what name, role, and state each control exposes. - Note where you get trapped, lost, or given no feedback. ## Phase 2 — Audit through 7 lenses Cite the component or screen for every finding. 1. **Keyboard reachability** — every interactive control operable without a mouse; no keyboard traps 2. **Focus order & visibility** — logical tab order, a visible focus ring, focus moved on route and modal changes 3. **Semantic structure** — real landmarks, headings, lists, and buttons instead of div-soup 4. **Name, role, state** — controls that announce what they are and their state (pressed, expanded, selected) 5. **Live regions** — async updates, toasts, and errors announced rather than silent 6. **Forms & errors** — labels tied to inputs; errors announced and associated with the field 7. **Media & motion** — captions and alt text present; `prefers-reduced-motion` honored ## Phase 3 — Curate - Rank by how completely a finding blocks the task: a keyboard trap on checkout outranks a missing heading. - Map each to the WCAG criterion it fails, so fixes are auditable. - Prefer fixes that use native semantics over ARIA patches. ## Phase 4 — Report Create `A11Y-DEEP.md` at repo root: 1. **Keyboard walk** — each core flow, where it breaks, and the blocking severity 2. **Screen-reader walk** — what is announced vs what should be, per control 3. **Findings** — each: WCAG criterion · location · who it blocks · the fix 4. **Highest-impact fixes** — the handful that unblock the most real AT users Start the report with today's date. If `A11Y-DEEP.md` already exists from a previous run, read it first and lead with what changed since. ## Rules - Test the path, not just the snapshot; automated scans miss the flow - Native semantics first; ARIA is a patch, not a foundation - No keyboard-operable UI in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding. - If a `reports/` directory exists at the repo root, write the report there instead of the root. - Before asking, present the top findings as a ranked list in plain words - Report only — end by asking which accessibility fixes to make first
reports/ directory exists at the repo root, write the report there instead of the root.Curated neighbors — briefs that answer the adjacent question, worth running in the same session.
A defensive review of your own codebase — auth gaps, injection surfaces, exposed secrets, and data leaks, ranked by exploitability.
Vulnerable, abandoned, oversized, or duplicated packages — the full health check on every dependency this project stands on, with removal candidates named.
Keyboard navigation, contrast, labels, and screen-reader flow — audited end-to-end along the core user journey.
Hardcoded strings, locale-blind number and date formatting, and layouts that break in translation — every gap between you and a non-default-locale user.