Use dependent fields when one completed controlling answer determines which later field values are valid, available, required, cleared, or stale.
Use dependent fields when one completed controlling answer determines which later field values are valid, available, required, cleared, or stale.
Practice the judgment: Imagine this situation: A subcategory remains selected after category changes, so the submitted record contains an impossible pair. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| 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 | Help the person reach a clear task outcome. | Help the person reach a clear task outcome. | Help the person reach a clear task outcome. | 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 stale dependent value is submitted with a new controlling value. | Placeholder as the only label. | Error message appears far from the field it describes. | A long settings page saves invalid combinations because validation checks each field in isolation and ignores dependencies between threshold, approvers, and escalation owner. |
| 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 jumps from Review back to Rules, changes a dependency, and sees Review marked stale until the affected sections pass validation again. |
| Bad UX | A stale dependent value is submitted with a new controlling value. | 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 | Controlling answer selected, with dependent options filtered to the valid subset. | Closed state with empty option or current selected value. | Invalid field with preserved user value and adjacent correction text. | 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. | Using select to hide two or three obvious choices that should be compared. | Showing field errors before users have interacted with the control. | Splitting tightly related settings across pages so dependencies are invisible during editing. |