A practical guide to local government website design for Australian councils and shires. Accessibility, procurement, CMS handover, security, and the questions to ask vendors before you sign.
If you manage communications or IT for a council, you already know the problem with your website. Residents cannot find bin collection days without three clicks and a PDF. The events calendar is maintained in a system nobody in the office fully understands. And the last redevelopment was scoped by a vendor who has since stopped returning emails. Local government website design is a different discipline from commercial web design, and treating it as the same job is how councils end up back at square one within four years.
This guide covers what actually matters in a council website redevelopment: the accessibility obligations you cannot negotiate away, how procurement realities shape your vendor shortlist, how to structure community services information so residents find things, and what a proper CMS handover looks like. It is written for the person who has to write the brief, evaluate the quotes, and live with the result.
If you are at the earlier stage of working out what is wrong with your current site, a structured website audit will give you an evidence base for the business case before you approach vendors. And if you want to see how we approach builds generally, our web design page explains the process.
TL;DR
- Australian government websites are expected to meet WCAG 2.2 AA accessibility standards, and the Disability Discrimination Act 1992 applies to council websites just as it does to physical services.
- Council website procurement is shaped by quote and tender thresholds set in each state's local government regulations, so scope your project with those thresholds in mind from day one.
- The biggest usability failure on council websites is information architecture organised around council departments instead of resident tasks like rates, waste, permits, and facilities.
- Insist on a full CMS handover: admin access, documented workflows, staff training, and no critical task that requires paying the vendor to publish a page.
- Security and hosting expectations for councils include Australian data residency, SSL, regular patching, backups, and a clear incident response arrangement in the contract.
- Evaluate vendors on government and institutional experience, accessibility evidence, and exit terms, not just the visual design in the pitch deck.
Why council websites are a different job
A commercial website has one job: turn visitors into enquiries. A council website has hundreds of jobs. It has to tell a resident when their green waste is collected, help a builder find the planning scheme, publish agendas and minutes because the law says so, take payments for rates and pet registrations, and stand up as the official information channel during a bushfire or flood.
That breadth is why council sites drift into chaos. Every department adds pages, nobody deletes anything, and after six years the site is an archive that happens to have a homepage. More than 500 local government areas across Australia face some version of this problem. A redevelopment is your one chance every five to eight years to reset the structure. The rest of this guide is about spending that chance well.
Accessibility is the non-negotiable
Start here, because everything else is negotiable and this is not. Council websites serve everyone in the local government area by definition: older residents, people using screen readers, people with low vision, motor impairments, or cognitive disabilities, and people on slow regional connections. Accessibility for a council is not a nice-to-have. It is the core service standard.
The practical benchmark in 2026 is WCAG 2.2 Level AA, the current version of the Web Content Accessibility Guidelines. Australian governments have referenced WCAG conformance as the expectation for public sector websites for well over a decade, and the Disability Discrimination Act 1992 applies to services delivered online. A council website that a screen reader user cannot operate is a compliance risk as well as a service failure.
What WCAG 2.2 AA means in practice for your project:
- Keyboard operability. Every menu, form, and payment flow must work without a mouse.
- Colour contrast. Text needs sufficient contrast against its background, which rules out a lot of fashionable low-contrast design.
- Meaningful structure. Proper headings, labels, and landmarks so assistive technology can navigate the page.
- Accessible forms. Clear labels, error messages that explain the fix, and no CAPTCHA that blocks assistive tech.
- Accessible documents. This is the one councils underestimate. A perfectly accessible website wrapped around hundreds of scanned PDFs still fails residents. Your redevelopment should include a policy for HTML-first content, with PDFs as the secondary format, not the primary one.
Ask every vendor two questions: which WCAG 2.2 AA success criteria they test against, and whether they conduct testing with actual assistive technology rather than just automated scans. Automated tools catch a minority of accessibility issues. A vendor who cannot name their testing process has not done this work before.
Be the business AI recommends
Procurement realities: quotes, panels, and tenders
Council website projects live inside procurement rules, and pretending otherwise wastes everyone's time. The specifics vary by state, but the shape is consistent everywhere:
- Low-value work can usually be engaged directly or with a small number of verbal or written quotes.
- Mid-range projects typically require multiple written quotes under your council's procurement policy.
- Above the tender threshold set in your state's local government regulations, you are running a public tender or buying through an established panel or prequalification arrangement.
Three practical consequences follow.
Scope shapes procurement path. A full redevelopment with design, development, content migration, and multi-year hosting can cross the tender threshold once whole-of-life cost is counted. Some councils split the project into honest stages (discovery and IA first, then build), which also produces a better brief. What you should not do is split a single project artificially to duck the threshold. Auditors notice.
Panels change your shortlist. Many councils buy through state government panels, regional procurement arrangements, or local government purchasing bodies. If your council uses one, find out early which web vendors are on it. There is no point falling in love with a studio you cannot legally engage without a full tender.
Whole-of-life cost is the real number. A quote that looks cheap on build cost and quietly loads the margin into mandatory hosting, licensing, and support over five years is not cheap. Require every quote to state total cost of ownership across the expected life of the site, including CMS licence fees, hosting, and a realistic support allowance.
Information architecture: organise around residents, not the org chart
Open ten council websites and you will find the same failure on seven of them: navigation that mirrors the council's internal departments. Residents do not know which directorate handles their problem, and they should not have to.
Good council information architecture starts from tasks. Analytics and search logs from almost any council site show the same top jobs: bin days and waste, rates payments, planning and building applications, pet registration, parks and facility bookings, local jobs, and reporting a problem like a pothole or dumped rubbish. Those tasks belong at the top level, in resident language.
Practical rules that hold up across council redevelopments:
- Top tasks get top billing. "Pay my rates", "Bin collection days", "Report a problem" belong on the homepage as direct actions, not buried under "Council services".
- Write in resident language. "Bin days", not "Waste management services". "Planning a renovation", not "Statutory planning". Your internal terminology is invisible to the people you serve.
- One page per answer. A single, canonical page for each service, maintained by one owner. Duplicated content across departments is how contradictory information ends up published.
- Community services need a directory pattern. Libraries, community centres, sport facilities, immunisation clinics, and support services work best as structured listings with consistent fields (location, hours, eligibility, contact), not as free-form pages each team formats differently.
- Emergency content gets its own plan. During a flood, fire, or outage, your website becomes critical infrastructure. The design must include a homepage alert pattern and an emergency page template that a comms officer can publish in minutes, from a phone, at 11pm.
Insist that your vendor runs a card sort or tree test with actual residents before locking the navigation. It is a small line item that prevents the most expensive category of mistake.
→ Free free AI SEO audit: see whether ChatGPT and Google AI recommend your business, and who they name instead. Run my free audit.
The CMS decision and what handover must include
The CMS matters less than vendors make out, and the handover matters more. Councils run successfully on open-source platforms like WordPress and Drupal, on government-focused SaaS products, and on commercial CMSs. What determines whether your team can actually run the site is the implementation and the handover.
Non-negotiables for the contract:
- Full administrative access. Your council owns the domain, the hosting account, the CMS admin, and the content. If a vendor proposes an arrangement where you cannot export your own site, keep looking.
- Editing workflows that match your team. Councils need draft, review, and approve steps, and role-based permissions so the library team can edit library pages and nothing else.
- Structured content types. News, events, facilities, meeting agendas and minutes, and public notices should be structured types with templates, not blank pages each officer lays out by hand. This is also what keeps the design and accessibility intact three years after launch.
- Real training, delivered twice. Once at launch for everyone, and a follow-up session six to eight weeks later once staff have hit real problems. Recorded sessions and written documentation, because your staff will turn over before the site does.
- No vendor toll gates on routine work. Publishing a page, adding an event, updating hours, and posting an emergency alert must all be doable in-house. If routine publishing requires a support ticket and an invoice, the site will decay, because busy staff stop bothering.
Security, hosting, and records expectations
Councils hold resident data, take payments, and are increasingly targets for exactly the kind of opportunistic cyber attacks that hit organisations with small IT teams and public profiles. Your website contract should address security explicitly, not as a line that says "secure hosting".
Reasonable expectations to write into the brief:
- Australian hosting and data residency for the website and any form submissions containing resident data.
- HTTPS everywhere, with certificates managed and renewed by the vendor or host, not by a calendar reminder in someone's inbox.
- Patching cadence. The CMS and its plugins or modules must be updated on a stated schedule, and the contract should say whose job that is.
- Backups and recovery. Automated backups with a stated recovery time. Ask the vendor when they last actually restored a site from backup, not whether backups exist.
- Payment handling by redirect. Rates and fee payments should hand off to your council's payment gateway or a compliant provider. Your website should never store card details.
- Incident response. A named contact, a response window, and an agreed process if the site is defaced or compromised. During an incident is the wrong time to discover your support agreement covers business hours in another time zone.
- Records obligations. Council websites publish agendas, minutes, and public notices that are records under state records legislation. Your CMS needs to handle retention and archiving rather than silently deleting superseded content.
Find out if AI recommends your business
We tested 151 top-rated Australian tradies and 84% were never named by ChatGPT. Check your business before your competitor checks theirs.
Tested: 151 top-rated Australian tradies · 15.9% named by ChatGPT · Q3 2026 study
Run my free audit →Content migration: the part everyone underestimates
Every council redevelopment brief says "migrate existing content". Every project that goes over budget goes over here. A council site that has grown for eight years typically carries thousands of pages and documents, and most of them should not survive the move.
Treat migration as an editorial project, not a copy job. Run a content audit early: what exists, what gets traffic, what is duplicated, what is legally required to remain, and what is simply old. Every page you delete is a page you do not pay to migrate, restructure, and make accessible.
Assign content ownership before the build starts. Every surviving page needs a named owner and a review date in the CMS. Without that, the new site starts decaying on launch day.
What a realistic budget covers
Council website redevelopments in Australia span a wide range, from modest rebuilds for small rural shires to six-figure programs for metropolitan councils with custom service integrations. Rather than anchoring on a number, anchor on what the money must cover: discovery and IA testing, accessible design and development, structured content types, migration of the content that earns its place, integration with payment and mapping systems where needed, training, documentation, and a support arrangement with named response times.
Be sceptical of quotes at both extremes. A quote far below the others usually means the vendor has not priced accessibility, migration, or training, and you will pay for them later as variations. A quote far above may be pricing enterprise infrastructure a smaller council does not need. The middle of the range, itemised transparently, is usually where the truth lives.
Questions to ask every vendor
Put these in your RFQ or ask them in the presentation. The answers separate government-capable vendors from commercial studios guessing:
- Which councils or government organisations have you built for, and can we speak to them? Reference checks with another council's comms manager are worth more than any case study.
- How do you test WCAG 2.2 AA conformance, and can we see an accessibility statement from a recent build?
- What is the total cost of ownership over five years, itemised?
- Who owns the domain, hosting, CMS licences, and content, and what does exit look like? Get the exit terms in writing before you sign, not when the relationship sours.
- Show us your emergency publishing workflow. Watch them publish an alert. Time it.
- What happens to support requests after launch? Named contacts, response windows, and what is included versus billable.
- How will you test the information architecture with our residents before building it?
For a deeper set, our guide to 25 questions to ask web designers before hiring covers the general-purpose questions that apply to any build, government or not.
Is ChatGPT naming you, or your competitor?
We tested 151 top-rated Australian tradies and 84% were never named by ChatGPT. Check your business before your competitor checks theirs.
Run my free audit →Frequently asked questions
What accessibility standard do Australian council websites need to meet?
The practical benchmark is WCAG 2.2 Level AA, the current version of the Web Content Accessibility Guidelines. Australian governments have long referenced WCAG conformance as the expectation for public sector sites, and the Disability Discrimination Act 1992 applies to services delivered online. Testing should combine automated scans with manual assistive technology testing, because automated tools only catch a portion of real issues.
How much does a council website redevelopment cost in Australia?
The range is wide, from modest rebuilds for small shires to six-figure programs for metropolitan councils with custom integrations. The more useful discipline is requiring every quote to state whole-of-life cost over five years, including CMS licensing, hosting, support, and training, and checking that accessibility work and content migration are itemised rather than assumed.
How long does a local government website project take?
A well-run council redevelopment typically takes six to twelve months from brief to launch, depending on scope, procurement path, and how much content migration is involved. Discovery, IA testing, and content auditing take longer for councils than for commercial sites because of the volume of services and stakeholders, and rushing those stages is the most common cause of a failed result.
Should councils use WordPress, Drupal, or a government-specific CMS?
Any of them can work, and councils run successfully on all three. The decision factors are your team's editing capability, whole-of-life licensing cost, security patching arrangements, and whether the implementation gives you structured content types and role-based workflows. A well-implemented open-source CMS beats a poorly implemented enterprise one every time.
What should a CMS handover from a web vendor include?
Full administrative access to the CMS, hosting, and domain, written documentation of editing workflows, role-based accounts for your staff, training delivered at launch and again after staff have used the system, and confirmation that routine tasks like publishing pages and emergency alerts require no vendor involvement. If any routine publishing task needs a paid support ticket, the handover is incomplete.
Who should own the council website domain and hosting?
The council, always. The domain, hosting account, CMS licences, and all content should sit in the council's name with the vendor holding delegated access, not the other way around. Exit terms, including a full content export in a usable format, should be agreed in the contract before the project starts.
If your council is heading toward a redevelopment, start with evidence rather than opinions. Our free website audit benchmarks your current site's accessibility, structure, and performance, and gives you a documented baseline for the business case. And if you want a build partner that treats accessibility and handover as the job rather than the fine print, see how we approach web design projects.