Accessibility testing that shows who can and cannot use your product, and why
Automated scans find a fraction of accessibility problems. We evaluate against WCAG 2.2 with scanners and keyboard testing, report what real users would meet, and verify the fixes. Conformance statements stay yours to make.
Overview
What it is. Accessibility testing evaluates whether people with disabilities can perceive, operate and understand a product, using standards such as WCAG 2.2 together with manual testing by keyboard and zoom.
Who it is for. Organisations selling to the public or to regulated sectors, teams preparing for procurement reviews or legal obligations, products with login, forms and checkout, and teams that have run scans but doubt the result.
Why it matters
The problem it addresses. Many barriers cannot be found by automation: whether a form can be completed by keyboard alone, whether alternative text is meaningful.
When it matters most. Before launch, during redesign, when regulation or a customer requires evidence, and after significant changes to key journeys.
What happens without it. People are excluded from tasks they came to complete, complaints and legal risk grow, and fixes are costlier after release.
What we test
Scoping and sampling following the WCAG-EM approach
what is in scope, which templates and journeys represent the whole
Automated scanning for repeatable checks such as contrast, labels and structure
Manual keyboard testing
focus order, focus visibility, traps and obscured focus
Zoom and reflow checks of key journeys
WCAG 2.2 additions
target size, dragging alternatives, consistent help, redundant entry and accessible authentication
Forms, errors, authentication and checkout as complete processes
Mobile app accessibility on iOS and Android where in scope
Report with severity, affected criterion and remediation guidance, plus retest of fixes
How UpDoer approaches Accessibility Testing
Understand
Requirements, tickets, code diffs and product context.
We agree the target conformance level, the platforms to cover, and the legal or procurement context you work in.
Risk Mapping
Where a failure would cost the most.
Journeys and templates are ranked by how many people they affect and how costly failure is, such as sign-in, search, checkout and support.
Test Strategy
Coverage chosen, test cases drafted.
We select a representative sample, including complete processes, and decide how manual and automated checks are split.
Execute
Manual and automated testing runs.
Scanners run first for repeatable issues, then testers work through keyboard, zoom and reflow, input and authentication checks.
AI-Assisted Quality Engineering
Failures classified, release risk scored.
AI helps cluster issues by component, map findings to criteria and draft consistent descriptions, so reviewers spend time on judgment.
Human Verification
A QA engineer checks every flagged result.
A trained tester decides whether an issue is a real barrier, whether alternative text is meaningful, and whether a process can be completed.
Report & Improve
The verified quality signal, then better coverage.
The report lists findings by severity and criterion with remediation guidance. After fixes we retest and report what remains. You decide on any conformance statement.
Accessibility testing: who can use it, and why
01
Where it breaks
Keyboard trap on a formMissing text alternativesLogin blocks some users02
Test workflow
UserInterfaceWCAG checkReport03
AI assists
Scan repeatable issuesGroup by componentSuggest alt text04
Humans decide
Test with a screen readerJudge if alt text is useful05
Release signal
Findings by criterionRetest of fixesConformance stays yours
Illustrative workflow. Not a client result or a measured outcome.
Accessibility evaluation matrix
A dash means no AI step is described for that area.
| WCAG principle | What we evaluate | AI and scanner role | Human and assistive-technology role |
|---|---|---|---|
| Perceivable | Text alternatives, captions, contrast, reflow, text spacing | Scans contrast and missing text alternatives; suggests candidate descriptions | Judges whether alternatives are meaningful; tests zoom and reflow |
| Operable (keyboard) | Focus order, visibility, traps, shortcuts, obscured focus | Flags missing focus styles | Tests complete tasks by keyboard |
| Operable (pointer and touch) | Target size, gestures, dragging alternatives | Measures target sizes | Tests on real devices and with alternative input |
| Understandable | Labels, instructions, error identification and help | Checks labels and error associations | Judges clarity and consistency of help |
| Robust | Name, role and value for custom components | — | Reviewed by a QA engineer |
| Authentication and forms | Accessible authentication, redundant entry, error recovery | — | Completes sign-in and checkout by keyboard |
| Games (where relevant) | Subtitles, remapping, difficulty, visual and motor options | Not applicable | Evaluates against game accessibility guidelines |
WCAG principle: Perceivable
- WHAT WE EVALUATE
- Text alternatives, captions, contrast, reflow, text spacing
- AI AND SCANNER ROLE
- Scans contrast and missing text alternatives; suggests candidate descriptions
- HUMAN AND ASSISTIVE-TECHNOLOGY ROLE
- Judges whether alternatives are meaningful; tests zoom and reflow
WCAG principle: Operable (keyboard)
- WHAT WE EVALUATE
- Focus order, visibility, traps, shortcuts, obscured focus
- AI AND SCANNER ROLE
- Flags missing focus styles
- HUMAN AND ASSISTIVE-TECHNOLOGY ROLE
- Tests complete tasks by keyboard
WCAG principle: Operable (pointer and touch)
- WHAT WE EVALUATE
- Target size, gestures, dragging alternatives
- AI AND SCANNER ROLE
- Measures target sizes
- HUMAN AND ASSISTIVE-TECHNOLOGY ROLE
- Tests on real devices and with alternative input
WCAG principle: Understandable
- WHAT WE EVALUATE
- Labels, instructions, error identification and help
- AI AND SCANNER ROLE
- Checks labels and error associations
- HUMAN AND ASSISTIVE-TECHNOLOGY ROLE
- Judges clarity and consistency of help
WCAG principle: Robust
- WHAT WE EVALUATE
- Name, role and value for custom components
- AI AND SCANNER ROLE
- —
- HUMAN AND ASSISTIVE-TECHNOLOGY ROLE
- Reviewed by a QA engineer
WCAG principle: Authentication and forms
- WHAT WE EVALUATE
- Accessible authentication, redundant entry, error recovery
- AI AND SCANNER ROLE
- —
- HUMAN AND ASSISTIVE-TECHNOLOGY ROLE
- Completes sign-in and checkout by keyboard
WCAG principle: Games (where relevant)
- WHAT WE EVALUATE
- Subtitles, remapping, difficulty, visual and motor options
- AI AND SCANNER ROLE
- Not applicable
- HUMAN AND ASSISTIVE-TECHNOLOGY ROLE
- Evaluates against game accessibility guidelines
Where AI helps
- Running and consolidating repeatable checks, then clustering results by component or template so one fix clears many instances.
- Suggesting candidate alternative text and labels, always reviewed by a person before use.
- Summarising the audit into a plain-language overview for non-specialists.
How we use AI: AI can accelerate test design, analysis and repetitive QA work, but important outputs remain subject to human review and validation. It informs the release decision; it does not make it.
Where humans matter
- Testing with the keyboard, and judging whether a task can really be completed.
- Deciding whether alternative text, headings, labels and error messages are meaningful, not merely present.
- Judging reading order, cognitive load and the clarity of instructions.
- Prioritising barriers by their effect on real tasks.
- Stating plainly what was and was not evaluated, and leaving conformance claims to the product owner.
Tools we build with
- Automation
- SeleniumPlaywrightAppiumKatalonTestComplete
- API & Performance
- PostmanSoapUISwaggerApache JMeter
- CI/CD & Reporting
- JenkinsTeamCityAllureMaven
Frequently asked questions
Will you certify that our product is accessible or compliant?
No. We report what was evaluated and found within a stated scope. A conformance statement or legal position is for the product owner, and for legal advisers where it matters.
Isn't an automated scan enough?
W3C guidance says some checks cannot be automated and tools can give inaccurate results. Scans are a useful first pass. Manual keyboard testing finds what they cannot.
Which version of WCAG do you test against?
WCAG 2.2 Level AA by default, which also covers 2.1 and 2.0 criteria. If a customer or regulation specifies another version, we map the findings accordingly.
Can AI write alternative text?
AI can suggest candidates. A person must review them because meaning depends on context and purpose.
Do you retest after fixes?
Yes. Retesting the fixed items and reporting what remains is part of a complete accessibility engagement.