Accessibility Requirements for Public Sector Websites in the UK

Public sector websites in the UK must meet WCAG 2.2 Level AA, publish an accessibility statement and keep both under regular review, under the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018. These accessibility requirements for websites apply to councils, NHS trusts, government departments, universities and many publicly funded bodies and they add to the existing duty to make reasonable adjustments under the Equality Act 2010. Priority Pixels provides web design for the public sector built around those obligations, so the detail below reflects the questions councils, trusts and statutory bodies ask most often.

The regulations came into force on 23 September 2018 and every compliance deadline they set has now passed. For most organisations the question is no longer when to start, but how to stay compliant as content, suppliers and systems change. GOV.UK’s guidance on understanding accessibility requirements for public sector bodies now references WCAG 2.2 AA and it points out that you’re legally responsible for your website meeting the requirements when you’ve outsourced it to a supplier.

The Accessibility Requirements for Websites in the Public Sector

A public sector body has to make its websites and mobile apps accessible to the WCAG 2.2 AA standard and publish a statement explaining how accessible they are. The full text of the Public Sector Bodies Accessibility Regulations 2018 runs to only a few pages and the core obligations are listed below.

• Meet WCAG 2.2 Level AA across public websites, intranets, extranets and mobile apps developed for the public.
• Publish an accessibility statement that follows the model statement and review it regularly.
• Carry out a documented assessment before claiming that any fix would be a disproportionate burden.
• Explain exempt and inaccessible content in the statement, with accessible alternatives where appropriate.
• Provide a contact route for reporting problems and requesting information in another format.
• Keep making reasonable adjustments for disabled people under the Equality Act 2010 for anything the regulations do not cover.

None of these duties ends when a website launches. Every new page, document and third party tool can introduce fresh problems, which makes accessibility a governance question for senior teams as much as a technical one for developers.

Who the Regulations Cover and Who Is Exempt

The regulations apply to public sector bodies, which covers central government, local authorities and bodies governed by public law such as NHS trusts, universities and many arm’s length organisations. Scope is set out in regulation 4 and it extends to intranets, extranets and mobile apps developed for use by the public. Apps built for a defined group, such as employees or students, are not covered by the regulations.

Three groups sit outside the full requirements. Public service broadcasters and their subsidiaries are exempt and charities and other non-governmental organisations are exempt except where they are mostly publicly funded, provide services the public depends on or provide services meant for disabled people. Primary and secondary schools and nurseries are partially exempt, with the content people need to use their services, such as an online form for school meal preferences, still in scope and an accessibility statement still required.

An exemption from the regulations is not an exemption from the law. Every UK service provider still has to make reasonable adjustments for disabled people under the Equality Act 2010 or, in Northern Ireland, the Disability Discrimination Act 1995. An exempt charity that receives a request for information in an accessible format still has to respond to it reasonably.

Why WCAG 2.2 AA Is the Standard to Meet

WCAG 2.2 Level AA is the standard public sector websites and apps are expected to meet, replacing the WCAG 2.1 AA benchmark many organisations originally worked towards. W3C published WCAG 2.2 as a recommendation on 5 October 2023 and its summary of what’s new in WCAG 2.2 lists nine additional success criteria, with the old 4.1.1 Parsing criterion removed as obsolete.

Six of those new criteria sit at Level A or AA, so they fall within scope for public sector bodies. They cover keyboard focus that stays at least partly visible, alternatives to dragging movements, a minimum target size for controls, help that appears in a consistent place, not asking people to re-enter information they have already given and login processes that do not depend on memory tests without an alternative. Level AA includes everything at Level A plus requirements such as colour contrast, clear form labels and helpful error messages and Level AAA is not required.

Most of the WCAG 2.1 criteria carry over unchanged, so a website that met 2.1 AA is not starting from scratch. Our article on the latest version of WCAG covers each change in more detail.

Deadlines for New and Existing Websites and Apps

Every deadline in the regulations has passed, so all public sector websites and apps in scope should already comply. The phasing set out in regulation 5 ran over three years, with newer websites first and mobile apps last.

The dates still matter, as several of the content exemptions are tied to them. Office documents published before 23 September 2018, recorded audio and video published before 23 September 2020 and intranet content published before 23 September 2019 are treated differently from anything published since and anything new has to meet the standard from the day it goes live.

How GDS Monitoring and Enforcement Work

The Government Digital Service monitors compliance on behalf of the Minister for the Cabinet Office and the Equality and Human Rights Commission and the Equality Commission for Northern Ireland enforce it. GDS checks a random sample of websites and apps each year, drawn from lists of public sector organisations and from domains such as .gov.uk, .ac.uk and .nhs.uk, according to its published approach to public sector accessibility monitoring.

A simplified test combines automated checks using the Axe tool with manual checks such as tabbing through pages without a mouse, viewing them at different zoom levels and simulating a small screen. Detailed audits test against every WCAG success criterion up to Level AA and add assistive technology testing, with priority given to websites with the greatest social impact and those that have attracted complaints.

If your organisation receives a GDS report, you have seven days to acknowledge it and 12 weeks to fix the issues it lists. GDS then asks what has been fixed, retests the website and passes the report and progress information to the EHRC in England, Scotland and Wales or the ECNI in Northern Ireland. GDS publishes a list of websites with non-compliant accessibility statements on behalf of the Minister for the Cabinet Office.

Failing the accessibility requirement counts as a failure to make reasonable adjustments, which is a breach of the Equality Act 2010 or the Disability Discrimination Act 1995. The EHRC and ECNI can respond with investigations, unlawful act notices and court action and members of the public can take a complaint to the Equality Advisory and Support Service if the organisation’s own response doesn’t resolve it.

Content the Regulations Do Not Cover

The regulations exclude certain types of content, but the exemptions are narrower than many teams assume and each one has to be explained in your accessibility statement. The table below summarises the exemptions in regulation 4 and the conditions attached to them.

Exempt content is not invisible to the law. A disabled person who needs an archived report or an old video can still ask for it in an accessible format and the reasonable adjustments duty applies to that request.

PDFs, Documents and Third Party Content

PDFs and other office documents published on or after 23 September 2018 must meet the same standard as web pages and older documents come back into scope if people need them to use a service. In practice that includes application forms, current policies, consultation papers and guidance that residents act on, regardless of when the file was first uploaded.

GOV.UK’s guidance on publishing accessible documents recommends HTML wherever possible, noting that PDFs often don’t work well with screen readers and are harder to find, use and maintain. For documents that change regularly, an HTML page is often easier to keep accessible than a PDF that needs remediating after every revision. The same structure gives search engines and AI platforms content they can read and cite, a point our article on public sector SEO and accessibility develops further.

Third party content is exempt only when your organisation neither funded nor developed it and does not control it. GDS states that if you funded, developed or control third party content, making it accessible is your responsibility, so booking systems, payment pages, embedded forms and consultation platforms bought from suppliers all fall within scope. Writing WCAG 2.2 AA into procurement requirements gives you a contractual basis for fixes and GOV.UK suggests building regular accessibility reviews into supplier contracts.

Accessibility Statements and Disproportionate Burden

Every public sector website and app in scope needs an accessibility statement that follows the model statement, is published in an accessible format and is kept under regular review. Regulation 8 says it must explain which content isn’t accessible and why, describe any accessible alternatives, link to a contact form for reporting problems and link to the enforcement procedure. Our article on how to write an accessibility statement covers the structure and wording in detail.

A disproportionate burden claim lets an organisation avoid fixing specific issues where the cost would be unreasonable, but only after a documented assessment. Under regulation 7, that assessment has to consider the size, resources and nature of the body and weigh its estimated costs against the benefits for disabled people, taking into account how often and how long the website or app is used.

Any claim has to be explained in the accessibility statement, with accessible alternatives provided where appropriate. GOV.UK notes that a claim is less likely to hold for services aimed at disabled people or services that help people take part in society, such as registering to vote or finding a job and that a claim should be reviewed if circumstances change.

GDS asks for any disproportionate burden evidence within seven days of sending a monitoring report, so the assessment needs to exist before an audit arrives. Treating a claim as a temporary position with a planned fix date is easier to defend than treating it as a permanent exemption.

Planning Compliance for Your Website

A compliance plan for a public sector website starts with an audit against WCAG 2.2 AA and ends with a monitoring routine that catches new issues as content changes. GOV.UK suggests checking how far your website currently meets WCAG 2.2 and then making a plan to fix the problems found and that sequence works for an existing website or a planned rebuild.

Accessibility problems come from content as often as code, so the plan needs to cover editors and suppliers, not only developers. Missing alternative text, unclear link text, poorly structured headings and inaccessible PDFs are introduced through everyday publishing, which is why training forms part of any lasting fix. The four stages below give a workable structure.

Priority Pixels carries out WCAG 2.2 accessibility audits and remediation that combine manual review of critical user paths with automated scans using axe-core and WAVE. Each audit produces a severity-ranked issue register, a prioritised roadmap and findings mapped to the accessibility statement sections the public sector regulations require, with a re-audit once remediation is delivered.

For public sector organisations building or rebuilding on WordPress, we design and develop to WCAG 2.2 AA as a minimum, without page builders or templates and train internal teams to maintain standards as they publish. Ongoing accessibility monitoring after launch picks up issues introduced through content updates, so compliance holds between audits instead of drifting until the next GDS sample.