An accessible government website is one that is designed, developed, and maintained to meet WCAG 2.1 AA standards from the start, ensuring all users can navigate, understand, and interact with public services.
Building a government website from scratch is one of the rarest and most valuable opportunities in public sector digital work. You are not remediating. You are not patching. You are not inheriting someone else's technical debt. You have a blank canvas and the ability to make every decision correctly from the beginning.
Most government agencies waste that opportunity.
Not because they do not care about accessibility. Because they treat it as a quality assurance activity at the end of the project rather than a design constraint at the beginning. The result is a site that is tested for accessibility two weeks before launch, produces a list of issues that are too expensive to fix in the timeline, gets launched with known failures, and regresses within months because the governance structures that would have sustained compliance were never built.
This guide is the antidote to that pattern. It covers every phase of building a government website from scratch — procurement and vendor selection, information architecture, design system, component development, content migration, CMS configuration, pre-launch validation, and governance handoff — with specific, actionable accessibility requirements at each stage.
The premise is straightforward. If you are building from scratch, there is no reason to build anything that is not accessible. Every decision you make before code is written is a design decision. Every design decision made accessibly is one fewer remediation project after launch.
TLDR: Accessible Government Website Build Framework
- Write accessibility requirements into the RFP
- Design information architecture for keyboard navigation
- Build an accessible design system (color, typography, focus)
- Develop and test accessible components
- Configure CMS for accessible content creation
- Audit and remediate content before migration
- Validate accessibility before launch
- Establish governance and monitoring post-launch
Phase 1: Accessibility Requirements in Government RFPs and Vendor Selection
Everything that follows is shaped by who you hire to build the site and what contract you give them. Accessibility decisions made in procurement determine what is possible in every subsequent phase.
Write Accessibility Into the RFP
The RFP is where your accessibility requirements become contractual. An RFP that mentions accessibility only in a general statement of compliance — "the vendor will ensure the site meets ADA Title II requirements" — produces proposals that treat accessibility as a checkbox. An RFP with specific, verifiable requirements produces proposals where vendors have to demonstrate how they will actually achieve them.
Specific RFP language that works:
The site will be developed to WCAG 2.1 Level AA conformance. All components in the component library will be tested for keyboard operability and screen reader compatibility before acceptance. Keyboard and screen reader testing will be conducted during development, not only at project completion. The vendor will provide a completed accessibility conformance report for the delivered site at launch.
Add these specific questions to the RFP:
Describe your process for ensuring accessibility during component development. How is keyboard testing and screen reader validation integrated into your development workflow?
What CMS configuration decisions will you make to support accessible content publishing? Describe specifically how alt text fields, heading selectors, and document upload workflows will be configured.
What does your governance handoff include? Describe the editor training, the publishing standards documentation, and the monitoring program that will be in place at launch.
Provide examples of WCAG 2.1 AA conformance reports from previous government website projects.
Proposals that cannot answer these questions specifically are proposals from vendors who will treat accessibility as pre-launch QA.
Evaluate Vendor Proposals on Accessibility Specifics
When scoring proposals, weight the accessibility responses heavily. A vendor who describes accessible component development during build is fundamentally different from a vendor who describes accessibility testing before launch. The first one builds correctly. The second one finds out what needs to be fixed.
Ask shortlisted vendors to demonstrate their accessibility testing process. Have them show you a component being tested — not slides about their process, an actual demonstration with a keyboard and a screen reader. This tells you more about their accessibility capability than any written proposal.
Require Accessibility Language in the Contract
The contract is where RFP requirements become enforceable obligations. The accessibility clauses in the contract should specify:
WCAG 2.1 AA as the technical standard for deliverables. Keyboard and screen reader testing as required validation steps for each component before client acceptance. An accessibility conformance report as a required deliverable at project completion. A defined remediation obligation for accessibility failures identified during client review. Post-launch support provisions for accessibility issues identified within a defined period after launch.
Without contract language, accessibility requirements are aspirational. With contract language, they are obligations.
Phase 2: Accessible Information Architecture and Content Strategy
Before any visual design begins, the information architecture of the site determines how content is organized, how navigation works, and how residents find what they need. Accessibility considerations at this phase are primarily structural — about how the site is organized rather than how it looks.
Design for Keyboard Navigation From the Start
The navigation structure of a government website is one of its most important accessibility considerations. A navigation system that is logical, consistent, and keyboard-navigable is fundamental — and it is far easier to design it correctly from the start than to retrofit keyboard accessibility into a complex navigation structure that was designed for mouse interaction.
Navigation accessibility requirements to build into the IA phase:
Skip navigation links are a required element — not an afterthought. The first focusable element on every page must be a skip link that allows keyboard users to bypass the navigation and jump directly to the main content.
Dropdown and mega-menu navigation must be designed for keyboard operability from the start. The interaction pattern — how submenus open, how they are navigated, how they close — needs to be defined in the IA phase so that the development team can implement accessible keyboard behavior without retrofitting it into a mouse-centric design.
Navigation consistency is a WCAG requirement. The navigation structure, labeling, and order must be consistent across all pages. Design this consistency into the IA before visual design begins.
The depth and complexity of the navigation structure directly affects keyboard navigation burden. Every level of navigation that a keyboard user must traverse to reach the skip link, and every item they must navigate through without it, is part of the accessibility burden. Simpler navigation is more accessible. This is a design constraint that should be established in the IA phase.
Plan Landmark Regions in the Page Architecture
HTML landmark regions — header, nav, main, aside, footer — are the structural elements that allow screen reader users to navigate pages by jumping between major sections rather than reading linearly. They need to be planned in the IA phase and consistently implemented in every page template.
Define the landmark structure for every page type before design begins. A standard government page might have: a banner region containing the site header and logo, a navigation region containing the primary navigation, a main region containing the page content, optionally an aside region for secondary content or related links, and a contentinfo region containing the footer. Every page template should implement this structure consistently.
Phase 3: Accessible Design Systems (Color, Typography, Focus)
The design phase is where color, typography, component patterns, and visual hierarchy are established. Every visual decision made at this stage has accessibility implications. The cost of getting these decisions wrong in design is small. The cost of getting them wrong after development is significant.
Build an Accessible Color Palette From the Start
Every color combination in the design system must be evaluated for WCAG 2.1 AA contrast compliance before a single line of code is written. This is not a post-design QA step — it is a design constraint that shapes the palette.
The requirements:
Normal text against its background must achieve a contrast ratio of at least 4.5:1. Large text (18pt or 14pt bold) against its background must achieve a contrast ratio of at least 3:1. UI components — buttons, form fields, focus indicators — and their states must achieve a contrast ratio of at least 3:1 against adjacent colors.
Evaluate the entire palette: primary text on primary backgrounds, secondary text on secondary backgrounds, text on colored backgrounds (call-out boxes, banners, notification areas), button text on button backgrounds in all states (default, hover, active, disabled), placeholder text on input backgrounds, error message text on error state backgrounds.
Tools for this evaluation: the WebAIM Contrast Checker, the Colour Contrast Analyser desktop application, or the Figma Contrast plugin for design teams working in Figma.
Any color combination that fails — and some will — needs to be adjusted during design, not after development. A brand color that fails contrast requirements needs either a darker or lighter variant that passes, or the design needs to be adjusted to avoid placing text on that background.
Design for Color Independence
WCAG requires that color not be the sole means of conveying information. Every element in the design that uses color to communicate something — required field indicators, error states, status indicators, chart data differentiation, notification levels — must have a secondary non-color indicator.
Required fields: a red asterisk alone fails. A red asterisk plus a text label or a "(required)" notation passes.
Error states: a red border alone fails. A red border plus an error message in text passes. A red border plus an inline error icon plus a text message is better.
Chart data: color-coded chart series with no other differentiation fails for users with color vision deficiencies. Adding patterns, labels, or accessible data tables alongside charts passes.
Design these secondary indicators in the design phase. Retrofitting them after development is more expensive and often produces awkward design solutions.
Design Focus Indicators Intentionally
The default browser focus indicator — typically a thin blue outline — is often suppressed in design systems for aesthetic reasons. This is one of the most common accessibility failures in newly launched government websites and one of the easiest to prevent.
Design custom focus indicators as a specific design element. They should be visible, high-contrast, and consistent across all interactive elements. A 2px solid outline in a color that achieves 3:1 contrast against both the element and the background behind it is the baseline. Many design systems use a combination of outline and offset to create a clearly visible focus state that does not feel visually intrusive.
The focus indicator design should be specified in the design system documentation with exact values so that developers implement it consistently rather than leaving it to default browser behavior.
Specify Typography for Readability and Accessibility
Typography decisions affect accessibility for users with low vision, dyslexia, and cognitive disabilities. The design system typography specification should include:
Minimum body text size of 16px for primary content. Anything smaller should be reserved for secondary information and should never be used for primary navigation or form labels.
Line height of at least 1.5 for body text. WCAG 1.4.12 (Text Spacing) requires that content remains accessible when line height is increased to 1.5 times the font size.
Sufficient spacing between paragraphs. At least 2 times the font size for paragraph spacing supports readability for users with dyslexia and cognitive disabilities.
Avoid all-caps text for anything beyond short labels or headings. All-caps text is significantly harder to read for users with dyslexia.
Avoid justified text alignment. Justified text creates uneven word spacing that significantly increases reading difficulty for users with dyslexia.
Phase 4: Accessible Component Development and Testing
The component library is the most important accessibility investment in a government website build. Every component built correctly once is accessible everywhere it is used. Every component built with an accessibility failure replicates that failure across every page that uses it.
The Component Development Process
Every component in the library should go through the same development process before it is accepted into the library:
Build phase: Semantic HTML first. Use native HTML elements wherever they can do the job without ARIA — a <button> instead of a <div> with click handlers, a <nav> instead of a <div class="navigation">, a <main> instead of a <div id="content">. Add ARIA only where native HTML cannot adequately communicate the role, state, or property to assistive technology.
Keyboard testing: Before the component is submitted for review, test it with keyboard-only navigation. Can every interactive element be reached with Tab? Can every action be performed with keyboard? Does focus behave correctly when the component opens, updates, or closes? Is there a keyboard trap anywhere in the component?
Screen reader testing: Test with NVDA on Chrome and VoiceOver on Safari. Does the screen reader announce the component correctly? Are roles, states, and properties announced appropriately? Are dynamic updates announced when content changes?
Automated testing: Run axe DevTools on the component. Address every violation before submission.
Acceptance criteria: A component is not accepted into the library until keyboard testing, screen reader testing, and automated testing are complete and all failures are resolved. Accessibility is a completion criterion, not a review comment.
Critical Components That Need Careful Accessibility Treatment
Navigation menus: The keyboard interaction pattern for dropdown navigation menus is specific and must be implemented correctly. Focus management when submenus open and close. Escape key to close open submenus. Arrow key navigation within submenus. Tab to move between top-level items.
Modal dialogs: Focus must move into the modal when it opens. Content behind the modal must be inert — not reachable by keyboard or screen reader while the modal is open. Escape must close the modal. Focus must return to the triggering element when the modal closes.
Form components: Every input must have a programmatically associated label. Error messages must be associated with their field and announced when they appear. Required fields must be indicated both visually and programmatically. The form must be completable using keyboard only from start to submitted confirmation.
Data tables: Header cells must use <th> with appropriate scope attributes. Complex tables with both row and column headers require id and headers attribute associations. Tables must not be used for layout.
Accordions and disclosure widgets: The toggle button must announce the expanded/collapsed state. Content must be actually hidden (not just visually hidden) when collapsed so screen readers do not read collapsed content. Focus must be managed appropriately when panels open and close.
Date pickers: One of the most consistently inaccessible components in government websites. Must be fully keyboard operable. Must announce the selected date to screen readers. Must allow manual date entry as an alternative to calendar interaction.
Carousels and sliders: Auto-advancing carousels that cannot be paused fail WCAG. If a carousel is used, it must have accessible controls to pause, play, and navigate between items. Each slide must be reachable by keyboard. Current slide position must be announced.
Phase 5: CMS Configuration for Ongoing Accessibility Compliance
A compliant component library produces a compliant empty website. The CMS configuration determines whether content editors can maintain that compliance when they start publishing.
Configure Text Formats for Accessibility
In Drupal, WordPress, and most government CMS platforms, the text format configuration determines what HTML editors can produce. Configure text formats to support accessible content:
Allow heading elements (H2 through H4 in body content — H1 should be reserved for the page title). Do not allow arbitrary font size changes that editors use as a heading substitute.
Allow table elements — but configure the editor to present accessible table creation options (caption, header row designation).
Allow figure and figcaption elements for image captions.
Allow blockquote for properly structured quotations.
Consider restricting or removing formatting options that are commonly misused to create visual structure without semantic meaning — manual bold-as-heading being the most common example.
Make Alt Text Required and Guided
Configure the image field to require alt text before an editor can save an image. Add helper text in the alt text field that gives specific guidance: "Describe what this image communicates, not what it looks like. For decorative images with no informational value, check the 'Decorative' checkbox instead."
Add a "mark as decorative" option that allows editors to set empty alt text for decorative images without leaving the field blank (which most CMS platforms interpret as missing alt text rather than intentional empty alt).
Configure Semantic Heading Selectors
The heading format selector in the WYSIWYG editor should display semantic level names — Heading 2, Heading 3, Heading 4 — not visual size names like Large, Medium, Small. This is a configuration decision that takes five minutes and has a significant ongoing impact on how editors apply heading structure.
Remove Heading 1 from the body editor heading options. H1 is the page title and should be controlled at the template level, not selectable in body content.
Add Pre-Publication Accessibility Checklists
Most CMS platforms support adding custom help text or checklists to the content editing interface. Use this to surface a short pre-publication checklist at the bottom of the editing form — five to eight items that editors confirm before submitting content for publication.
Phase 6: Content Migration
If the new site is replacing an existing site, content migration is one of the highest-risk accessibility phases. Migrated content often carries forward the accessibility failures of the old site — or introduces new ones during the migration process.
Audit Before Migrating
Before migrating any content, audit it. Identify which pages have structural accessibility failures — missing heading hierarchy, inaccessible tables, images without alt text — and remediate them before migration, not after. Migrating broken content into an accessible template produces an accessible template with broken content inside it.
Document Inventory and Classification
Before migrating documents, inventory every PDF and downloadable file. Classify each document by type (active service forms, meeting documents, regulatory publications, archival content) and by accessibility status (fully tagged, untagged, scanned). Create a remediation queue prioritized by document type and traffic volume. Establish a going-forward standard for new document creation and upload.
Establish Accessible Content Standards Before Editors Touch the New CMS
Before a single content editor logs into the new CMS and starts creating or migrating content, the accessible content publishing standards should be distributed, the training should be complete, and the quick reference cards should be at workstations. The new site should never have a period where editors are creating content without understanding the standards.
Phase 7: Pre-Launch Validation
Pre-launch validation is not the first accessibility check — it is the final one. By the time a site built following this guide reaches pre-launch, most accessibility failures will already have been caught and addressed during component development and CMS configuration testing.
Pre-launch validation should confirm:
Full site automated scan. Run axe DevTools or an equivalent tool across every page template and content type. Address any failures that were not caught during component-level testing.
Keyboard navigation testing of all transactional workflows. Every form, every application, every payment flow — completed end to end using keyboard only. This is the test that catches the failures automated scanning misses.
Screen reader testing of primary templates and workflows. Test with NVDA on Chrome and VoiceOver on Safari. Focus on the navigation, primary content templates, and all interactive components.
Document accessibility verification. Spot-check the document library. Confirm that documents created and uploaded using the new standards are accessible. Confirm that the pre-upload checklist is being used.
Third-party integration testing. Test every embedded vendor tool for keyboard operability and screen reader compatibility. Confirm that accessible alternative pathways are working for any vendor tool with known accessibility gaps.
Accessibility statement review. Confirm the accessibility statement is published, current, accurate, and the complaint contact is monitored.
Phase 8: Accessibility Governance Handoff and Compliance Program
The governance handoff is what separates a compliant website from a compliant program. It is the last phase of the project and the one most frequently cut when timelines compress.
Do not cut it. Everything before this phase produces a compliant site on day one. The governance handoff determines whether it is still compliant on day 180.
The governance handoff deliverables:
A remediation log initialized with any known issues identified during pre-launch testing. A monitoring program scheduled and active — the first automated scan should run on launch week.
An accessibility policy formally adopted by the relevant authority.
An accessibility statement published and linked from the footer of every page.
Editor training completed for all content-creating roles with attendance documented.
Accessible content publishing standards distributed in writing to all editors.
A complaint intake process defined, the contact monitored and tested, and the process documented.
An executive reporting template created with the first quarterly report scheduled.
Vendor VPAT documentation filed for all embedded third-party tools.
A defined program owner named and responsible for the ongoing governance program.
The governance handoff is a contractual deliverable. It should be in the project scope, in the timeline, and in the acceptance criteria. A site that launches without these elements in place has not been delivered completely.
Related:
How to Write Alt Text for Government Images, Charts, and Maps
How to Audit Your CMS for Accessibility
How to Train Your Government Staff on Accessibility
FAQ: Building an Accessible Government Website From Scratch
When in a government website build should accessibility testing begin?
Accessibility evaluation should begin before any code is written — in the design phase when color palettes, typography, and component patterns are being established. Color contrast requirements, focus indicator design, and color independence are design decisions that are far less expensive to get right during design than to fix after development. During the build phase, every component should be tested for keyboard operability and screen reader compatibility before it is accepted into the component library. Pre-launch testing is the final validation — not the first check.
What are the most important accessibility decisions in a government website build?
The decisions with the highest impact are the component library architecture (every component built correctly once is accessible everywhere it is used), the CMS configuration for accessible publishing (alt text requirements, semantic heading selectors, document upload guidance), the navigation design (skip links, keyboard-operable dropdown patterns, landmark region structure), and the governance handoff (training, publishing standards, monitoring program, remediation log). Getting these right produces a system that creates accessible content by default. Getting them wrong produces a site that requires constant remediation to maintain compliance.
How should accessibility requirements be written into a government website RFP?
The RFP should specify WCAG 2.1 Level AA conformance as a technical requirement, require keyboard and screen reader testing as part of the component development process (not only at project completion), require an accessibility conformance report as a launch deliverable, and ask vendors to specifically describe their accessible development process, their CMS configuration approach, and their governance handoff deliverables. Generic accessibility language in an RFP produces generic accessibility commitments in proposals.
What CMS configuration decisions most affect ongoing accessibility compliance?
The highest-impact CMS configuration decisions are: making alt text required on image fields rather than optional, configuring heading selectors to display semantic level names rather than visual size names, removing or restricting formatting options that editors commonly misuse to create visual structure without semantic meaning, and adding pre-publication accessibility guidance at the point of content creation. These configuration decisions make accessible publishing the default behavior rather than the exception that requires extra editor effort.
What should the governance handoff include at the end of a government website build?
The governance handoff should include: a remediation log initialized and active, a monitoring program scheduled with the first scan run, an accessibility policy formally adopted, an accessibility statement published with a monitored complaint contact, role-specific editor training completed with attendance documented, accessible content publishing standards distributed in writing, a complaint intake process documented and functional, an executive reporting template created, vendor VPAT documentation filed for all embedded tools, and a named program owner with defined responsibilities. A site that launches without these elements will begin regressing immediately.
How long does it take to build an accessible government website from scratch?
Timeline depends on site complexity, team size, and the number of unique page templates and components required. What the accessibility requirements add to the timeline is primarily front-loaded — additional time during design for contrast evaluation and component specification, additional time during development for keyboard and screen reader testing of each component. This front-loaded investment is significantly less expensive than the post-launch remediation that results from not making it. The governance handoff adds time at the end of the project that most timelines do not currently account for — but that time is essential to producing a durable compliance program rather than a compliant website that regresses.