UX Patterns Guide
UI + UX Trust, Safety, And Privacy established

Age gate

Provide a risk-proportionate age gate with clear reason, threshold, input format, data-minimization copy, underage or adult outcomes, parent or guardian route, age-assurance handoff where needed, correction and appeal paths, and content protection before eligibility is known.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Age or age band controls whether users may access content, features, commerce, community interaction, personalization, or data collection.
  • The product needs child-safe defaults, parent authorization, mature-content restriction, or region-specific age eligibility.
  • The experience can explain the threshold, data use, recovery route, and underage outcome honestly.

Avoid when

  • The question is whether an eligible user consents to optional data use; use consent prompt.
  • The boundary is camera, location, microphone, file, or contact access; use permission request.
  • The user is revealing already-authorized hidden content; use sensitive-data reveal.
  • The surface needs durable privacy controls after eligibility; use privacy settings.
  • The product cannot protect restricted content before the answer or cannot safely process age evidence.

Problem it prevents

Age-sensitive products can expose children to unsuitable content, collect child data without the right route, overcollect identity evidence, or deny legitimate users when age checks are vague, easy to game, irreversible, or blended with unrelated consent.

Pattern anatomy

What a strong implementation has to make clear

User need

Age gates may be used for child privacy, mature content, gambling, alcohol, social features, app-store ratings, regional legal thresholds, account creation, creator content, or family settings.

Pattern promise

Provide a risk-proportionate age gate with clear reason, threshold, input format, data-minimization copy, underage or adult outcomes, parent or guardian route, age-assurance handoff where needed, correction and appeal paths, and content protection before eligibility is known.

Required state

Age prompt state with reason, threshold, and input format.

Recovery path

An adult-default button encourages users to lie about their age.

Access contract

Label date, month, year, age band, parent email, verification provider, continue, cancel, correction, and appeal controls with the target threshold or action.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A video service asks for date of birth before showing mature content, explains that age is needed for content eligibility, and blocks access without previewing restricted media when the user is under the threshold.
  • A family app asks a child for an age band, switches to a parent-consent flow for under-13 users, and says which information is collected for the age check.
  • A user enters a birth date, sees that they meet the age threshold for the current region, and can continue without seeing repeated checks during the same signed-in session.
  • An underage user is shown a child-safe version, parent consent route, correction support, and privacy note rather than a dead end that encourages guessing a different birth date.
Weak implementation

Vague, hidden, hard to recover from

  • A modal asks Are you 18? with the Yes button preselected, no explanation, and mature content visible behind the overlay.
  • A low-risk forum demands a government ID scan before showing a text discussion, with no data-minimization, deletion, or fallback explanation.
  • A user denied by an age check can immediately retry unlimited times until they guess an adult birth year.
  • A parent-consent step bundles age authorization with marketing, tracking, and terms acceptance, so users cannot understand what is being authorized.
UI guidance
  • Render the age gate as a clear eligibility boundary that states why age is needed, what threshold or age band applies, which answer format is required, and what happens next.
  • Use the least intrusive age evidence that matches the risk, with separate states for declared age, age band, verified age, parent or guardian consent, underage denial, and age-assurance handoff.
UX guidance
  • Use an age gate when the product must adapt, restrict, or verify access because of age-sensitive content, child data protection, app-store rating, regulated features, or parent authorization.
  • Help users recover honestly by explaining underage outcomes, correction rules, parent or guardian routes, privacy treatment of age evidence, regional thresholds, and appeal or support paths.
Implementation contract

What the implementation must handle

States

  • Age prompt state with reason, threshold, and input format.
  • Neutral date-of-birth or age-band entry state without adult-default bias.
  • Adult allowed state with session or account recognition where appropriate.
  • Underage denied or adapted state that does not leak restricted content.

Interaction

  • The gate appears before restricted content, restricted actions, or child-data collection are exposed.
  • The UI states why age is needed and does not ask for exact birth date or identity evidence when an age band would satisfy the decision.
  • Age choices are neutral: no preselected adult answer, no highlighted lie path, no mature-content preview, and no reward copy for passing.
  • Underage results explain the threshold, available child-safe route, parent route, correction or appeal policy, and what data is retained or deleted.

Accessibility

  • Label date, month, year, age band, parent email, verification provider, continue, cancel, correction, and appeal controls with the target threshold or action.
  • Use fieldsets and error messages for multi-part birth dates or age bands rather than relying on input examples inside empty fields.
  • Do not communicate allowed, underage, pending, failed, or unavailable states by color, lock icon, or blur alone.
  • Announce verification pending, underage blocked, parent consent required, and age accepted states through status text.

Review

  • What exact content, feature, data collection, or action requires age gating?
  • Which age threshold, region, and policy source controls this surface?
  • Is exact date of birth necessary, or would an age band or declared age be enough?
  • What does an underage user see, and does it leak restricted content?
Interactive lab

Inspect the states before you copy the pattern

Check age before age-sensitive access

Inspect age gate, age prompt, neutral age entry, age band selection, adult allowed, underage adapted, parent consent required, age assurance handoff, data minimization, region threshold, retry correction, known account age, appeal route, expired session, verification unavailable, mobile compact age gate, and compare adult-default, content leak, overcollection, no-parent-route, unlimited-retry, bundled-consent, and provider-confusion failures.

Age gate
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Age prompt state with reason, threshold, and input format.

Keyboard / Access

Tab reaches the reason text, input fields or age-band controls, privacy details, continue, cancel, parent route, correction, and appeal controls.

Avoid Generating

Preselecting Yes, I am over 18 or styling the adult path as the obvious safe answer.
Evidence trail

Source-backed claims behind this guidance

Full agent/debug reference

Problem Context

  • Age gates may be used for child privacy, mature content, gambling, alcohol, social features, app-store ratings, regional legal thresholds, account creation, creator content, or family settings.
  • Evidence strength varies by risk: self-declared age, age band, date of birth, signed-in account age, parental consent, third-party age assurance, document check, payment-card check, or organization-managed birth date.
  • The gate itself can create privacy risk when it collects exact birth dates, identity documents, parent contact information, or verification provider data that is not needed for the decision.
  • Underage, unknown-age, verified-adult, parent-consent, regional-threshold, retry, and unavailable-verification outcomes need different UI states.

Selection Rules

  • Choose age gate when age or age band controls whether content, features, data collection, contact, commerce, or personalization is available.
  • Use a declared age or age band when the risk is low and the product only needs coarse adaptation, such as child-safe defaults or content filtering.
  • Use stronger age assurance when regulated content, adult features, child-data collection, payments, gambling, or platform policy requires higher confidence.
  • Use parent or guardian consent when a child may continue only through an adult authorization route.
  • Use consent prompt when the user is already eligible and the question is whether to allow a specific data use or action.
  • Use permission request when the boundary is access to camera, location, microphone, contacts, files, or another device or account resource.
  • Use sensitive-data reveal when age is already known and the user must intentionally expose hidden information.
  • Use privacy settings for durable age-related defaults, child profiles, family controls, or data-sharing settings after the eligibility step.

Required States

  • Age prompt state with reason, threshold, and input format.
  • Neutral date-of-birth or age-band entry state without adult-default bias.
  • Adult allowed state with session or account recognition where appropriate.
  • Underage denied or adapted state that does not leak restricted content.
  • Parent or guardian consent required state.
  • Age assurance handoff state with provider, data, and return status.
  • Data-minimization explanation state.
  • Region-specific threshold state.
  • Retry, correction, appeal, signed-in known age, expired session, verification unavailable, and mobile compact states.

Interaction Contract

  • The gate appears before restricted content, restricted actions, or child-data collection are exposed.
  • The UI states why age is needed and does not ask for exact birth date or identity evidence when an age band would satisfy the decision.
  • Age choices are neutral: no preselected adult answer, no highlighted lie path, no mature-content preview, and no reward copy for passing.
  • Underage results explain the threshold, available child-safe route, parent route, correction or appeal policy, and what data is retained or deleted.
  • Parent consent, legal acceptance, marketing consent, cookie consent, and device permissions remain separate decisions with separate labels.
  • Retry and correction rules prevent easy guessing while allowing genuine mistakes to be corrected through a clear route.
  • Verification provider handoffs preserve return state, explain data sharing, and handle canceled, failed, unavailable, and pending results without claiming success.
  • Known-age signed-in sessions avoid repeated prompts while still refreshing when policy, region, account state, or session risk changes.

Implementation Checklist

  • Map age-sensitive surfaces, age thresholds, regions, risk levels, required confidence, parent routes, and allowed child-safe alternatives before designing the gate.
  • Choose the minimum age evidence needed for each surface and document retention, deletion, verification-provider, and audit behavior.
  • Write separate copy for adult allowed, underage denied, child-safe adaptation, parent consent required, verification pending, verification failed, unavailable provider, correction, and appeal states.
  • Block restricted content previews, search snippets, recommendations, notifications, and deep links until eligibility is known.
  • Keep age-gate decisions separate from terms acceptance, cookie consent, marketing consent, payment consent, and device permission prompts.
  • Test long localized threshold copy, low vision, keyboard entry, date formatting, screen readers, mobile numeric keyboards, regional thresholds, family accounts, and locked or managed profiles.
  • Audit logs and analytics so age, birth date, parent contact, identity evidence, and failed checks are minimized and protected.

Common Generated-UI Mistakes

  • Preselecting Yes, I am over 18 or styling the adult path as the obvious safe answer.
  • Showing restricted content behind or before the age gate.
  • Collecting identity documents when only an age band is needed.
  • Letting users retry unlimited birth dates until one passes.
  • Bundling parent consent with marketing, tracking, legal acceptance, or cookie consent.
  • Giving an underage user a dead end with no child-safe alternative, parent route, correction, or appeal.
  • Treating a device permission denial as an age gate result.
  • Remembering a failed or sensitive age answer forever without explaining retention or correction.

Critique Questions

  • What exact content, feature, data collection, or action requires age gating?
  • Which age threshold, region, and policy source controls this surface?
  • Is exact date of birth necessary, or would an age band or declared age be enough?
  • What does an underage user see, and does it leak restricted content?
  • Can a genuine mistake be corrected without allowing unlimited guessing?
  • What parent, guardian, family, or managed-account route exists?
  • What age evidence is collected, where is it stored, and when is it deleted?
Accessibility
  • Label date, month, year, age band, parent email, verification provider, continue, cancel, correction, and appeal controls with the target threshold or action.
  • Use fieldsets and error messages for multi-part birth dates or age bands rather than relying on input examples inside empty fields.
  • Do not communicate allowed, underage, pending, failed, or unavailable states by color, lock icon, or blur alone.
  • Announce verification pending, underage blocked, parent consent required, and age accepted states through status text.
  • Keep parent route, correction, appeal, privacy notice, and child-safe alternative keyboard reachable.
  • Use numeric keyboard hints where appropriate, but preserve manual entry, paste, and localized date formats.
Keyboard Behavior
  • Tab reaches the reason text, input fields or age-band controls, privacy details, continue, cancel, parent route, correction, and appeal controls.
  • Enter submits only when required fields are valid and focus remains on the first invalid field after validation errors.
  • Escape closes optional help or provider detail surfaces without submitting an age answer.
  • After an allowed result, focus moves to the newly available content heading or next task step.
  • After an underage or failed result, focus moves to the explanation and then to the child-safe, parent, correction, or appeal action.
  • Provider handoff cancellation returns focus to the verification choice rather than losing the task.
Variants
  • Date of birth gate
  • Age band selector
  • Declared adult gate
  • Verified age gate
  • Age assurance provider handoff
  • Parent consent gate
  • Child-safe adaptation
  • Regional age threshold
  • Known-age account check
  • Age correction or appeal
  • Expired age session
  • Managed child account

Verification

Last verified: