Form blocks and controls
A form is a series of questions, and most form bugs are a control answering a different question from the one being asked. These blocks cover the controls and the assembled forms, and the rules for matching one to the other are older and firmer than most people expect.
10 families, 51 blocks
- Forms3 blocksContact, application and settings forms: anything that asks and has to be answered
- Inputs8 blocksAnything typed: a name, a search, a password, a number, a card, a link
- Text Areas3 blocksComments, prompts, long-form input
- Checkboxes6 blocksForms, bulk selection, settings
- Radio Groups5 blocksPlans, single-choice settings, surveys
- Switches8 blocksSettings, integrations, consent: anything that applies the moment it is flipped
- Sliders7 blocksVolume, budgets, ranges
- Button Groups4 blocksA row of peers answering one question, an ordered walk, or actions welded to a field
- Ratings4 blocksReviews, feedback forms, product pages
- Sign in3 blocksSign-in, sign-up, verification and account recovery screens
What these are for
The controls here split by the shape of their answer. One value from a small known set is a radio group or a button group. Any number from a set is checkboxes. A single on-or-off that takes effect immediately is a switch. A number from a continuous range is a slider. Free text is an input or a text area depending on whether the answer has a length. Those mappings are conventions, but they are conventions every reader already knows, and breaking one costs comprehension for no gain.
The assembled blocks — forms and sign-in — are here because the hard parts of a form are not its fields. They are the error summary, the label-to-input association, the order things receive focus, what happens when submission fails on the server after passing in the browser, and where the button goes. Those are solved once in the block rather than re-solved per screen.
Validation display is part of the control, not a layer over it. A field that turns red without saying why has told the reader they are wrong and not what to do, which is the single most common failure in this category and the reason every input block here carries a message slot rather than only a border colour.
Choosing between them
Switch or checkbox?
A switch applies immediately; a checkbox is a value you are still composing and will submit. "Email notifications" in a settings panel that saves as you go is a switch. "I agree to the terms" is a checkbox, because nothing happens until you submit. The tell is whether there is a save button: if there is, the control is almost certainly a checkbox, and a switch will make readers wonder whether it already took effect.
Radio group or dropdown?
Count the options and ask whether seeing them matters. Up to about five, and when comparing them is part of choosing — pricing plans, shipping speed — a radio group shows all the answers at once and is faster and more accurate. Beyond that, or when the reader already knows the answer they want, a dropdown or combobox stops the options from swamping the form. A list of fifty countries is never a radio group.
Button group or tabs?
They look alike and mean different things. A button group answers a question and its value gets submitted or applied — a unit toggle, a date-range picker, a sort order. Tabs move you between views of something that is already on screen and change nothing about the data. If you would put the value in a form payload, it is a button group.
Slider or number input?
A slider is for values where the approximate answer is acceptable and the range is the context — a budget between two bounds, a volume, an opacity. A number input is for values where precision matters or the range is unbounded. Sliders are also hard to operate precisely on a touchscreen, so any value a reader might want to type exactly should have an input beside the slider rather than instead of the reader's patience.
Input or text area?
Whether the answer can contain a line break. A name, an email, a reference number and a search term are all one line, and a text area for them invites a paragraph that the field behind it cannot store. A comment, a description or a prompt is a text area, and it should grow with its content rather than trapping the reader in three visible lines of a longer answer.
Questions
Are these controls accessible?
Every control here ships with its label association, its focus behaviour and its keyboard interaction, because those are the parts that get dropped when a control is rebuilt per project. A radio group moves between options with the arrow keys and takes one tab stop, not one per option; a switch reports its state rather than only showing it. Accessibility that is rebuilt per screen is accessibility that is wrong on most of them.
Do they come with validation?
They come with the display of validation — the message slot, the error styling, the association between a field and its message so a screen reader announces them together. The rules themselves stay yours and stay with your schema, because the same field is required in one form and optional in another, and a control that decided that for you would be wrong half the time.
Can I use these with React Hook Form or similar?
Yes. They are controlled components taking a value and a change handler, which is the interface every form library in both React and Vue already expects. Nothing here owns its own state in a way that would fight a form library for it.
The other categories
All documentation
Getting started
Foundations
All components