Official-site banner

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?