Trust — is it safe?
Brief 08

Accessibility Audit

Keyboard navigation, contrast, labels, and screen-reader flow — audited end-to-end along the core user journey.

A11Y.md4 phases8 lenses~2.8k chars

Free & open · no signup · read-only — it ends by asking · nothing leaves your machine

What it does

You are working inside this repo. Mission: audit this product's accessibility end-to-end along its core user journey, and produce fixes ranked by who gets blocked.

This is the broad end-to-end pass. For the deep assistive-tech walk — keyboard only, announcements traced — run 86 after it.

Read-only pass. Your only write is the report file.

What it looks for

8 lenses it looks through

Phase 2 sweeps the codebase through every one of these, citing file and line for each finding.

1

Keyboard

every interactive element reachable and operable; no traps; logical tab order; visible focus styles

2

Semantics

real buttons and links (not clickable divs), heading hierarchy, landmarks, lists as lists

3

Labels

inputs labeled, icon-only buttons named, images with meaningful alt or marked decorative

4

Contrast

body text, secondary text, and UI states against their actual backgrounds

5

Forms

errors associated with fields and announced; instructions not conveyed by color alone

6

Motion

prefers-reduced-motion respected; nothing flashing or auto-moving without control

7

Custom widgets

dropdowns, modals, tabs: correct roles, states, focus management on open/close

8

Touch & zoom

target sizes, page usable at 200% zoom, no viewport zoom disabling

The deliverable

What lands in your repo

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.

A11Y.md
1
Journey walkthrough
the core path narrated as a keyboard + screen-reader user experiences it
2
Findings
each: Issue · Severity · Location · Who it blocks · Fix · Effort
3
Component-level fixes
single fixes that clear many findings at once
4
Quick wins
labels, alt text, focus styles shippable today
One file. Evidence-backed. It ends by asking before touching anything.
How it works

What it makes the agent do

Every Goal Prompt follows the same four steps, so results are consistent and repeatable — no matter which one you run.

1
Phase 1

Pick the journey

Identify the core user journey from the code.

2
Phase 2

Audit through 8 lenses

Cite the component or template for every finding.

3
Phase 3

Curate

Severity.

4
Phase 4

Report

Create A11Y.md at repo root.

Get started

Three ways to run this Goal Prompt

01 · COPY

Paste it in

Copy it and paste it into your agent inside the repo you want checked.

02 · INSTALL

As a slash command

Install the goal plugin once — two commands — then just type /goal:accessibility-audit.

1/plugin marketplace add GhostlyGawd/goal-prompts
2/plugin install goal@goal-prompts

Or install only this Goal Prompt as /goal-accessibility-audit:

curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=08 sh
03 · AGENT

From an agent (MCP)

Let an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.

https://goal-prompts.vercel.app/raw/08.md
Transparency

The exact prompt

Nothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.

Read the full brief (2,763 characters)
# Goal: Accessibility Audit

You are working inside this repo. Mission: audit this product's accessibility end-to-end along its core user journey, and produce fixes ranked by who gets blocked.

This is the broad end-to-end pass. For the deep assistive-tech walk — keyboard only, announcements traced — run 86 after it.

Read-only pass. Your only write is the report file.

## Phase 1 — Pick the journey
- Identify the core user journey from the code: entry → key action → result.
- That path gets the full audit; secondary screens get a lighter pass.
- Note the UI stack: component library, custom widgets, styling system.

## Phase 2 — Audit through 8 lenses
Cite the component or template for every finding.
1. **Keyboard** — every interactive element reachable and operable; no traps; logical tab order; visible focus styles
2. **Semantics** — real buttons and links (not clickable divs), heading hierarchy, landmarks, lists as lists
3. **Labels** — inputs labeled, icon-only buttons named, images with meaningful alt or marked decorative
4. **Contrast** — body text, secondary text, and UI states against their actual backgrounds
5. **Forms** — errors associated with fields and announced; instructions not conveyed by color alone
6. **Motion** — prefers-reduced-motion respected; nothing flashing or auto-moving without control
7. **Custom widgets** — dropdowns, modals, tabs: correct roles, states, focus management on open/close
8. **Touch & zoom** — target sizes, page usable at 200% zoom, no viewport zoom disabling

## Phase 3 — Curate
- Severity: **blocker** (journey impossible for some users) · **major** (painful workaround) · **minor** (friction)
- Group findings that share one root fix (e.g., one Button component fixes 30 instances)

## Phase 4 — Report
Create `A11Y.md` at repo root:
1. **Journey walkthrough** — the core path narrated as a keyboard + screen-reader user experiences it
2. **Findings** — each: Issue · Severity · Location · Who it blocks · Fix · Effort
3. **Component-level fixes** — single fixes that clear many findings at once
4. **Quick wins** — labels, alt text, focus styles shippable today

Start the report with today's date. If `A11Y.md` already exists from a previous run, read it first and lead with what changed since.

## Rules
- Audit the rendered reality, not the intention — trace what actually reaches the DOM
- Component fixes beat page-by-page patching
- No user interface to make accessible 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 fixes to make

House rules for this Goal Prompt

  • Audit the rendered reality, not the intention — trace what actually reaches the DOM
  • Component fixes beat page-by-page patching
  • No user interface to make accessible 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 fixes to make
Keep exploring

Pairs well with

Curated neighbors — briefs that answer the adjacent question, worth running in the same session.

More Trust briefs

Runs inside these playbooks — curated sequences you can launch with one paste: