Section 3 Form Components
3.1 Component Types
Engles states the top 3 components to use on a form are:
- radio buttons
- checkboxes
- text boxes
for the following reasons:
- users are familiar with them
- they work on all screen sizes, including mobile
- they’re built into the HTML specification
- they’re accessible
- they’re simple to use
3.1.1 Input text field
3.1.1.1 Best Practices:
3.1.1.1.1 Use field length as an affordance
Match the size of the text input box to the length of the response the user should provide.
3.1.1.2 Anatomy of a text box
An input text field consists of the following parts:
- Container/Border
- Label
- Placeholder/Input text
- Trailing icon (Optional element)
- Helper text/Error text (Optional element)
- Leading icon (Optional element)
3.1.1.2.1 Container
The container is the visible boundary of the input — usually a border, a background fill, or both. Its job is to communicate three things at a glance: that this is an area to be filled in, how much room the answer should take (see Use field length as an affordance), and what state the field is in.
Keep the resting state quiet but clearly delineated — a field with no visible boundary at all forces users to hunt for where to click. Reserve stronger visual treatment for the focus, error, and disabled states, so those changes carry meaning. Make sure the container’s border has sufficient contrast against the page background to remain perceivable for low-vision users; a very faint hairline border can fail contrast requirements.
3.1.1.2.2 Label
Top line label improves speed of completion (easy to scan), label to the left improves accuracy. Use sentence case.
3.1.1.2.3 Input text or Placeholder text
Use placeholder text for instructions only e.g. Please select… or DD/MM/YYYY. There should be a very clear distinction between the placeholder itself and the value typed by the respondent. If there is not, the respondent might think that the fields with placeholders are already filled fields.
3.1.1.2.4 A note on placeholder text as a label
Never use placeholder text as a substitute for a visible label. It’s a common and tempting shortcut, but it fails users in several ways: the prompt vanishes the moment they start typing, so anyone who forgets what the field was for has to delete their answer to check; placeholder text is typically low-contrast and can fail accessibility requirements; and screen readers don’t reliably announce it as a label. Always pair an input with a persistent, visible label, and reserve placeholders for supplementary instructions or format hints (e.g. DD/MM/YYYY).
3.1.1.2.5 Icons
Icons can be effective labels when they are easy to decipher, either because their meaning is clear or because they are familiar, such as the text formatting icons used on most text editor toolbars. When the meaning is not clear, icons are best paired with descriptive text. The icons should be easy to visually scan and recognize, and the text should provide additional clarity about the purpose of the control. https://www.webstyleguide.com/7-interface-design.html
3.1.1.2.6 Help text
Position the help text between the label and the input field. Don’t use headings, labels or placeholder text for help text.4 Don’t repeat the label or explain the obvious (eg fill in your first name).
3.1.3 Check Boxes
Checkboxes are used when the user can select any number of options from a set — none, one, or many — and each choice is independent of the others. This is the key distinction from radio buttons: if the choices are mutually exclusive, use radio buttons; if they aren’t, use checkboxes.
A single standalone checkbox is also the right control for a binary yes/no agreement, such as accepting terms or opting in to a mailing list. Don’t use a single checkbox for a choice the user genuinely needs to consider in both directions (e.g. “Do you have dietary requirements?”) — a pair of radio buttons or an explicit question is clearer and leaves less room for an accidental default. Best Practices All options should be visible. As with radio buttons, users should be able to scan the full set of choices to make an informed selection, rather than having options hidden in a collapsed control.
Stack them vertically. A vertical list is easiest to scan and makes the association between each box and its label unambiguous.
Make the label clickable. Associate each label with its checkbox (via the for attribute or by wrapping the input) so that clicking the text toggles the box. This enlarges the target — important on touch devices — and is expected behaviour.
Use positive wording. Phrase each option so that ticking it means “yes, this applies.” Avoid negatives like “Don’t send me updates,” where a ticked box means an opt-out — double negatives are a reliable source of user error.
3.1.4 Dropdowns
Dropdowns (select menus) hide their options until opened, which makes them compact but comes at a cost: users can’t scan the choices without interacting, they’re fiddly on touch devices, and long lists are slow to navigate. Reach for a dropdown only when the options are numerous, well-known to the user, and not worth the vertical space of showing them all.
Guidance on when to use something else:
- Few options (roughly seven or fewer): use radio buttons instead. The options stay visible and selection is a single tap or click, rather than open-scan-select.
- Very long, familiar lists (e.g. country, university, department): a text box with autosuggest is usually better. It lets the user type the first few characters and narrow the list, which is far faster than scrolling through hundreds of items.
- Ordered, predictable data (e.g. a date): consider a dedicated control or clearly-structured inputs rather than a set of nested dropdowns.
If you do use a dropdown, order the options meaningfully — alphabetically for lookup, or by frequency if a few choices dominate — and avoid using the first option as a de facto label. Use explicit placeholder text such as “Please select…” as the initial, non-selectable state so an unanswered dropdown is distinguishable from a deliberate choice.
3.1.6 3.1.5 Links
Links inside a form should reflect their state visually — visited, active, focus, and hover — so users always know what’s interactive and where they are.
Be cautious about forcing links to open in a new window or tab. The instinct is a good one: you don’t want a user to click a link — say, to a help page or a terms document — and lose a half-completed form when the page navigates away. But forcing a new window has real costs. It can disorient people using screen readers, who may not notice that the context has changed, and it breaks the browser’s back button, which many users rely on to return to where they were.
So treat this as a tradeoff rather than a rule:
- Prefer solving the underlying problem directly. The real goal is not losing the user’s work. Autosaving form state (or at minimum preserving entered data across navigation) protects the user regardless of how any given link behaves, and lets links work the way people expect. Where you can do this, it’s the better fix.
- If you do open a link in a new window, signal it. Don’t let the new window be a surprise. Indicate it visually — commonly an external-link icon — and make it available to assistive technology, for example with visually-hidden text such as “opens in a new window.” Announcing the behaviour lets users decide whether to follow the link, and prepares screen-reader users for the context change.
- Keep in-form links to a minimum. Every link is an invitation to leave the form. Ask whether the information could instead be shown inline — as help text, an expandable panel, or a tooltip — so the user never has to navigate