Reach more people
Millions of people use assistive technology. An accessible product works for all of them.
[ Why accessibility testing ]
Accessible products reach more people, with less risk
A missing label, a low-contrast button or a menu that can’t be opened with a keyboard can lock people out completely. These problems are easy to miss if you have never used a screen reader, and automated tools catch only some of them. Accessibility is also increasingly expected by law and by buyers, especially in government, education and large enterprises. We test the way people with disabilities really use your product, and help your team fix what we find.
We test against the standards and give you evidence; we don’t promise legal compliance or certification. Want to watch real users? See usability testing →
Lower legal and procurement risk
Clear evidence against the standards your buyers and regulators expect.
Better for everyone
Clear structure, good contrast and keyboard support help every user.
Fixes your team can act on
Every issue explained, linked to WCAG and paired with a practical fix.
Standards we test against
Which ones apply depends on where you operate and who you sell to.
Worldwide
WCAG 2.2 AA
The international standard most laws and policies point to. Our audits test against level AA.
United States
Section 508
Required for US federal agencies and the products they buy.
United States
ADA
US civil rights law; WCAG is commonly used as the technical benchmark.
European Union
EN 301 549
The European standard behind the European Accessibility Act and public sector rules.
Ontario, Canada
AODA
Ontario’s accessibility law, which refers to WCAG for websites and web content.
[ What we test ]
Twelve ways we make your product accessible
From a full WCAG audit to training your team so issues don’t come back. Each one lists what we do, when you need it and the problem it prevents.
WCAG 2.2 AA audits
Full reviewA complete audit of your key pages, screens and journeys against WCAG 2.2 level AA, combining automated scans with careful manual testing.
What we test
- Agreed sample of pages, templates and journeys
- Every WCAG 2.2 A and AA success criterion checked
- Issues linked to the exact criterion they fail
- Severity, user impact and fix guidance for each issue
When you need it
Before launch, before a procurement or audit, and once a year.
The problem it preventsNot knowing where you stand until a complaint arrives
Manual screen reader testing
How it really soundsWe use your product the way blind and low-vision users do, with the screen readers they rely on.
What we test
- NVDA and JAWS on Windows, VoiceOver on Mac and iOS, TalkBack on Android
- Headings, landmarks, labels and reading order
- Forms, errors, dialogs and live updates announced correctly
- Custom components such as menus, tabs and carousels
When you need it
For every audit, and whenever custom components change.
The problem it preventsPages that pass automated checks but make no sense when read aloud
Keyboard-only & focus testing
No mouse neededMany people navigate without a mouse. We check that every action can be done with a keyboard, in a sensible order, with a visible focus.
What we test
- Every control reachable and usable by keyboard
- Logical tab order and visible focus indicator
- No keyboard traps in menus, dialogs or embeds
- Skip links and shortcuts working as expected
When you need it
For every audit and every new interactive feature.
The problem it preventsUsers stuck in a menu or unable to submit a form
Automated accessibility scans
Fast, wide coverageAutomated tools quickly find common problems across many pages. We use them for breadth, then confirm and add context by hand.
What we test
- Scans with axe, WAVE, Lighthouse and Accessibility Insights
- Site-wide checks across templates
- False positives removed before you see them
- Clear note of what automation can’t catch
When you need it
At the start of an audit and on a regular schedule.
The problem it preventsHundreds of repeated issues nobody has counted
Mobile app accessibility
iOS and AndroidNative apps have their own accessibility features and rules. We test with the settings and assistive technology people really use on their phones.
What we test
- VoiceOver on iOS and TalkBack on Android
- Dynamic Type, font scaling and display zoom
- Touch target size, gestures and alternatives
- Colour, contrast and reduced-motion settings
When you need it
Before every major app release.
The problem it preventsAn app that becomes unusable with a larger text size
PDF & document accessibility
Beyond the web pageDownloadable documents are often the least accessible part of a site. We check that PDFs and documents can be read with assistive technology.
What we test
- Tags, reading order and headings in PDFs
- Alternative text for images and charts
- Accessible tables and form fields
- Checks in Adobe Acrobat and with screen readers
When you need it
For public reports, forms, statements and policies.
The problem it preventsImportant information locked inside an inaccessible PDF
VPAT / ACR preparation support
Procurement-readyBuyers often ask for an Accessibility Conformance Report (ACR), usually built on the VPAT template. We provide the test evidence you need to complete it accurately.
What we test
- Testing mapped to the VPAT edition you need
- Evidence for each criterion: supports, partially supports, does not support
- Clear notes and known exceptions
- Review of your draft ACR for accuracy
When you need it
Before selling to government, education or large enterprises.
The problem it preventsA sales deal stalled because there is no credible accessibility report
Remediation guidance & retesting
From findings to fixesA list of problems is only useful if your team can fix them. We explain each issue in plain words, suggest a fix and check it once it is done.
What we test
- Practical fix suggestions with code-level hints
- Issues grouped so one fix solves many
- Help prioritising by user impact and effort
- Retesting of every fixed issue
When you need it
After every audit, until issues are closed.
The problem it preventsAn audit report that sits in a folder and changes nothing
Accessibility in CI/CD
Every buildAutomated accessibility checks in your pipeline, so common problems are caught before they are merged.
What we test
- axe or Pa11y checks on key pages in CI
- Rules agreed with your team to keep noise low
- Failing builds on serious new issues
- Trend reports over time
When you need it
Once the main issues from an audit are fixed.
The problem it preventsNew accessibility problems added faster than old ones are fixed
Testing with people with disabilities
Lived experienceSessions with people who use screen readers, keyboard navigation, magnification, voice control or switch devices every day.
What we test
- Participants who rely on assistive technology
- Real tasks with their own devices and settings
- Barriers recorded with quotes and clips
- Findings that expert testing alone may miss
When you need it
For public-facing products and before major launches. See also usability testing.
The problem it preventsA product that technically conforms but is still hard to use
Design & prototype reviews
Shift leftAccessibility problems are cheapest to fix in design. We review your Figma files and prototypes before development starts.
What we test
- Colour contrast and use of colour
- Focus order, headings and structure planned
- Touch target size and spacing
- Notes for developers on accessible behaviour
When you need it
During design, before build.
The problem it preventsRebuilding finished screens to fix problems that started in design
Team training & checklists
Build it inShort, practical sessions and checklists that help designers, developers and testers build accessibility into their everyday work.
What we test
- Role-based sessions for design, development and QA
- Checklists for your stack and components
- Examples from your own product
- Follow-up questions answered as you build
When you need it
After an audit, or when your team is starting out.
The problem it preventsThe same issues coming back every release
[ Automated vs manual vs real users ]
Why automated scans alone aren’t enough
We combine all three. Here is what each finds, and what a real accessibility issue report looks like.
| Method | What it finds | Strengths and limits |
|---|---|---|
| Automated scans | Finds common, detectable issues across many pages | Fast and wide, but catches only part of WCAG |
| Manual expert testing | Checks every criterion with screen readers and keyboard | Thorough and accurate; needed for conformance |
| Testing with disabled users | Shows real barriers in real use | Reveals what experts may miss; slower to run |
Sample issueHigh impact
- Page
- Checkout · payment step
- WCAG
- 1.3.1 Info and Relationships · 3.3.2 Labels or Instructions (A)
- Issue
- Card number field has no programmatic label
- Impact
- High · screen reader users hear “edit text” and can’t tell what to enter
- Found with
- NVDA + Chrome, VoiceOver + Safari; missed by automated scan
- Fix
- Add a visible label linked with for/id, or aria-labelledby
Example only. Real issues come from your own audit.
[ How we work ]
Six steps from first scan to lasting accessibility
Automated breadth, manual depth and real fixes, with evidence you can use for statements and procurement.
-
Step 1 of 6
Agree scope and standards
Pages, journeys, platforms and the standards that apply to your markets.
You getAudit scopeStandards list -
Step 2 of 6
Scan for breadth
Automated tools across your templates, with false positives removed.
You getScan summary -
Step 3 of 6
Test by hand
Screen readers, keyboard, zoom, contrast and every WCAG criterion.
You getIssue log with WCAG references -
Step 4 of 6
Report and prioritise
Severity, user impact and fix guidance, in plain words.
You getAudit reportPrioritised fix list -
Step 5 of 6
Support the fixes
Answer developer questions and retest every fix.
You getRetest results -
Step 6 of 6
Keep it accessible
CI checks, training and evidence for your ACR or statement.
You getCI checksEvidence pack
- Free one-week POCWe test one important journey by hand and show you the findings and fixes.
- Honest about complianceClear evidence against the standards, without legal promises we can’t make.
- Retests includedEvery fixed issue is checked again before it is closed.
[ Tools ]
The tools behind our accessibility testing
12 tools across four jobs. Tools find patterns; people confirm what users really experience.
Automated checkers
Wide, fast coverage.
- axe DevToolsAutomated WCAG checks
- WAVEVisual page evaluation
- LighthouseAccessibility audits
- Accessibility InsightsGuided assessments
- Pa11yChecks in CI
Screen readers
How it really sounds.
- NVDAWindows screen reader
- JAWSWindows screen reader
- VoiceOvermacOS and iOS
- TalkBackAndroid
Visual & documents
Contrast and PDFs.
- Colour Contrast AnalyserContrast checks
- Adobe AcrobatPDF accessibility
Devices
Real phones and browsers.
- BrowserStackReal device cloud
See every tool we use on our technology stack page →
[ Case Studies ]
Products our QA engineers have worked on
Each one links to the full write-up by the engineers who ran it. Accessibility was part of our work for Supply Ontario; the others show our wider QA work.
[ Ways to work ]
Six ways to get accessibility testing done
A one-off audit, checks every release, or VPAT evidence before a big sale.
01Dedicated QA teamChoose it when you release every sprint and want testers who know your product.02Managed testingChoose it when you want audits, retests and reporting handled for you.03Fixed-price projectChoose it for a launch or a test cycle with a clear scope and date.04On-demand testingChoose it for a release, a launch week or a device sweep.05Staff augmentationChoose it when your team needs extra manual testers for a while.06QA consultingChoose it for a review of your test process, cases and documentation.
Hire our QAHire a Manual QA engineerA manual tester who joins your sprints, stand-ups and tools, and learns your product inside out.See the role →
Start risk-freeFree one-week proof of conceptWe test one important journey by hand and show you the findings, so you can judge our work first.How it works →
Not sure which fits? Find your model in four questions or compare all six.
[ FAQ ]
Accessibility testing questions, answered
{{ f.a }}
[ Contact us ]
Get an accessibility audit plan for your product
✓ Free one-week POC✓ NDA before access✓ A QA lead replies the same day