Public Sector Bodies Accessibility Regulations 2018: What You Need to Know

Public Sector Bodies Accessibility Regulations 2018 set out duties for most UK public sector websites and mobile apps to be accessible. This article explains the requirements, what to publish, how to test, and practical steps you can use today.

What the Regulations require

The Regulations require public sector bodies to make their web content and mobile apps accessible. You must publish an accessibility statement and provide a way for users to report problems. You must also set out what content is not accessible and, where possible, offer alternatives.

Who the Regulations cover

The rules apply to most core public sector organisations. That typically includes central government departments, local authorities, NHS bodies and state-funded schools. Some organisations and some content types can be out of scope. Check official guidance for a definitive list that applies to your organisation.

Technical benchmark and standards

The Regulations refer to accessibility requirements rather than a single technical standard. In practice, UK public sector guidance commonly uses WCAG 2.1 level AA as the technical benchmark. For procurement and ICT, EN 301 549 is the harmonised standard often cited. Use these when you write acceptance criteria and test plans.

Core duties every public body must follow

• Make websites and mobile apps accessible, both new and existing where required.
• Publish an accessibility statement that is easy to find.
• Provide a transparent process for reporting accessibility problems and for replying to reports.
• Keep records of known problems and publish plans to fix them.
• Consider accessibility when procuring digital services and products.

What an accessibility statement must contain

Your accessibility statement should be concise and factual. At a minimum include:

• The scope of the statement, for example which website or app it covers.
• Your assessment of whether content conforms to the accessibility requirements.
• Clear list of content that is not accessible and brief reasons why.
• Alternative ways to access the information or service where possible.
• Contact details so users can report problems and request content in another format.
• The date of the statement and when it will next be reviewed.

Quick template for an accessibility statement

Use this short template and fill the brackets.

• Scope: This statement covers [site or app URL].
• Conformance: [conforms / partly conforms / does not conform] with the accessibility requirements.
• Non-accessible content: [short list or explanation of types of content not accessible].
• Alternatives: [how users can access content or services in other ways].
• Feedback: Report accessibility problems at [contact email or form]. We will reply within [timeframe].
• Review: Statement last reviewed on [date].

How to test and prove accessibility: a practical test plan

Testing needs automated checks and real-user tests. Put both into a simple plan and keep results as evidence.

Automated checks

• Run a site-wide tool such as axe, WAVE or Lighthouse to find common issues.
• Record the report, page sampled, and date.

Manual checks

• Keyboard only: complete common tasks without a mouse.
• Screen reader: test critical pages with NVDA on Windows or VoiceOver on iOS.
• Forms and controls: verify labels, error messaging and focus order.
• Media: check captions for video and transcripts for audio.
• Colour and contrast: test with a contrast tool and check for colour-dependent meaning.

Evidence and acceptance criteria

Agree pass-fail criteria before testing. For example, set a maximum number of WCAG 2.1 AA failures per priority page. Keep signed-off reports and a log of fixes linked to tickets.

Common accessibility issues and quick fixes

• Missing alt text: add meaningful alt for images used for content.
• Poor heading structure: use a logical H1 to H3 hierarchy for pages.
• Keyboard traps: ensure users can tab into and out of interactive components.
• Unlabelled form controls: add explicit labels and aria-describedby where needed.
• Low contrast: raise text contrast to meet WCAG 2.1 AA ratios.
• Video without captions: add captions or provide a transcript.

Procurement tips for accessible digital services

Make accessibility a pass-fail requirement in invitations to tender. Include acceptance tests based on WCAG 2.1 AA and require suppliers to deliver test evidence. Ask for a maintenance plan that covers accessibility monitoring and updates.

A practical process for handling user reports

1. Acknowledge receipt quickly and give an expected reply time.
2. Record the report in a central ticket system and mark priority.
3. Provide a short-term workaround if available.
4. Assign to a developer or content owner and log remediation steps.
5. Reply to the reporter when the issue is resolved and update the accessibility statement if needed.

Governance, monitoring and training

Assign clear roles for accessibility ownership. Keep an issues register and set periodic audits. Train content authors and developers on accessible practices. Small, regular checks keep the backlog manageable.

Where to get further guidance

Use the official public sector accessibility guidance and technical standards as your starting point. Useful references include WCAG 2.1, EN 301 549 and materials from accessibility-focused organisations and vendors. If you need independent assurance, hire an accessibility specialist to run a formal audit and provide remediation recommendations.

Following the Public Sector Bodies Accessibility Regulations 2018 is an ongoing programme, not a one-off project. Start with a clear accessibility statement, a simple test plan, and a record of fixes. That approach keeps you compliant and improves access for users.