A clean scanner report and a usable product are different claims
Accessibility Testing
Automated accessibility scanners are useful and badly incomplete at the same time. They catch missing alt text and contrast ratios reliably, and they miss almost everything about whether a screen reader user can actually complete a task. This practice pairs automated scanning with manual testing on real assistive technology, because a clean scanner report and a usable product are two separate claims.
Why a manual assistive-technology pass runs on every audit
Screen reader testing, keyboard navigation and the gap automated scanning leaves open.
90 secSample frame · video pending01Before scheduling the audit
Automated scanning alone will not tell you the truth
A scanner report and a usable product are different claims, and the gap between them is exactly where most real accessibility complaints originate. Four questions decide how much manual testing a given engagement actually needs.
How complex are the interactive components?
A simple content page needs less manual verification than a multi-step form or a custom widget built outside the standard component library.
Which assistive technologies do real users rely on?
Screen reader, switch access and voice control users each surface different barriers, and testing only one leaves the others unverified.
What conformance level has actually been promised?
WCAG 2.1 AA is the common commitment, but a public sector or enterprise contract sometimes names AAA criteria that change the testing scope.
Is this a one-time audit or ongoing conformance?
A pre-launch audit is scoped as a single pass, while ongoing conformance needs a recurring check wired into the release pipeline instead.
| Automated scanning | Manual AT testing | |
|---|---|---|
| Coverage | Fast, broad, shallow | Slower, narrow, accurate |
| Catches | Missing alt text, contrast ratios | Task completion, focus order, real announcement |
| Cost per pass | Low | Higher, worth it for real barriers |
| Best fit | Continuous pipeline gate | Pre-launch and periodic verification |
02Agreed before testing starts
The ledger that keeps an audit honest
Accessibility engagements go wrong when a scanner's pass becomes the whole story and nobody checks whether a real screen reader user can finish the task. This ledger sets out what you bring, what we test, what comes back, and what always stays with your product team.
- Your side
You bring
- The product or feature scheduled for launch
- Any target WCAG conformance level already agreed with stakeholders
- Existing design system components and their current markup
- Our side
We build
- Automated scanning across every screen and state
- Manual testing with a screen reader and keyboard-only navigation
- A written list of conformance gaps ranked by severity
- Your side
You receive
- A conformance report mapped to specific WCAG criteria
- A prioritised remediation list a development team can act on
- Verification testing once the highest-severity fixes ship
Never leaves you
- The product and its design system
- The decision on which fixes ship before launch versus after
- The relationship with your design and engineering teams
Where the line sitsWe test against the standard; you decide which gaps block the launch date. A ranked severity list keeps that call informed rather than guessed.
03From scan to verified fix
Four stages, each closing on a real check
A conformance claim that skips manual verification tends to fall apart the first time a real assistive-technology user tries the product. These four stages keep that from happening quietly.
Scan first, broadly
Automated tools sweep every screen and interactive state for the barriers they catch reliably, producing a fast baseline before any manual time gets spent.
Every screen, every stateTest manually against the standard
A tester using an actual screen reader and keyboard-only navigation works through the product's real tasks, because simulated testing misses how assistive technology actually announces content.
A real screen reader, not a simulationRank gaps by what they actually block
Findings get ranked by whether they block a task entirely or merely inconvenience it, so a development team fixes what matters before the launch date, not the easiest item on the list.
Severity that reflects real impactVerify the fix, not just the ticket
Once a fix ships, the same manual pass runs again against the specific barrier, because a closed ticket and a resolved barrier are not automatically the same thing.
Retesting closes the loop
04What actually moves the number
Four drivers, sized from real complexity
Accessibility testing is scoped from the product's actual complexity, because these four factors change how much manual time a conformance audit genuinely needs.
Number of unique interactive components
A handful of standard form fields needs less manual verification than a product built around custom widgets, drag-and-drop or a rich data table.
Target conformance level
AA conformance is the common bar, while AAA criteria add extra checks around contrast and language that meaningfully extend the manual testing pass.
Whether this is a one-time audit or ongoing
A single pre-launch audit costs less overall than a recurring conformance check wired into every release, though the recurring option catches regressions the single pass cannot.
How much remediation is scoped in
An audit alone costs less than an audit paired with the actual fixes, and most engagements price the two separately so a client can choose either.
05Evidence and proof
Conformance that held up under a real assistive-technology pass.
Accessibility proof here is a barrier found manually that automated scanning missed entirely. These records carry that bar while written approvals are secured.
Explore case studiesA conformance audit that found the keyboard trap a scanner missed.
Pillar Learning's course player passed every automated scan clean. A manual keyboard-only pass found a modal that trapped focus and made the course unfinishable without a mouse.
- Automated scan result
- Clean pass
- Task-blocking barriers found manually
- 3
An ongoing conformance gate that caught a regression before release.
Aster North shipped a new dashboard widget that silently broke screen reader announcements. A pipeline-integrated conformance check flagged it before the release went out.
- Regression caught before release
- 1 critical
- Conformance checks now automated
- Every release
Our scanner had said we were fine for two years. The first real screen reader pass told a very different story.
Sample · pending client approval
06Read this first
When a full audit is the wrong first move
Commissioning a full manual accessibility audit for an internal tool three people will ever use spends effort on the wrong risk. The exits below are marked honestly.
The product has almost no real users yet
Save the manual pass until the product has traffic worth protecting, and rely on automated scanning in the meantime to catch the obvious issues.
- Software architecture
The real problem is the underlying design system
Fixing accessibility component by component wastes effort when the design system itself needs correction; that work belongs with the team maintaining it.
- Team extension
You need an accessibility engineer embedded long-term
A large, fast-moving product sometimes needs a named specialist on the team full-time rather than a discrete audit engagement.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Single audit | Launch is scheduled and conformance is unverified | The launch date and fix priorities | The scan, manual testing and report |
| Audit plus remediation | You want fixes shipped, not just found | Which fixes ship first | Testing, fixes and retesting |
| Ongoing conformance gate | Releases are frequent and regressions are a real risk | The release cadence | The pipeline gate and recurring manual pass |
07Straight answers
Asked before an accessibility budget gets approved.
01What's included in an accessibility testing engagement?
Accessibility testing combines automated scanning with manual passes using a real screen reader and keyboard-only navigation, checked against WCAG conformance criteria. Colour contrast and ARIA semantics get verified against how they actually get announced.
02Is automated scanning enough on its own?
No. Automated tools catch missing alt text and contrast ratios reliably, but they miss most of what actually blocks a real assistive-technology user from completing a task.
03Which WCAG conformance level do you test against?
Most engagements target WCAG 2.1 or 2.2 at level AA, the common legal and commercial bar. A public sector contract sometimes specifies AAA criteria instead, which extends the testing scope.
04Do you fix the accessibility issues you find, or only report them?
Both are available, priced separately. Many clients start with an audit alone and bring the remediation to their own development team, while others want fixes shipped in the same engagement.
05Can accessibility testing be wired into our CI pipeline?
Yes, automated scanning integrates into most CI pipelines as a routine gate. A recurring manual pass then runs on a schedule for the barriers automation cannot catch.
06How is this different from a general functional test pass?
Functional testing checks whether a feature matches its written requirement. Accessibility testing checks a separate standard: whether someone using a screen reader or keyboard alone can complete that same feature.
07What does accessibility testing cost?
Cost scales with the number of interactive components and the target conformance level, priced from a short scoping look at the product. A single-page audit costs far less than a full ongoing gate.
08Do you test mobile apps for accessibility, not just websites?
Yes, mobile accessibility testing covers screen reader gestures and platform-specific accessibility APIs, which differ meaningfully from how a desktop browser announces content.