Skip to main content
Back to Guides
Compliance9 min read

Cookie Consent for Government Websites: Compliance Standards and Accessibility Requirements

Government websites face the highest bar for cookie consent compliance: mandatory accessibility standards, strict analytics restrictions, multi-language requirements, and public trust obligations. This guide covers EU, US, and UK requirements and how to meet them.

Why Government Websites Face the Highest Compliance Bar

Cookie consent on a government website is more than a legal obligation. Citizens don't choose to visit their tax authority's portal the way they choose an online store. They have to be there. That creates a fundamentally different consent dynamic, and regulators know it.

Government sites operate under overlapping mandates that most private-sector sites never encounter. Accessibility is a legal requirement with specific technical standards, not a best practice. Analytics are subject to procurement rules and explicit restrictions on tracking citizens. Consent interfaces must work in every language the government serves. And every implementation decision is subject to public records requests, legislative oversight, and press scrutiny that no private company faces.

The typical CMP setup, designed for commercial e-commerce, falls short here. Government digital service teams need solutions that satisfy accessibility law, procurement rules, and the political reality that a dark-pattern cookie banner on a government site is a front-page story.

EU Government Website Requirements

EU member state government websites operate under three intersecting regulatory layers for cookie consent.

The ePrivacy Directive and GDPR

Like all websites serving EU residents, government sites must comply with the ePrivacy Directive (requiring consent before setting non-essential cookies) and the GDPR (governing lawful processing of personal data). Government sites cannot claim "legitimate interest" as a basis for analytics cookies the way some commercial sites attempt to. DPAs across the EU have been clear: public authorities face restrictions on relying on legitimate interest under GDPR Article 6(1)(f), particularly for non-essential processing like web analytics. The practical result is that consent is the only viable legal basis for analytics cookies on EU government sites.

The Web Accessibility Directive (2016/2102)

The EU Web Accessibility Directive (Directive 2016/2102) requires all public sector websites and mobile applications to meet WCAG 2.1 Level AA conformance. This isn't optional. Member states transposed the directive into national law between 2018 and 2020, and it applies to all public sector bodies including national, regional, and local government agencies, courts, police services, public hospitals, universities, and libraries.

The directive's scope explicitly includes cookie consent interfaces. A banner that doesn't meet WCAG 2.1 AA is a compliance failure for the entire site, not just the banner. National monitoring bodies conduct periodic accessibility audits and publish compliance reports. Several member states have begun issuing enforcement actions against public sector sites with inaccessible consent mechanisms.

The European Accessibility Act (2025)

From June 2025, the European Accessibility Act extends similar accessibility requirements to many private-sector digital services. For government sites, it reinforces existing obligations. Teams that meet WCAG 2.1 AA for main content but deploy a third-party consent banner that doesn't are now explicitly exposed.

US Federal Website Requirements

US government websites face a different regulatory structure but equally strict requirements, driven by Section 508, OMB guidance, and domain-specific rules for .gov sites.

Section 508 and WCAG Conformance

Section 508 of the Rehabilitation Act requires all federal IT to be accessible. The Access Board's ICT Standards incorporate WCAG 2.0 Level AA by reference; most agencies now target WCAG 2.1 AA to align with international standards.

Section 508 applies to all content on a federal website, including third-party components like consent banners. If an agency deploys a CMP that produces an inaccessible banner, the agency is liable, not the vendor.

OMB M-10-22: Cookie Guidance for Federal Sites

OMB memorandum M-10-22 ("Guidance for Online Use of Web Measurement and Customization Technologies") categorizes web measurement into three tiers:

  • Tier 1 (single-session): session cookies. Permitted by default with privacy policy disclosure.
  • Tier 2 (multi-session): persistent cookies. Require agency head approval and a compelling need.
  • Tier 3 (PII-linked): persistent tracking tied to individuals. Require explicit opt-in consent.

Most federal sites restrict themselves to Tier 1 and first-party analytics. Third-party advertising cookies are effectively prohibited.

.gov Domain Requirements

CISA's .gov domain program requires HTTPS and HSTS. These intersect with cookie consent through Secure and SameSite cookie attributes: cookies set without the Secure flag on an HSTS-enforced domain are rejected by browsers, creating consent flows that silently fail.

UK Government Standards: GDS and PECR

The UK Government Digital Service (GDS) sets standards that go beyond minimum legal requirements. The Privacy and Electronic Communications Regulations (PECR) govern cookie consent in the UK, and the ICO has published specific guidance on cookies for public sector websites.

GDS's Service Standard requires all GOV.UK services to meet WCAG 2.1 Level AA, with many teams targeting AAA criteria where feasible. The GDS cookie consent pattern has become an informal international benchmark: a simple banner with accept/reject of equal visual weight, no pre-ticked boxes, no dark patterns, and a link to detailed settings.

GOV.UK uses a custom analytics setup that avoids third-party cookies entirely. Government sites don't need retargeting, so the compliance cost of those technologies is pure downside.

Analytics on Government Sites: The First-Party-Only Standard

The analytics question is where government websites diverge most sharply from the private sector. Commercial sites optimize for conversion tracking, attribution modeling, and remarketing audiences. Government sites need to know how many people used the service, where they got stuck, and whether the service is performing. Different questions, different tools.

The emerging standard for government analytics follows a clear pattern:

  • First-party analytics only. No data leaves your infrastructure to third-party analytics vendors. Self-hosted tools like Matomo, or privacy-focused services like Plausible that don't use cookies at all, are replacing GA4 on government sites across Europe and increasingly in the US.
  • No cross-site tracking. Government analytics should not correlate a citizen's visit to the tax portal with their visit to the health services portal. Each service is instrumented independently.
  • IP anonymization or exclusion. Truncating or hashing IP addresses before storage. Some implementations skip IP collection entirely.
  • Minimal data retention. 13 months is the CNIL-recommended maximum for analytics data. Many government implementations use shorter windows.
  • Consent still required under ePrivacy. Even first-party, privacy-preserving analytics that set cookies require consent under the ePrivacy Directive. Cookieless measurement approaches (counting page views server-side without any client-side storage) can sometimes operate without consent, but the legal analysis depends on national transposition.

For government teams evaluating GA4: even with IP anonymization, GA4 sends data to Google's servers. Several EU DPAs have ruled this raises GDPR Chapter V concerns, and government sites bear more scrutiny than commercial ones.

Accessibility Requirements for Government Consent Banners

Meeting WCAG 2.1 AA for a cookie consent banner goes well beyond adding aria-label attributes. For a full technical walkthrough, see our cookie banner accessibility guide. The requirements that trip up government deployments most often:

  • Keyboard navigation (WCAG 2.1.1, 2.1.2): every button, toggle, and link must be operable by keyboard alone. Focus must be trapped within the banner while it's displayed as a modal, and focus order must follow the visual layout.
  • Screen reader compatibility (WCAG 4.1.2, 1.3.1): semantic HTML (<dialog> or role="dialog" with aria-modal="true"), real <button> elements, toggles with role="switch" and aria-checked state. The banner must be announced when it appears.
  • Color contrast and text sizing (WCAG 1.4.3, 1.4.4, 1.4.12): minimum 4.5:1 contrast for text, 3:1 for UI components. The banner must remain functional at 200% text zoom and with adjusted text spacing.
  • Equal prominence for accept and reject: EU DPAs (CNIL, Italian Garante) enforce this as a consent validity requirement. Same button size, same visual weight, no color tricks. Rejecting cookies must take no more clicks than accepting them.

Multi-Language Requirements for Government Consent Interfaces

Government websites serve multilingual populations, and consent interfaces must follow suit. For implementation patterns, see our multi-language cookie banner localization guide.

Legal requirements vary by jurisdiction:

  • EU member states with multiple official languages (Belgium, Luxembourg, Finland, Ireland) must provide consent interfaces in all official languages.
  • US federal sites must comply with Executive Order 13166 on limited English proficiency access. If a service is available in Spanish, the consent mechanism shouldn't be English-only.
  • Canadian government sites must serve consent in both English and French under the Official Languages Act.

Key implementation considerations: language detection should follow the user's site language preference, not browser settings alone. Translations must be legally accurate, not just linguistically correct, since terms like "data controller" have specific translations in each member state's GDPR transposition. RTL language support (Arabic, Hebrew) must be tested. And German or Finnish text runs 30-40% longer than English, so banner layouts must accommodate variable-length content without breaking.

Open-Source vs. Commercial CMP for Government Procurement

Government procurement teams face a genuine tradeoff here. Neither option is categorically better.

Open-source CMPs (Orejime, Klaro, Tarteaucitron) offer code transparency, easier procurement (no vendor contract), and alignment with digital sovereignty initiatives in France and Germany. The tradeoff is internal maintenance burden: when WCAG standards change or a browser API breaks consent storage, your team owns the fix. No SLA, no support line, no contractual accountability if the tool fails an audit.

Commercial CMPs offer support contracts, SLAs, automated regulatory updates, managed cookie scanning, and a named data processor with contractual liability. The procurement path is heavier (RFP cycles, vendor security assessments, authority-to-operate reviews), but for agencies without dedicated front-end teams, a commercial CMP with accessibility and multi-language support out of the box is often the lower-risk path.

Key evaluation criteria regardless of approach: VPAT or accessibility conformance report demonstrating WCAG 2.1 AA compliance; data residency guarantees (EU hosting for EU agencies, FedRAMP-equivalent for US federal); no third-party data sharing from the CMP itself; multi-language support with customizable legal text; tamper-evident consent logging; and source code escrow or transparency provisions.

How CookieBeam Meets Government Compliance Standards

CookieBeam is built around default-deny consent, which aligns directly with the strict posture government sites require.

Accessibility-first banner design. Semantic HTML, full keyboard navigation, ARIA attributes for screen readers, and configurable color schemes that maintain WCAG 2.1 AA contrast ratios. Accept and reject buttons carry equal visual weight by default.

Default script blocking. All non-essential scripts are blocked until the user makes a consent choice. No window where analytics fires before consent is collected, meeting the baseline for OMB M-10-22's tiered approach.

Multi-language consent interfaces. Localized banners with language detection that follows the user's site language preference. Legal text can be customized per language to match national GDPR transpositions.

First-party-only analytics compatibility. Category-based blocking lets government teams allow first-party analytics with consent while permanently blocking third-party advertising tags. The automated cookie scanner detects unauthorized third-party cookies added outside the procurement process.

Consent audit trail. Every consent decision is logged with timestamp, choices made, and banner version. These consent records support regulatory audits and freedom-of-information requests.

Server-side consent enforcement. CookieBeam's consent signals integrate with server-side consent enforcement and Google Consent Mode v2, enforcing consent decisions at the infrastructure level.

Government digital service teams can request an accessibility conformance report and technical assessment covering the standards outlined in this guide.

Cookie Consent for Government Websites: Compliance & Accessibility Guide 2026 | CookieBeam | CookieBeam