PSBAR NHS Website Accessibility Requirements: What Actually Applies to You

PSBAR provides the legal framework for accessibility requirements covering relevant public sector websites and mobile applications.

For NHS teams, the practical issue is not simply whether a website meets WCAG. You must also demonstrate that the organisation understands its accessibility obligations and has published the required information.

The distinction becomes important during procurement, redesigns, content migrations, and accessibility reviews.

PSBAR comes from the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018.

The regulations establish accessibility requirements for websites and mobile applications operated by public sector bodies, subject to their scope and applicable exceptions.

Brexit did not remove these accessibility obligations from relevant UK public sector bodies. NHS organisations therefore still need to consider PSBAR when planning, procuring, maintaining, and reviewing digital services.

The technical standard also needs to be considered alongside the legal requirements.

WCAG provides the technical accessibility framework, while PSBAR establishes the relevant public sector obligation around accessibility and accessibility statements.

A common procurement mistake is writing "WCAG 2.1 AA" into a project specification and treating that as the permanent PSBAR requirement.

Updated Cabinet Office and Government Digital Service guidance means PSBAR automatically tracks the latest published version of WCAG. A 12 month grace period follows the publication of a new WCAG version before GDS expects conformance evidence against that version.

For current projects, this means WCAG 2.2 AA is the relevant technical reference under the current guidance.

Your procurement documents should therefore avoid locking accessibility requirements to an outdated version without checking the current PSBAR position.

For the technical implementation side, see our WCAG 2.2 AA compliance for healthcare resource.

Scope is one of the areas where NHS teams can make incorrect assumptions.

The organisation operating the website, the source of funding, the nature of the service, and the relationship with the public sector can all affect how PSBAR applies.

A website being developed by an external agency does not automatically place the legal responsibility onto the agency.

NHS Trusts and Integrated Care Boards operate within the public sector environment covered by PSBAR.

Their websites and relevant digital services therefore need to address applicable accessibility requirements, including the accessibility statement obligations.

The responsibility should be reflected in project governance from the beginning.

During healthcare implementations, reviewing the existing accessibility statement can reveal a problem before any code is changed. One Trust statement reviewed against the GDS model format had been copied from another organisation's website rather than reflecting the actual service.

For project teams, the practical lesson is simple. Treat the accessibility statement as an organisational deliverable with an accountable owner, not as generic website content.

For wider regulatory context, see the NHS digital compliance standards relevant to your project.

GP practices require more careful consideration because not every practice operates within the same organisational structure as an NHS Trust.

Where a GP practice uses an NHS funded web platform or operates a service within the relevant public sector scope, PSBAR requirements may apply.

Do not decide scope solely because the practice is independently operated.

Instead, establish:

That assessment should happen before procurement or redevelopment.

If your project involves a shared platform across multiple practices, document the scope decision centrally. Otherwise, different teams may make inconsistent assumptions about accessibility responsibilities.

External development does not automatically transfer the public body's accessibility responsibilities.

A healthcare organisation may commission an external supplier to design, develop, host, maintain, or provide content for its website. The contractual relationship should define responsibilities, but the commissioning organisation still needs to understand its own regulatory position.

Include accessibility requirements in the procurement specification and contract.

Ask suppliers to explain how they will test accessibility, document known limitations, support remediation, and maintain the accessibility statement.

The project should also define who approves the statement and who reviews it after major releases.

That approach prevents accessibility from becoming an unresolved responsibility between the NHS organisation and its supplier.

The accessibility statement is a core PSBAR requirement, not a footer link added after accessibility testing.

Under Regulation 8, the statement must follow the government's model format and provide users with specific information about accessibility and available remedies.

A statement can therefore fail even when parts of the website itself have been tested successfully.

Your statement needs to communicate the required information clearly.

The core elements include:

The statement should reflect the actual website rather than describe an ideal future state.

Known accessibility limitations should be specific enough for users to understand what they may encounter.

Generic wording such as "some content may not be fully accessible" provides little useful information when the organisation already knows which components or content create barriers.

Copying another organisation's accessibility statement creates an immediate accuracy problem.

Different websites have different technologies, content, known issues, third party components, accessibility testing results, and remediation plans.

During a statement review, compare the published wording directly against the live website and current accessibility evidence.

Check whether the statement identifies the actual non-accessible content. Confirm that the reporting route works and that the enforcement information remains appropriate.

The statement should also reflect the organisation's current position rather than a previous version of the website.

Our complete WCAG 2.2 AA guide for healthcare can provide the technical accessibility context behind this review.

The accessibility statement needs to remain accurate as the service changes.

A major redesign, new component library, new forms, content migration, third party integration, or significant WCAG-related change can affect the statement.

At minimum, build a formal review into the website governance process.

Based on our healthcare IT experience, placing accessibility statement review alongside release governance helps prevent the common situation where the website changes repeatedly while its published accessibility information remains unchanged.

The review should confirm both the technical position and the accuracy of the published statement.

Disproportionate burden is one of the most misunderstood parts of PSBAR.

It does not provide a general exemption for organisations that find accessibility expensive, technically difficult, or inconvenient.

The assessment must consider whether making particular content accessible would impose a disproportionate burden on the organisation.

The exception requires an assessment rather than a general declaration.

An organisation needs to consider relevant factors when determining whether making particular content accessible would create a disproportionate burden.

That means the assessment should be documented rather than reduced to a statement such as "the cost is too high".

Consider the resources available to the organisation, the likely benefit to users, and the impact of making the content accessible.

The decision also needs to remain connected to the specific content or functionality being considered.

A disproportionate burden assessment should not become a blanket exemption covering an entire website.

The relevant question is whether the accessibility of particular content or functionality creates the circumstances for an applicable exception.

Across recent compliance projects, assessing a disproportionate burden claim has required narrowing the issue to specific archived content rather than applying the exception across the wider website.

That distinction matters for NHS organisations with large content libraries.

For example, an older archive may require a different assessment from the core patient information that users rely on to understand services or access care.

Document the reasoning for each applicable exception and keep the assessment available for governance review.

Healthcare websites often contain information that directly affects patients, carers, professionals, or members of the public.

Core information about services, appointments, contact routes, clinical information, and access to care can therefore have significant user impact.

That makes broad reliance on disproportionate burden difficult to justify.

If content is important to users, the accessibility objective should normally be addressed through remediation, redesign, alternative formats, or another appropriate solution rather than assuming the exception applies.

A useful project control is to ask whether the content is operationally important before considering disproportionate burden.

If removing the content would create a meaningful service problem, accessibility should remain a delivery priority.

PSBAR monitoring creates a defined process for identifying accessibility issues and giving organisations an opportunity to address them.

A monitoring finding does not mean every issue immediately becomes an enforcement action.

The important point is to understand the escalation route and respond within the available correction period.

The Government Digital Service monitors public sector websites and applications for accessibility compliance.

Where monitoring identifies outstanding issues, the organisation is given a period to correct them.

The approved regulatory guidance describes a 12 week correction window for addressing identified issues before escalation.

That period should be treated as a remediation deadline, not as additional time to decide whether the issue matters.

Once a monitoring notice arrives, establish a remediation owner immediately.

Create a short action register covering each identified issue, the affected page or component, the required fix, the responsible team, evidence of completion, and the expected completion date.

If issues remain unresolved after the correction period, the matter can be referred to the relevant enforcement body.

In England, the Equality and Human Rights Commission can consider further enforcement action. In Northern Ireland, the Equality Commission for Northern Ireland has the relevant enforcement role.

The escalation process makes timely remediation important.

The objective should not be to produce evidence only after escalation. A stronger governance model identifies accessibility gaps continuously and addresses them as part of normal delivery.

PSBAR contains specific exceptions covering certain types of content.

These include narrow circumstances involving heritage collections and live streamed media.

The existence of an exception does not create a general exclusion for healthcare websites.

Most operational NHS website content will need to be assessed according to the applicable accessibility requirements.

If your organisation believes an exception applies, document exactly which content it covers and why.

Do not extend the exception to unrelated pages or functionality.

If GDS has identified issues, treat the notice as a structured remediation exercise.

A practical response should:

Use the following checklist during procurement, project kickoff, annual governance reviews, and major website releases.

Do not treat the checklist as a one-time certification exercise.

Your website can change through new content, templates, forms, integrations, and releases. The compliance position therefore needs to remain connected to the live service.

Our full NHS website compliance checklist provides a broader project-level view across NHS digital standards, including requirements that sit alongside PSBAR.