That gap is why manual accessibility testing exists. It's a human-led review where a trained tester navigates your product with a keyboard, a screen reader, zoom settings, and real task scenarios, exactly the way a person with a disability might use your software every day.
This article breaks down what manual testing involves, how it differs from automated scanning, what to actually test, and how to build it into your product workflow without slowing your team down.
Key Takeaways
- Manual testing catches barriers automated tools cannot detect, like confusing focus order or meaningless alt text
- Keyboard, screen reader, zoom, and task-based checks work best as a combined process, not separate boxes to check
- Automated scans offer speed and scale, but a "zero errors" result is not proof of accessibility
- Every finding should link to user impact, a WCAG criterion, and a clear fix
What Is Manual Accessibility Testing?
Manual accessibility testing is a hands-on evaluation where a trained tester interacts directly with a website, application, or workflow to find barriers that affect people with disabilities.
A tester operates the controls, listens to how information gets communicated, and checks whether someone can complete a real task from start to finish—work that goes beyond reading source code.
This connects closely to WCAG conformance, but the two goals aren't identical. A page can technically meet a WCAG success criterion and still frustrate a real user. Standards-based review answers "does this meet the rule?" Usability validation answers "can someone actually get their work done?" Good manual testing does both.
Testers need a mix of skills, including:
- Working knowledge of WCAG success criteria
- Familiarity with accessible interaction design patterns
- Hands-on experience with assistive technology (screen readers, magnifiers, switch devices)
- Understanding of semantic HTML structure, forms, and dynamic content
- Awareness of common user workflows in the product's domain
A B2B Example That Shows the Difference
Take a B2B analytics dashboard. An automated scanner might confirm every table has a header row and every button has a name. That's useful baseline coverage.
It still says nothing about whether a keyboard user can locate the dashboard, filter a dense data table, open a detail panel, and fix a validation error—or finish without getting trapped in a modal they can't leave.
Manual testing walks through that exact sequence. It's the only method that can confirm whether the workflow itself, not just the individual components, functions as intended.
The tradeoff: manual testing provides context and judgment that automation can't replicate, but it takes real time and skill. For large B2B products with dozens of screens, teams need to prioritize which workflows get tested first, usually the ones tied to core revenue or compliance requirements.
Manual vs. Automated Accessibility Testing
Automated tools are genuinely good at certain things. They catch missing form labels, some contrast failures, absent heading structures, and code-level patterns that repeat across hundreds of pages. That scale is valuable, especially for regression testing after a release.
What automation generally can't judge:
- Whether alt text actually describes what an image is for
- Whether focus order makes logical sense to a real user
- Whether written instructions are understandable
- Whether someone can complete a multi-step task without confusion
A concrete example: an automated tool can confirm an image has an alt attribute. Only a human tester can determine whether that alt text says "image047.png" or actually conveys the image's purpose.
Here's how the two approaches stack up:
| Factor | Automated Testing | Manual Testing |
|---|---|---|
| Speed | Fast, scans pages in seconds | Slower, requires human time |
| Scale | Covers thousands of pages easily | Limited to sampled workflows |
| Judgment | None; rule-based only | Context and real-world reasoning |
| Assistive tech validation | Cannot confirm real AT behavior | Confirms actual screen reader/keyboard experience |
| Remediation context | Flags the issue | Explains why it matters and how to fix it |
The scale of what automation misses matters more than most teams realize. WebAIM's 2024 analysis of the top one million home pages found automatically detectable WCAG failures on 95.9% of them—and that figure only reflects issues automation can catch.
A separate Deque study of over 2,000 audits found automated tools fully covered just 57% of total issue volume across nearly 300,000 documented problems. That's a dated, study-specific number, not a universal rule, but it makes the point clearly: a clean automated scan is not proof of an accessible product.
The most reliable approach combines automated checks for scale and regressions with manual review for context, plus testing with actual people with disabilities when the workflow is high-stakes.
Yes Yes Know's audits follow this hybrid model directly, pairing automated tools with manual NVDA and VoiceOver testing plus usability sessions with real assistive-technology users.
How to Perform Manual Accessibility Testing
Manual testing works best as a structured process, not an ad hoc click-through. Use this sequence.
Prepare Before You Test
Before opening a browser, nail down:
- Product version and environment: browsers, devices, and screen reader combinations you'll use
- Critical user journeys: the workflows that matter most to your users and your business
- Target standard: usually WCAG 2.2 AA for most B2B compliance needs
- Representative sample: login, onboarding, search, forms, account management, dashboards, and data tables—not just the homepage
- Owner assignment: who fixes what you find
Test With a Keyboard
Use Tab, Shift+Tab, Enter, Space, arrow keys, and Escape to move through the interface. Check for:
- Logical, predictable focus order
- Visible focus indicators at every step
- No keyboard traps (you should always be able to leave a component)
- Working skip links, dialogs, menus, and custom widgets
- Full form completion without touching a mouse
Test With a Screen Reader
Pair the right browser and screen reader—commonly Chrome with NVDA or Safari with VoiceOver. Confirm that these announce correctly:
- Headings and landmarks
- Link names and form labels
- Error messages
- Dynamic content updates
Tables and custom controls deserve extra scrutiny; they're where screen reader experiences most often break down.
Check Zoom and Visual Behavior
Enlarge text and resize the viewport to confirm content reflows properly, nothing gets clipped or overlaps, and horizontal scrolling doesn't appear unexpectedly. Contrast and color dependence matter here too.
Document Everything
Capture each finding with:
- URL or screen and workflow step
- Reproduction steps
- Observed vs. expected behavior
- Affected user group
- Screenshot
- Relevant WCAG criterion
- Priority and recommended fix
Yes Yes Know's audit reports use this structure and rate each issue as critical, serious, moderate, or minor.
What to Test During a Manual Accessibility Review
A thorough review covers several interconnected areas. Skipping one usually means missing real barriers.
Keyboard and focus behavior:
- Every interactive control is reachable and operable
- Focus stays visible and follows a logical order
- Dialogs can be entered and exited without getting stuck
Screen reader and semantic structure:
- Headings and landmarks communicate page structure
- Controls have meaningful, descriptive names
- Tables expose row and column relationships
- Status updates and loading states get announced
Forms and error handling:
- Labels, instructions, and required-field indicators connect to the right inputs
- Error messages are specific and appear at the right moment
- Valid data stays populated after a failed submission
Visual and low-vision access:
- Contrast meets WCAG thresholds for text and UI components
- Text resizes and reflows without breaking layout
- Focus indicators remain visible at every zoom level
Content and multimedia:
- Heading hierarchy makes sense out of context
- Link purpose is clear from the link text alone
- Captions, transcripts, and alt text are present and accurate
Task completion for B2B workflows: This is where manual testing really earns its place. Run realistic scenarios using only assistive technology:
- Filtering a dense data table
- Changing user permissions
- Exporting a report
- Responding to an alert
- Recovering from an error
A component can pass every individual check and still fail when chained into a real task.
Build Manual Accessibility Testing Into Your Product Workflow
Manual testing works best woven into your development cycle, not bolted on right before launch. Test at multiple checkpoints:
- Design review, before code gets written
- Component development, as reusable pieces get built
- Feature QA, before a release ships
- Pre-release validation, on the full workflow
- Regression testing, after significant changes Set a cadence based on risk. High-traffic workflows and reusable components need more frequent checks than a rarely-used settings page. Prioritize accordingly, then schedule broader reviews on a regular rhythm. Assign clear ownership. Product, design, engineering, and QA teams should all have a stake, and accessibility findings belong in the same issue tracker as functional bugs, not a separate spreadsheet nobody checks. That same principle shapes how Yes Yes Know works. The team structures engagements around three iterative phases—Understanding, Designing, and Building—with accessibility built into each one rather than treated as a final QA step. When outside expertise helps. Teams tackling complex B2B software, ADA or WCAG requirements, VPAT-related procurement questions, or unfamiliar assistive technology often benefit from a dedicated partner. Yes Yes Know's Flat-fee Accessibility Audit runs $5,000 and delivers a full report within 10 business days. The engagement combines:
- Automated scanning plus manual NVDA and VoiceOver testing
- Usability sessions with people who use assistive technology
- Every finding mapped to a WCAG 2.2 criterion, with severity and a clear next step Work is led by practitioners with hands-on WCAG, ADA, and Section 508 experience, including CPACC-certified founder Jen Bullard.
Frequently Asked Questions
Is WCAG legally required?
WCAG is a technical standard, not a law itself. Whether it's legally required depends on your organization, applicable regulations like ADA Title II, your contracts, and procurement requirements. Talk to qualified legal counsel for compliance-specific questions.
What are the three types of accessibility testing?
The three types are automated testing, manual expert testing, and testing with assistive technology or people with disabilities. A strong accessibility program combines all three rather than relying on just one.
Can you give me an example of accessibility testing?
One example: completing a form using only a keyboard and a screen reader, checking that focus order makes sense, labels announce correctly, error messages are clear, and the form actually submits successfully.
What is the best tool for accessibility testing?
No single tool catches every barrier. Choose scanners suited to your platform, then pair them with manual keyboard, screen reader, zoom, and usability testing for a complete picture.
How do you perform manual accessibility testing?
Prepare by defining your scope and standard, select representative workflows, test with a keyboard and screen reader, check zoom and visual behavior, document every finding, then remediate and retest.
What does manual accessibility testing find that automated tools miss?
Manual testing catches contextual issues like meaningless alt text, illogical focus order, confusing labels, missing dynamic announcements, and broken multi-step task completion, none of which a scanner can judge on its own.
