When a resident visits your city’s website, it’s usually to do one specific thing — pay a water bill after work, find tomorrow’s council agenda, report the pothole that just ate a tire. They can’t take their business to a competitor; the city is the only place to do it. Yet most small-city websites make these errands harder than they should be: aging CMS platforms, buried PDFs, tiny tap targets, and accessibility failures that — as of April 2026 — are no longer just bad service but a federal compliance problem. I built the City of Pawnee demo site, a complete website for a fictional Indiana city of 66,218, to demonstrate the alternative. Every technique in this paper is running on the demo right now, and every claim about it was verified with tooling, not asserted.
1. The stakes: why a city’s website is different
A municipal website carries obligations no business site does:
- Accessibility is now a federal mandate with a date on it. The Department of Justice’s 2024 rule under ADA Title II requires state and local government web content to conform to WCAG 2.1 Level AA — by April 2026 for jurisdictions of 50,000 or more, and April 2027 for smaller ones. This is no longer guidance; it is regulation. Meanwhile the WebAIM Million study still finds detectable accessibility failures on roughly 96% of top homepages.
- Residents have nowhere else to go. A private customer who can’t use your site shops elsewhere. A resident who can’t use the city’s site simply doesn’t get the service — or crowds your phone lines and counter staff instead.
- Local government is a ransomware target. Cities and counties are now among the most attacked organizations in the country (CISA, Sophos), and the traditional municipal CMS — database, plugins, admin logins — is exactly the attack surface those campaigns look for.
- Transparency is the law. Open-meetings acts mean agendas, minutes, and notices aren’t nice-to-haves — they are statutory obligations the website either makes easy or makes risky.
- Trust is the product. The website is city hall’s front counter. If it looks abandoned, residents assume the government is too.
2. The technology under the hood
The demo is built on Next.js with React and TypeScript — the same framework behind sites like Nike and OpenAI — styled with Tailwind CSS:
- Static-first architecture. All 53 pages are pre-rendered to plain HTML at build time — no database, no plugins, no CMS admin login to phish, no patching treadmill. There is nothing running on a server at 2 a.m. for an attacker to exploit, and pages load near-instantly even on rural cell connections.
- Every fact lives in typed, validated content files. Departments, staff, meetings, news, events, alerts, and ordinances are plain data files checked by schema validation on every build — a malformed entry fails the build instead of quietly breaking the homepage. Content edits never touch layout code, and the model is ready to swap behind a content-management interface for clerk self-service.
- An automated content audit runs before every build. For this demo it screens fictional data; for a real city, the same gate can enforce style rules, banned phrases, or stale-date checks — automatically, forever.
- Resident privacy by design. No trackers, no analytics cookies, no third-party scripts, no consent banner needed — the privacy posture a government should model. Demo service flows process entirely in the browser and transmit nothing.
- Verified as it ships. Lighthouse audits on this build: Accessibility 100, Best Practices 100, SEO 100 on every page tested, with layout shift of exactly zero. (Performance measured 81–88 on a local development workstation under Lighthouse’s simulated mid-range-mobile throttling; static pages on production CDN hosting score higher, and the project’s stated budget is 95+.)
3. ADA & accessibility: engineered, then verified
The site was built to WCAG 2.1 AA — the exact standard the DOJ rule names — as a hard requirement, then verified:
- Lighthouse Accessibility: 100/100 on every page audited.
- The color system is contrast-engineered at the source. Every approved text/background pairing in the design palette meets or beats AA ratios — the civic navy on white measures 10.7:1, the harvest-gold pairing 9.4:1 — with the math documented in the stylesheet itself, so contrast can’t regress page by page.
- Keyboard-verified: a skip-to-content link is the first Tab stop; the desktop mega-menu, mobile drawer, dialogs, and accordions all follow WAI-ARIA patterns — reachable, operable, and escapable without a mouse, with a visible 3px focus ring throughout.
- Public-notice banners that don’t rotate themselves. Emergency and advisory alerts use manual next/dismiss controls — no auto-rotating content — and every severity color pairing is contrast-checked.
- Forms that speak. Persistent visible labels, errors announced to assistive technology and described to the field, correct mobile keyboards, and multi-step flows that move focus and announce progress.
- The calendar works two ways: a month grid rendered as a real, labeled table for visual scanning, and an equivalent list view — the pattern that keeps calendars usable with a screen reader.
- Reflow verified at 320px with zero horizontal scrolling; reduced-motion preferences honored; tap targets 44×44px or larger; and a published accessibility statement page written as the model I’d give any client.
4. Built for a resident on a phone
The design assumes the resident is on a phone, in a hurry:
- The home page leads with a quick-action grid — pay a bill, report an issue, trash schedules, meeting agendas — because analytics on real municipal sites show that’s nearly all anyone comes for.
- Mobile-first layout verified from 320px up — no horizontal overflow at any width; the header keeps Pay Online and Contact one tap away.
- Pages are static HTML with optimized images (the full-width City Hall hero transfers roughly 30 KB on a phone), so they load fast on weak connections — and layout shift is zero, so nothing jumps out from under a tapping thumb.
- Every interactive control works by touch, keyboard, and screen reader alike.
5. Resident self-service, modeled end to end
The demo doesn’t show a brochure — it shows the errands, working:
- Pay Online: utility bills, court fines, and permit fees, with accessible validation and honest demo confirmations (nothing is stored or transmitted).
- Report an Issue: a four-step categorized intake form — category, location, description, contact — with per-step validation, focus management, and a tracking-number confirmation pattern.
- Trash & utilities: address-based collection-day lookup, service start/stop, and holiday-shift rules.
- Text alerts: topic-based signup modeled on real municipal notification systems.
- Forms & permits, FAQs, voter information: categorized, searchable, and written in plain language.
6. Transparency by default
- Agendas & minutes: a filterable public-meetings table — body, date, agenda, minutes, video — the record-keeping pattern open-meetings laws expect.
- Municipal calendar: meetings and civic events in one place, month or list view.
- Searchable ordinances, a filterable staff directory with every employee’s title, extension, and email, and a press-release news section — plus sitewide search (Ctrl+K) across pages, people, news, and events.
- Plain, earnest municipal voice throughout — short sentences, no jargon, written for the resident, not the org chart.
The typical municipal CMS site vs. this build
| Measure | Typical small-city website | The Pawnee demo build |
|---|---|---|
| Platform | Vendor CMS: database, plugins, admin logins to defend | Static Next.js — no database, plugins, or admin login to attack |
| ADA / WCAG | Overlay widget or unverified claims; ~96% of homepages have detectable failures (WebAIM) | WCAG 2.1 AA engineered in; Lighthouse Accessibility 100 on every audited page; keyboard-verified |
| Contrast | Template defaults, unmeasured | Every approved pairing measured (10.7:1 primary); ratios documented in the stylesheet |
| Mobile | Responsive theme, unverified | Verified from 320px; zero horizontal scroll; zero layout shift |
| Speed | CMS render on every request | Pre-rendered static pages; ~30 KB hero image on mobile |
| Privacy | Analytics trackers; cookie banner | No trackers, no cookies, no consent banner needed |
| Content edits | Vendor ticket, or a risky admin panel | Typed content files validated on every build; CMS-ready model |
| Transparency | Agendas as buried PDFs | Filterable meetings table, calendar, searchable ordinances, staff directory, sitewide search |
| Hosting cost | Annual CMS licensing + hosting contract | Static hosting — little to nothing, with preview deployments per change |
7. What this means for your city
- If your compliance deadline was April 2026 — or is April 2027: this is what conformance actually looks like: engineered into the design system, verified on every build, with results you can hand to counsel.
- If a resident uses a screen reader, a keyboard, or a ten-year-old phone: they pay the bill and find the agenda like everyone else — that’s the point of the mandate, and of the build.
- If the clerk needs to post Tuesday’s agenda or a boil-water notice: it’s a data-file edit that cannot break the layout — not a vendor ticket.
- If the next ransomware wave hits your county: a static site has no CMS admin panel to phish and no database to encrypt.
- If it’s budget season: static hosting costs pennies, and the security patching line item largely disappears.
8. The build path
- Discover. Map your departments, services, and records obligations into a resident-first information architecture — the errands on top, the org chart underneath.
- Brand. Your seal and colors, contrast-engineered to meet WCAG AA without losing the identity.
- Build. Static-first stack; every department, meeting, and notice in validated content files; plain-language copy.
- Verify. Automated accessibility, responsive, and performance audits on every build, with documented results — evidence you can file, not promises.
- Launch. Low-to-no-cost static hosting with preview deployments for every change — and a clear path to clerk self-service via a content-management layer when you want it.
Sources
- U.S. Department of Justice — Final Rule, Nondiscrimination on the Basis of Disability: Accessibility of Web Information and Services of State and Local Government Entities (28 CFR Part 35, April 2024).
- Centers for Disease Control and Prevention — Disability Impacts All of Us.
- StatCounter Global Stats — mobile vs. desktop market share.
- WebAIM — The WebAIM Million (annual accessibility analysis).
- CISA and Sophos — reporting on ransomware targeting state and local government.
- Parker Technology Solutions — build and verification records for the City of Pawnee demo site, including Lighthouse audit runs (July 2026).