Website Design for Public Sector Organisations: Balancing Compliance and Usability
Public sector websites carry a weight that most commercial sites never have to deal with. A council website might need to serve a retired resident checking their council tax, a new parent applying for a school place, a business owner looking for planning permissions and a social worker accessing referral forms, all on the same platform. Getting the design right means making every one of those journeys straightforward, accessible and compliant with a legal framework that most private sector organisations barely think about. For organisations that need this done properly, working with a team that provides digital services for public sector organisations can make the difference between a website that people tolerate and one they can actually use.
The challenge isn’t just about making something look professional. Public sector website design sits at the intersection of legal obligation, democratic accountability and genuine service delivery. Every design decision has to account for accessibility legislation, a user base that spans every demographic in the country and the reality that for many services, there is no alternative website to go to. If the council’s planning portal is difficult to use, residents don’t switch to a competitor. They phone the council, visit in person or simply give up.
Why Public Sector Websites Demand a Different Approach
Commercial websites exist to convert visitors into customers. Public sector websites exist to help people complete tasks, access services and find information they’re entitled to. That fundamental difference shapes every aspect of the design process. The audience isn’t a target demographic. It’s the entire population of a geographic area, with all the diversity in age, ability, language, digital confidence and device access that implies.
Most commercial website projects start with a brand brief and a set of conversion goals. Public sector projects start with user research, service maps and a legal compliance checklist. The procurement process itself is different too. Most public bodies are bound by procurement regulations that require formal tendering, evidence of past performance and detailed technical specifications. A council can’t simply choose a supplier because they liked the portfolio. There are frameworks, scoring criteria and audit trails to satisfy.
Legacy systems add another layer of complexity. Many councils and NHS trusts run on infrastructure that was built over a decade ago. The website needs to integrate with case management systems, payment gateways, booking platforms and document management tools that were never designed to talk to each other. A redesign project is rarely just a redesign. It’s an integration project, a content migration project and an accessibility remediation project all running in parallel.
Accessibility Compliance Is a Legal Baseline
The Public Sector Bodies (Accessibility Regulations) 2018 require public sector websites to meet the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA. This isn’t guidance or best practice. It’s law. Organisations that fail to comply face enforcement action from the Government Digital Service monitoring body, reputational damage and, increasingly, legal claims under the Equality Act 2010.
WCAG 2.2 introduced several new success criteria that are particularly relevant to public sector websites. Target size requirements mean that interactive elements like buttons and form fields need to be large enough for users with motor impairments to activate reliably. Consistent help criteria require that help mechanisms appear in the same relative position across pages. Accessible authentication rules mean that login processes cannot rely solely on cognitive function tests like remembering a password without offering alternatives.
| WCAG 2.2 Criterion | What It Means for Public Sector Sites |
|---|---|
| 2.5.8 Target Size (Minimum) | Interactive elements must be at least 24×24 CSS pixels, with exceptions for inline links and elements where spacing provides equivalent clearance |
| 3.2.6 Consistent Help | Contact details, chat widgets or help links must appear in the same location on every page where they’re provided |
| 3.3.7 Redundant Entry | Users should not have to enter the same information twice in a single process unless re-entry is required for security |
| 3.3.8 Accessible Authentication | Login flows must not depend on cognitive tests. Offer alternatives like passkeys, email magic links or biometric authentication |
Meeting these criteria is the minimum, not the goal. A website can be technically WCAG compliant and still be difficult to use for people with disabilities if the content is poorly structured, the navigation is confusing or the reading level assumes a university education. Real accessibility goes beyond passing automated checks. It means testing with actual users, including people who navigate with keyboards, screen readers and voice control. Organisations looking to meet both the letter and the spirit of the regulations should work with specialists in website accessibility who understand the public sector context.
Designing for Diverse Audiences with Competing Needs
A private healthcare company can design its website for a fairly well-defined audience. A council website has to work for everyone, from digitally confident professionals submitting planning applications to elderly residents who have never used a search function. These audiences don’t just have different levels of digital skill. They have fundamentally different mental models for how a website should work.
The GDS design principles offer a useful starting point here. “Do the hard work to make it simple” is the principle that matters most for public sector web design. It means doing the research to understand how people think about services, then designing interfaces that match those mental models rather than the organisation’s internal structure. A resident looking for information about bin collections shouldn’t need to know whether waste management sits under environmental services or neighbourhood operations.
Task-oriented design works well for this kind of audience diversity because it doesn’t assume any particular level of knowledge about the organisation. Start pages that ask “What do you need to do?” rather than presenting a departmental sitemap let users self-select into the right journey without needing to understand the bureaucracy behind it. Combined with clear headings, plain language and generous spacing, this approach reduces the gap between the most and least confident users.
Plain Language and the Reading Level Challenge
GDS recommends writing for a reading age of 9. That isn’t about patronising readers. It’s about acknowledging that even highly educated professionals prefer clear, direct language when they’re trying to complete a task. Medical consultants don’t want to parse dense bureaucratic prose when they’re trying to submit a leave request through an NHS trust’s HR portal. They want the same clarity that everyone else does.
Public sector content tends toward complexity for understandable reasons. Legal teams want precise language. Subject matter experts use the terminology they know. Senior leaders worry that simple language will make the organisation look unsophisticated. The job of content design is to push back on all of those instincts without losing accuracy. A phrase like “You might be able to get help with your rent” communicates the same idea as “Eligible applicants may submit an application for discretionary housing payment assistance” but reaches a far wider audience.
This matters for web design because the content and the interface need to work together. A beautifully designed page with dense, jargon-heavy content still fails the user. A well-written page wrapped in confusing navigation fails just as badly. The design system, the content guidelines and the editorial process need to be aligned so that every page delivers both clear language and clear structure. Strong content marketing principles apply here, even though the goal is service delivery rather than lead generation.
Integrating Public Services into the Website
Public sector websites are not just information resources. They’re service delivery platforms. Residents expect to report problems, make payments, book appointments, submit applications and track the progress of requests online. Each of those interactions requires integration with back-office systems that are often decades old, poorly documented and maintained by teams that are stretched thin.
Forms are the most common integration point and the most common source of frustration. A well-designed form breaks a complex process into manageable steps, validates input in real time, saves progress so users don’t lose their work and confirms submission clearly. A poorly designed form dumps every field onto a single page, uses internal terminology as labels, offers no validation until the user hits submit and provides no confirmation beyond a generic message.
Payment integration needs particular care in the public sector. PCI DSS compliance is non-negotiable. The payment journey must be accessible, and the confirmation process needs to be clear enough that users trust the transaction has gone through. Many councils use third-party payment providers, which means the design team needs to manage the handoff between the main site and the payment gateway without breaking the user’s sense of continuity.
Booking systems, whether for appointments at a register office, slots at a household waste recycling centre or consultations with a planning officer, need to handle capacity management, cancellations and reminders. These aren’t features you can bolt on as an afterthought. They need to be planned into the website architecture from the start.
Multilingual Considerations for Public Bodies
In Wales, the Welsh Language (Wales) Measure 2011 requires many public bodies to provide services in Welsh. That means the website needs proper bilingual support, not just a machine translation toggle but genuinely maintained Welsh language content with its own editorial process. The design system needs to accommodate text that may be longer or shorter than its English equivalent without breaking layouts.
Beyond Welsh, many councils serve communities where significant numbers of residents speak languages other than English as their first language. Translation adds cost and complexity to every content update, so the decision about which pages to translate and into which languages needs to be informed by local demographic data. There’s no point translating the entire site into 15 languages if the translated pages are never maintained and quickly become inaccurate. A smaller set of well-maintained translations for the most-used service pages delivers more value than broad but shallow coverage.
From a technical perspective, multilingual websites need to handle right-to-left text for languages like Arabic, character encoding for scripts like Bengali and Mandarin, and URL structures that make translated pages discoverable by search engines. These requirements should be part of the initial brief, not discovered halfway through development.
Content Management for Multiple Contributors
A council website might have dozens of people publishing content across different departments. Some will be trained content designers. Others will be subject matter experts who publish once a quarter and forget their login details between sessions. The content management system needs to accommodate this range of experience without creating bottlenecks or compromising quality.
The best public sector CMSs provide structured content templates that guide authors toward good practice without requiring them to understand HTML, accessibility guidelines or the design system. A form builder that automatically generates accessible markup is more effective than a training course that most people will have forgotten within a month.
Workflow and approval processes matter too. Content that goes through a review cycle before publication is more likely to be accurate, accessible and on-brand. But if the approval process is too slow, teams will find workarounds, publishing directly or creating microsites outside the main CMS. The governance model needs to balance quality control with practical turnaround times.
- Structured content templates that enforce consistent formatting without requiring technical knowledge
- Role-based permissions so authors can only edit their own sections
- Built-in accessibility checks that flag common issues before publication
- Scheduled review dates attached to every published page
- Version history so changes can be tracked and rolled back if needed
Choosing the right CMS is one of the most consequential decisions in a public sector web design project. The platform needs to be maintainable by an in-house team after the initial build, extensible enough to handle future requirements and supported by a community or vendor that will still exist in five years.
Why WordPress Makes Sense for Public Sector Procurement
Procurement in the public sector favours platforms that avoid vendor lock-in. Proprietary CMS platforms tie organisations to a single supplier for hosting, development and support. If that supplier raises prices, reduces support or goes out of business, the organisation faces a costly and disruptive migration. WordPress, as an open-source platform, removes that risk. The codebase is publicly available, the hosting can be moved between providers and the development work can be carried out by any competent agency or in-house team.
The WordPress accessibility team maintains accessibility standards for the core platform, and the block editor provides a structured authoring experience that guides content creators toward accessible output. Custom themes built on WordPress can implement a design system that matches the organisation’s branding while maintaining WCAG compliance at the template level, so individual authors don’t need to think about heading hierarchy or colour contrast every time they create a page.
Cost is a legitimate factor in public sector procurement, and WordPress reduces total cost of ownership in several ways. There are no licence fees for the core platform. Hosting options range from shared servers for smaller bodies to enterprise-grade managed WordPress hosting for larger organisations. The global developer community means that finding skilled WordPress developers is straightforward, and the in-house team can handle routine content updates without waiting for an external supplier. For organisations that need WordPress development built around their specific service requirements, the platform’s flexibility makes it a strong fit for the public sector’s mix of content publishing, service delivery and integration needs.
Public sector website design will always involve balancing what’s ideal with what’s achievable. Budgets are constrained, internal politics are real and the pace of change in accessibility standards means compliance is a moving target rather than a fixed destination. But the organisations that get this right, the ones that put users first, build on open platforms, invest in accessibility from day one and maintain their content after launch, end up with websites that genuinely serve the public they were built for.
FAQs
What accessibility standard must public sector websites meet in the UK?
Public sector websites in the UK must meet the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA, as required by the Public Sector Bodies (Accessibility Regulations) 2018. This covers everything from colour contrast and heading structure to form labels, keyboard navigation and alternative text for images.
Why is WordPress a good choice for public sector website projects?
WordPress is open-source, which means there are no licence fees and no vendor lock-in. Public sector organisations can move hosting between providers, hire any developer to work on the site and maintain content in-house. The platform’s accessibility team also maintains standards in the core software, which gives public bodies a solid foundation for WCAG compliance.
How do public sector websites handle multilingual content requirements?
In Wales, many public bodies are legally required to provide bilingual Welsh and English content. Other councils translate key service pages based on local demographic data. From a technical perspective, multilingual websites need to support different character sets, right-to-left text and separate editorial workflows for each language.
What makes public sector web design different from commercial web design?
Public sector websites serve the entire population of an area, not a target demographic. The audience includes people of all ages, abilities, languages and levels of digital confidence. Legal accessibility requirements are stricter, procurement processes are more formal and the website often needs to integrate with legacy back-office systems for service delivery.
Do public sector websites have to follow the GDS design principles?
Central government departments are expected to follow GDS standards. Local authorities, NHS trusts and other public bodies are not formally required to adopt them, but many do because the underlying principles around user-centred design, plain language and accessibility are sound starting points for any public-facing website.