Public Sector Website Requirements. Everything in one checklist.

The obligations on a public-serving website are spread across accessibility standards, records law, language-access rules, security expectations and your own procurement policy. This pulls them into a single list you can work through before writing a specification, and hand to a committee that needs to understand why the project costs what it costs.

We grow your business with

CROturn traffic into leads
SEOrank & get found
GEOwin generative search
AEOget cited by AI answers

How to use this

A specification input, not a compliance certificate

This is a working checklist drawn from the requirements that recur across public-sector and nonprofit web projects. It is not legal advice, and the specifics vary by jurisdiction, funding source and organization type — a federally funded housing authority, a city clerk's office and a 501(c)(3) all carry a different mix.

Use it two ways. Before you write a specification, work through it and note which items apply to you, because each one that does is a line in the budget. After you receive proposals, use it to check whether a vendor priced the requirements or quietly omitted them — our guide to evaluating proposals covers what omission looks like.

1

Accessibility

The most frequently specified requirement and the most frequently underpriced.

✓
A named standard — WCAG 2.2 AA is the current sensible baseline, and it clears Section 508
✓
Verification described, not just asserted: automated testing plus manual keyboard and screen-reader passes
✓
Key journeys tested specifically — apply, pay, register, contact, donate
✓
Documents assessed, not exempted; scanned PDFs are images and unreadable to a screen reader
✓
Video captioned, including meeting recordings
✓
Accessibility guidance for content editors, so conformance survives the first year
✓
A published accessibility statement with a working contact route for complaints

2

Records, retention and the archive

The requirement most often discovered after launch, when the archive has already broken.

✓
Every existing URL resolves after launch, or redirects permanently to a real destination
✓
A redirect mapping document delivered and reviewed before go-live
✓
Agendas, minutes, notices, budgets and annual reports remain findable and searchable
✓
Retention obligations identified before any content is archived or removed
✓
Meeting materials structured rather than dumped into an ever-growing PDF list
✓
Public-records request routes clearly published and reachable

3

Language access and plain language

✓
The languages your community actually uses identified from real data, not assumption
✓
Translation approach decided per content type — machine translation is weakest exactly where accuracy is legally significant
✓
Critical service pages written in plain language and tested for scanability on a phone
✓
Translated content maintained on the same cycle as the source, not translated once and abandoned

4

Security, hosting and continuity

✓
HTTPS everywhere, with certificate renewal automated and owned by a named party
✓
Patching schedule for the CMS and its dependencies, with a responsible owner
✓
Backups with a tested restore procedure, not just a backup that exists
✓
Uptime monitoring with alerts routed to someone who will act on them
✓
An emergency publishing path that works when the main site is under load
✓
Accounts registered to the organization, never to an individual or the vendor

5

Findability and answer accuracy

✓
Every core fact — hours, fees, deadlines, eligibility — with a single source on the site
✓
Structured data for hours, locations, services and events
✓
Content out of images and PDFs where residents need to read it
✓
Real review dates on the pages carrying the facts people ask about most
✓
External listings consistent with the site, so assistants are not reconciling conflicting sources

6

Procurement and handover

✓
Scope broken into separately priced line items so bids are comparable
✓
Page and document counts stated, from an actual crawl
✓
Ownership of code, content and accounts stated, and not conditional on a support contract
✓
Handover documentation named as a deliverable, with acceptance criteria
✓
Training for named staff, recorded so it outlives the trainer
✓
Post-launch support scope and duration stated explicitly

Go deeper

Guides for each section

Blog

WCAG 2.2 AA Checklist for Government and Nonprofit Websites

Read article →Blog

Website Migration Checklist for Government and Nonprofit Sites

Read article →Blog

Why Website Handover Documentation Matters

Read article →Blog

GEO for Government Websites

Read article →Blog

How to Write a Government Website RFP

Read article →

Project Managers who will work with you on your project!

David Geder
David Geder
Irina Shvaya
Irina Shvaya
Benjamin Gunther
Benjamin Gunther
Jeanette Mordvinov
Jeanette Mordvinov
Mark Shvaya
Mark Shvaya

Wondering what this costs? Every service has published pricing — no discovery call required to see it.

View pricing

Want this reviewed against your actual site?

Send us the URL and we will tell you which of these you already meet and which you do not, before you commit anything to a specification.

Book a Strategy Call →