Accessibility testing is the process of checking whether a web application can be used by people with disabilities, including those who rely on screen readers, keyboard navigation, voice control or magnification software. For a business commissioning a CRM, portal, internal tool or SaaS product, the question is not whether testing happened, but what form it took, what it covered and what evidence the supplier can provide.
Decision summary: Agree WCAG 2.2 scope, critical journeys, manual methods, issue severity, remediation and retest evidence before sign-off.
Testing typically involves two broad categories. Automated checks use software tools to scan pages for detectable problems: missing alt text on images, incorrect heading hierarchy, low colour contrast, missing form labels and similar issues. These tools are fast and repeatable, but they only catch a portion of real barriers. Manual testing involves a person — ideally someone with relevant experience or who uses assistive technology — working through the application's key tasks to find problems that automated tools cannot detect, such as whether a workflow makes sense when read aloud by a screen reader or whether a custom interactive component is operable by keyboard alone.
The Web Content Accessibility Guidelines (WCAG) are the standard most businesses reference when specifying accessibility requirements. WCAG is organised around principles (perceivable, operable, understandable, robust) and three conformance levels: A, AA and AAA. Most commercial specifications target Level AA as a practical baseline. However, simply writing "WCAG 2.2 AA compliant" in a contract without defining what that means in testing terms leaves significant room for disagreement later.
The distinction between planning accessibility into a system and testing for it matters. Planning — covered separately in this guide — is about making design and development decisions that reduce barriers from the start. Testing is about verifying that those decisions produced a usable result and catching what was missed. A business can have strong accessibility planning and still receive an application with serious problems if testing was superficial or absent.
| Accessibility area | User impact | Evidence |
|---|---|---|
| What to specify in a statement of work | When a business is procuring a web application, the contract or statement of work should set out what testing will be performed, by whom, at what stage and what will be delivered as evidence. | Retain test scope, issue evidence, remediation and retest status. |
| Internal tools versus customer-facing portals | The rigour of testing should reflect who uses the system and what the consequences of inaccessibility are. | Retain test scope, issue evidence, remediation and retest status. |
| Who should perform the testing | There is a meaningful difference between a development team testing its own work and an independent party testing it. | Record scope, method, findings, owner, remediation and retest result. |
| When testing should happen | Testing only at the end of a project is a common and expensive approach. | Record scope, method, findings, owner, remediation and retest result. |
Test against WCAG 2.2 and the actual service context
For UK public-sector websites and mobile applications, current government practice uses WCAG 2.2 AA as the technical baseline alongside the 2018 accessibility regulations and an accessibility statement. Other organisations may have duties under the Equality Act 2010 and contractual or sector requirements, but the exact legal position is not identical.
A credible test combines automated tools, keyboard review, screen-reader use, zoom and reflow, contrast checks, form and error-state testing, and manual assessment of dynamic workflows. The report should identify scope, environment, methods, severity, evidence and retest status.
What to specify in a statement of work
When a business is procuring a web application, the contract or statement of work should set out what testing will be performed, by whom, at what stage and what will be delivered as evidence. Vague language such as "the application will be tested for accessibility" creates disputes. Instead, the requirement should name the standard (for example, WCAG 2.2 Level AA), list the testing methods (automated scan, manual keyboard testing, screen reader testing), identify the pages and user journeys to be tested and state what documentation the supplier will provide.
Internal tools versus customer-facing portals
The rigour of testing should reflect who uses the system and what the consequences of inaccessibility are. A customer portal where users submit applications, view statements or manage accounts carries higher risk than an internal admin panel used by a small team of known staff — although even internal tools may need to meet accessibility requirements if an employee has a disability and the system affects their ability to do their job. For a SaaS product sold to other businesses, accessibility is often a procurement requirement for your customers, making it a commercial concern as well as a legal one.
Who should perform the testing
There is a meaningful difference between a development team testing its own work and an independent party testing it. Self-testing catches obvious issues and is a necessary part of development, but it carries an inherent conflict of interest. An independent tester — whether an internal accessibility specialist, a hired consultant or a specialist agency — brings distance and is more likely to find problems the team has become accustomed to. Some businesses require both: developer testing throughout the build, followed by independent testing before acceptance.
When testing should happen
Testing only at the end of a project is a common and expensive approach. Problems discovered after development are complete may require significant rework. A more effective pattern is to test key components and templates early — for example, checking that the design system's form components, navigation pattern and data tables work with assistive technology before those patterns are replicated across dozens of pages. Final testing then focuses on the assembled application rather than uncovering fundamental design flaws.
Evidence to request
A business should expect to receive a test report that lists the pages and journeys tested, the methods used, the issues found and their severity. For each issue, the report should state which WCAG success criterion it relates to, the steps to reproduce it and, where relevant, a screenshot or screen recording. The report should also distinguish between issues the supplier will fix before handover and any known limitations or third-party dependencies that remain. A simple "passed" or "failed" summary without underlying detail is not sufficient for a business to make an informed acceptance decision.
Relying solely on automated tools
This is the most frequent mistake. Automated tools can scan a page in seconds and produce a report, which creates a false sense of completeness. Research consistently shows that automated tools catch roughly 30 to 40 percent of accessibility issues. The remaining problems — keyboard traps, illogical reading order, confusing link text, inaccessible custom widgets — require human judgement. A supplier that offers only an automated scan as its accessibility testing is not providing adequate coverage.
Testing only a homepage or a single page
Some test reports cover a single page, often the login screen or homepage, and present that as evidence of overall accessibility. A web application's accessibility depends on the journeys users actually perform: searching records, completing a multi-step form, editing data in a table, downloading a document. Testing should cover the application's core tasks, not just its entry point.
Not defining what "pass" means
Even with WCAG as a reference, disagreements arise over whether a particular issue constitutes a failure. A business should agree with its supplier in advance on how severity will be classified, how many issues of each severity are acceptable at each stage and what happens when issues are found. Without this, acceptance testing becomes a negotiation rather than a verification step.
Ignoring third-party components
Many web applications embed third-party elements: charting libraries, rich text editors, payment forms, map widgets, embedded iframes from other services. These components are often the least accessible part of an application. Testing should explicitly cover them, and the business should understand which issues are within the supplier's control to fix and which depend on a third party.
Limitations of testing
No testing process can guarantee that an application is fully accessible to every user in every situation. Assistive technology combinations are numerous, user needs vary widely and some barriers only become apparent in real-world use. Testing reduces risk; it does not eliminate it. A business should treat accessibility testing as part of an ongoing commitment — including monitoring after launch and having a process for users to report barriers — rather than a one-time gate that confers permanent compliance.
Key questions to put to a supplier
- Which WCAG version and conformance level are you testing against?
- What proportion of testing is automated versus manual?
- Which assistive technologies do you test with, and on which browsers and operating systems?
- Which pages, roles and user journeys does your test scope cover?
- Who performs the manual testing — your development team or an independent tester?
- What does your test report look like? Can you share a redacted example?
- How do you classify issue severity, and what is your remediation process?
- How do you handle accessibility problems in third-party components you did not build?
- What happens if new issues are discovered after handover?
These questions are not exhaustive, and the specific regulatory context for a business — particularly for public-sector bodies — may impose additional requirements. For the purposes of specifying and accepting testing work, however, they establish whether a supplier has a considered process or is treating accessibility as a box-ticking exercise. A supplier that cannot answer them clearly is unlikely to deliver testing that gives a business genuine confidence in its application.
Accessibility evidence to retain
- Identify the critical journeys and users that must be included in manual testing.
- Use WCAG 2.2 AA as a practical testing baseline where appropriate, while documenting any additional user or sector requirements.
- Test with keyboard operation, screen readers, zoom, reflow, contrast and realistic error states.
- Keep an evidence-backed remediation plan and retest after significant changes.
Primary guidance checked for this edition
Sources for “Accessibility Testing: What a Business Should Require” were checked on 22 July 2026. Recheck the applicable rules, product documentation and contractual terms before implementation because these can change after the review date.