Accessibility Test Suite
Make accessibility checks part of normal development rather than an audit before launch.
What it adds
Automated accessibility checks over components and pages, paired with a defined set of manual keyboard and screen reader passes.
What your agent is told to do
5
What your agent is told to do
5-
1
Run automated checks against both isolated components and assembled pages, because contrast and naming failures show up in components while landmark, heading order, and duplicate-label failures only appear once the page is built.
-
2
Write scripted keyboard passes for the flows that matter: tab through the whole flow, operate every control without a pointer, confirm focus is visible at each step, and confirm focus returns sensibly when a dialog closes.
-
3
Test components in their open, loading, error, and disabled states rather than only their resting state, since a dialog that traps focus correctly when open may leave focus stranded when it closes on an error.
-
4
Record any known violation as a dated, owned exception with a stated reason and a review date, and fail the run when an exception passes that date rather than letting it become permanent.
-
5
Broader visual review — hierarchy, spacing, copy, and responsive behaviour — belongs to the Design QA Checklist; this brief owns the machine-checkable and keyboard-checkable half. Do not duplicate the checklist's judgement items as automated assertions.
Edge cases it handles
7
Edge cases it handles
7- An automated pass covers only a fraction of real accessibility barriers, so a green run must never be reported as an accessibility guarantee — pair it with the manual passes and say plainly what was not checked.
- Components hidden behind an interaction go untested unless the suite opens them, so menus, dialogs, tooltips, and expanded rows must be driven into their open state before being checked.
- Loading and error states are where accessible names and live-region announcements are most often missing, and they are the states least likely to be present when a check runs against a resting component.
- An exception with no expiry becomes a permanent silence; every suppression needs an owner, a reason, and a date at which it is reconsidered.
- Checks running against a component in isolation will report missing landmarks and heading structure that the surrounding page actually provides, so those rules belong to the page-level run only.
- Colour contrast depends on the rendered theme, so a suite that only tests one theme misses every contrast failure in the other.
- A check that fails intermittently because the page had not settled will be disabled rather than fixed; wait for a visible, stable outcome before asserting.
Definition of done
8
Definition of done
8- Automated checks run against both components in isolation and fully assembled pages, in every supported theme.
- Scripted keyboard passes cover each major flow end to end, including focus visibility and focus return after a dialog closes.
- Open, loading, error, and disabled states are exercised, not only resting states.
- Every suppressed violation has a named owner, a written reason, and a review date, and the run fails once that date passes.
- The reported result states which checks are automated and which require a human, rather than presenting a passing run as full coverage.
- No check in the suite fails intermittently on an unchanged codebase.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Interaction Test Harness
Interaction Test Harness
Test the app the way a person uses it, through real clicks, keys, and focus.
What it does
A test setup that drives menus, dialogs, forms, and navigation through genuine user interactions and asserts on what the user can see.
How it works
- 1 Find elements the way a user finds them — by their visible label, their role, and their accessible name — rather than by class names or internal test hooks, so a test breaks when the interface becomes unusable and not when a wrapper is renamed.
- 2 Drive each interaction through both pointer and keyboard where both are supported, and assert on where focus ends up as well as on what the screen shows.
- 3 Assert on the visible outcome and wait for it to appear, rather than sleeping for a fixed interval and hoping. A timer-based wait is either slow on every run or flaky on a loaded machine.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/interaction-test-harness
UX Edge-Case Checklist
UX Edge-Case Checklist
Make every UI feature state what it does when things go wrong before it counts as done.
What it does
A required list of non-happy-path behaviours — failure, empty, loading, offline, permission, mobile, and accessibility — answered per feature.
How it works
- 1 Attach the checklist to the point where work is proposed and to the point where it is reviewed, so the answers exist before the feature is built rather than being reconstructed afterwards.
- 2 Require a concrete answer for each category: what the empty state says and what it offers, what appears while data is loading, what the user sees when the request fails, and what a user without permission gets instead.
- 3 Make each answer an outcome someone else could verify. A feature that says errors are handled has not answered; one that says a failed save keeps the form open with the values intact and a retry has.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/ux-edge-case-checklist
Responsive QA Matrix
Responsive QA Matrix
Decide which screen sizes, zoom levels, and text settings every flow has to survive.
What it does
A written matrix of viewports, orientations, zoom levels, and text-size settings that each major flow is tested against.
How it works
- 1 List the app's major flows, then write down for each the exact widths, orientations, zoom levels, and text-size settings it must pass, so testing stops depending on whichever window size the reviewer happened to have open.
- 2 Include the widths that break layouts rather than only the comfortable ones: the tablet in portrait, the narrow desktop window beside a chat panel, the phone in landscape, and the width just below each breakpoint.
- 3 Include a large-text pass at increased browser font size and at 200 per cent zoom, and treat clipped, overlapped, or unreachable content at those settings as a failure rather than a cosmetic issue.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/responsive-qa-matrix
How it works
-
1
Copy the link
Grab the Markdown instruction URL for this feature.
-
2
Give it to your AI
Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
-
3
It inspects, then implements
Your agent reads your existing app first, then adds the feature to fit it.
Works with your stack
These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.
Need it tighter than that? Customize the feature and tell it exactly what you're running.