UX Patterns Guide
UI + UX Input And Data Entry anti-pattern

Required field hidden by conditional logic

Keep conditional requirement state synchronized with the visible branch: reveal required follow-ups beside their triggers, clear or exclude hidden answers when triggers change, restore hidden branches before linking errors, and use review or separate pages when branching is too large for same-page reveal.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Use this anti-pattern entry to audit forms where conditional logic, validation, saved drafts, or server schemas might require fields that are not visible or reachable.
  • Use it during design and QA reviews of eligibility, account, checkout, consent, benefits, healthcare, enterprise configuration, and onboarding forms with conditional branches.

Avoid when

  • Do not use this entry to reject simple conditional reveal fields that visibly reveal and validate a related follow-up only while its trigger is active.
  • Do not apply it to optional hidden metadata that never blocks submit and is not required for the user's task.

Problem it prevents

Conditional form logic often hides fields to reduce noise, but if hidden fields remain required, stale, submitted, or server-enforced without a visible recovery path, users cannot tell what blocks completion.

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 Required field hidden by conditional logic in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

A form has radio, checkbox, select, eligibility, account type, permission, or saved-draft answers that control which later answers are required.

Pattern promise

Keep conditional requirement state synchronized with the visible branch: reveal required follow-ups beside their triggers, clear or exclude hidden answers when triggers change, restore hidden branches before linking errors, and use review or separate pages when branching is too large for same-page reveal.

Required state

Initial state with all currently required fields identified before users submit.

Recovery path

Submit fails because a required field is hidden.

Access contract

Newly required conditional fields must be placed after the trigger in DOM order or announced through tested status behavior.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A benefits form asks whether the user needs an accommodation; selecting Yes reveals a required Accommodation details field directly below the trigger with helper text and validation.
  • After failed submit, the error summary says Accommodation details is required because Yes is selected and links to the visible revealed field.
  • A user changes Yes to No and the required follow-up is cleared, excluded from validation, and removed from the review page.
  • A user returns from review after changing an upstream answer and is asked the newly required question before final submit.
Weak implementation

Vague, hidden, hard to recover from

  • Submit fails with Enter accommodation details, but the accommodation field is hidden because the branch is collapsed and the trigger is off-screen.
  • A server requires Partner date of birth from an old draft answer, but the current page shows Single and no partner fields.
  • A user repeatedly presses Submit because the only missing required field lives in a hidden branch with no link or visible trigger state.
  • A screen reader user changes a radio answer and is not told that a new required question appeared below it.
UI guidance
  • Do not let a required answer be hidden, visually collapsed, disabled, off-screen, or absent from the current branch while validation still blocks submission.
  • When a trigger makes a follow-up required, keep the trigger, the revealed required field, the requirement text, and the error summary recovery path visible and connected.
UX guidance
  • Users should be able to tell which answers are currently required before submit, why they are required, and how to reveal or remove the requirement.
  • Treat conditional requirement state as data, not decoration: every hide, reveal, trigger change, saved draft, browser Back, server validation, and review step must recompute whether the hidden field is required or excluded.
Implementation contract

What the implementation must handle

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.

Interaction

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

Accessibility

  • Newly required conditional fields must be placed after the trigger in DOM order or announced through tested status behavior.
  • Error summaries must link to visible fields or reveal collapsed branches before moving focus.
  • Do not use display none, hidden, aria-hidden, inert, or disabled controls for active required fields.
  • Use fieldsets, legends, labels, hints, and error text to explain why a conditional field is required.

Review

  • 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?
Evidence trail

Source-backed claims behind this guidance

U.S. Web Design System: Form component

U.S. Web Design System - checked

USWDS form guidance supports required indicators, validation alignment, DOM order, grouping, and explaining disabled states.

Full agent/debug reference

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?
Accessibility
  • Newly required conditional fields must be placed after the trigger in DOM order or announced through tested status behavior.
  • Error summaries must link to visible fields or reveal collapsed branches before moving focus.
  • Do not use display none, hidden, aria-hidden, inert, or disabled controls for active required fields.
  • Use fieldsets, legends, labels, hints, and error text to explain why a conditional field is required.
  • Avoid color, indentation, animation, or collapsed-panel badges as the only signal that a required answer exists.
  • Screen reader and keyboard users must be able to discover, fill, clear, and recover every active required branch.
  • When focus is inside a branch that becomes hidden, move focus to the owning trigger or next logical control.
Keyboard Behavior
  • Tab order reaches the trigger before the revealed required field.
  • Activating the trigger reveals the required field without moving focus unexpectedly.
  • Submit with a missing active conditional field moves focus to an error summary or the revealed field, never to a hidden target.
  • Error summary links open or restore the branch before focusing the missing field.
  • Changing the trigger while focused in a branch returns focus to the trigger or next logical visible control.
  • Collapsed required sections can be opened by keyboard and expose the missing field in order.
  • Disabled controls are not used to satisfy required answers; an enabled recovery path is provided.
Variants
  • Hidden required field
  • Collapsed required section
  • Disabled required control
  • Server-only required field
  • Saved draft stale requirement
  • Review edit creates required branch
  • Nested hidden required branch
  • Mobile accordion required trap
  • Error summary hidden target
  • Assistive technology missed reveal

Verification

Source trail checked:

Saved items