Best for
- Checking a new screen before it ships, in minutes not days
- Making accessibility part of review instead of a yearly audit
- Developers who want the checklist that actually matters
What you give it
- The page, component or diff to sweep
What you get back
- Pass/fail per check with the failing element named and the fix suggested
- Severity honestly assigned: who is locked out versus who is inconvenienced
- The component-level note when a fix belongs in the design system, not this screen
How it works
- Runs the high-yield checklist in a fixed order: keyboard reachability and traps, visible focus, names and labels, contrast, zoom, announcements of dynamic changes.
- Names the failing element specifically and suggests the fix in your codebase's own patterns.
- Ranks by exclusion: cannot-use beats hard-to-use beats unpleasant.
- Spots the pattern-level fixes: when the bug is a component, fixing the screen is treating one symptom.
Example
You: Sweep the new settings page before Thursday's release.
Result: Nine checks run: three fails — the toggle rows are divs with click handlers (keyboard users locked out: blocker; the fix is the existing Button component), the danger-zone text fails contrast at 2.8:1, and the save confirmation appears without being announced. Six passes noted. Fifteen minutes, fix list ordered, and a note that the toggle pattern recurs on two other pages — one component fix covers all three.
Limits — please read
- A sweep catches the common majority of issues; full flows against a standard need the deeper audit (an auditing agent pairs well).
- Assistive-technology user testing remains the truth a sweep approximates.
- Content quality (alt text that is PRESENT but useless) is flagged where obvious, judged by humans where subtle.