Accessibility Testing Tools and Techniques: UK Guide
Table of Contents
Accessibility testing tools and techniques are how development teams confirm that websites and applications work for people with disabilities, not just in theory, but in practice, across real devices and assistive technologies. For businesses in the UK and Ireland, this is not a niche concern. The Equality Act 2010 and the Public Sector Bodies Accessibility Regulations (PSBAR) create a legal obligation for organisations to make their digital content accessible.
ProfileTree works with SMEs across Northern Ireland and Ireland to build websites that meet accessibility standards from the ground up. In our experience, accessibility is treated as an afterthought far too often. By the time a site is built and live, fixing structural barriers is significantly more expensive than designing for inclusion from the start.
What Is Accessibility Testing?
Accessibility testing is the process of evaluating a website or application against established standards to confirm that users with visual, auditory, motor, or cognitive impairments can navigate and interact with it effectively.
The primary benchmark is the Web Content Accessibility Guidelines (WCAG), maintained by the World Wide Web Consortium (W3C). WCAG is built around four core principles, known as POUR:
- Perceivable — content can be seen or heard by all users
- Operable — all functions work via keyboard, not just a mouse
- Understandable — content is clear, and the interface behaves predictably
- Robust — content works across different browsers and assistive technologies
WCAG compliance is measured at three levels: A (minimum), AA (the legal and practical benchmark for most UK organisations), and AAA (maximum). Targeting Level AA is the standard expectation for public sector bodies under PSBAR and is widely adopted as the commercial baseline.
WCAG 2.2, published in October 2023, added nine new success criteria. The most practically significant additions cover touch target sizing, focus visibility, and dragging interaction areas that matter greatly for mobile users and those using switch devices.
UK Legal Context: What You Are Actually Required to Do
Most published guidance on accessibility testing is written for a US audience and focuses on the Americans with Disabilities Act (ADA) and Section 508. UK businesses operate under a different legal framework.
The Equality Act 2010 requires service providers not to discriminate against disabled people. Courts have found that inaccessible websites can constitute a failure to make reasonable adjustments, which is a breach of the Act.
PSBAR (the Public Sector Bodies Accessibility Regulations) go further for public sector organisations: they require compliance with WCAG 2.1 Level AA as a minimum, a published accessibility statement, and regular auditing. As of 2024, PSBAR was updated to reference WCAG 2.2, so public sector teams need to be testing against the newer standard.
For private sector organisations, PSBAR does not apply directly, but the Equality Act duty still holds. The safest position for any UK business is to treat WCAG 2.2 Level AA as the working target.
Automated Accessibility Testing Tools
Automated tools can scan a site and flag technical accessibility failures quickly. They are best used as a first pass to catch the obvious missing alt text, low colour contrast, and form inputs without labels. The key limitation is that automated tools typically detect around 30 to 40 per cent of real accessibility issues. The rest require human judgment.
Axe DevTools is the most widely used developer-facing tool. It runs as a browser extension in Chrome and Firefox, integrates with testing frameworks like Cypress and Jest, and reports against WCAG criteria with zero false positives as its design goal.
WAVE (Web Accessibility Evaluation Tool) from WebAIM provides a visual overlay directly on the page, highlighting errors, alerts, and structural features. It is well-suited for content editors and non-developers who need a readable summary without technical output.
Google Lighthouse is built into Chrome DevTools and produces an accessibility score alongside performance and SEO scores. It is useful for quick audits and CI/CD pipeline integration, though its accessibility coverage is less detailed than Axe.
Siteimprove is the enterprise option, offering continuous automated monitoring across an entire site rather than page-by-page testing. It generates compliance reports formatted for stakeholder reporting, which is useful for public sector teams with formal audit requirements.
A practical approach for most SMEs is to use Axe DevTools during development and WAVE for periodic content-level checks. Running Lighthouse in your browser gives a useful at-a-glance score. None of these replaces manual testing.
Manual Accessibility Testing Techniques
Manual testing is where accessibility work becomes real. These techniques simulate how users with disabilities actually experience a website.
Keyboard Navigation Testing
Unplug your mouse and navigate the entire site using only the keyboard. Use Tab to move forward, Shift+Tab to move back, Enter to activate links and buttons, and the arrow keys within menus and dropdowns. Check that a visible focus indicator appears at every interactive element. If you cannot complete a form, buy a product, or close a modal with keyboard alone, the site has a barrier that automated tools will often miss.
Screen Reader Testing
Screen readers convert on-screen content to speech or Braille. The most widely used are NVDA (free, Windows), JAWS (paid, Windows), and VoiceOver (built into macOS and iOS). Testing with a screen reader reveals whether heading structure is logical, whether images have meaningful alt text, whether buttons have descriptive labels, and whether dynamic content announces changes to the user.
For teams new to screen reader testing, starting with NVDA and Chrome on Windows is the most accessible entry point. Even a basic 30-minute test with NVDA navigating a key user journey will surface issues that no automated scan will catch.
Colour Contrast and Visual Testing
Use a contrast checker (WebAIM’s contrast checker is free) to verify that text meets the 4.5:1 ratio required for normal text at WCAG AA. Test the site with browser zoom set to 200 per cent to check that content reflows without horizontal scrolling. View the site in Windows High Contrast Mode to check whether interactive elements remain distinguishable.
Cognitive and Structural Testing
Read the page without any assumptions about prior knowledge. Is the language plain? Are error messages specific about what went wrong and how to fix it? Are forms labelled clearly? Does the navigation stay consistent across pages? These checks require human evaluation; no tool can reliably assess plain language or error message quality.
Testing for WCAG 2.2: The Nine New Criteria
Teams upgrading from WCAG 2.1 to 2.2 need to test nine additional success criteria. The three most practically significant are:
2.5.8 Target Size (Minimum) — Level AA. Interactive elements must be at least 24×24 CSS pixels. Test by overlaying a 24×24 grid on your page and checking that each button, link, and interactive element meets the minimum. Pay particular attention to icon-only buttons and close elements on modals.
2.4.11 Focus Appearance — Level AA. The keyboard focus indicator must meet specific contrast and size requirements. The indicator must have a contrast ratio of at least 3:1 between focused and unfocused states and enclose the component with a perimeter of at least the component’s CSS border-box perimeter.
2.5.7 Dragging Movements — Level AA. Any functionality that uses a dragging action (sliders, drag-and-drop interfaces) must also be achievable with a single pointer without dragging. Test every draggable element to confirm an alternative interaction exists.
The remaining six new criteria cover authentication, redundant entry, consistent help, accessible authentication (enhanced), focus appearance (enhanced), and focus not obscured (minimum). The W3C’s WCAG 2.2 Understanding documents provide testing procedures for each.
Building a Practical Testing Workflow
An effective accessibility testing process follows a “shift left” approach: testing begins during design and development, not after launch.
During design: check colour contrast in Figma or your design tool before any code is written. Review proposed component interactions for keyboard operability. Flag any animations that could cause issues for users with vestibular disorders.
During development: run Axe DevTools on each component as it is built. Write automated accessibility checks into your test suite using axe-core. Review the semantic HTML structure: are headings in a logical order, are lists marked up as lists, are buttons used for actions and links for navigation?
During QA: conduct full keyboard navigation testing on the complete user journey. Test with NVDA on Chrome. Check the site in High Contrast Mode and at 200 per cent zoom.
After launch: schedule quarterly WAVE or Siteimprove scans. Review your accessibility statement against the current state of the site. When new features are added, include accessibility testing in the definition of done.
As Ciaran Connolly, founder of ProfileTree, puts it: “Building accessibility into a project from day one costs a fraction of what remediation costs after launch. For most SME websites we work on, the technical changes are small — it’s the process discipline that makes the difference.”
How ProfileTree Approaches Accessibility in Web Projects
ProfileTree builds websites for SMEs across Northern Ireland, Ireland, and the UK using WordPress as the primary platform. Accessibility is part of the build standard, not an optional extra.
Our development process includes semantic HTML structure, keyboard-navigable navigation menus, accessible form labelling, and alt text requirements built into the content management workflow. For clients in the public sector or regulated industries, we carry out a full WCAG 2.2 Level AA audit as part of the project handover.
For businesses with existing sites, our web design and development services include accessibility audits that identify the highest-impact issues and prioritise fixes based on user journey criticality rather than working through a raw list of WCAG criteria.
Frequently Asked Questions
Got questions about accessibility testing? Here are answers to what UK developers and site owners ask most.
What are the four types of accessibility testing?
The four types are automated scanning, manual keyboard and screen reader testing, assistive technology testing with real users of those tools, and user testing with people who have disabilities.
Does automated testing guarantee WCAG compliance?
No. Automated tools typically catch 30 to 40 per cent of accessibility issues. Manual testing is required for full compliance.
What is the best free tool for accessibility testing?
WAVE and Axe DevTools (browser extensions) are both free and reliable starting points for most teams.
Is WCAG 2.2 legally required in the UK?
For public sector bodies under PSBAR, WCAG 2.2 Level AA is now the referenced standard. Private sector organisations are covered by the Equality Act 2010, which does not name a specific version but makes inaccessible services a legal risk.
How often should accessibility testing happen?
At a minimum, whenever new features are added and at quarterly intervals for established sites. Continuous automated monitoring via tools like Siteimprove is the most efficient approach for larger sites.
What is the difference between WCAG 2.1 and WCAG 2.2 testing?
WCAG 2.2 adds nine new success criteria to the 2.1 set. Teams testing against 2.2 need to add checks for target size, focus appearance, and dragging movements, among others. All 2.1 Level AA criteria still apply.