Dependent fields vs Select vs Inline validation vs Complete complex form

Prefer dependent fields when a controlling field narrows a dependent field's options, requirement, value, availability, validation, or stale state on the same form record.

Dependent fields live example Select live example Inline validation live example Complete complex form live example

Decision dimensions

Dimension	Dependent fields	Select	Inline validation	Complete complex form
UI or UX	UI + UX - Controlling and dependent form fields	UI + UX - Single-choice dropdown control	UI + UX - Field-level validation feedback	UI + UX - Sectioned enterprise configuration form
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.	Render a persistent label, hint text, native closed value, finite option list, selected option, and validation state.	Render a labeled field with hint text, field-adjacent error text, invalid styling, preserved value, and corrected state.	Render one coherent form surface with a clear title, section navigation or section headings, current section state, grouped controls, persistent labels, helper text, required indicators, error summary, field-level errors, review or summary state, and one save contract.
UX guidance	Use dependent fields to prevent impossible combinations and guide users through valid answer pairs without forcing them to learn backend data rules.	Help users choose one value from a moderate known list without showing every option permanently.	Help users correct a specific field without losing or re-entering the value they already typed.	Use a complete complex form when users must edit many related product settings together and need to inspect dependencies across sections before saving.
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.	Persistent label, hint text, visible selected value, readable options, and clear required validation state.	Error text appears next to the field with readable spacing, persistent label, hint text, and the invalid value still visible.	A policy configuration form has Basics, Rules, Approvals, Notifications, and Review sections; Approvals shows an error because the threshold in Rules requires at least two approvers.
Bad UI	A Subcategory dropdown appears disabled at page load with no explanation of which Category unlocks it.	Placeholder as the only label.	Only a red border with no message.	A single grid shows Nm, Rule, Appr, Esc, Mail, JSON, Mode, and Owner fields with no labels, fieldsets, section status, or error ownership.
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.	Users can open, scan, choose one value, and review the selected value after close.	Validation appears after blur or submit when it helps correction.	A user raises a spend threshold, validates the form, is moved to the Approvals section, adds a second approver and escalation owner, reviews the complete policy, and saves without re-entering earlier values.
Bad UX	A user submits a record with Category Facilities and Subcategory VPN because the stale dependent value was hidden but not cleared.	Hiding two obvious critical choices in a dropdown.	Showing errors before users type.	A user clicks Save, sees three generic errors somewhere in the page, and must scan many controls to discover which section owns each problem.
Best fit	A downstream field's valid values or requirement depend on a previous answer.	The user chooses one option from a moderate known list.	A single field has a specific correctable problem.	A product configuration has many related fields across named sections.
Avoid when	The choices are independent and users need to compare them together.	The option set is short and comparison matters.	The main recovery task is finding several errors across a submitted page.	The form is a short related set of fields that fits a simple single-page form.
Required state	No controlling answer selected, with dependent field unavailable or empty and prerequisite helper text.	Closed state with empty option or current selected value.	Neutral field with label, hint, and no error.	Initial draft state with named sections, required-field convention, grouped controls, and save unavailable or clearly pending validation.
Accessibility burden	Keep controlling and dependent fields in logical DOM order and use labels, hints, and descriptions that name the relationship.	Prefer native semantics or implement equivalent name, role, state, and keyboard behavior.	Expose invalid state on the input and connect error text to the field description where possible.	Use semantic headings, fieldsets, legends, and persistent labels so each section and field group has a programmatic name.
Common misuse	Leaving a stale dependent value selected after the controlling field changes.	Custom select with no keyboard support or hidden selected state.	Showing field errors before users have interacted with the control.	Calling a dense settings table a complex form without section status, labels, or validation ownership.

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.

Select

UI or UX: UI + UX - Single-choice dropdown control
UI guidance: Render a persistent label, hint text, native closed value, finite option list, selected option, and validation state.
UX guidance: Help users choose one value from a moderate known list without showing every option permanently.
Good UI: Persistent label, hint text, visible selected value, readable options, and clear required validation state.
Bad UI: Placeholder as the only label.
Good UX: Users can open, scan, choose one value, and review the selected value after close.
Bad UX: Hiding two obvious critical choices in a dropdown.
Best fit: The user chooses one option from a moderate known list.
Avoid when: The option set is short and comparison matters.
Required state: Closed state with empty option or current selected value.
Accessibility burden: Prefer native semantics or implement equivalent name, role, state, and keyboard behavior.
Common misuse: Custom select with no keyboard support or hidden selected state.

Inline validation

UI or UX: UI + UX - Field-level validation feedback
UI guidance: Render a labeled field with hint text, field-adjacent error text, invalid styling, preserved value, and corrected state.
UX guidance: Help users correct a specific field without losing or re-entering the value they already typed.
Good UI: Error text appears next to the field with readable spacing, persistent label, hint text, and the invalid value still visible.
Bad UI: Only a red border with no message.
Good UX: Validation appears after blur or submit when it helps correction.
Bad UX: Showing errors before users type.
Best fit: A single field has a specific correctable problem.
Avoid when: The main recovery task is finding several errors across a submitted page.
Required state: Neutral field with label, hint, and no error.
Accessibility burden: Expose invalid state on the input and connect error text to the field description where possible.
Common misuse: Showing field errors before users have interacted with the control.

Complete complex form

UI or UX: UI + UX - Sectioned enterprise configuration form
UI guidance: Render one coherent form surface with a clear title, section navigation or section headings, current section state, grouped controls, persistent labels, helper text, required indicators, error summary, field-level errors, review or summary state, and one save contract.
UX guidance: Use a complete complex form when users must edit many related product settings together and need to inspect dependencies across sections before saving.
Good UI: A policy configuration form has Basics, Rules, Approvals, Notifications, and Review sections; Approvals shows an error because the threshold in Rules requires at least two approvers.
Bad UI: A single grid shows Nm, Rule, Appr, Esc, Mail, JSON, Mode, and Owner fields with no labels, fieldsets, section status, or error ownership.
Good UX: A user raises a spend threshold, validates the form, is moved to the Approvals section, adds a second approver and escalation owner, reviews the complete policy, and saves without re-entering earlier values.
Bad UX: A user clicks Save, sees three generic errors somewhere in the page, and must scan many controls to discover which section owns each problem.
Best fit: A product configuration has many related fields across named sections.
Avoid when: The form is a short related set of fields that fits a simple single-page form.
Required state: Initial draft state with named sections, required-field convention, grouped controls, and save unavailable or clearly pending validation.
Accessibility burden: Use semantic headings, fieldsets, legends, and persistent labels so each section and field group has a programmatic name.
Common misuse: Calling a dense settings table a complex form without section status, labels, or validation ownership.

Decision rules

Prefer dependent fields when a controlling field narrows a dependent field's options, requirement, value, availability, validation, or stale state on the same form record.
Prefer select when the user only needs to choose one value from a finite list and no other field changes that list after selection.
Prefer inline validation when one field's own value is wrong and can be corrected locally without recomputing another field's available choices.
Prefer complete complex form when dependency rules span several sections and users need section status, cross-section validation, review, and error-summary navigation.
Dependent fields must show which upstream answer controls the downstream field and must update helper text, options, required status, and error state when that answer changes.
When the controlling answer changes, clear or mark stale any dependent value that is no longer valid; do not silently keep an incompatible downstream answer.
Keep dependent fields in logical reading order after their controlling field, unless the product gives a clear summary of the dependency and recovery path.
Avoid a disabled dependent control with no explanation; if it cannot be used yet, explain the prerequisite and keep it discoverable to keyboard and assistive technology users.
Use conditional reveal when the downstream question should appear only after a related answer, but use dependent fields when the downstream control remains part of the form and its options or validity depend on another value.
Do not model independent choices as dependent just to reduce visible options; users should still be able to compare independent answers when comparison matters.
Server-side validation must enforce the same dependency rules as the UI because stale or incompatible dependent values can arrive through reloads, APIs, or browser manipulation.
If dependency rules are many-to-many, nested, asynchronous, permission-based, or opaque, show loading, unavailable, conflict, and fallback states rather than pretending a simple parent-child select is enough.

Inspect live examples

Dependent fields Select Inline validation Complete complex form

Failure modes

A subcategory remains selected after category changes, so the submitted record contains an impossible pair.
The dependent field is disabled without saying which controlling field must be answered first.
Options update visually but the error text still describes the old controlling answer.
A many-to-many dependency is forced into a one-parent select, hiding valid options.
A dependent field appears before its controlling field in the reading order, so keyboard and screen reader users encounter a blocked field first.
Client-side dependency filtering is bypassed and the backend accepts an incompatible controlled value.

Sources

ServiceNow Docs: Make a field dependent
ServiceNow documents choice and reference fields whose available values depend on another same-table field, including category-to-subcategory behavior and many-to-many caveats.
Salesforce Trailhead: Dependent Picklists
Salesforce documents dependent picklists filtering one picklist based on a controlling value to guide users, save UI space, and improve data integrity.
U.S. Web Design System: Form component
USWDS form guidance anchors disabled-state and validation-accessibility requirements for dependent controls that are unavailable until prerequisites are met.
GOV.UK Design System Radios component
GOV.UK radio guidance provides the boundary for simple conditional reveal, which is different from option filtering and stale dependent-value management.

Verification

Last verified: 2026-06-09