UX Patterns Guide
My learning 0 of 20 lessons complete
Start lesson 1 →

Application · lesson 25 of 34 · Input And Data Entry

Dependent fields

Underlying principle: An input pattern carries a question, an expected answer, and a consequence. Visible labels, suitable controls, tolerant entry, and specific recovery keep that agreement clear.

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.

Start with the decision

Does this fit your task?

A downstream field's valid values or requirement depend on a previous answer.

Review the boundary: Compare the task with the alternatives in the decision section.

Review the decision →
Try the live example →Compare alternatives →
Study the interaction

Follow the task before choosing the component

An input pattern carries a question, an expected answer, and a consequence. Visible labels, suitable controls, tolerant entry, and specific recovery keep that agreement clear.

01 / Recognize the need

What the person is doing

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

02 / Design the response

What the interface must communicate

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.

Controlling answer selected, with dependent options filtered to the valid subset.

03 / Judge the outcome

What to look for

Which field controls this dependent field, and can users see that relationship?

Users encounter the controlling field before the dependent field in reading and tab order.

Practice this pattern: Sketch dependent fields for this situation: A downstream field's valid values or requirement depend on a previous answer. Include this state: Controlling answer selected, with dependent options filtered to the valid subset. Review your sketch with this question: Which field controls this dependent field, and can users see that relationship?

Study the Input And Data Entry family →Read the underlying principle →
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.

Problem it prevents

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

Test the behavior

Open the interactive example when you need it

The full lab is intentionally loaded on request. That keeps this reading page fast while preserving the strong and weak states, keyboard checks, and failure scenarios.

In the lab you can
  • switch between strong UI, weak UI, strong UX, and weak UX;
  • trigger required, empty, loading, error, and recovery states;
  • inspect keyboard and accessibility expectations beside the demo.
Launch Dependent fields in the lab
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

Controlling answer selected, with dependent options filtered to the valid subset.

Failure to inspect

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 stale dependent value is submitted with a new controlling value.
  • The dependent field looks optional even though it becomes required after the controlling answer.
  • The option list updates but the selected value, helper text, or error message still belongs to the old parent.
  • The UI clears a dependent answer silently, making users think data was lost.
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

  • 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.

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.
  • The dependent field communicates which controlling value currently governs it.
  • Errors name both fields when the pair is incompatible.

Accessibility

  • Keep controlling and dependent fields in logical DOM order and use labels, hints, and descriptions that name the relationship.
  • Connect errors to both the controlling and dependent fields when the pair is invalid.
  • Tab reaches the controlling field before the dependent field.
  • If the dependent value is cleared, focus stays stable and a status message explains the change.

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?
  • Would a simple conditional reveal, ordinary select, or section-level complex form be clearer?
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

Source trail checked:

Saved items