UK Accessibility Regulations: A PSBAR Guide

What are the UK Public Sector Bodies Accessibility Regulations?

The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 — commonly referred to as PSBAR, the PSB Regulations, or simply “the UK accessibility regulations” — came into force in September 2018. They implement the EU Web Accessibility Directive (WAD) into UK law and continue to apply post-Brexit under the UK’s retained EU law framework.

PSBAR requires public sector bodies to make their websites and mobile applications accessible to people with disabilities. Compliance is measured against the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA, and all in-scope organizations are required to publish and maintain an accessibility statement.

Who must comply?

PSBAR applies to public sector bodies as defined in the regulations. This is a broad category that includes:

• Central government departments and executive agencies
• Non-departmental public bodies (NDPBs) and arm’s-length bodies
• Local authorities and councils
• NHS trusts and health bodies
• Universities and further education colleges (with some nuance)
• Police, fire, and other emergency services
• Maintained schools and multi-academy trusts
• Libraries, museums, and cultural institutions operated by public bodies

Private sector organizations are not covered by PSBAR. However, if a private company provides digital services on behalf of a public sector body — for example, operating a council’s online payments portal — the public sector body remains responsible for ensuring those services are accessible.

What does “in scope” mean for content?

The regulations cover all publicly available websites and mobile applications operated by public sector bodies. This includes intranets and extranets where they are accessible to the public.

However, several categories of content are explicitly exempt:

• Office file formats (PDFs, Word documents, spreadsheets) published before 23 September 2018, unless they are needed to use a service
• Pre-recorded time-based media (video, audio) published before 23 September 2020
• Live video (live captions are not required, though best practice is to provide them where possible)
• Online maps — as long as essential navigational information is provided accessibly
• Third-party content that the public sector body does not fund, develop, or control
• Heritage collections and archived content that cannot be made accessible without disproportionate burden
• Intranets and extranets where the content predates September 2019 and has not been substantially revised

The exemption for legacy office files is frequently misunderstood. It applies to documents published before the relevant date — not to all PDFs ever. Any new document, or any existing document that is updated after the effective date, must meet the standard.

The technical standard: WCAG 2.1 Level AA

PSBAR requires conformance with WCAG 2.1 Level AA. This standard, published by the W3C, covers 50 success criteria organized under four principles:

Perceivable — information and UI components must be presentable in ways users can perceive. Key requirements include:

• Text alternatives for non-text content (images, icons, charts)
• Captions for video content
• Sufficient color contrast (4.5:1 for normal text, 3:1 for large text and UI components)
• Content that can be presented in different ways without losing information

Operable — UI components and navigation must be operable. Key requirements include:

• Full keyboard accessibility — all functionality must work without a mouse
• No keyboard traps
• No content that flashes more than three times per second
• Descriptive page titles, headings, and link text
• A visible focus indicator for keyboard navigation

Understandable — content and UI must be understandable. Key requirements include:

• Language declared in HTML (lang attribute)
• Consistent navigation and labeling
• Descriptive error messages with instructions for correction
• Labels and instructions for all form inputs

Robust — content must be robust enough for interpretation by assistive technologies. Key requirements include:

• Valid, well-structured HTML
• Correct use of ARIA roles, states, and properties
• Status messages communicated to assistive technologies without requiring focus

WCAG 2.1 added 17 new success criteria compared to WCAG 2.0, with particular focus on mobile accessibility, low vision users, and cognitive and learning disabilities. The new criteria include:

• 1.3.4 Orientation — content must not be locked to a single screen orientation
• 1.3.5 Identify Input Purpose — form inputs that collect personal information must use autocomplete attributes
• 1.4.10 Reflow — content must reflow at 320px without horizontal scrolling
• 1.4.11 Non-text Contrast — UI components and graphical objects must meet 3:1 contrast
• 1.4.12 Text Spacing — users must be able to adjust text spacing without loss of content
• 1.4.13 Content on Hover or Focus — additional content triggered by hover or focus must be dismissible and persistent
• 2.5.3 Label in Name — accessible names of components must contain the visible text label

The accessibility statement requirement

One of PSBAR’s most distinctive obligations — and one where many public sector bodies fall short — is the mandatory accessibility statement.

Every in-scope website and mobile application must publish an accessibility statement that:

1. States which standard the site aims to meet — typically WCAG 2.1 AA
2. Lists known accessibility issues — specific barriers that have been identified and not yet resolved, with a description of each
3. Includes a disproportionate burden claim (if applicable) — a documented justification for why certain content has not been made accessible
4. Provides a feedback mechanism — a way for users to contact the organization to report accessibility barriers or request accessible alternatives
5. States the enforcement procedure — directing users who are not satisfied with the response to the relevant enforcement body
6. Shows the review date — when the statement was last updated

The Government Digital Service (GDS) publishes a standard accessibility statement template. Public sector bodies are encouraged (and in practice expected) to use this template or one that covers all the required elements.

Common mistakes in accessibility statements:

• Claiming full WCAG 2.1 AA compliance without evidence
• Listing no known issues when issues clearly exist
• Providing a contact mechanism that is itself inaccessible
• Publishing a statement that has not been reviewed in over a year
• Using a generic statement copied from another organization without customizing it to the actual site

An accessibility statement that misrepresents conformance is not only non-compliant — it undermines user trust and creates reputational risk when the actual barriers are reported.

Disproportionate burden

PSBAR allows public sector bodies to claim a disproportionate burden exemption for specific content where the cost or effort of making it accessible would be disproportionate to the benefit for users with disabilities. This is not a blanket exemption and must be applied to specific, identified content — not an entire website.

To claim disproportionate burden, the organization must:

1. Conduct a formal assessment weighing the costs of making the content accessible against the benefit to users with disabilities
2. Consider the organization’s size, resources, and the nature of the content
3. Document the assessment
4. State the claim in the accessibility statement, identifying the content and the basis for the claim
5. Review the claim periodically

GDS guidance is clear that disproportionate burden cannot be used to avoid making core user journeys accessible. Claiming disproportionate burden for a payment form or service application would not be considered valid.

Enforcement in the UK

PSBAR enforcement is handled differently from accessibility litigation in the US. The UK does not have a private right of action analogous to ADA Title III for website accessibility. Instead, enforcement is structured around:

Government Digital Service (GDS) monitoring — GDS is responsible for monitoring public sector body compliance with PSBAR. They conduct sampling audits of websites and mobile applications, and report compliance findings to the European Commission (for pre-Brexit reporting periods) and now under UK-retained obligations.

The Cabinet Office oversees the overall compliance framework, including the requirement for departments to have accessibility plans.

The Equality Act 2010 provides a parallel route. The Equality Act requires service providers (including public sector bodies) to make reasonable adjustments for disabled people. A public sector website with accessibility barriers that prevents a disabled person from accessing services may constitute unlawful discrimination under the Act. Unlike PSBAR, the Equality Act does support individual claims — disabled users can bring cases to an employment tribunal or county court.

Ofcom handles enforcement for broadcast-related requirements. The Financial Conduct Authority (FCA) and other sector regulators may also apply sector-specific accessibility expectations.

In practice, PSBAR enforcement has been relatively light-touch — GDS publishes compliance data and engages with organizations to improve, rather than pursuing formal enforcement action. However, this does not reduce the legal obligation, and Equality Act claims remain a real risk.

Post-Brexit status

PSBAR was transposed from the EU Web Accessibility Directive under the European Communities Act. Following Brexit, it is retained as UK domestic law under the Retained EU Law (Revocation and Reform) Act 2023. The regulations remain fully in force; post-Brexit, the UK is no longer required to follow updates to the EU WAD or the EN 301 549 harmonized standard, but WCAG 2.1 AA remains the applicable technical standard.

Organizations operating in both the UK and EU must comply with both PSBAR and the relevant EU member state implementations of the Web Accessibility Directive — which also reference WCAG 2.1 AA, creating alignment in practice.

Mobile applications

PSBAR applies to mobile applications as well as websites. Mobile apps operated by public sector bodies must:

• Meet WCAG 2.1 Level AA success criteria as applicable to native mobile apps
• Have an accessibility statement (which may be published on the web, within the app, or in the app store listing)
• Be compatible with platform accessibility features (VoiceOver on iOS, TalkBack on Android)

Mobile accessibility is assessed against EN 301 549, which incorporates WCAG 2.1 and adds mobile-specific requirements around touch target size, orientation, and platform API usage.

A practical PSBAR compliance roadmap

1. Audit your current conformance

Start with an honest assessment of where you stand. Automated scanning tools can identify a significant portion of WCAG failures quickly — color contrast issues, missing alt text, form labeling problems. But automated tools reliably detect only 30–40% of accessibility issues. A manual accessibility audit using screen readers and keyboard-only navigation is essential for a complete picture.

2. Prioritize your remediations

Fix the barriers that most directly prevent users from accessing core services first. For a local council, this might be: the planning application portal, the housing benefit form, the contact page, and the main navigation. Address transactional journeys before informational content.

3. Publish a compliant accessibility statement

Use the GDS template. Be honest about known issues. Provide a working contact mechanism. If you are claiming disproportionate burden for any content, document the assessment and state it clearly.

4. Fix and retest

After each remediation, verify the fix resolves the issue and has not introduced regressions. This requires both automated retesting and manual verification with assistive technology.

5. Embed accessibility in your publishing workflow

Every new page published, every document uploaded, every feature deployed can introduce new barriers. Content management training, pre-publication checklists, and automated scanning in the publishing workflow catch issues before they reach users.

6. Review your accessibility statement annually

The statement must reflect the current state of your site. An annual review — combined with a fresh audit — keeps it accurate and demonstrates ongoing commitment.

Summary

PSBAR is a binding legal obligation for UK public sector bodies. It requires WCAG 2.1 Level AA conformance across websites and mobile applications, and mandates an accurate, current accessibility statement for every in-scope site.

The regulations are not aspirational guidance — they are law, reinforced by the Equality Act 2010’s duty to make reasonable adjustments. Public sector bodies that treat accessibility as a continuous quality practice, rather than a compliance checkbox, will find it easier to meet the standard, respond to GDS monitoring, and serve the full range of their users.

If you operate a public sector website and are unsure of your current compliance position, a free accessibility scan is the fastest first step. For a full audit mapped against WCAG 2.1 AA and the PSBAR requirements, get in touch with our team.