Selection & Input
The Selection & Input page demonstrates form fields and controls for user input. Our priority was reducing user effort and errors. We designed all forms in a single-column vertical layout, since multi-column forms can confuse users about field order. Each input has a clear label and, if needed, placeholder or helper text indicating the required format.
Insights
Finally, our selection and input components (forms, fields, controls) were designed for intuitive, inclusive data entry. I made sure every input element follows best practices so users can interact without confusion. We require visible labels outside every field – typically placed above the control – so users always know what to input. (In forms, floating labels or inline placeholders that disappear can cause accessibility issues, so our labels remain persistently visible.)
For text fields, we follow Material’s guidance:
We also provide optional hint text or helper text below fields for examples or validation messages. Every input’s state is clearly indicated, an active text field gets a highlight (using our primary color), and an errored field turns its underline and label red, with an error message next to it. As WCAG recommends, we ensure these error messages are announced and placed predictably – on desktop, for instance, we place errors to the right of the field (so users with screen readers find them in logical order), and on mobile they appear below the field to fit narrow layouts.
We similarly designed other controls, checkboxes, radio buttons, and toggles have large hit areas and clear on/off labels. Grouped controls (like a set of related checkboxes) are enclosed in fieldsets with legend text, making the purpose obvious to all users. Overall, these decisions make our forms easy to scan and fill: users never have to guess what an input means or how to correct an error
Best Practices
Keyboard-Friendly Layouts:
One question per line, left-aligned labels, and logical tab order. For checkboxes/radios, clicking the label text should toggle the input.
Inline Validation:
When possible, validate fields as the user types and show success or error messages in real time. Avoid generic “submit and see errors” flows.
Clear Error Messages:
Show clear error messages next to the field (right of the input on desktop, below on mobile) in plain language and in contrast-colored text, as advised by accessibility experts.
Descriptive Error Hint:
Always include a descriptive error hint or required-field marker. Screen readers should announce errors.
Touch Targets:
Ensure touch targets meet minimum size (at least 44×44 points) and sufficient spacing so users on mobile can tap inputs comfortably.
Test Forms With Assistive Tools:
Check that each input has an accessible name and that the focus order matches the visual order, fulfilling the WCAG Consistent Navigation (3.2.3) and Predictable (3.2.4) criteria.