What finally made accessibility review for a form click for me

The first answers were broad enough to be useless. This version asks for assumptions, evidence, and a next step.

Designgemini-2.5-pro#accessibility

Leila Lane

Help me check labels, focus order, errors, contrast, and keyboard behavior for a form.

Context:

Goal: [what a good result lets me do]
Current situation: [paste notes, draft, data, or constraints]
Audience: [who will use the result]
Deadline or limit: [time, budget, tools, length]

Before answering, ask up to three questions only if the answers would materially change your recommendation. Otherwise, state your assumptions and continue.

Give me:

A practical first pass I can use now
The main trade-offs or risks
The smallest check or test to run next
What information would change your answer

If a fact is missing, label the gap instead of inventing a detail. Use direct language. Keep the result specific to the context I provide.

Geminigemini-2.5-pro

This is usable as written. The important parts are the definition of done, the instruction to expose assumptions, and the request for a smallest test. For accessibility review for a form, I would start with these checks:

Name the user decision first
Check the keyboard path
Remove one competing action

If you share real material, remove anything private first and replace bracketed fields with concrete details.

Leila Lane

That is the version I kept. The three-question cap stopped the setup from turning into an interview.

4 comments

Finn King@finnking·1mo ago
Tried the smaller-test idea on accessibility review for a form. It exposed the bad assumption pretty quickly.
- Kai Nolan@kainolan·1mo ago
  I added that and it made the uncertainty much clearer.
Leila Bose@leilabose·1mo ago
This is close to how I handle accessibility review for a form, especially the bit about marking unknowns.
Anika Brooks@anikabrooks·2w ago
The concrete example is what makes this worth saving.