All 141 tools / Research and usability testing
Check a form's markup against Wroblewski's Web Form Design rules and get a fix for each finding
Form checkFreeFor designers, developers and product teams
15/day
free runs a day, no sign-in.
Before: what you give it
The example input, as typed in. You give it a page address.
<form action="/join"><input type="text" name="name" placeholder="Your name"><label>Email <input type="text" name="email"></label><label for="pw">Password *</label><input type="password" id="pw" name="pw" required><label>Plan <input type="radio" name="plan" value="a"> Free <input type="radio" name="plan" value="b"> Pro</label><button type="submit">Submit</button><input type="reset" value="Reset"></form>
After: what comes back
The first lines of a real run on that input. Nothing here is edited by hand.
# Form check: 1 form(s), 2 high, 5 medium, 3 low Rules follow Luke Wroblewski's Web Form Design (label alignment, required marking, input count, grouping, button labels, inline validation). Where a check is a common convention and not his stated rule, the finding says so. Static markup only: label position on screen, real error behaviour and script-built fields need a browser check. ## Form 1 (5 visible fields) - [high] placeholder-as-label (name): Field "Your name" has a placeholder but no label. The hint vanishes when the person types, and many screen readers will not announce it as a name. Fix: Add a visible label above the field and keep the placeholder for an example only. - [high] button-label: A Reset button sits in the form. It is easy to hit by mistake and wipes everything. Fix: Remove it. If you need an escape, use a quiet text-style Cancel link, visually weaker than the primary action. - [medium] autocomplete (name): Looks like a name field with no autocomplete attribute. Fix: Add autocomplete="name" so browsers can fill it. ... full output on the tool page
What you get
Findings by severity covering labels, placeholders, field count, input types, validation hooks and buttons
What it cannot do
Reads static markup only, so label alignment from CSS and script-built fields are invisible; use audit_form for WCAG findings.
Who it is for
- Designers
- Developers
- Product teams
Free and Pro
| Free | 15 runs a day per IP address, up to 100,000 characters a run. |
|---|---|
| Pro | No daily limit, 300 requests a minute, up to 200,000 characters a run. |
Use it from your assistant
The tool is called check_form. Connect the server once, then ask for it by name or just describe the job. Install steps for each app.
claude mcp add --transport http designers https://designers.allthepossibles.com/mcpcurl -X POST https://designers.allthepossibles.com/api/form-check -H 'content-type: application/json' -d '{"html":"<form action=\"/join\"><input type=\"text\" name=\"name\" placeholder=\"Your name\"><label>Email <input type=\"text\" name=\"email\"></label><label for=\"pw\">Password *</label><input type=\"password\" id=\"pw\" name=\"pw\" required><label>Plan <input type=\"radio\" name=\"plan\" value=\"a\"> Free <input type=\"radio\" name=\"plan\" value=\"b\"> Pro</label><button type=\"submit\">Submit</button><input type=\"reset\" value=\"Reset\"></form>"}'Try it here
The form starts with the same example input, so you can run it first and then swap in your own.
More in research and usability testing
- Usability numbers
Score SUS results and work out sample sizes for usability tests, A/B tests and surveys.
- Heuristic review
Get a Nielsen heuristic worksheet for a screen or flow, with signals showing where to look first.
- Critique plan
Plan a design critique for the stage the work is in, with timed rounds, roles and feedback to hold back.
- Research questions
Find leading, double-barrelled and hypothetical questions in an interview or survey script and rewrite them.
- Trunk test
Check whether a page answers Krug's six trunk-test questions: site, page, sections, options, location, search
- Card sort analyser
Turn open card-sort results into a similarity matrix and suggested categories from participant agreement