Use conditional reveal fields when a selected answer should reveal one directly related follow-up field or short supporting question in the same local context.
Use conditional reveal fields when a selected answer should reveal one directly related follow-up field or short supporting question in the same local context.
Practice the judgment: Imagine this situation: A revealed email field remains submitted after the Email checkbox is unchecked. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Conditional reveal fields | Dependent fields | Radio group | Single-question page |
|---|---|---|---|---|
| UI or UX | UI + UX - Trigger-owned follow-up form field | UI + UX - Controlling and dependent form fields | UI + UX - Single-choice form control | UI + UX - Focused form page for one answer or decision |
| UI guidance | Place the revealed field directly under the radio, checkbox, or select option that triggers it, visually nested enough to show ownership while keeping the label and error text fully visible. | Place the controlling field before the dependent field, label both clearly, and explain the dependency in helper text such as Choose a category first to see valid subcategories. | Render a fieldset/legend with visible native radio options, selected state, focus state, optional hints, and group-level validation. | Render one clear question as the page heading, optional explanatory text before the answer, one answer area, a primary Continue action, and a Back link or equivalent return path. |
| UX guidance | Use conditional reveal fields when a short follow-up answer is only relevant for users who choose a specific option and should remain in the same decision context. | Help the person reach a clear task outcome. | Help the person reach a clear task outcome. | Use a single-question page when users need to focus on one decision, understand one piece of information, or answer one conceptual question before moving on. |
| Good UI | A Contact me by email checkbox reveals an Email address field immediately below that checkbox and hides it when Email is unchecked. | An incident form asks Category first, then Subcategory shows only options for that category and says why it was cleared after Category changed. | Visible native radio options with a clear legend, selected state, focus state, and helper text. | A date question uses three related fields on the same page because day, month, and year answer one question. |
| Bad UI | Selecting Other reveals a long nested form with its own Save button and unrelated questions. | A stale dependent value is submitted with a new controlling value. | Allowing several options in the group to appear active at once. | One page asks for name, address, evidence status, and payment method under a vague Details heading. |
| Good UX | A user selects Phone, sees the Phone number field appear under Phone, enters the number, then unchecks Phone and sees the number excluded from submission. | A user chooses Hardware, selects Laptop, switches Category to Network, sees Laptop cleared, and chooses VPN from the new valid list before submitting. | Exactly one option is selected at a time and labels are clickable. | A user chooses Yes, sees a follow-up detail field on the same question page, goes Back, returns, and the answer is still selected. |
| Bad UX | Hidden required fields block submission. | A stale dependent value is submitted with a new controlling value. | Using radios for choices where multiple selections are allowed. | A user goes Back to check the previous step and the question page clears the answer they already gave. |
| Best fit | A selected radio, checkbox, or select option needs one short related follow-up field. | A downstream field's valid values or requirement depend on a previous answer. | Users must choose exactly one option. | A sequential service flow needs reliable answers before deciding the next page. |
| Avoid when | The revealed content is a complete form, separate workflow, or separate submit action. | The choices are independent and users need to compare them together. | Users can choose multiple options. | Users need to compare or edit several fields together before submitting. |
| Required state | Trigger selected state with the related follow-up field revealed directly under the trigger. | Controlling answer selected, with dependent options filtered to the valid subset. | Exactly one selected option state. | Initial unanswered state with question heading, optional explanation, answer control, Back link, and Continue action. |
| Accessibility burden | Keep the revealed field immediately after the triggering control in DOM order so keyboard and screen reader users encounter it naturally. | Keep controlling and dependent fields in logical DOM order and use labels, hints, and descriptions that name the relationship. | Use a programmatic group label through fieldset/legend or an accessible radiogroup name. | Use a single visible h1 that states the question users are answering. |
| Common misuse | Hiding a required field and still validating it after its trigger is unselected. | Leaving a stale dependent value selected after the controlling field changes. | Using radios for independent choices where several answers can be true. | Putting several unrelated questions on one page and still calling it one thing per page. |