WCAG Compliance for Public Sector: A Practical Implementation Guide

WCAG compliance is one of those responsibilities that every public sector organisation knows about but relatively few handle well. Councils, NHS trusts, government departments and arms-length bodies are all required by law to make their websites accessible, yet many still have significant gaps in their compliance. The regulations have been in place since 2018 and the underlying principles go back much further, so there’s little excuse for not meeting the standard at this point. For public sector bodies that need specialist support, working with an agency that provides digital services for public sector organisations can make the difference between patchy compliance and a website that works for everyone.

This isn’t about ticking boxes on an audit checklist. Accessibility affects real people trying to access services they’re entitled to, whether that’s applying for housing, booking a GP appointment or finding out when their bins are collected. When a website fails on accessibility, it creates a barrier between the public and the services they need. That’s the context within which WCAG compliance sits. Getting this right matters far more than meeting a regulatory minimum.

The Legal Framework Underpinning Public Sector Accessibility

Two pieces of UK legislation create the legal obligation for public sector accessibility. The first is the Equality Act 2010, which requires organisations to make reasonable adjustments so that disabled people are not placed at a substantial disadvantage when accessing services. This applies to digital services just as much as physical ones. A council website that can’t be used with a screen reader is no different, in legal terms, from a council building with no wheelchair access.

The second is the Public Sector Bodies (Accessibility Regulations) 2018, which transposed the EU Web Accessibility Directive into UK law. These regulations go further than the Equality Act by specifying exactly what public sector websites and mobile applications must do. They require compliance with WCAG 2.1 at level AA as a minimum, though the W3C has since published WCAG 2.2 and organisations are increasingly expected to meet the newer standard. The regulations also require every public sector website to publish an accessibility statement. They also give the Central Digital and Data Office (CDDO) the power to monitor and enforce compliance.

The enforcement model is not heavy-handed compared to some regulatory regimes, but it is real. The CDDO publishes monitoring reports that name organisations failing to meet the standard. Being listed in one of those reports carries reputational risk. It also signals to disabled users and advocacy groups that an organisation is not meeting its duties. Legal claims under the Equality Act remain a possibility as well, particularly as awareness of digital accessibility rights continues to grow among the public.

WCAG 2.2 AA as the Compliance Benchmark

The Web Content Accessibility Guidelines (WCAG) 2.2 are published by the World Wide Web Consortium (W3C) and represent the current international standard for web accessibility. The guidelines are organised around four principles, often referred to by the acronym POUR: Perceivable, Operable, Understandable and Robust. Each principle contains guidelines. Each guideline contains testable success criteria at three levels: A, AA and AAA.

Public sector organisations in the UK are required to meet level AA. This covers the success criteria that address the most common barriers faced by disabled users without imposing requirements that would be unreasonable for most websites to meet. Level AAA is aspirational and not expected across entire sites, though meeting individual AAA criteria where practical is good practice.

WCAG 2.2 introduced several new success criteria beyond what was in version 2.1. These include requirements around focus appearance, dragging movements and target size that reflect how people actually interact with websites today. Organisations that met 2.1 AA will find that the additional work to meet 2.2 AA is manageable, but it does require attention. Touch targets, for example, need to be at least 24 by 24 CSS pixels under the new criteria, which affects buttons, links and form controls across the site.

The POUR framework gives organisations a practical way to think about accessibility beyond individual technical tests. A website might pass automated checks but still be unusable for someone relying on a screen reader if the page structure is confusing or form fields don’t have proper labels. Meeting the standard means satisfying each success criterion, but truly accessible sites go beyond that by considering the full experience from a disabled user’s perspective.

Publishing an Accessibility Statement

The 2018 regulations require every public sector website to publish an accessibility statement. This isn’t optional and it isn’t a formality. The statement must follow a specific format and include details about how the site meets the accessibility standard, any known areas of non-compliance and how users can report problems or request content in alternative formats. The government guidance on accessibility requirements sets out what the statement should contain.

A good accessibility statement is honest about where the site falls short. Most public sector websites have some areas of non-compliance, whether that’s legacy PDFs that haven’t been remediated, third-party booking systems that don’t fully meet the standard or older content that predates current accessibility practices. The statement should list these honestly, explain what the organisation is doing to address them and provide a clear route for users to get in touch if they encounter a barrier.

The statement also needs to be kept up to date. An accessibility statement written two years ago that hasn’t been reviewed since is worse than not having one at all, because it gives users and regulators a false picture of the site’s current state. Reviews should happen at least annually. Ideally they should be updated whenever significant changes are made to the site. Organisations that work with Priority Pixels on website accessibility build statement reviews into their ongoing maintenance schedule so the document stays current.

Common Accessibility Failures on Public Sector Websites

Certain types of accessibility failures appear on public sector websites far more often than others. The WebAIM Million report, which analyses the accessibility of the top one million websites annually, consistently finds the same categories of issues dominating. Public sector sites are not immune to these patterns. Many have their own specific challenges on top of the common ones.

PDFs are one of the most persistent problems. Public sector organisations publish committee papers, policy documents, reports and forms as PDFs, and the majority of these are not tagged for accessibility. An untagged PDF is effectively invisible to a screen reader. The content might as well not exist for someone who relies on assistive technology to read it. Remediating existing PDFs is time-consuming, which is why many organisations choose to prioritise publishing new content in HTML and working through their PDF backlog over time.

Forms are another frequent failure point. Contact forms, application forms and service request forms often have fields without labels, error messages that don’t explain what went wrong or validation that only works visually. A sighted user might see a red border around a field that needs correcting, but a screen reader user gets no indication of what the problem is or where it occurred. Properly labelled form fields, descriptive error messages and logical tab order are all required under WCAG.

The most common accessibility failures are not obscure technical issues. They are missing alt text, poor colour contrast, empty links, missing form labels and document structure problems. Fixing these basics addresses the majority of barriers that disabled users encounter on public sector websites.

Navigation is a broader concern that covers everything from the main menu to breadcrumbs, skip links and heading structure. Screen reader users rely heavily on headings to navigate long pages, so a page that jumps from H2 to H4 or uses headings purely for visual styling creates real navigation problems. Similarly, dropdown menus that require precise mouse movements and don’t respond to keyboard input exclude anyone who can’t use a mouse.

A Practical Approach to Implementation

Achieving WCAG compliance across an entire public sector website isn’t something that happens in a single sprint. Most organisations are dealing with years of accumulated content, third-party integrations and legacy systems that were built before accessibility was a priority. A phased approach works better than trying to fix everything at once, because it allows teams to address the most significant barriers first and build capability over time.

The implementation typically follows four stages. The first is an audit, where the current state of the site is assessed against the WCAG 2.2 AA criteria. This should combine automated testing with manual checks. Automated tools catch obvious issues like missing alt text and contrast failures, but they miss the kinds of problems that only human testing reveals, such as confusing tab order, misleading link text or content that makes no sense when read out of visual context. Priority Pixels builds accessible web design into projects from the start, but for existing sites an audit is the necessary first step.

The second stage is prioritisation. Not every WCAG failure has the same impact. A contrast issue on a decorative element is less urgent than a form that can’t be submitted using a keyboard. Prioritisation should consider the severity of the barrier, the number of users affected and which pages or services are most critical. High-traffic service pages, online forms and anything related to statutory services should sit at the top of the list.

The third stage is remediation, where the actual fixes are made. Some issues are straightforward, such as adding alt text to images or correcting heading hierarchy. Others require more significant development work, particularly around interactive elements, embedded content and third-party tools. The fourth stage is retesting to confirm that fixes have been implemented correctly and haven’t introduced new issues elsewhere.

This cycle isn’t something that runs once. Accessibility compliance is an ongoing commitment, not a project with a fixed end date. New content gets published, features are added and third-party tools are updated. Each of these changes can introduce new accessibility issues if the process isn’t built into how the team works day to day.

Building Accessibility into Procurement and Development

One of the most effective ways to maintain WCAG compliance is to make accessibility a requirement at the point where new work is commissioned. Procurement specifications for websites, applications and digital services should include explicit accessibility requirements referencing WCAG 2.2 AA. Suppliers should be asked to demonstrate how they will meet the standard, provide evidence of accessibility testing and commit to fixing any issues found during acceptance testing.

The same principle applies to internal development. Whether a team is building new features in-house or customising an existing platform, accessibility should be part of the definition of done for every piece of work. This means including accessibility checks in code review, testing with keyboard navigation and screen readers before sign-off and running automated scans as part of the deployment pipeline. Organisations running their sites on WordPress have a particular advantage here, because the platform’s core is built with accessibility in mind and the community actively maintains accessibility standards in the editor and default themes.

Third-party tools and embedded content deserve special attention. Booking systems, payment gateways, mapping tools and social media widgets are all common on public sector sites, and they all carry their own accessibility risks. The organisation publishing the site remains responsible for the accessibility of embedded content, even if it was built by a third party. This makes it important to assess the accessibility of any tool before integrating it and to have a plan for what happens if a third-party component fails to meet the standard.

Staff Training and Awareness Across the Organisation

Technical fixes only address part of the challenge. Public sector websites are maintained by content editors, communications teams, policy officers and service managers, most of whom are not accessibility specialists. If these people don’t understand the basics of accessible content, they will inadvertently introduce new issues every time they publish a page, upload a document or add an image.

Training should cover the practical skills that content contributors need. These include writing meaningful alt text for images, creating proper heading structures, using descriptive link text instead of “click here” or “read more,” writing clear and concise content, and checking that any documents they upload meet basic accessibility standards. The training doesn’t need to turn everyone into a WCAG expert. It needs to give them enough knowledge to avoid the most common mistakes and to recognise when they need to ask for specialist advice.

The GOV.UK accessibility blog is an excellent free resource for public sector teams. It publishes practical guidance, case studies from government departments and updates on accessibility policy that are directly relevant to anyone working on UK public sector digital services. Making this kind of resource available to content teams, and giving them time to engage with it, builds a culture where accessibility is understood as everyone’s responsibility rather than a specialist concern.

Maintaining Compliance Over Time

Achieving WCAG compliance is a milestone, not a finish line. Websites change constantly. New pages are published, existing content is updated, features are added and redesigns happen. Each change is an opportunity for new accessibility issues to appear, and without a process for catching them, compliance will degrade over time. Organisations that treat accessibility as a one-off project inevitably find themselves back where they started within a year or two.

Regular auditing is the foundation of ongoing compliance. A full audit might happen annually, but lighter-touch checks should be more frequent. Running automated scans monthly, spot-checking new content for common issues and including accessibility in the acceptance criteria for any new feature or design change all help maintain the standard. Some organisations assign an accessibility champion within the digital team whose role includes reviewing new content, flagging issues and keeping training materials up to date.

Content governance plays a part as well. If there’s no process for reviewing and retiring outdated content, the site accumulates pages that nobody maintains. Those pages still need to meet the accessibility standard, and they often contain the oldest and least accessible content on the site. A regular content review cycle that removes pages no longer needed, updates those that are still relevant and remediates any accessibility issues found during the review keeps the overall quality of the site high.

Technology choices matter too. Choosing a content management system that supports accessible output by default, using a design system with accessible components and selecting third-party tools that meet WCAG criteria all reduce the ongoing effort needed to stay compliant. The platform should help content editors produce accessible content without requiring them to think about the underlying markup. When the technology works against accessibility, every piece of content becomes a potential compliance issue, and that’s not a sustainable position for any public sector organisation to be in.