Accessibility Testing Services

Why accessibility matters

Millions of people use screen readers, keyboard navigation, magnification, voice control or captions to use digital products. If your site or app is not accessible, they cannot buy from you, apply for a job, book an appointment or use the service they pay for.

Accessibility also carries legal weight. In the United States, the ADA is regularly applied to websites and apps, and the number of digital accessibility lawsuits has grown year after year. Public-sector and education organisations have specific requirements under Section 508 and related rules. The widely accepted technical benchmark is WCAG 2.2 Level AA.

Problems we solve

• Forms and checkouts that cannot be completed with a keyboard
• Images and icons without text alternatives
• Low colour contrast and text that breaks when enlarged
• Custom components that screen readers announce incorrectly
• A customer complaint or demand letter about accessibility

What’s included

How an accessibility audit works

1. ScopeDays

   Choose representative pages, templates and critical journeys such as sign-up and checkout.

2. Automated scan1–2 days

   Tools such as axe and Lighthouse catch common issues quickly.

3. Manual testing1–2 weeks

   Experts test with keyboards and screen readers — automated tools find only a portion of issues.

4. Report & fixAs agreed

   Findings mapped to WCAG criteria with severity, screenshots and fixes; retest after remediation.

Accessibility is cheaper when built in

Fixing accessibility after launch means revisiting designs and code across the product. Building it in from the start costs far less: accessible colour palettes and focus styles in the design system, semantic HTML, labelled form fields, accessible component libraries and automated checks in the pipeline. We help teams adopt these habits so new features are accessible by default.

Timeline and budget

Typical ranges to help you plan. Your written estimate comes after a free discovery call.

Automated vs manual accessibility testing

Automated scanners are useful, but they only detect a portion of accessibility issues. Checks that need human judgement — whether alt text is meaningful, whether focus order makes sense, whether instructions are clear — require manual testing:

Common issues we find

• Custom dropdowns, date pickers and modals that cannot be operated by keyboard
• Form errors shown only in red without text or announcements
• Icon-only buttons without accessible names
• Low-contrast placeholder text used as labels
• Headings chosen for visual size rather than structure
• Content that appears dynamically without being announced
• PDFs and documents that are not tagged

Many of these come from a handful of shared components. Fixing the component once, in your design system, often resolves the issue across hundreds of pages.

Keeping accessibility from regressing

An audit captures a moment in time; without process, new issues appear with the next release. We help teams build accessibility into their workflow: automated checks in the CI pipeline that fail builds on clear violations, accessibility acceptance criteria in user stories, accessible components in the design system, a short keyboard and screen-reader check in the definition of done, and periodic manual re-audits of key journeys. Publishing an honest accessibility statement with a contact route also helps users report barriers you have not found yet.

WCAG 2.2: what changed and what we test

WCAG 2.2, published by the W3C in October 2023, keeps the earlier success criteria (apart from removing 4.1.1 Parsing) and adds new ones focused on mobile users, people with cognitive disabilities and keyboard users. Level AA is the standard most organisations and procurement teams ask for.

How we test with assistive technology

Manual testing uses the tools people with disabilities actually rely on. We test the most important user journeys — sign-up, login, search, checkout, forms — rather than random pages, because those journeys are where barriers cost users and businesses most.

From findings to fixes: the remediation workflow

1. Prioritise

   Rank issues by severity and by how many users and journeys they affect.

2. Fix patterns, not pages

   Most issues come from shared components; fixing a button or form field component fixes it everywhere.

3. Retest

   Verify each fix with the same tools used to find it.

4. Prevent regressions

   Add automated checks and component tests so fixed issues stay fixed.

Reports include the WCAG criterion, a screenshot or recording, steps to reproduce, the affected users and a code-level recommendation, so developers can act without guessing.

Documents, video and third-party content

• PDFs and documents — tagged structure, reading order, alternative text and form fields that work with screen readers.
• Video and audio — accurate captions, transcripts and audio description where visual information matters.
• Third-party widgets — chat tools, maps, booking engines and payment pages tested as part of the journey, with vendor follow-up where needed.
• Email templates — semantic structure, readable contrast and meaningful link text.

Accessibility statements and conformance reports

After testing and remediation, many organisations publish an accessibility statement describing the standard they aim for, known limitations and how to report problems. Software vendors selling to government and large companies are often asked for an Accessibility Conformance Report based on the VPAT template. We provide the testing evidence for these documents; the statement or report itself is published by you, describing your product honestly.

Related services

Part of our QA & testing services. Accessible design is built into our UI/UX design and design system work.

This page is part of QA & Software Testing Services — see the full overview for related services, approach and pricing.