Required field hidden by conditional logic

Problem Context

• A form has radio, checkbox, select, eligibility, account type, permission, or saved-draft answers that control which later answers are required.
• The required field may be visually hidden, collapsed, disabled, moved to another page, filtered out, or missing from the current route.
• Validation may run on the client, server, saved draft, review step, imported payload, or resumed session.
• Users need recovery after submit, browser Back, review edits, mobile accordions, assistive technology changes, and stale conditional answers.

Selection Rules

• Flag this anti-pattern when a required field can block submit while it is hidden, collapsed, disabled, off-screen, absent from the current route, or disconnected from its trigger.
• Use conditional reveal fields when one selected answer owns a short visible follow-up field directly under the trigger and required only while selected.
• Use dependent fields when an always-owned downstream control changes options, requirement, or validity based on an upstream answer.
• Use error summary when submit-time validation needs a top-of-page list of visible, linked errors with matching field messages.
• Use single-page form when a short set of related fields can remain visible together with clear required indicators and one submit action.
• Use review before submit when changed answers can create newly required branches that must be resolved before final commitment.
• Use a separate question page, multi-step form, or wizard when the conditional branch has multiple required fields, long reading, or enough complexity that same-page hiding becomes hard to recover from.
• Do not mark hidden fields required unless the trigger that makes them required is visible, selected, and recoverable from validation errors.
• When hiding a branch, clear or exclude its values and errors unless draft restoration is explicitly tied to reselecting the same trigger.
• When server validation finds a conditional required error, restore or route to the owning trigger and field before asking users to fix it.

Required States

• Initial state with all currently required fields identified before users submit.
• Trigger selected state where the newly required follow-up is revealed adjacent to the trigger.
• Trigger cleared state where hidden follow-up values and errors are cleared or excluded.
• Failed submit state where the error summary links to a visible field, not a hidden target.
• Server validation state where backend-required conditional fields are restored or routed to before recovery.
• Saved draft return state where trigger and required branch are synchronized.
• Browser Back or review edit state where changed upstream answers recompute required downstream questions.
• Nested branch state where the UI escalates to a page or step instead of hiding several required fields.
• Assistive notification state where newly revealed required fields are discoverable to keyboard and screen reader users.
• Mobile collapsed state where a required field is not trapped inside a closed panel with no error route.
• Bad hidden blocker state where submit fails but the required field remains invisible.
• Bad stale trigger state where old saved values keep a hidden branch required.
• Bad disabled-required state where a disabled or unavailable control is still required.
• Bad error-summary dead link state where the error target is hidden or missing.
• Bad server-only required state where the UI never exposed the field that the backend requires.

Interaction Contract

• Selecting a trigger that creates a required follow-up reveals that follow-up immediately in logical DOM and visual order.
• Changing or clearing the trigger removes hidden required state, hidden errors, and hidden payload values unless reselecting the trigger intentionally restores a draft.
• Submit-time errors only point to fields that are visible or are made visible before focus moves.
• Error summary links restore collapsed branches, select or preserve the owning trigger, and move focus to the field or group that can be fixed.
• Server-side validation returns enough branch context for the client to reveal or route to the owning conditional field.
• Review changes that create new required branches send users through those questions before final submit.
• Assistive technology users are informed when a selected answer reveals a new required field.

Implementation Checklist

• Create a requirement map that ties every conditional required field to its owning trigger, active condition, visibility state, payload key, and error target.
• Keep client validation, server validation, saved draft restoration, and review pages using the same condition rules.
• Reveal short required follow-ups beside the trigger; route larger branches to pages or steps with their own required indicators.
• Before submit, validate only fields whose triggers make them active and visible or routeable.
• When hiding a branch, clear or mark inactive its values, errors, dirty state, and review rows.
• When an error is produced for a hidden field, first restore the branch or route to the owning question, then focus the summary or field.
• Test with browser Back, saved drafts, server errors, review edits, mobile collapsed sections, screen readers, keyboard-only navigation, and stale branch values.
• Log or assert when validation references a hidden or missing DOM target so hidden blockers are caught before release.

Common Generated-UI Mistakes

• Keeping a visually hidden input required because the backend schema says the field is required in some cases.
• Showing an error summary that links to an element hidden by CSS, collapsed accordion state, or conditional route logic.
• Using disabled required controls to represent unavailable answers.
• Clearing the trigger visually but leaving the old branch active in saved draft or server payload.
• Only marking required fields after failed submit, forcing users to discover branch rules by trial and error.
• Putting a required conditional field at the bottom of the form far away from its trigger.
• Nesting several required conditional fields inside one local reveal instead of splitting the flow.
• Relying on visual reveal animation without making new required fields discoverable to assistive technology.

Critique Questions

• Which trigger makes this field required, and is that trigger visible when the error appears?
• Can a hidden, disabled, collapsed, or off-route field ever block submit?
• What happens to values and errors when the trigger changes?
• Does the error summary link to a visible recoverable field?
• Does server validation return enough branch context to reveal or route to the missing answer?
• Can review edits or browser Back create newly required questions before final submit?
• Would this branch be clearer as a separate page, step, or review-gated question?