Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →jpoindexter/forms-and-data-entry
Reference-grade guide to forms and data entry — single-column layout, persistent labels, the right input type + mobile keyboard + autocomplete token per field, blur-timed inline validation with :user-invalid and actionable errors, smart defaults, multi-step wizards, and data tables/grids at scale, all keyboard- and screen-reader-accessible across web and mobile.
Passed 21 of 22 test cases with the skill, and 18 of 22 without it.
3 fixed18 passed either way1 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
To minimize visual clutter and height on our login form, we plan to remove field labels and rely on placeholder text inside the input boxes (e.g. 'Enter Email'). Is this a recommended design pattern?
| Checked | Without skill | With skill |
|---|---|---|
| Rejects using placeholder text as a substitute for a persistent label. | Passed | Passed |
| Requires explicit label elements associated programmatically via label for and input id. | Missed | Passed |
The instructions your model reads when the skill loads.
A form is a conversation, not an interrogation. Every field is a cost the user pays; every field you remove is a conversion you keep. The job: ask for the least, in the clearest order, with the right control and keyboard, validate kindly, and tell people exactly how to fix mistakes. Get layout, labels, input type, and validation right and the rest is polish.
Single column wins. A single top-to-bottom column has one unambiguous reading path; multi-column forms force the eye to zig-zag, double completion time, and routinely get fields skipped or mis-paired. The only sanctioned exceptions sit inside one logical field and read left-to-right anyway: City / State / ZIP, Expiry / CVC, First / Last. Never split unrelated fields across columns.
| Do | Don't |
|---|---|
| One vertical column, full-width fields | Two columns of unrelated inputs side by side |
Group Expiry+CVC, City+State+ZIP on one row | Put Name and Phone side by side |
| Order fields the way the user thinks (name → email → address → payment) | Random or DB-schema order |
| One thing per screen on mobile for long flows | Cram a 15-field form onto one mobile view |
<fieldset> + <legend> for related sets (an address block, a radio group). Section long forms with headings ("Contact", "Shipping", "Payment") and visual breaks so it reads as chunks, not a wall.The label is the contract. It must be visible, persistent, programmatically associated, and clickable.
<!-- Always: real <label for> tied to input id. Clicking the label focuses the field. -->
<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email" />
| Placement | Pros | Cons | Use when |
|---|---|---|---|
| Top (default) | Fastest scan, single eye-path, wraps on mobile, most room | Slightly taller form | Almost always — the safe default |
| Left / inline | Compact vertical height | Slow eye-path, fragile RTL/i18n, weak on mobile | Dense desktop settings, short label set |
| Floating | Compact at rest, label persists once filled | Tiny when floated, animation distracts, empty-state reads like placeholder | Space-constrained, when done carefully |
*. If you use *, define it and add aria-label="required" / required.aria-describedby so AT reads it.aria-live="polite"), shown as remaining ("28 left"), and never the sole signal — pair with maxlength only when a hard cap is real (don't cap names/addresses).test cases passed, vs 18 / 22 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.