UX Patterns Guide
UI + UX Input And Data Entry established

Conditional reveal fields

Reveal only the short related follow-up field owned by the selected answer, place it under the trigger, announce or describe the change, validate it only while relevant, and clear or exclude values when it becomes hidden.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A selected radio, checkbox, or select option needs one short related follow-up field.
  • The follow-up belongs to the same local question context.
  • Showing every possible follow-up field would add noise for most users.
  • The implementation can safely hide, clear, and validate the field based on trigger state.

Avoid when

  • The revealed content is a complete form, separate workflow, or separate submit action.
  • The follow-up has several questions, branching, or enough complexity to need a page of its own.
  • The later field should remain visible but have filtered options based on a controlling value.
  • The field contains sensitive or important data that should not disappear without warning.
  • The product cannot reliably exclude hidden values from validation, submission, search indexing, or saved drafts.

Problem it prevents

Forms become noisy or misleading when all follow-up fields are always shown, but they become fragile when hidden fields are required, submitted, or revealed without a clear relationship to the triggering answer.

Pattern anatomy

What a strong implementation has to make clear

User need

A radio, checkbox, or select answer determines whether one short follow-up field or piece of supporting information is relevant.

Pattern promise

Reveal only the short related follow-up field owned by the selected answer, place it under the trigger, announce or describe the change, validate it only while relevant, and clear or exclude values when it becomes hidden.

Required state

Initial state with trigger options visible and no conditional field shown.

Recovery path

Hidden required fields block submission.

Access contract

Keep the revealed field immediately after the triggering control in DOM order so keyboard and screen reader users encounter it naturally.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A Contact me by email checkbox reveals an Email address field immediately below that checkbox and hides it when Email is unchecked.
  • A Yes radio for Do you have a reference number? reveals one Reference number field directly under Yes, with the error shown on that revealed field.
  • 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 submits after choosing Email but leaving Email address blank and gets a clear error on the revealed field while the Email option remains selected.
Weak implementation

Vague, hidden, hard to recover from

  • A hidden required email field blocks submit after Email was unchecked, but no visible field explains the error.
  • Selecting Other reveals a long nested form with its own Save button and unrelated questions.
  • A user changes from Email to No contact and the hidden email address still gets sent.
  • A screen reader user chooses an option and is not told that a new follow-up question appeared.
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.
  • Show only directly related follow-up questions or support text; avoid revealing unrelated content, complete subforms, independent submit actions, or a hidden journey inside one option.
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.
  • Treat reveal and hide as data-state changes: when the trigger is removed, clear or exclude hidden values and validate the revealed field only while it is relevant.
Implementation contract

What the implementation must handle

States

  • Initial state with trigger options visible and no conditional field shown.
  • Trigger selected state with the related follow-up field revealed directly under the trigger.
  • Revealed field completed state with value included in submission.
  • Trigger changed or deselected state where the revealed field hides and its value is cleared or excluded.

Interaction

  • Selecting the trigger shows the related field immediately under that trigger.
  • Deselecting the trigger hides the related field and removes or marks its value out of scope.
  • The revealed field does not steal focus unless the product deliberately moves focus for a validated error or guided step.
  • Validation checks revealed required fields only while their trigger is selected.

Accessibility

  • Keep the revealed field immediately after the triggering control in DOM order so keyboard and screen reader users encounter it naturally.
  • Use clear labels and descriptions that identify the revealed field as related to the selected trigger.
  • Test whether assistive technology users are informed when content appears; add status text or guidance where the component does not reliably announce changes.
  • Do not rely on indentation, color, animation, or visual proximity alone to communicate the relationship.

Review

  • Is the revealed field directly related to the selected answer?
  • What happens to the revealed value when the trigger is unselected?
  • Is the field required only while visible and relevant?
  • Can keyboard and screen reader users discover the newly revealed field?
Interactive lab

Inspect the states before you copy the pattern

Reveal related follow-up fields

Choose answers that reveal and hide follow-up fields, validate a required revealed value, and verify hidden stale values are cleared.

Conditional reveal fields
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Initial state with trigger options visible and no conditional field shown.

Keyboard / Access

Tab reaches the trigger option, then the revealed field when the trigger is selected.

Avoid Generating

Hiding a required field and still validating it after its trigger is unselected.
Evidence trail

Source-backed claims behind this guidance

GOV.UK Design System Checkboxes component

Government Digital Service - checked

GOV.UK checkbox guidance supports conditional content revealed when a checkbox is checked, including related contact detail fields.

Full agent/debug reference

Problem Context

  • A radio, checkbox, or select answer determines whether one short follow-up field or piece of supporting information is relevant.
  • The revealed content belongs to the same question or answer choice rather than a separate task, page, or section.
  • The product can remove hidden values from validation and submission when the trigger is no longer selected.
  • The implementation can be tested with keyboard and assistive technology so newly revealed fields are discoverable.

Selection Rules

  • Choose conditional reveal fields when one option needs a short, directly related follow-up field in the same local context.
  • Use dependent fields instead when the later field remains part of the form and its option set or validity changes based on a controlling value.
  • Use a plain radio group or checkbox group when no answer needs a follow-up field.
  • Use single-question page or multi-step form when the follow-up has multiple questions, branching, submit behavior, or enough reading burden to need its own page.
  • Use details or progressive disclosure for optional explanation text that is not part of the answer data.
  • Place revealed content immediately after the triggering input, not at the bottom of the form or in a disconnected panel.
  • Require revealed fields only while their trigger is selected.
  • Clear or omit hidden field values when the trigger becomes unselected, unless the user is explicitly returning to the same selected option and draft restoration is intended.
  • Show validation errors on the revealed field and preserve the selected trigger so users can see and fix the missing follow-up.
  • Avoid nested reveals unless the branch remains short and easy to understand; otherwise split the flow.

Required States

  • Initial state with trigger options visible and no conditional field shown.
  • Trigger selected state with the related follow-up field revealed directly under the trigger.
  • Revealed field completed state with value included in submission.
  • Trigger changed or deselected state where the revealed field hides and its value is cleared or excluded.
  • Revealed field required error state while the trigger remains selected.
  • Hidden field not required state after the trigger is cleared.
  • Multiple checkbox reveal state where more than one selected option can own its own follow-up field.
  • Assistive notification or descriptive state that makes the newly revealed field discoverable.
  • Error summary state linking to the revealed field when submission fails.
  • Oversized branch state where the UI points users to a separate page or flow instead of revealing too much content.

Interaction Contract

  • Selecting the trigger shows the related field immediately under that trigger.
  • Deselecting the trigger hides the related field and removes or marks its value out of scope.
  • The revealed field does not steal focus unless the product deliberately moves focus for a validated error or guided step.
  • Validation checks revealed required fields only while their trigger is selected.
  • Errors on a revealed field identify the revealed field and keep the trigger visible.
  • Keyboard users can tab from the trigger into the revealed field in logical order.
  • Submission payload excludes hidden stale values unless the user reselects the trigger and intentionally keeps the draft.

Implementation Checklist

  • Map each trigger option to exactly which field or short content block it reveals.
  • Keep revealed content adjacent to the triggering input in DOM and visual order.
  • Use stable IDs and descriptions so the trigger and revealed field relationship can be understood by assistive technology.
  • Clear, exclude, or explicitly mark hidden values as inactive when their trigger is deselected.
  • Apply required validation conditionally based on the trigger state.
  • Ensure error summary links target the revealed field and that the trigger remains selected when errors are shown.
  • Test with keyboard, screen reader, browser Back, form reload, saved draft, error summary, mobile layout, multiple selected checkboxes, and deselection.
  • Escalate to a separate page, wizard, or multi-step flow when the revealed branch contains several questions or a separate submit action.

Common Generated-UI Mistakes

  • Hiding a required field and still validating it after its trigger is unselected.
  • Submitting hidden stale values because the field was visually hidden but still active in the model.
  • Revealing a complete form or separate task under a single option.
  • Placing the revealed field far away from the answer that triggered it.
  • Using conditional reveal to hide independent choices users should compare.
  • Nesting several levels of reveals until users cannot tell what is required.
  • Relying only on visual appearance so assistive technology users miss the newly revealed question.

Critique Questions

  • Is the revealed field directly related to the selected answer?
  • What happens to the revealed value when the trigger is unselected?
  • Is the field required only while visible and relevant?
  • Can keyboard and screen reader users discover the newly revealed field?
  • Would this branch be clearer as its own question page or step?
  • Does the error summary link to the revealed field while keeping the trigger selected?
Accessibility
  • Keep the revealed field immediately after the triggering control in DOM order so keyboard and screen reader users encounter it naturally.
  • Use clear labels and descriptions that identify the revealed field as related to the selected trigger.
  • Test whether assistive technology users are informed when content appears; add status text or guidance where the component does not reliably announce changes.
  • Do not rely on indentation, color, animation, or visual proximity alone to communicate the relationship.
  • Connect revealed-field errors to the revealed field and keep the triggering option selected during recovery.
  • Avoid disabled hidden controls that cannot receive focus but still block validation.
  • Ensure hiding a field does not trap focus or move focus unexpectedly.
Keyboard Behavior
  • Tab reaches the trigger option, then the revealed field when the trigger is selected.
  • Space or Enter on the trigger toggles reveal state without moving focus unexpectedly.
  • If the revealed field is hidden while focused, focus returns to the trigger or next logical control.
  • Submit with a missing revealed value moves focus to the error summary or revealed field, with the trigger still selected.
  • Deselecting a checkbox-triggered reveal removes its field from the tab order.
  • Multiple reveals preserve a predictable order matching the selected options.
Variants
  • Radio conditional reveal
  • Checkbox conditional reveal
  • Select-triggered reveal
  • Other please specify field
  • Contact method follow-up field
  • Yes reveal detail field
  • Multiple checkbox follow-up fields
  • Conditional reveal with error
  • Conditional reveal with cleared hidden value
  • Conditional reveal escalated to page

Verification

Last verified: