Accessibility review checklist for interfaces

--- name: accessibility-review-checklist-for-interfaces description: "Reviews web or app interfaces, designs, or front-end code for accessibility barriers and reports each issue with severity, affected users, guideline reference, and a concrete fix. Use when reviewing a page, component, or design before release." --- Apply this whenever you are asked to review, build, or critique a user interface, a design mockup, or front-end code, even if accessibility was not mentioned. Steps: 1. Identify what you can actually check from the material given (screenshot, design file description, code, written description). State clearly what you could not test, such as real screen reader output or keyboard behaviour in a live page. 2. Check the essentials: text alternatives for meaningful images and icons; colour contrast for text and controls; information not conveyed by colour alone; headings and page regions in a logical order; every interactive element reachable and usable by keyboard with a visible focus indicator; form fields with visible labels, clear error messages, and instructions; accessible names and roles for custom controls; focus moved sensibly when dialogs, menus, or new content appear; content that still works at 200% zoom and on narrow screens; motion that can be reduced; time limits that can be extended; plain language and predictable behaviour. 3. For each issue, state where it is, what goes wrong, who is affected (for example screen reader users, keyboard-only users, people with low vision or cognitive disabilities), the relevant web accessibility success criterion by number and name when you are confident of it, a severity (critical, serious, moderate, minor), and a concrete fix, with a short code or design example when it helps. 4. Order issues by impact on people, not by guideline number. Output shape: a one-paragraph summary, a table of issues (location, problem, affected users, criterion, severity, fix), then a short list of things to test manually with assistive technology. Avoid: declaring a product compliant, treating automated scores as proof, adding ARIA attributes where a native element would work, and vague advice such as 'improve contrast' without the target ratio.

Summary: The sign-up form has two critical barriers for keyboard and screen reader users and one moderate contrast issue. Real screen reader behaviour could not be tested from the code alone. | Location | Problem | Affected users | Criterion | Severity | Fix | |---|---|---|---|---|---| | Country dropdown | Custom menu cannot be opened with the keyboard | Keyboard-only, screen reader | 2.1.1 Keyboard | Critical | Use a native select element | | Email field | Placeholder is the only label | Screen reader, low vision | 3.3.2 Labels or Instructions | Serious | Add a visible label tied to the input | | Grey helper text | Contrast 2.9:1 | Low vision | 1.4.3 Contrast (Minimum) | Moderate | Darken to at least 4.5:1 | Test manually: tab order through the form; how errors are announced on submit.