PhraseryPhrasery homeGet Phrasery
Tests & QA21 categories

Accessibility test pass on a feature

Before shipping any interface, not after someone files a complaint.

Longaccessibilitychecklistfrontend
Run an accessibility review of the interface below.

Check, and for each state pass, fail or cannot tell from what I gave you:
1. Keyboard only: every action reachable, visible focus, logical order, no traps, escape closes what it opens.
2. Screen reader: meaningful names for controls, correct roles, headings in order, images with appropriate alternatives, decorative images hidden.
3. State changes announced: errors, loading, results appearing, dynamic content.
4. Colour: contrast ratios for text and interactive elements, and nothing conveyed by colour alone.
5. Forms: labels tied to inputs, errors identified in text and associated with the field, no reliance on placeholder as label.
6. Motion, zoom to 200 percent, and reduced-motion preferences.

Give the exact element for each failure and the fix. Then list what can only be verified by testing with a real screen reader.

Interface or markup:

Making it yours

  • Paste your own material where the prompt asks for it. Everything above that line is instruction, not content.
  • Delete any rule that does not apply to you. A shorter prompt that fits beats a thorough one that does not.
  • If the answer comes back vague, add a line saying what you do not want. Constraints work better than encouragement.

Beyond unit tests. Manual QA, exploratory charters, accessibility, load, and contracts between services.

Related prompts

Keep this one

Phrasery saves prompts with a right-click and puts them back the same way. Add this to your own library in one click.

Add to your browser โ€” free