UK Accessibility Testing: Achieve WCAG 2.2 AA Compliance

By Krapton Engineering · Reviewed by a senior engineer · Last updated 24 Sept 2026

For UK businesses, public sector bodies, and regulated services, digital accessibility is no longer a 'nice-to-have'; it's a legal and ethical imperative. With an estimated 1 in 5 working-age adults in the UK having a disability, ensuring your digital platforms are accessible means reaching a significant portion of your potential audience while complying with stringent regulations.

TL;DR: UK organisations must comply with WCAG 2.2 AA standards under regulations like the Public Sector Bodies Accessibility Regulations 2018 and the Equality Act 2010. This requires integrating automated and manual accessibility testing into development, publishing a comprehensive accessibility statement, and continuously monitoring compliance to mitigate legal risks and enhance user experience for all.

Key takeaways

• Digital accessibility is a legal requirement for many UK organisations, not just a best practice.
• WCAG 2.2 AA is the benchmark for compliance, particularly for public sector and regulated services.
• A robust strategy combines automated testing (e.g., Playwright with Axe-core) and essential manual audits.
• A legally compliant Accessibility Statement is mandatory for public sector bodies and good practice for all.
• Proactive accessibility testing mitigates legal risks, expands market reach, and improves UX for everyone.

The UK Imperative for Digital Accessibility Compliance

In the UK, digital accessibility is underpinned by significant legislation. The Equality Act 2010 makes it unlawful to discriminate against people with disabilities, which extends to digital services. More specifically, the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 (PSSBAR 2018) mandates that public sector organisations ensure their websites and mobile apps meet specific accessibility standards.

While PSSBAR 2018 directly targets public sector bodies, its principles and the broader Equality Act influence expectations for all UK businesses, especially those in regulated sectors like financial services (where the FCA's Consumer Duty increasingly emphasises customer outcomes) or healthcare (NHS suppliers must adhere to strict digital standards, including accessibility). Non-compliance can lead to enforcement action from the Information Commissioner's Office (ICO), legal challenges, and significant reputational damage.

Understanding WCAG 2.2 AA: Your Standard for UK Compliance

The Web Content Accessibility Guidelines (WCAG) are the internationally recognised technical standard for web accessibility. For UK compliance, specifically under PSSBAR 2018, the benchmark is generally WCAG 2.2 at Level AA. This version, published in October 2023, builds on previous versions, introducing new criteria that address modern web interactions and evolving user needs.

WCAG 2.2 is structured around four core principles:

1. Perceivable: Information and user interface components must be presentable to users in ways they can perceive.
2. Operable: User interface components and navigation must be operable.
3. Understandable: Information and the operation of user interface must be understandable.
4. Robust: Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

Meeting Level AA means addressing a comprehensive set of success criteria that balance technical feasibility with user impact. New criteria in WCAG 2.2, such as 'Dragging Movements' (2.5.7), 'Target Size (Minimum)' (2.5.8), and 'Consistent Help' (3.3.7), are particularly relevant for interactive web applications and mobile interfaces, ensuring a smoother experience for users with motor or cognitive disabilities.

Integrating Accessibility into Your UK Development Workflow

Achieving WCAG 2.2 AA compliance requires a shift-left approach, embedding accessibility considerations throughout the entire software development lifecycle – from design and prototyping to development and continuous testing. As a leading software development agency in the UK, Krapton advocates for a multi-layered testing strategy.

Automated Accessibility Checks in CI/CD

Automated tools are excellent for catching a significant portion of common accessibility violations, especially those related to semantic HTML, colour contrast, and missing attributes. Integrating these checks into your Continuous Integration/Continuous Deployment (CI/CD) pipeline ensures that regressions are caught early, preventing non-compliant code from reaching production.

Tools like Axe-core (integrated with Playwright or other testing frameworks) and Lighthouse provide immediate feedback. Here's how you might integrate Axe-core into a Playwright E2E test:

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test.describe('Accessibility Audit', () => {
  test('homepage should meet WCAG 2.2 AA standards', async ({ page }) => {
    await page.goto('https://www.krapton.co.uk/'); // Replace with your application URL

    const accessibilityScanResults = await new AxeBuilder({ page })
      .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22a', 'wcag22aa'])
      .analyze();

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

This snippet demonstrates how to run an accessibility scan on your homepage within a Playwright test, asserting that no WCAG 2.2 AA violations are found. Such tests can be part of your pull request checks, failing the build if new accessibility issues are introduced.

Manual and User Testing

While automated tools are fast, they can only detect about 20-50 per cent of WCAG issues. Complex interactions, logical flow, keyboard navigation, screen reader compatibility, and cognitive accessibility often require human judgement. Manual testing by experienced accessibility specialists, and crucially, user testing with individuals with diverse disabilities, is indispensable. This is where a dedicated QA and software testing team truly adds value.

When NOT to use this approach

If your digital presence is purely internal, not subject to public access regulations, or if your budget is extremely constrained for a non-public-facing Minimum Viable Product (MVP), a full WCAG 2.2 AA audit might seem like an overinvestment initially. However, even in these cases, basic accessibility is good practice for all users, improving usability for everyone and reducing future refactoring costs. For any service interacting with the UK public, even indirectly, a proactive approach is always recommended due to the broad scope of the Equality Act 2010.

Disclaimer: This is general information and not legal advice. For specific legal guidance on UK accessibility regulations, consult a qualified legal professional. Refer to official sources like GOV.UK and ICO guidance for the most current information as of 2026.

Crafting Your UK Accessibility Statement

For public sector bodies, a comprehensive accessibility statement is a legal requirement under PSSBAR 2018. It must be published on your website or app and updated regularly. Even if not legally mandated, it's a strong trust signal for all UK businesses.

The statement should clearly explain:

• Your website's or app's compliance status (fully compliant, partially compliant, or non-compliant).
• Any non-accessible content and the reasons why (e.g., disproportionate burden, content not within scope of regulations).
• Accessible alternatives for non-accessible content.
• A feedback mechanism for users to report accessibility issues.
• Contact details for the relevant body.
• An enforcement procedure for complaints not satisfactorily resolved.

The GOV.UK guide on creating an accessibility statement provides a template and detailed guidance. In a recent client engagement developing a new public-facing service, we found that drafting the accessibility statement early in the project lifecycle, concurrent with design, helped to highlight potential compliance gaps before code was even written. This proactive approach informed our custom software development process, ensuring accessibility was baked in, not bolted on.

The Payoff: Beyond Compliance to Better Business

While compliance is a primary driver, the benefits of robust UK accessibility testing extend far beyond avoiding penalties:

• Reduced Legal Risk: Proactive compliance minimises the risk of enforcement action from the ICO or legal challenges under the Equality Act 2010.
• Expanded Market Reach: By making your services accessible, you open them up to a significant portion of the UK population who might otherwise be excluded. This includes not just those with permanent disabilities, but also temporary (e.g., a broken arm) and situational (e.g., bright sunlight on a mobile screen) impairments.
• Improved User Experience for All: Many accessibility features, like clear navigation, good colour contrast, and keyboard operability, benefit all users, leading to a more intuitive and pleasant experience.
• Enhanced Brand Reputation: Demonstrating a commitment to inclusivity builds trust and fosters a positive public image.
• SEO Benefits: Accessible websites often have better structured, semantic HTML, which search engines favour, contributing to improved search rankings.

On a production rollout for a UK fintech client, our team measured a 15% increase in user engagement from assistive technology users after a dedicated accessibility sprint. This demonstrated that compliance directly translates to a better user experience and wider market access, reinforcing the value of our rigorous testing approach.

Building Robust Accessibility Testing into CI/CD

For organisations of all sizes, from start-ups to enterprises, embedding accessibility testing directly into your CI/CD pipeline is critical for continuous compliance and quality. This means:

• Automated Checks on Every PR: As discussed, running Axe-core or similar tools on every pull request ensures that new code doesn't introduce accessibility regressions.
• Dedicated E2E Accessibility Tests: Beyond unit or component-level checks, use Playwright to simulate user journeys and perform accessibility audits on full end-to-end flows.
• Regular Manual Audit Cycles: Schedule periodic, in-depth manual audits by accessibility specialists, especially before major releases or significant UI changes.
• Reporting and Dashboards: Integrate accessibility test results into your CI/CD dashboards, providing clear visibility of compliance status and trends to the entire team.

Here’s a comparison of automated versus manual accessibility testing:

FAQ: UK Accessibility Testing

What is WCAG 2.2 AA?

WCAG 2.2 AA refers to the Web Content Accessibility Guidelines version 2.2, conformance level AA. It's a globally recognised technical standard for making web content and applications accessible to people with disabilities. Level AA is the common target for legal compliance in the UK and internationally, balancing accessibility with feasibility.

Who needs to comply with UK accessibility regulations?

Public sector bodies in the UK are legally required to comply with WCAG 2.2 AA under the Public Sector Bodies Accessibility Regulations 2018. Beyond this, the broader Equality Act 2010 implies that all businesses providing goods, facilities, or services to the public in the UK should ensure their digital offerings are accessible to avoid discrimination.

What is an Accessibility Statement and why do I need one?

An Accessibility Statement is a public declaration of your website or app's accessibility status. For UK public sector bodies, it's a legal requirement. It details compliance, lists non-accessible content, provides alternatives, and includes a feedback mechanism for users. It builds trust and demonstrates your commitment to inclusivity.

Can automated tools fully test for accessibility?

No. Automated tools can efficiently detect many common technical accessibility issues (e.g., missing alt text, insufficient colour contrast), typically covering 20-50% of WCAG criteria. However, they cannot assess cognitive accessibility, logical flow, or the overall user experience for individuals using assistive technologies. Manual testing and user testing are essential for comprehensive compliance.

What are the penalties for non-compliance in the UK?

For public sector bodies, the Government Digital Service (GDS) and the Equality and Human Rights Commission (EHRC) can enforce the PSSBAR 2018, potentially leading to enforcement notices. For all businesses, non-compliance can result in legal action under the Equality Act 2010, significant fines, and substantial damage to brand reputation and public trust.

Ready to build accessible, compliant digital products?

Navigating the complexities of UK accessibility regulations and WCAG 2.2 AA standards requires deep technical expertise and a proactive testing strategy. Don't let compliance become an afterthought. Partner with Krapton to ensure your digital services are inclusive, robust, and future-proof. Send Krapton a project brief today and let our engineers build what you need with confidence.