Government Website Standards Consolidated in One Place

Image

Government website standards are a stack of federal laws and executive policies that apply differently depending on your agency type.

Executive agencies must follow OMB M-23-22, which provides government-wide direction for delivering a digital-first public experience and clarifies requirements and best practices. Section 508 of the Rehabilitation Act sets the accessibility baseline for all federal technology.

But federal isn't the whole picture.

The DOJ's 2024 ADA Title II final rule extends web accessibility requirements to state and local governments with specific deadlines tied to population size. Jurisdictions serving 50,000 or more people must comply by April 24, 2026. Smaller entities and special district governments have until April 24, 2027.

Both deadlines adopt WCAG 2.1 Level AA as the enforceable technical standard. That means the same success criteria apply whether you sit in a federal office or a county planning department.

Let’s break each requirement area into what the law actually asks for and what it looks like on a working website.

Core government website standards and requirements

OMB M-23-22 organizes requirements into several areas that overlap in practice. Here is what each one demands:

• Design and user experience standards require agencies to adopt the U.S. Web Design System for new sites and significant redesigns. USWDS provides standardized components, templates and design tokens that enforce visual consistency across federal properties. Legacy sites can remain as-is until a significant update triggers the requirement.
• Accessibility under Section 508 requires federal web content to meet WCAG 2.0 Level AA. OMB M-23-22 directs agencies to adopt more modern standards (like WCAG 2.1 or 2.2) to stay consistent with ADA Title II requirements.
• Mobile optimization is mandated by the Connected Government Act of 2018, which requires new and redesigned federal public websites to be mobile-friendly.
• Required content and functionality spans every federal site. Each one needs an About page, contact information, privacy policy, FOIA information, a homepage link on every page and a search function. While these specific pages are mandated for federal sites, they serve as the blueprint for state and local transparency as well. Footers must link to USA.gov, the agency's parent department, a privacy policy and an accessibility statement with a complaint mechanism. No FEAR Act data must be published on the agency’s principal website.
• Domain and security rules generally require official federal websites to use a .gov or .mil domain and enforce HTTPS. However, agencies may use approved third-party services that do not use a .gov or .mil domain when necessary.
• Performance and structure standards prohibit broken links, empty pages and "under construction" placeholders. Pages must load quickly and remain available.

What WCAG 2.1 Level AA means in practice on a website

WCAG 2.1 Level AA is the technical standard behind both Section 508 and ADA Title II. On an actual site it translates into testable behaviors your team can audit before launch:

• Keyboard navigation requires all functionality to be operable without a mouse.
• There must be no focus traps, and every interactive element needs a visible focus indicator.
• Semantic HTML means using proper heading hierarchy and landmark elements like main, nav and section so assistive technology can parse page structure.
• Skip navigation links must let users bypass repeated content blocks.
• Color contrast must hit a 4.5:1 ratio for normal text and 3:1 for large text.
• Text must resize to 200% without loss of content and reflow at 400% zoom without requiring horizontal scrolling.
• Multimedia requires synchronized captions for video and audio descriptions for visual-only content.
• Any time limits must be adjustable or removable.
• Forms must identify errors specifically and suggest corrections.
• Data tables need proper header elements and scope attributes so screen readers can associate cells with their labels.

The WCAG 2.1 quick reference is the best working reference for the full success criteria. Platform tooling can catch visual regressions but compliance lives in your code, content and editorial process.

Adopting the U.S. Web Design System (USWDS)

USWDS is not an all-or-nothing commitment. The system uses a maturity model that lets agencies adopt incrementally across levels:

• Level 1 means applying USWDS design principles like accessibility, consistency, and user-centered design without changing your codebase.
• Level 2 adds UX guidance and CSS foundations, including typography scales, spacing tokens and color themes.
• Level 3 includes full code components such as buttons, form controls, banners, and navigation patterns, ready to drop into Drupal or WordPress templates.

M-23-22 mandates USWDS adoption for new federal sites and significant redesigns. Legacy sites are not required to adopt until a significant update triggers the requirement. That distinction is important for planning.

Teams running older sites can start at Level 1 by aligning design decisions with USWDS principles then move to Level 2 and Level 3 as redesign cycles allow. The maturity model gives you a defensible adoption path you can cite in procurement documents and project timelines.

Domain, security and trust signals

U.S. federal sites must operate on a .gov or .mil domain. These domains are administered by CISA and signal to users that the site is an official government property.

Every federal website must display the standardized USWDS banner at the top of every page. This banner must include the U.S. flag icon and a "Here’s how you know" dropdown that provides specific, unaltered technical explanations of .gov domains and HTTPS security to ensure consistent trust signals across the federal government.

Image

While federal agencies must use the "United States government" text, state and local entities should adapt the USWDS banner language to reflect their specific jurisdiction (e.g., "An official website of the City of Springfield").

HTTPS is mandatory under OMB M-23-22 (PDF) and enforced through DHS/CISA binding operational directives. Additional requirements such as HSTS, DNSSEC and IPv6 may apply under separate federal cybersecurity directives and agency network policies.

Any use of third-party tracking or analytics must be disclosed in the site's privacy policy. Agencies cannot embed tracking scripts that collect personally identifiable information without explicit notice.

Platform infrastructure like CDNs, WAFs and managed TLS certificates supports these requirements but does not replace them. Your hosting provider can deliver transport security and uptime. It cannot publish your banner, write your privacy disclosures, or configure your DNSSEC records. Those are agency responsibilities regardless of where the site runs.

Required pages, footer links and search

These are the elements auditors check first:

• Every federal site must have an About page, a contact page, FOIA information and a search function. M-23-22 directs agencies to participate in Search.gov to improve governmentwide search visibility.
• Every page must include a link back to the homepage, and the footer must link to USA.gov and the agency's parent department. That parent department link should point to your actual parent agency, not HHS.gov universally.

Statutory footer requirements go further. You need a privacy policy, an accessibility statement that includes a complaint mechanism, No FEAR Act data, and an Office of Inspector General (OIG) "Report Fraud" link. These are legal requirements with specific language expectations.

The Plain Writing Act requires agencies to implement plain writing policies and make compliance information publicly available.

Link standards under M-23-22 require meaningful link text instead of "click here" and indicators for file type and size on downloads. Visited and unvisited links must be visually distinct. Custom 404 pages must provide helpful navigation back to the main site. No page should return an empty response or display an "under construction" message.

Plain language, analytics and continuous improvement

The Plain Writing Act requires federal agencies to use clear language in all public-facing content. That means no jargon, unnecessarily complex sentence structures or buried meaning.

Agencies must also maintain a dedicated Plain Writing compliance page on their site that explains how they meet the requirement and identifies a point of contact for public feedback.

The Digital Analytics Program (DAP) is mandatory for federal executive branch agencies. DAP provides a unified analytics baseline across government sites so agencies can track user behavior and measure whether content is actually serving visitor needs. Analytics should feed directly into improvement cycles, not unreviewed dashboards.

Continuous improvement depends on process as much as tooling. Staging environments let teams test content changes, accessibility fixes, and design updates before they reach production. The goal is a repeatable workflow where user feedback and analytics data drive iteration rather than one-off audits.

Limited English proficiency and language attributes

Following Executive Order 14224, English is the official language of the United States, revoking the previous mandates of EO 13166. However, federal agencies are still encouraged to provide multilingual materials for mission-critical services – like emergency alerts and health safety – while prioritizing English as the authoritative version of all information.

Not all content carries the same translation obligation. Vital documents like applications, consent forms, notices of rights and eligibility determinations require high-quality human-verified translations. General web content carries a lower bar, but agencies must still take reasonable steps to provide meaningful access for people with limited English proficiency.

On the technical side, HTML lang attributes tell screen readers which language to use for pronunciation. When content switches language mid-page, such as a Spanish paragraph on an English site, each block needs its own lang attribute so assistive technology can shift pronunciation correctly.

Foreign language links should appear in their respective languages, not as English labels. Social media accounts and third-party services that serve limited proficiency populations must also comply with language access standards.

What hosting provides and what it does not

A modern hosting platform handles infrastructure. These are baseline expectations any serious government hosting provider should deliver without custom configuration:

• HTTPS termination ensures encrypted connections between your server and every visitor without your team managing certificates manually.
• WAF protection filters malicious traffic and common attack patterns before requests reach your application layer.
• CDN delivery distributes cached content across edge locations so pages load fast regardless of user geography.
• Uptime monitoring and automated failover keep your site available and alert your team when something breaks.
• Update workflows let you apply CMS core and security patches through staged deployments rather than risky production hotfixes.

No platform delivers ADA or Section 508 compliance. A site can score perfectly on transport security and uptime while failing every accessibility requirement that touches users:

• Heading hierarchy is a content decision that determines how well assistive technology can parse your page structure.
• Alt text on images is content your team writes, not something a server generates.
• Color contrast ratios depend on design choices made in your theme and stylesheets.
• Form error handling requires deliberate development against WCAG success criteria.
• Plain language is a writing discipline no platform can automate.

When evaluating vendors ask what the platform provides and what it expects your team to own. Any vendor claiming their hosting makes your site compliant is either confused about the requirements or hoping you are.

You can set your team up for success by prioritizing platforms like Pantheon, which have a solid history hosting government websites.

Levelling up your compliance

The standards in this article live in your code, your content and your editorial workflows. No platform can make them disappear. But the right platform can make the ongoing work significantly easier to manage.

Pantheon runs on Google Cloud and provides the infrastructure layer covered above: HTTPS, global CDN, WAF, automated backups and uptime monitoring. For government teams running Drupal or WordPress that’s the baseline. Where Pantheon becomes more useful is in its workflow tooling.

Dev, Test, Live environments let you stage accessibility fixes, content updates and USWDS component rollouts without touching your production site. Your team can test WCAG fixes in isolation and verify them before they go live.

Autopilot handles CMS core and plugin updates automatically by applying them in a sandboxed environment and running visual regression tests before deployment. That means security patches don’t stack up waiting for a change window.

Pantheon is available through Carahsoft on NASPO ValuePoint, OMNIA Partners and E&I Cooperative Services contracts. If your compliance roadmap starts with the standards above, Pantheon handles the infrastructure so your team can focus on the decisions that actually determine compliance.

If the standards above are your roadmap, start building on Pantheon.