Manual accessibility testing is the practice of evaluating a website by hand — with real screen readers, keyboard-only navigation, and zoom — instead of trusting an automated scanner alone. It’s how Curbcut finds the WCAG 2.1 AA barriers that tools can’t detect, and it’s the foundation of every audit we deliver.
Why manual testing matters
Automated scanners are useful, but they have a hard ceiling. Most industry research puts the share of WCAG issues a tool can reliably detect at roughly a third. The rest depend on human judgment — and those are frequently the exact barriers cited in ADA demand letters and lawsuits.
A scanner can tell you an image is missing alt text. It cannot tell you whether existing alt text is accurate, whether alt="image123.jpg" is meaningless, or whether a chart needs a longer description. The same gap shows up across the board:
| What a scanner catches | What only a human catches |
|---|---|
| Missing form labels | Whether the label describes the field correctly |
| Missing alt attribute | Whether the alt text is meaningful in context |
| Low color contrast values | Whether content is understandable without color |
| Empty links and buttons | Whether focus order matches the visual flow |
| Missing page language | Whether a custom dropdown is operable at all |
This is why automated and manual testing are complementary, not interchangeable. Automation gives breadth and speed across thousands of pages; manual testing gives the depth and judgment that conformance actually requires. The W3C/WAI is explicit that conformance evaluation requires human review — there is no tool that certifies a site as accessible on its own.
The POUR lens we test against
Every check maps back to the four POUR principles that organize WCAG: content must be Perceivable, Operable, Understandable, and Robust. Manual testing is the only way to confirm all four hold up for a real person using assistive technology, not just that the markup passes a regex.
How Curbcut tests by hand
Our testers work through your key user journeys — homepage, navigation, search, forms, checkout — the way a person with a disability would. Here’s what that involves.
1. Screen reader testing
We run your site through the screen readers real users depend on, because each one interprets HTML and ARIA differently:
- NVDA (free, Windows) — the most widely used screen reader worldwide.
- JAWS (Windows) — long the enterprise standard, still common in workplaces.
- VoiceOver (built into macOS and iOS) — essential for testing the mobile and Apple experience.
A fix that sounds perfect in NVDA can break in VoiceOver, so we verify across more than one. We listen for whether headings, landmarks, links, and form errors are announced clearly — and whether ARIA is helping or actively getting in the way. Overused or incorrect ARIA is one of the most common problems we hear, and a scanner will never catch it.
2. Keyboard navigation
Many people can’t use a mouse. We unplug ours and operate the entire site with the keyboard alone — Tab, Shift+Tab, Enter, Space, and arrow keys. We confirm that:
- Every interactive element is reachable and operable.
- The focus indicator is always visible.
- Focus order follows a logical reading sequence.
- Nothing becomes a “keyboard trap” the user can’t escape.
- Modals, menus, and custom widgets behave correctly.
3. Zoom and magnification
We zoom the page to 200% and 400% and reflow it to a narrow viewport. Content shouldn’t get clipped, overlap, or force horizontal scrolling. Low-vision users rely on this every day, and broken layouts at zoom are a frequent finding.
4. Cognitive and content review
Finally, a human reviews the things that resist automation entirely: plain-language clarity, consistent navigation, helpful error messages, predictable behavior, and content that doesn’t rely on timing or motion. These understandability barriers matter enormously and are invisible to any tool.
How manual testing fits the bigger picture
Manual testing is the engine. The deliverable is a documented accessibility audit: every finding mapped to a specific WCAG success criterion, rated by severity, with concrete remediation guidance your developers (or ours) can act on. That same evidence base is what feeds a VPAT or Accessibility Conformance Report when a client or government buyer asks for one.
Where the legal stakes are concerned, the manual report is what makes a difference. Thousands of ADA web lawsuits are filed every year, and most hinge on barriers a scanner would have passed. Courts and the DOJ treat WCAG 2.1 AA as the practical benchmark for ADA Title III websites, and federal agencies apply WCAG through Section 508 (Section508.gov). Hand-tested evidence is what stands up when someone challenges your accessibility.
Why we don’t use overlays
It’s worth being blunt: an accessibility overlay — the kind of one-line JavaScript widget sold as an instant fix — cannot replace manual testing or remediation. Overlays sit on top of broken code without fixing it, frequently degrade the experience for the very screen-reader users they claim to help, and have been named in hundreds of lawsuits. We test by hand and fix in the source. That’s the only approach that produces durable conformance.
What you get from a Curbcut manual test
- A criterion-by-criterion findings report against WCAG 2.1 AA (A and AA conformance levels; AAA noted where relevant).
- Severity ratings so you fix the highest-impact barriers first.
- Real screen-reader, keyboard, and zoom evidence — not just scanner output.
- Clear, code-level remediation guidance.
- A foundation for an accessibility statement, VPAT, or attorney response.
This page is informational and not legal advice; consult a qualified attorney about your specific obligations. If you already know you need the real thing, the next step is simple. Book a manual accessibility audit and we’ll hand-test your site against WCAG 2.1 AA — or start with a free scan to see where you stand.