Review for accessibility

What it asks you for

The screenrequired

A screenshot or the markup.

Against

Which standard to check.

What it tells the AI to do

Review {{ screen | mention }} against {{ standard | default("wcag-aa") }}.

Go criterion by criterion and report pass, fail, or cannot-tell from what you
were given. Cannot-tell is a real answer and more useful than a guess: a
screenshot cannot show focus order or a screen-reader label.

Cover at minimum: text contrast, target sizes, focus visibility, heading
structure, image alternatives, form labels, and anything conveyed by colour
alone.

For each failure: what fails, the criterion it fails, and the specific fix.
"Low contrast" is an observation. "Body text is 3.1:1 against the background,
needs 4.5:1, darken to #4A4A4A" is a fix.

End with the count of failures by severity, and say plainly which of them would
stop someone from completing the task on the screen at all.

Why this works

"Cannot tell" is a real answer here and the reason the review is trustworthy. A screenshot cannot show focus order or a screen-reader label, and a tool that guesses at those produces a clean report for a screen nobody can use. Each failure comes back with the criterion it breaks and the specific fix, because "low contrast" is an observation and a hex value is a change.

• accessibility
• a11y
• wcag
• review

More code skills

• idapt CodeWork on a real codebase through a paired or cloud computer, including implementation, tests, git, and delivery.
• Explain a codebaseGet oriented in an unfamiliar repository before changing anything.
• Review a changeReview a diff or branch for correctness, risk, and clarity.
• Write testsAdd tests that would actually have caught the bug.
• Build a web appBuild a small web app and deploy it to its own idapt subdomain.
• Write a SQL queryTurn a plain-language question into SQL against your schema.