Age gate

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?