UX Patterns Guide
Back to compare picker

Conditional reveal fields vs Dependent fields vs Radio group vs Single-question page

Prefer conditional reveal fields when a radio, checkbox, or select answer needs one directly related follow-up field that belongs under that answer.

Conditional reveal fields live exampleDependent fields live exampleRadio group live exampleSingle-question page live example

Decision dimensions

Dimension Conditional reveal fieldsDependent fieldsRadio groupSingle-question page
UI or UX UI + UX - Trigger-owned follow-up form fieldUI + UX - Controlling and dependent form fieldsUI + UX - Single-choice form controlUI + 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.Use dependent fields to prevent impossible combinations and guide users through valid answer pairs without forcing them to learn backend data rules.Help users compare the available options and choose exactly one without opening an extra control.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 page heading asks Do you have evidence to upload?, explanatory text sits above a yes/no radio group, Continue follows the answer, and Back returns to the previous service step.
Bad UI A hidden required email field blocks submit after Email was unchecked, but no visible field explains the error.A Subcategory dropdown appears disabled at page load with no explanation of which Category unlocks it.Custom circles that do not show focus or selected state clearly.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 A user changes from Email to No contact and the hidden email address still gets sent.A user submits a record with Category Facilities and Subcategory VPN because the stale dependent value was hidden but not cleared.Using radios for choices where multiple selections are allowed.A user answers three unrelated questions on one screen and submits, but the error only says fix details without naming the question.
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.One answer or decision should be read and completed without competing form questions.
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 Initial state with trigger options visible and no conditional field shown.No controlling answer selected, with dependent field unavailable or empty and prerequisite helper text.No selection state for required unanswered groups.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.

Conditional reveal fields

UI or UX
UI + UX - Trigger-owned follow-up form field
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.
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.
Good UI
A Contact me by email checkbox reveals an Email address field immediately below that checkbox and hides it when Email is unchecked.
Bad UI
A hidden required email field blocks submit after Email was unchecked, but no visible field explains the error.
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.
Bad UX
A user changes from Email to No contact and the hidden email address still gets sent.
Best fit
A selected radio, checkbox, or select option needs one short related follow-up field.
Avoid when
The revealed content is a complete form, separate workflow, or separate submit action.
Required state
Initial state with trigger options visible and no conditional field shown.
Accessibility burden
Keep the revealed field immediately after the triggering control in DOM order so keyboard and screen reader users encounter it naturally.
Common misuse
Hiding a required field and still validating it after its trigger is unselected.

Dependent fields

UI or UX
UI + UX - Controlling and dependent form fields
UI guidance
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.
UX guidance
Use dependent fields to prevent impossible combinations and guide users through valid answer pairs without forcing them to learn backend data rules.
Good UI
An incident form asks Category first, then Subcategory shows only options for that category and says why it was cleared after Category changed.
Bad UI
A Subcategory dropdown appears disabled at page load with no explanation of which Category unlocks it.
Good UX
A user chooses Hardware, selects Laptop, switches Category to Network, sees Laptop cleared, and chooses VPN from the new valid list before submitting.
Bad UX
A user submits a record with Category Facilities and Subcategory VPN because the stale dependent value was hidden but not cleared.
Best fit
A downstream field's valid values or requirement depend on a previous answer.
Avoid when
The choices are independent and users need to compare them together.
Required state
No controlling answer selected, with dependent field unavailable or empty and prerequisite helper text.
Accessibility burden
Keep controlling and dependent fields in logical DOM order and use labels, hints, and descriptions that name the relationship.
Common misuse
Leaving a stale dependent value selected after the controlling field changes.

Radio group

UI or UX
UI + UX - Single-choice form control
UI guidance
Render a fieldset/legend with visible native radio options, selected state, focus state, optional hints, and group-level validation.
UX guidance
Help users compare the available options and choose exactly one without opening an extra control.
Good UI
Visible native radio options with a clear legend, selected state, focus state, and helper text.
Bad UI
Custom circles that do not show focus or selected state clearly.
Good UX
Exactly one option is selected at a time and labels are clickable.
Bad UX
Using radios for choices where multiple selections are allowed.
Best fit
Users must choose exactly one option.
Avoid when
Users can choose multiple options.
Required state
No selection state for required unanswered groups.
Accessibility burden
Use a programmatic group label through fieldset/legend or an accessible radiogroup name.
Common misuse
Using radios for independent choices where several answers can be true.

Single-question page

UI or UX
UI + UX - Focused form page for one answer or decision
UI guidance
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 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 page heading asks Do you have evidence to upload?, explanatory text sits above a yes/no radio group, Continue follows the answer, and Back returns to the previous service step.
Bad UI
One page asks for name, address, evidence status, and payment method under a vague Details heading.
Good UX
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
A user answers three unrelated questions on one screen and submits, but the error only says fix details without naming the question.
Best fit
One answer or decision should be read and completed without competing form questions.
Avoid when
Users need to compare or edit several fields together before submitting.
Required state
Initial unanswered state with question heading, optional explanation, answer control, Back link, and Continue action.
Accessibility burden
Use a single visible h1 that states the question users are answering.
Common misuse
Putting several unrelated questions on one page and still calling it one thing per page.
Decision rules
  • Prefer conditional reveal fields when a radio, checkbox, or select answer needs one directly related follow-up field that belongs under that answer.
  • Prefer dependent fields when the later control is always part of the form and its valid options, requirement, value, or stale state depend on a controlling value.
  • Prefer radio group when users only need to choose one answer and no follow-up field needs to appear under a specific option.
  • Prefer single-question page when the follow-up question needs focused reading, branching, page-level validation, or enough content that same-page reveal would overload the first question.
  • Revealed content must sit directly under the triggering option so users can understand why it appeared and which answer owns it.
  • Limit revealed content to related questions or support information; do not reveal a complete form, a separate submit action, unrelated marketing content, or a different task.
  • When the triggering option is deselected, hide the revealed field and either clear its value or mark it excluded from submission so hidden stale answers cannot block or leak.
  • If a revealed field is required, require it only while its trigger is selected and show the error on the revealed field, not as a mysterious error on the parent group alone.
  • Do not hide a required field behind conditional logic without showing the trigger state and recovery path in an error summary after submit.
  • Make reveal and hide changes perceivable to assistive technology users through DOM placement, descriptions, status text, or tested component behavior rather than relying on visual appearance alone.
  • Use progressive disclosure or details text for optional explanatory content; use conditional reveal only when the revealed control is part of the answer flow.
  • For multiple or nested conditional reveals, consider splitting the flow into pages or a multi-step form so users do not lose track of which answers are currently required.
Inspect live examples
Conditional reveal fieldsDependent fieldsRadio groupSingle-question page
Failure modes
  • A hidden required field blocks submit with no visible clue until users guess which answer reveals it.
  • A revealed email field remains submitted after the Email checkbox is unchecked.
  • A follow-up field appears far from the option that triggered it, so users do not know why it is required.
  • A complete subform with its own submit action is revealed inside a radio group.
  • Screen reader users are not informed that selecting an option introduced a new follow-up question.
  • Nested conditional fields hide stale values that continue to affect validation or eligibility.