What a small city or municipal website should include

What should a small city or municipal website include?

A small city website should be built around the handful of things residents actually arrive to do: pay a bill, report a problem, find a schedule, apply for a permit, follow council, and reach a human. Organize the site around those tasks, write it in plain language, and hold it to WCAG 2.2 AA.

Here is the pattern I see on civic sites of every size. The navigation mirrors the organization: Corporate Services, Development Services, Engineering and Operations, Community Services. That structure is completely correct on an internal chart, and completely useless to a resident standing in their kitchen trying to work out who takes a report about a loose dog before the school bus comes.

Residents think in verbs. Pay. Report. Apply. Book. Attend. Find out. Every extra guess between the verb and the answer becomes a phone call to the front counter, and the front counter is the most expensive search engine a municipality owns. So the site gets built around the verbs, and the departments become the supporting layer underneath.

• The top tasks one tap from the home page: pay a bill, report a problem, apply for a permit, register for a program, book a facility, find the next council meeting.
• Plain-language service pages that answer the question without making a resident learn a department name, a bylaw number, or the name of the software behind the counter.
• One permanent, obvious home for advisories, closures, and public notices, so the habit of checking it gets built during the calm months.
• Request forms that route by what happened, so a resident describes the problem in their own words and the right desk receives it.
• Council agendas, minutes, budgets, and bylaws on findable pages, with the filed document attached where a document is genuinely the record.
• Accessibility to WCAG 2.2 AA: keyboard paths, real contrast, captions, readable headings, and a working way for a resident to report a barrier.

What does a municipal website actually have to do?

A civic site has six jobs: answer the resident's task in the first screen, speak in the words residents use, route requests by what happened, carry public notices faster than rumour travels, show the council's work openly, and clear accessibility barriers on purpose. Design that does not serve those six is decoration on public infrastructure.

1. 01

   Answer the task, in the first screen

   A resident arrives holding one job: pay before the tax due date, find out whether the water is safe, get a pet licence, check the pool schedule. The home page earns its keep by putting the ten most common jobs where a thumb can reach them, in the words residents use for them.

2. 02

   Speak the resident’s language

   Staff say "development variance permit" and "corporate officer" because those are the correct terms inside the building. A resident says "can I build a shed" and "who do I send this to". Both can be true on the page: the plain sentence first, the exact legal term named right beside it.

3. 03

   Route the request by what happened

   Most people cannot name the department that handles a loose dog, a pothole, a broken streetlight, or an overflowing bin. So the intake path should ask what happened, then carry the answer to the right queue. That single change cuts misdirected reports and front-counter phone calls at the same time.

4. 04

   Make the public notice outrun the rumour

   A boil-water advisory, a road closure, a wildfire evacuation alert, a public hearing date. In the Kootenays these land every year, and they land fast. One stable page that residents, local radio, and the community Facebook group can all point at beats any amount of scattered news posts.

5. 05

   Show the council’s work

   Agendas, minutes, recordings, budgets, bylaws, and hearing notices are the public record of how decisions got made. When they are organized so a resident can follow one issue from first report to final vote, the whole council reads as competent, and questions arrive better informed.

6. 06

   Clear the barriers, on purpose

   A meaningful share of residents rely on screen readers, captions, keyboard navigation, high contrast, or plain text. Local governments are among the public sector organizations covered by the Accessible British Columbia Act. A page that locks someone out of a tax payment is a failed public service.

The front counter is the most expensive search engine a municipality owns. Every unanswered question on the site gets asked out loud, at staff wages.

Org-chart website vs. resident-first website

An org-chart site organizes information the way the municipality is organized, so residents have to understand the structure before they can get help. A resident-first site organizes around tasks, and the departments live underneath as supporting pages. The difference shows up in call volume, in misdirected reports, and in how competent the whole municipality feels.

None of this is a criticism of municipal staff. Most civic sites were shaped by a procurement cycle, a locked template, and a decade of well-meant additions, each one reasonable on its own. The structure drifted toward the org chart because that is the map everyone inside the building already has in their head. Closing the gap is mostly about starting from the resident's question and working backwards.

What does each hub of a civic site do?

A municipal site needs a small number of hubs, each with one clear job: home carries the top tasks, services carries the transactions, government carries the record, planning carries the applications, reporting carries the problems, notices carry the urgent, support carries the people who need help most, and contact carries the humans.

Home

Ten top tasks, the current notice, and the next council meeting, above anything decorative. If a resident has to scroll past a photo of the valley to find "pay a bill", the photo is doing the wrong job.

Services

The pay, apply, report, register, and book paths gathered in one hub, sorted by how often residents need them. Property taxes, utilities, pet licences, business licences, recreation registration, facility bookings.

Government and council

Meetings, agendas, minutes, recordings, budgets, bylaws, policies, elections, and reports, arranged so a resident can follow one topic through the process without knowing internal language.

Planning and permits

Building permits, inspections, development applications, zoning questions, and business licences, each with a plain-language page explaining who needs it, what it costs, and what happens after you apply.

Report an issue

One front door for problems, branching by category into forms that capture what staff actually need. The animal concern, the pothole, the water leak, the bylaw complaint, and the streetlight all start in the same place.

Notices and alerts

Advisories, closures, evacuation information, statutory public notices, and hearing dates, on a permanent URL that never moves. Signup routes into whatever alert system the community already runs sit on the same page.

Support hub

Crisis lines, housing, food, mental health, seniors, youth, newcomers, Indigenous resources, warming and cooling centres. These get first-class paths, because the residents who need them are the least able to hunt for a footer link.

Contact and staff

Real departments, real people, real phone numbers, and a stated response time. The form should be one route among several, and the page should say what happens after someone sends it.

This is the structure behind City of Silvermere, a full municipal concept I built for a fictional city to show the approach: 175 routes covering services, government, planning, community, notices, documents, requests, payments, and a support hub, all organized around what residents arrive to do. It is a concept build, so nothing in it represents a real municipality, real residents, or a real council. It exists so a council can walk the whole structure before commissioning anything.

How do you rewrite bylaw and permit content in plain language?

Lead with the plain sentence, name the exact legal term right beside it, then link the bylaw or filed document as the record. A resident finds out whether they need a permit for a shed in ten seconds, and the person who needs precise wording is one click away. Nothing gets dumbed down and nothing gets hidden.

The fear I hear from corporate officers is reasonable: simplify the language and the legal precision goes with it, then a resident acts on a summary that does not match the bylaw. That risk is real, and the fix is layering. The page answers the question a resident asked. The paragraph underneath names the bylaw, the section, and the official term. The document sits beside it as the authority. All three are true at once, and the resident chooses how deep to go.

A worked example. A page titled "Building permits" that opens with "You need a building permit for most new construction, additions, and structural changes, including a shed over the size limit in the zoning bylaw" tells a resident more in one line than a page of application procedure. Then comes the size limit, the fee, the form, what happens after you apply, and how long inspections usually take. Then comes the bylaw itself, named and linked.

Two habits carry most of the improvement. Write the sentence you would say across the counter, then check that the page uses the resident's word for the thing at least once before the official one. And put the number people phone about, the fee, the deadline, the size limit, on the page in text where search can find it.

How should service requests and reports be handled?

Give residents one report-an-issue front door that branches by what happened, then let each category open a form capturing exactly what staff need. A resident reporting a loose dog should never have to work out which department owns animal control. Category-aware routing means fewer misdirected reports, cleaner intake, and far fewer calls asking where a report went.

The general contact form is where municipal intake usually breaks. Everything lands in one inbox, half the reports are missing the address or the photo staff needed, and someone has to triage manually before any work order exists. The resident hears nothing for a week and phones to ask.

The fix is a single entry point with real categories behind it: animal concerns, road and sidewalk issues, water and sewer, streetlights, bylaw complaints, parks and facilities, garbage and recycling. Each category opens a short form that asks only what that category needs. The animal concern asks for a description of the animal, the location, and whether anyone was hurt. The pothole asks for the nearest address and a photo. Staff receive a complete report already pointed at the right desk.

Two details make residents trust it. Tell them on the form what happens next and roughly when, then send a confirmation that repeats what they submitted. That confirmation prevents the follow-up phone call more reliably than any amount of navigation work, because the anxiety it removes is the anxiety of not knowing whether the message landed.

A realistic before and after

Illustrative composite. No specific municipality, no invented numbers. The point is the shape of the change.

What accessibility standard should a municipal website meet?

WCAG 2.2 Level AA is the recognized benchmark and the standard I build to. Local governments in this province are among the public sector organizations covered by the Accessible British Columbia Act, so accessibility belongs in the foundation. In practice: keyboard access to every task, real contrast, captions on council recordings, readable headings, and a working way to report a barrier.

Accessibility on a civic site carries a weight it does not carry on a commercial one. A restaurant with an unusable menu page loses a booking. A municipality with an unusable tax payment page has excluded a resident from a service they are legally required to use, and there is no competitor down the road for them to switch to. That is why it goes in the foundation of the build, and why the claim on my builds is always the specific one: WCAG 2.2 Level AA.

The criteria that bite hardest on civic sites are the ordinary ones. Forms that announce errors in plain words. Focus that stays visible when someone tabs through a payment path. Contrast that survives a bright screen outdoors. Captions on the council recordings, which double as a searchable record of what was said. Headings in an order that lets a screen reader user skim a bylaw page the way a sighted reader skims it. I wrote the longer version of this for every kind of organization in the guide on website accessibility and WCAG in Canada.

One honest caution about vendor language. "Fully accessible" and "100% compliant" are claims nobody can support, because accessibility is measured against specific criteria and tested with real assistive technology. Ask any vendor which version and which level, ask how it was tested, and ask what the feedback route is when a resident finds a barrier anyway. A vendor who answers those three questions plainly is worth talking to.

Why do buried PDFs fail residents?

A PDF three clicks deep fails on four fronts at once: it is awkward on a phone, a scanned one is unreadable by assistive technology, most exports were never tagged for screen readers, and changing one line means a full re-export. The answer belongs on a web page, with the filed document beside it where the filed version genuinely is the record.

1. 01

   A PDF is a chore on a phone

   It opens in a viewer, it does not reflow, and the resident is now pinching and dragging a letter-sized page on a five-inch screen. Most municipal traffic is mobile, which means the format fights the majority of the people using it.

2. 02

   A scanned PDF is a picture of text

   If a bylaw was scanned from paper, nothing inside it is selectable, searchable, or readable by assistive technology. It looks like a document and behaves like a photograph, and the resident who needs it most is the one who cannot get in.

3. 03

   Screen readers need tagging most files never got

   An accessible PDF requires a proper tag tree, reading order, alternative text, and language settings. Very few municipal exports have any of that, so a file that passes a visual glance can still be unusable with a screen reader.

4. 04

   One changed line means a whole re-export

   Fees go up, a phone number changes, a program moves. On a page that is a two-minute edit. In a PDF it is a round trip through whoever holds the source file, so the outdated version stays live for months.

The rule I use is simple. If a resident needs an answer, that answer is a web page: the fee, the deadline, the eligibility, the process, in text. If the municipality has a duty to publish a document as filed, a bylaw, a set of minutes, a signed report, an audited statement, that document sits beside the page as the authority. The page gets found and read. The document gets cited.

Where a PDF has to carry information on its own, it needs the same care as a page: real selectable text, a tag structure, a document title, alternative text on figures, and headings a screen reader can navigate. That work is not free, which is another argument for keeping the answer in HTML and reserving the document for the record.

Where should a small city start?

Start with the twenty questions the front counter answers by phone every week. That list is the real navigation, it costs nothing to collect, and it will disagree with the current menu structure almost immediately. From there the order is: top task pages, one plain-language rewrite, category-aware intake, then the accessibility pass.

1. 1Write down the twenty things the front counter answers by phone every week. That list is your real navigation, and it costs nothing to collect.
2. 2Turn the top ten into their own pages, each one leading with the answer in a sentence a resident would say out loud, then the detail, then the form or payment link.
3. 3Rewrite one permit page and one bylaw page in plain language, keeping the exact legal term and the filed document beside the plain sentence so nothing is lost.
4. 4Rebuild intake as a single report-an-issue path that branches by category, so residents describe what happened and staff receive a complete, correctly routed report.
5. 5Run the accessibility pass to WCAG 2.2 AA: keyboard through every task, check contrast and heading order, caption the council recordings, and publish a working route for reporting a barrier.

Phasing is what makes this affordable for a village office or a regional district working inside a budget cycle. The notices centre and the top resident tasks can go live long before the document library is finished. Council records, payments routing, and the support hub follow as the budget allows. Each phase stands on its own and none of it needs the whole project approved at once, which is also how it survives a council term.

What does a municipal website cost?

Municipal work is a scoped build, so the number follows the service list. Resident task architecture, a notices and alerts centre, council records, payments routing, plain-language rewriting, and WCAG 2.2 AA accessibility all carry real hours. At Kootenay Made Digital this is Empire scope, from $15,000, quoted against your actual services and billed by milestone.

What moves the number is the size of the service list, the volume of documents that need a home, how many systems the site has to route into for payments and alerts and recreation registration, and how much existing content needs a plain-language rewrite. Empire projects are quoted and staged directly, delivered in phases from eight weeks, with the full number on the table before anything starts. The full picture of how I approach civic work, including FOIPPA and procurement notes, lives on the municipal website design page.

Two starting points, depending on where your community is today. If the municipality has no usable public site, or the current one is past rescuing, that is a build from the ground up, and The Empire is the tier it lands in; a note through the contact page is enough to start the conversation. If you have a site that mostly works and you want to know where residents are getting stuck, the free 60-second check-up is the cheaper first move, and it will usually surface the org-chart navigation and the buried documents inside a minute.

Weigh the rebuild against what the current site already costs every week: the phone calls the front counter fields, the reports that arrive at the wrong desk, the advisory a resident never saw, and the quiet erosion of trust that happens every time an accurate municipality looks disorganized. A site organized around what residents came to do is one of the cheapest credibility instruments a council has.

Sources and further reading

• W3C: WCAG 2.2 quick reference

  The success criteria behind a WCAG 2.2 AA claim, including the target size, focus appearance, and consistent help criteria that landed in 2.2 and matter on civic forms.

• W3C WAI: WCAG 2 overview

  What the levels A, AA, and AAA actually mean, which is worth reading before any vendor tells a council their template is "fully accessible".

• Google Search Central: creating helpful content

  People-first usefulness is the same standard a resident applies: can I tell what this page is for, and can I finish what I came to do?

• Google Search Central: SEO starter guide

  Clear titles, sensible headings, and real HTML pages are how a bylaw or a notice becomes findable when a resident searches for it by name.

Frequently asked questions