Mastering UK Public Sector Accessibility Testing for Continuous Compliance

By Sahil Chaudhary · Last updated 22 Oct 2026

In the UK, digital services offered by public sector bodies and regulated organisations face stringent accessibility requirements. Non-compliance isn't just a reputational risk; it carries legal penalties and alienates a significant portion of the population. Ensuring your web applications and mobile apps meet these standards demands more than a one-off audit – it requires a continuous, integrated testing strategy.

TL;DR: UK public sector and regulated services must implement continuous accessibility testing to comply with the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 (PSBAR) and WCAG 2.2 AA. This involves integrating automated checks, manual testing, and user feedback, alongside maintaining transparent, up-to-date accessibility statements as guided by the GOV.UK Service Manual.

Key takeaways

• **Legal Mandate:** UK public sector bodies are legally required to make their digital services accessible under PSBAR, adhering to WCAG 2.2 AA.
• **Continuous Process:** Accessibility is not a one-time audit but an ongoing commitment, integrated throughout the software development lifecycle (SDLC).
• **Hybrid Testing:** Combine automated tools for speed with essential manual testing, including assistive technology and user feedback, for comprehensive coverage.
• **GOV.UK Service Manual:** Leverage its guidelines for designing and delivering accessible services, ensuring consistent user experience and compliance.
• **Transparent Reporting:** Maintain accurate and regularly updated accessibility statements, backed by robust testing evidence, to meet regulatory expectations.

The Mandate: Why UK Public Sector Accessibility is Non-Negotiable

For organisations operating in the UK public sector, accessibility is not merely a best practice; it's a legal imperative. The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 (PSBAR) legally mandate that public sector websites and mobile applications must be accessible. This regulation transposes the EU Web Accessibility Directive into UK law, ensuring that digital services are usable by everyone, including those with disabilities.

The core technical standard for compliance is WCAG 2.2 AA (Web Content Accessibility Guidelines 2.2 Level AA). This comprehensive set of guidelines covers a wide range of recommendations for making web content more accessible. Achieving this level of conformance ensures that your digital services are perceivable, operable, understandable, and robust.

Beyond the technical standards, PSBAR also requires public sector bodies to publish and regularly update an accessibility statement. This statement must detail your level of compliance, explain any non-accessible content, and provide a clear process for users to report accessibility issues. The statement acts as a public commitment to accessibility and is a critical component of your overall compliance strategy.

Beyond Launch: Embedding Continuous Accessibility Testing in Your SDLC

The traditional approach of a single accessibility audit before launch is insufficient for sustained compliance, especially within the dynamic environment of UK public sector digital services. The GOV.UK Service Manual itself advocates for continuous improvement and user-centred design, which inherently extends to accessibility. This means integrating accessibility checks throughout your software development lifecycle (SDLC), shifting from reactive fixes to proactive prevention.

This continuous approach ensures that new features, content updates, and platform migrations do not inadvertently introduce accessibility barriers. By embedding testing early and often, you reduce the cost and effort of remediation, foster a culture of inclusive design, and maintain consistent compliance. Krapton engineers prioritise building quality in from the start, a philosophy deeply integrated into our QA and software testing services.

Automated Accessibility Checks in CI/CD

Automated tools are an essential first line of defence for catching common accessibility issues quickly. Integrating these tools into your Continuous Integration/Continuous Deployment (CI/CD) pipeline allows for immediate feedback on every code change, preventing regressions from reaching production.

Tools like Axe-core, integrated via Lighthouse CI or directly into testing frameworks like Playwright, can scan your UI for violations of WCAG rules related to colour contrast, missing alt text, incorrect ARIA attributes, and structural issues. While automated checks typically cover only 30-50 per cent of WCAG issues, they are invaluable for their speed and consistency.

// Example Playwright test with Axe-core for accessibility checks
import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test.describe('Homepage accessibility', () => {
  test('should not have any detectable accessibility issues', async ({ page }) => {
    await page.goto('https://your-public-sector-service.gov.uk/');

    const accessibilityScanResults = await new AxeBuilder({ page }).analyze();

    expect(accessibilityScanResults.violations).toEqual([]);
  });
});

Manual & Assistive Technology Testing

Automated tools cannot replicate the real-world experience of users with disabilities. Manual testing is crucial for evaluating complex interactions, keyboard navigation, logical content flow, and the effectiveness of assistive technologies. This includes:

• **Keyboard Navigation:** Ensuring all interactive elements are reachable and operable using only the keyboard.
• **Screen Reader Testing:** Using tools like NVDA (Windows), VoiceOver (macOS/iOS), or TalkBack (Android) to verify content is announced correctly and navigation is intuitive.
• **Zoom and Magnification:** Checking that content reflows correctly and remains legible when zoomed up to 200-400 per cent.
• **User Testing:** Engaging individuals with diverse disabilities to gain authentic feedback on usability and identify barriers that technical checks might miss. This is especially vital for public sector services, where inclusive access is paramount.

Crafting Your UK Public Sector Accessibility Testing Strategy

A robust strategy for UK public sector accessibility requires a blend of different testing methods. The choice and frequency depend on your project's complexity, budget, and the criticality of the service. Below is a table outlining common testing methods and their suitability for public sector needs:

Testing Method	Description	Pros for Public Sector	Cons for Public Sector	Cost & Effort
**Automated Checks**	Tools (e.g., Axe-core, Lighthouse) integrated into CI/CD for quick scans.	Fast, scalable, catches ~30-50% of WCAG issues, good for regressions.	Limited coverage, can't assess user experience or complex interactions.	Low initial setup, minimal ongoing cost.
**Manual/Keyboard Testing**	Human testers navigating with keyboard, checking focus, tab order.	Essential for operability, good for form validation and interactive components.	Time-consuming, requires trained testers.	Moderate, depends on tester experience and scope.
**Screen Reader Testing**	Testers using screen readers to verify content and navigation.	Critical for visually impaired users, identifies semantic and content flow issues.	Requires specialised skills, can be slow.	Moderate to High, often needs expert testers.
**Expert Accessibility Review**	Experienced accessibility specialists conducting thorough audits.	Comprehensive WCAG compliance check, identifies subtle issues, provides detailed recommendations.	Can be expensive, typically a snapshot in time.	High, often a project-based cost.
**User Testing with Disabilities**	Real users with disabilities test the service and provide feedback.	Invaluable for real-world usability, identifies critical blockers, builds empathy.	Logistically complex, requires recruitment and facilitation.	High, includes participant incentives and coordination.

When NOT to use this approach

While comprehensive accessibility testing is paramount for most UK public sector digital services, this intensive approach may be overkill for extremely niche internal tools that are not public-facing, have a very limited and known user base, and are explicitly exempt under PSBAR (e.g., legacy systems with disproportionate burden justifications, or content published before September 2018). Always consult official government guidance and legal advice before making such determinations.

Data, Evidence, and Reporting: Meeting UK Procurement & ICO Expectations

For UK public sector organisations, demonstrating compliance extends beyond simply fixing issues; it involves providing clear, verifiable evidence. Procurement teams often require proof of accessibility standards in supplier contracts, and the Information Commissioner's Office (ICO) is responsible for enforcing PSBAR. Robust reporting is therefore crucial.

Your testing process should generate an audit trail that documents:

• **Test Plans:** What was tested, by whom, and using what methodology.
• **Issues Log:** Detailed records of identified accessibility barriers, their WCAG reference, severity, and remediation status.
• **Test Results:** Screenshots, video recordings of user testing, and output from automated tools.
• **Remediation History:** When issues were fixed, by whom, and re-tested.

This evidence directly feeds into your accessibility statement, ensuring it is accurate and reflects the current state of your service. Regular reviews and updates of this statement are mandatory, especially after significant changes or new feature deployments. Choosing a software development agency in the UK that understands these intricate requirements can significantly streamline your compliance efforts.

Key Challenges and How to Overcome Them

Implementing and maintaining continuous accessibility in the public sector comes with unique challenges:

• Legacy Systems Integration: Many public sector bodies rely on older systems that were not built with modern accessibility in mind. Incremental improvements, using accessibility overlays where appropriate (with caution), and strategic replatforming are necessary.
• Third-Party Components and Suppliers: Services often integrate third-party tools (e.g., payment gateways, mapping services). It's vital to include accessibility requirements in procurement contracts and verify the accessibility of these components. Your suppliers must also demonstrate their commitment to WCAG 2.2 AA.
• Training Internal Teams: Developers, designers, content creators, and QA engineers all play a role in accessibility. Regular training ensures that accessibility considerations are integrated into every stage of the development process, not just at the testing phase.
• Budget and Resources: Securing funding and dedicated personnel for ongoing accessibility work can be challenging. Highlighting the legal risks, improved user experience for all citizens, and reduced long-term costs of proactive design can help build a strong business case.

FAQ: Your UK Public Sector Accessibility Questions Answered

What is the GOV.UK Service Manual's role in accessibility?

The GOV.UK Service Manual provides comprehensive guidance for designing, building, and running government digital services. It embeds accessibility as a core principle, offering practical advice on meeting WCAG 2.2 AA standards throughout the service design and development process, from research to going live and beyond.

How often should accessibility statements be updated?

Accessibility statements must be reviewed and updated regularly, especially after any significant changes to your website or mobile application, or at least annually. This ensures the statement accurately reflects your current compliance status and any planned improvements, maintaining transparency with users and regulators.

Does WCAG 2.2 AA apply to all UK businesses?

While WCAG 2.2 AA is best practice for all digital services, the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 (PSBAR) specifically mandate compliance for UK public sector bodies. Other businesses, however, are still subject to the Equality Act 2010, which requires them not to discriminate against disabled people, often implying a need for accessible digital services.

What are the penalties for non-compliance with PSBAR?

The Information Commissioner's Office (ICO) can take enforcement action against public sector bodies that fail to comply with PSBAR. While specific monetary penalties are not explicitly outlined in the regulations for accessibility failures, the ICO has broad powers under the Data Protection Act 2018 and can issue enforcement notices, requiring organisations to take specific steps to become compliant, or potentially face fines for non-compliance with those notices.

Build Compliant, Accessible Digital Services with Krapton

Navigating the complexities of UK public sector accessibility testing requires deep technical expertise and a clear understanding of regulatory requirements. Our engineering team builds software with a focus on comprehensive testing and compliance from the outset. Want shipping confidence and services that meet every UK standard? Book a free consultation with Krapton to discuss your custom software development needs.

About the author

Krapton Engineering is a team of principal-level software engineers dedicated to building robust web, mobile, SaaS, and AI solutions. We focus on engineering excellence, ensuring every product is thoroughly tested, secure, and production-ready, covering everything from core architecture to intricate compliance requirements.