Why a Date-of-Birth Field Is Not an Age Gate: Design Principles for Neutral Age Screens

The difference between asking and establishing age

A date-of-birth field is common in online registration. It can help a service understand the age a user declares, calculate an age range or decide which experience to present. However, the field does not independently confirm the information entered. A person who selects a birth date indicating that they are 25 has supplied a declaration, not evidence that they are 25.

This distinction becomes important when a service restricts access to adults. If the only barrier is a date picker followed by a continue button, the service has created an age declaration screen. It has not necessarily created an effective age gate. The UK regulator Ofcom explicitly states that self-declaration is not capable of being highly effective at correctly determining whether someone is 18 or over under its Online Safety Act guidance.

What a neutral age screen should communicate

A neutral age screen presents the restriction clearly without encouraging a particular answer. Its purpose is to explain the age threshold and the next step, not to persuade users to select the adult option. Neutral wording also helps avoid creating an interface that nudges children towards entering a false date of birth.

A straightforward opening might say: This service is restricted to people aged 18 or over. You will need to complete an age check before accessing restricted content. The screen can then explain which information is needed, who processes it and what happens if the check cannot establish the required age. The precise wording should reflect the actual method being used.

• State the minimum age in plain language.
• Explain whether the next step is a declaration, estimate or verification.
• Describe the information that will be requested.
• Keep restricted material out of view before the required check is complete.
• Explain the available alternative and appeal routes.

A practical adult sign-up flow

A useful way to design an 18+ app sign-up flow is to separate the access decision from ordinary account registration. Users should encounter the age restriction before they can view adult-only material or use a restricted feature. The service should then provide the appropriate assurance method and wait for the outcome before enabling access.

For example, imagine a service with an adult-only area and a separate account creation process. Its journey might begin with a neutral restriction notice, continue to an age assurance provider, return an adult or under-18 outcome, and then allow eligible users to proceed to account registration. An inconclusive result should lead to a clearly explained alternative route. The exact order depends on the service and its regulatory obligations.

• Step 1: Display the age restriction and explain the requirement.
• Step 2: Offer an appropriate age assurance method.
• Step 3: Process the result without exposing restricted content.
• Step 4: Provide an alternative or appeal route if the result is inconclusive.
• Step 5: Allow eligible users to continue to registration.
• Step 6: Apply the correct access permissions to the account.

The front gate and the placement of restricted content

A front gate is an interface placed before access to restricted material. Its role is to prevent users from seeing the material before completing the required age assurance process. This is especially relevant to services that publish pornography. Ofcom's guidance states that pornography should not be visible before or during the age check, and describes a blank landing page as an appropriate approach to preventing premature exposure.

A front gate is different from a pop-up placed over content that is already visible. If a user can see thumbnails, previews, descriptions or other restricted material before the check, the restriction may be undermined by the surrounding interface. Product teams should consider the entire journey, including search previews, embedded media, cached pages and direct links, when deciding where to enforce access controls.

Error states, alternative routes and repeat attempts

Age assurance can fail for reasons that do not establish that a user is underage. A document photograph might be unreadable, a supported document may be unavailable, or an estimation result may fall too close to the threshold. A neutral design should distinguish an underage decision from a technical failure or an inconclusive result. Combining these outcomes into one generic rejection message makes the process harder to understand and challenge.

A well-defined flow explains what happened and what the user can do next. It might offer another assurance method, explain document requirements or provide an assessment appeal. Ofcom's guidance discusses challenge ages, liveness detection where relevant, repeat checks, anti-circumvention measures and appeals. A service should also consider whether repeated attempts create opportunities to bypass the restriction.

• Underage outcome: explain that access is restricted.
• Technical failure: explain how to retry or use another method.
• Inconclusive outcome: offer an appropriate additional check.
• Disputed outcome: provide a route to challenge the decision.
• Repeated attempts: apply proportionate controls against circumvention.

Privacy should be part of the screen design

An age gate can collect more information than is necessary if its data requirements are not carefully designed. A document check may expose a full name, document number and photograph even when the service only needs to know whether someone is over 18. An estimation process may involve facial information. A service should understand what its provider collects, what is returned and what is retained.

The ICO's age assurance guidance emphasises transparency, data minimisation, security and the need to avoid using age assurance information for incompatible purposes. Users should be told what information is processed and why. Where possible, a service can receive a limited result such as an over-18 signal or age band without retaining the original identity evidence. Whether this arrangement is suitable depends on the method, provider and legal context.

Design checks before an age gate goes live

A product team should assess the complete access journey rather than treating the first screen as the whole age restriction. The relevant questions include whether restricted content is visible before a decision, whether the selected method provides the required level of assurance, whether people with accessibility needs can complete it and whether adults who receive incorrect outcomes can challenge them.

The legal position also needs to be identified before selecting the interface. Under the UK Online Safety Act, certain services must use highly effective age assurance, while the Children's Code takes a broader risk-based approach to services likely to be accessed by children. The obligations depend on the service's characteristics and current regulatory guidance. This article is general information, not legal advice.

• Identify the exact threshold: 16+, 18+ or another age category.
• Identify the applicable regulatory requirement.
• Check the whole journey for premature exposure to restricted material.
• Document the method's accuracy, limitations and failure states.
• Explain the collection and retention of personal information.
• Provide accessible alternatives and a meaningful challenge process.

Sources and a practical next step

The primary UK sources for these design decisions include Ofcom's Age Assurance Duties under the Online Safety Act and its Guidance on Highly Effective Age Assurance. The ICO's Age Assurance Opinion for the Children's Code and its guidance on the Age Appropriate Design Code provide further information on privacy, proportionality and children's rights. These sources address different regulatory duties, so the relevant document should be selected according to the service and the decision being made.

For an existing 18+ sign-up journey, begin by drawing every screen from the first landing page to the first restricted feature. Mark where personal information is collected, where the age decision is made and where access becomes available. Then identify every route that could expose restricted material before the required decision and specify how each error or appeal outcome will be handled.

Questions readers ask