UX Patterns Guide
UI + UX Input And Data Entry established

Dependent fields

Model the relationship explicitly with a controlling field and a dependent field that updates options, availability, requirement, helper text, validation, and stale-value recovery whenever the controlling answer changes.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A downstream field's valid values or requirement depend on a previous answer.
  • Filtering dependent choices prevents invalid combinations and reduces scanning burden.
  • The relationship is understandable enough to explain near the fields.
  • The system can enforce the same dependency rules outside the visible UI.

Avoid when

  • The choices are independent and users need to compare them together.
  • The downstream question should simply be hidden until a related answer is selected.
  • The dependency spans many sections and requires review before save.
  • The product cannot reliably clear, mark stale, or reject invalid dependent values.
  • The dependency rules are opaque, volatile, or permission-based without a clear loading or fallback state.

Problem it prevents

Forms with related fields produce invalid, confusing, or stale data when users can choose downstream values before the upstream answer that defines which values are possible.

Pattern anatomy

What a strong implementation has to make clear

User need

A field's valid values, requirement, label, helper text, or validation depend on another answer in the same form or record.

Pattern promise

Model the relationship explicitly with a controlling field and a dependent field that updates options, availability, requirement, helper text, validation, and stale-value recovery whenever the controlling answer changes.

Required state

No controlling answer selected, with dependent field unavailable or empty and prerequisite helper text.

Recovery path

A stale dependent value is submitted with a new controlling value.

Access contract

Keep controlling and dependent fields in logical DOM order and use labels, hints, and descriptions that name the relationship.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • An incident form asks Category first, then Subcategory shows only options for that category and says why it was cleared after Category changed.
  • A product request form shows Region, then Site; Site is available only after Region is selected and uses helper text instead of a silent disabled select.
  • A user chooses Hardware, selects Laptop, switches Category to Network, sees Laptop cleared, and chooses VPN from the new valid list before submitting.
  • A user tries to submit before choosing Category and the form points to Category first, explaining that Subcategory depends on it.
Weak implementation

Vague, hidden, hard to recover from

  • A Subcategory dropdown appears disabled at page load with no explanation of which Category unlocks it.
  • Changing Category from Network to Facilities leaves VPN selected as Subcategory and the form still shows no error.
  • A user submits a record with Category Facilities and Subcategory VPN because the stale dependent value was hidden but not cleared.
  • A user tabs to a disabled dependent field before the controlling field and hears no reason it cannot be used.
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.
  • When the controlling value changes, update the dependent options, requirement label, helper text, stale-value status, loading state, and validation message together so the downstream field never looks independently valid.
UX guidance
  • Use dependent fields to prevent impossible combinations and guide users through valid answer pairs without forcing them to learn backend data rules.
  • Treat a changed controlling answer as a data integrity event: clear, preserve-as-stale, or require review of any downstream value that no longer matches the new parent.
Implementation contract

What the implementation must handle

States

  • No controlling answer selected, with dependent field unavailable or empty and prerequisite helper text.
  • Controlling answer selected, with dependent options filtered to the valid subset.
  • Dependent answer selected and valid for the current controlling answer.
  • Controlling answer changed, causing previous dependent value to clear or become explicitly stale.

Interaction

  • Users encounter the controlling field before the dependent field in reading and tab order.
  • Changing the controlling field recomputes the dependent options immediately or shows a loading state until they are ready.
  • If the current dependent value is no longer valid, the UI clears it or marks it stale before submit.
  • The dependent field communicates which controlling value currently governs it.

Accessibility

  • Keep controlling and dependent fields in logical DOM order and use labels, hints, and descriptions that name the relationship.
  • If the dependent field is unavailable, explain the prerequisite in text and avoid relying only on a disabled attribute that cannot receive focus.
  • Announce option-list updates, stale clearing, and no-options states through nearby status text or field descriptions where practical.
  • Connect errors to both the controlling and dependent fields when the pair is invalid.

Review

  • Which field controls this dependent field, and can users see that relationship?
  • What happens to a dependent value when the controlling answer changes?
  • Can the backend reject stale or impossible field pairs?
  • Does the dependent field need a no-options, loading, permission, or unavailable state?
Interactive lab

Inspect the states before you copy the pattern

Keep dependent answers valid

Choose a controlling value, select a dependent option, change the controller, and verify stale dependent answers are cleared or repaired.

Dependent 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

No controlling answer selected, with dependent field unavailable or empty and prerequisite helper text.

Keyboard / Access

Tab reaches the controlling field before the dependent field.

Avoid Generating

Leaving a stale dependent value selected after the controlling field changes.
Evidence trail

Source-backed claims behind this guidance

ServiceNow Docs: Make a field dependent

ServiceNow - checked

ServiceNow supports dependent choice and reference fields where the selected controlling value determines available dependent options.

U.S. Web Design System: Form component

U.S. Web Design System - checked

USWDS supports explaining disabled states, aligning validation with inputs, and preserving accessible form order for dependent controls.

GOV.UK Design System Radios component

Government Digital Service - checked

GOV.UK conditional radio guidance anchors the distinction between simple conditional reveal and dependent option/value management.

Full agent/debug reference

Problem Context

  • A field's valid values, requirement, label, helper text, or validation depend on another answer in the same form or record.
  • The downstream field represents a constrained subset such as category/subcategory, country/state, product/model, group/assignee, region/site, or type/detail.
  • Changing the upstream answer can make an existing downstream answer invalid, ambiguous, hidden, or no longer required.
  • The product can enforce the dependency in the data model or server validation, not only in client-side display logic.

Selection Rules

  • Choose dependent fields when one answer controls another field's valid choices, requirement, editability, helper text, or validation.
  • Use an ordinary select when all users see the same finite option set and no upstream answer changes that set.
  • Use conditional reveal fields when the main behavior is showing an extra related question after an answer, not filtering an always-owned downstream field.
  • Use inline validation when the problem is only a single field's own invalid value, not a mismatch between controlling and dependent values.
  • Use complete complex form when dependencies span multiple sections, high-risk rules, review state, or several stale downstream fields.
  • Make the dependency understandable before users interact with the dependent field.
  • Clear the dependent value automatically when the new controlling value makes it invalid, or mark it stale and require an explicit review choice.
  • Do not silently keep, hide, or submit a dependent answer that no longer belongs to the controlling answer.
  • Avoid true disabled controls unless the prerequisite is stated and the control remains discoverable; consider enabled validation or aria-disabled behavior when users need feedback.
  • Keep dependency rules in backend validation, import, API, and saved-draft recovery paths so stale pairs cannot bypass the UI.

Required States

  • No controlling answer selected, with dependent field unavailable or empty and prerequisite helper text.
  • Controlling answer selected, with dependent options filtered to the valid subset.
  • Dependent answer selected and valid for the current controlling answer.
  • Controlling answer changed, causing previous dependent value to clear or become explicitly stale.
  • Dependent options loading after an async controlling change.
  • No valid dependent options for the selected controlling value.
  • Required dependency error when the controlling field or dependent field is missing.
  • Invalid pair error when a stale dependent value no longer matches the controlling field.
  • Submitted valid state that includes both controlling and dependent answers.
  • Server-rejected state when persisted data violates the dependency rule.

Interaction Contract

  • Users encounter the controlling field before the dependent field in reading and tab order.
  • Changing the controlling field recomputes the dependent options immediately or shows a loading state until they are ready.
  • If the current dependent value is no longer valid, the UI clears it or marks it stale before submit.
  • The dependent field communicates which controlling value currently governs it.
  • Submitting without a valid pair points first to the controlling field when the dependency cannot be evaluated.
  • Errors name both fields when the pair is incompatible.
  • Reloading a saved draft revalidates the pair against current dependency rules.

Implementation Checklist

  • Define the controlling field, dependent field, valid value matrix, requirement rules, defaults, empty states, and no-options states before building the UI.
  • Keep the controlling and dependent values as separate model fields; do not infer one from a display label that can drift.
  • Clear, mark stale, or require confirmation when a controlling change invalidates the dependent value.
  • Update helper text, required labels, option list, aria descriptions, and validation messages in the same state transition.
  • Add loading and retry behavior if dependent options are fetched asynchronously.
  • Validate the dependency on submit, save, import, API write, and draft resume.
  • Test keyboard order, screen reader descriptions, no-option states, stale clearing, browser Back, saved drafts, API-submitted stale values, and mobile reflow.

Common Generated-UI Mistakes

  • Leaving a stale dependent value selected after the controlling field changes.
  • Disabling the dependent field with no explanation of the prerequisite.
  • Putting the dependent field before its controller in DOM or tab order.
  • Using dependent fields to hide independent options that users need to compare.
  • Only filtering options client-side while the backend accepts invalid pairs.
  • Clearing a user's downstream answer without any status message after a parent change.
  • Treating many-to-many or permission-based dependencies as a simple one-parent dropdown without fallback.

Critique Questions

  • Which field controls this dependent field, and can users see that relationship?
  • What happens to a dependent value when the controlling answer changes?
  • Can the backend reject stale or impossible field pairs?
  • Does the dependent field need a no-options, loading, permission, or unavailable state?
  • Would a simple conditional reveal, ordinary select, or section-level complex form be clearer?
  • Are disabled states explained to keyboard and screen reader users?
Accessibility
  • Keep controlling and dependent fields in logical DOM order and use labels, hints, and descriptions that name the relationship.
  • If the dependent field is unavailable, explain the prerequisite in text and avoid relying only on a disabled attribute that cannot receive focus.
  • Announce option-list updates, stale clearing, and no-options states through nearby status text or field descriptions where practical.
  • Connect errors to both the controlling and dependent fields when the pair is invalid.
  • Do not communicate dependency solely with indentation, color, icons, or disappearing options.
  • Ensure loading, retry, and no-options states are keyboard reachable and do not trap focus.
Keyboard Behavior
  • Tab reaches the controlling field before the dependent field.
  • Changing the controlling select updates the dependent field without moving focus unexpectedly.
  • If the dependent value is cleared, focus stays stable and a status message explains the change.
  • Users can reach prerequisite help and dependent-field errors by keyboard.
  • Submit with an invalid pair moves focus to an error summary or the first field needed to repair the dependency.
  • Async loading does not trap focus inside a disabled dependent control.
Variants
  • Category and subcategory fields
  • Country and state fields
  • Product type and model fields
  • Assignment group and assignee fields
  • Region and site fields
  • Checkbox-controlled dependent picklist
  • Async dependent options
  • Dependent required field
  • Stale dependent value warning
  • No dependent options available

Verification

Last verified: