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

Official-site banner

Show a jurisdiction-approved official-site banner at the top of eligible pages with official identity text, symbol, trusted-domain explanation, HTTPS explanation, accessible expandable details, consistent placement, and strict rules preventing misleading use.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • The service is eligible to identify itself as an official government or public-authority website.
  • Users need to verify ownership and secure connection before sharing sensitive information.
  • The product can use approved wording, top placement, domain rules, and HTTPS accurately.

Avoid when

  • The site is not an official government or public-authority service.
  • The page is on a staging, prototype, private vendor, partner, non-approved, or non-HTTPS domain.
  • The message is a service outage, deadline, validation error, marketing campaign, beta status, or navigation aid.
  • The system has detected an active threat; use security warning.

Problem it prevents

Users can mistake spoofed, partner, staging, insecure, or unaffiliated sites for official services when official ownership and secure-connection signals are hidden, inconsistent, misleading, or mixed with ordinary announcements.

Pattern anatomy

What a strong implementation has to make clear

User need

Official-site banners appear on government, public-authority, benefits, tax, health, immigration, identity, veterans, legal, licensing, emergency, and account services where users may share sensitive information.

Pattern promise

Show a jurisdiction-approved official-site banner at the top of eligible pages with official identity text, symbol, trusted-domain explanation, HTTPS explanation, accessible expandable details, consistent placement, and strict rules preventing misleading use.

Required state

Collapsed official identity state.

Recovery path

Official identity is hidden below the fold, inside the footer, or after sensitive forms.

Access contract

Use the approved semantic structure and labels for the banner landmark or region.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A benefits service shows an official government banner above the header with a flag, official-site text, a How you know disclosure, and expanded .gov plus HTTPS explanations.
  • An agency site repeats the official banner on every page before the service header, while service navigation and emergency site alerts remain visually separate below it.
  • A user expands the banner before entering a tax ID, reads that .gov belongs to an official government organization, checks the HTTPS guidance, and continues with more confidence.
  • A user on a mobile page opens the identity details, sees both domain and secure connection guidance in a compact stack, and returns to the form without losing progress.
Weak implementation

Vague, hidden, hard to recover from

  • A private vendor checkout copies government official-site copy while using a commercial domain.
  • A real agency site places official identity in a footer seal after users have already entered sensitive data.
  • A staging site uses official banner copy during a user test and participants believe it is a live government service.
  • A banner says the site is secure even though the page is served over HTTP and lacks a trusted government domain.
UI guidance
  • Place the official-site banner at the very top of every eligible page, before the header, service navigation, alerts, and page content.
  • Use the approved jurisdictional identity text, official symbol, domain explanation, HTTPS or lock explanation, and expandable details rather than custom trust copy or marketing language.
UX guidance
  • Use the banner to help users verify official ownership and secure connection status before they share personal, financial, health, legal, or account information.
  • Keep it consistent, non-dismissible where required, and honest about eligibility; do not use official identity treatments on staging, partner, non-government, or insecure surfaces.
Implementation contract

What the implementation must handle

States

  • Collapsed official identity state.
  • Expanded details state with trusted-domain explanation.
  • Expanded details state with HTTPS or lock explanation.
  • Every-page top placement state.

Interaction

  • The banner appears before the header, service navigation, site alerts, notification banners, and main content.
  • The collapsed label identifies the page as official only when the current domain, protocol, and ownership are eligible.
  • The disclosure control expands details without navigating away or moving focus unexpectedly.
  • Expanded details explain trusted-domain rules and HTTPS or lock indicators in plain language.

Accessibility

  • Use the approved semantic structure and labels for the banner landmark or region.
  • Make the expand/collapse control keyboard reachable and announce its state.
  • Do not rely on a flag, seal, lock icon, or color alone to communicate official status.
  • Keep official identity text, domain details, and HTTPS details readable at high zoom and compact widths.

Review

  • What rule proves this page is eligible to claim official identity?
  • Is the banner first on the page before header, alerts, service navigation, and content?
  • Does the detail region explain the trusted domain and HTTPS indicators users can actually verify?
  • What prevents staging, prototype, partner, non-HTTPS, or non-government pages from rendering this banner?
Interactive lab

Inspect the states before you copy the pattern

Verify official ownership and secure connection

Inspect official-site banner, collapsed official identity, expanded domain details, expanded HTTPS details, every-page top placement, agency identity, mobile compact banner, bilingual identity, non-eligible domain, insecure connection blocked, staging warning, coexists with site alert, coexists with service navigation, and compare copied-to-private-site, footer-only-identity, dismissible-proof, maintenance-message, http-secure-claim, and navigation-mix failures.

Official-site banner
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

Collapsed official identity state.

Keyboard / Access

Tab reaches the official banner disclosure before the header navigation and main task controls.

Avoid Generating

Copying an official government banner onto a private, partner, staging, or prototype site.
Evidence trail

Source-backed claims behind this guidance

U.S. Web Design System Banner Component

U.S. Web Design System - checked

Supports official-site identity, .gov explanation, secure HTTPS explanation, top placement, and accessibility guidance.

Full agent/debug reference

Problem Context

  • Official-site banners appear on government, public-authority, benefits, tax, health, immigration, identity, veterans, legal, licensing, emergency, and account services where users may share sensitive information.
  • The banner teaches users how to verify official status and connection security, but it does not replace phishing detection, browser security warnings, service navigation, agency branding, or content trust.
  • Eligibility depends on jurisdiction and platform rules such as official government ownership, approved domain, HTTPS, correct symbols, production status, and non-misleading presentation.
  • The banner sits above the header and must stay separate from service navigation, maintenance banners, notification banners, emergency site alerts, phase banners, and marketing messages.

Selection Rules

  • Choose official-site banner when a page is eligible to claim official government or public-authority identity and users need to verify domain and secure connection status.
  • Use it on every eligible page, including interior service pages, before users enter sensitive information.
  • Use banner for broad product messages that are not official identity or secure-connection verification.
  • Use site alert for urgent sitewide incidents that require temporary public attention.
  • Use notification banner for before-heading service notices such as personal deadlines or previous-page outcomes.
  • Use security warning when the system detects a dangerous destination, certificate issue, unsafe download, or phishing risk.
  • Use service navigation for named-service movement and current-section state, not for official-ownership proof.
  • Do not use official-site banner on non-government, partner, prototype, staging, non-HTTPS, or unapproved-domain pages where it would mislead users.

Required States

  • Collapsed official identity state.
  • Expanded details state with trusted-domain explanation.
  • Expanded details state with HTTPS or lock explanation.
  • Every-page top placement state.
  • Mobile compact expanded state.
  • Agency or jurisdiction identity variant.
  • Non-eligible domain blocked or alternate identity state.
  • HTTP or insecure connection failure state.
  • Staging or prototype warning state.
  • Interaction with site alert, service navigation, phase banner, and language selector states.

Interaction Contract

  • The banner appears before the header, service navigation, site alerts, notification banners, and main content.
  • The collapsed label identifies the page as official only when the current domain, protocol, and ownership are eligible.
  • The disclosure control expands details without navigating away or moving focus unexpectedly.
  • Expanded details explain trusted-domain rules and HTTPS or lock indicators in plain language.
  • The banner does not disappear through ordinary dismissal, marketing preference, or local route changes when the standard requires every-page presence.
  • If a page is ineligible, insecure, staging, or partner-hosted, the product uses alternate identity copy instead of official-site banner claims.
  • Emergency site alerts, product banners, service navigation, phase banners, and notification banners remain separate surfaces below the identity banner.
  • The banner is tested on compact widths, high zoom, keyboard, screen reader, no-JavaScript details fallback, and language variants.

Implementation Checklist

  • Confirm the site is eligible by jurisdiction, ownership, production status, official domain, HTTPS certificate, and platform policy.
  • Use the approved component, official symbol, wording, details structure, and accessibility semantics for the jurisdiction.
  • Place the banner at the very top of every eligible page before the header and service navigation.
  • Include trusted-domain and HTTPS explanations in an expandable or otherwise accessible details region.
  • Keep ordinary maintenance, emergency, phase, validation, marketing, and service-navigation content out of the official identity banner.
  • Add guards so staging, prototype, non-HTTPS, partner, and non-government domains cannot render misleading official-site copy.
  • Test keyboard toggle behavior, focus order, screen-reader labels, high zoom, compact layout, translated copy, and coexistence with site alerts and service navigation.
  • Monitor domain, certificate, and deployment changes so official identity claims stay accurate.

Common Generated-UI Mistakes

  • Copying an official government banner onto a private, partner, staging, or prototype site.
  • Using the banner without an approved government domain or HTTPS.
  • Making the official identity banner dismissible so users cannot later verify domain and secure connection guidance.
  • Mixing official identity proof with maintenance notices, outage alerts, campaign messages, or navigation links.
  • Replacing the official banner with a logo, footer seal, agency header, or unverified trust badge.
  • Showing secure-site language on an insecure page.
  • Changing approved official wording into marketing copy that sounds more persuasive but less verifiable.

Critique Questions

  • What rule proves this page is eligible to claim official identity?
  • Is the banner first on the page before header, alerts, service navigation, and content?
  • Does the detail region explain the trusted domain and HTTPS indicators users can actually verify?
  • What prevents staging, prototype, partner, non-HTTPS, or non-government pages from rendering this banner?
  • Can keyboard and screen-reader users expand the details and return to the page task?
  • Are emergency alerts, service navigation, and product messages kept outside the identity banner?
  • How will the banner behave under localization, compact viewport, high zoom, and route changes?
Accessibility
  • Use the approved semantic structure and labels for the banner landmark or region.
  • Make the expand/collapse control keyboard reachable and announce its state.
  • Do not rely on a flag, seal, lock icon, or color alone to communicate official status.
  • Keep official identity text, domain details, and HTTPS details readable at high zoom and compact widths.
  • Avoid focus jumps when expanding details, and preserve the user's route and form state.
  • Provide translated official wording where required without changing the legal meaning.
Keyboard Behavior
  • Tab reaches the official banner disclosure before the header navigation and main task controls.
  • Enter and Space expand or collapse the details using native button behavior.
  • Focus remains on the disclosure control or moves predictably into the details according to the approved component.
  • Tab order through expanded details reaches trusted-domain and HTTPS explanatory links before continuing to the header.
  • Collapsing details does not move focus to the top of the document or erase form progress.
  • The banner remains available after route changes when every-page placement is required.
Variants
  • Collapsed official-site banner
  • Expanded how-you-know details
  • Domain explanation
  • HTTPS explanation
  • Every-page government banner
  • Agency official banner
  • Mobile official identity banner
  • Bilingual official identity banner
  • Non-eligible domain fallback
  • Insecure connection prevention

Verification

Last verified: