Manual Testing and User Testing with Assistive Technology

Manual testing is where the depth of accessibility evaluation happens. While automated tools efficiently catch technical violations, manual testing reveals the usability barriers that affect real users — the confusing focus order, the widget that technically has ARIA attributes but behaves unpredictably, the form that passes automated checks but frustrates everyone who tries to use it with a screen reader.

Keyboard Testing

Keyboard testing is the single most valuable manual test you can perform. Disconnect your mouse (or simply do not touch it) and attempt to complete every task on your site using only the keyboard.

What to test: Can you reach every interactive element using Tab and Shift+Tab? Is the focus order logical and follows the visual layout? Is the focus indicator always visible? Can you activate buttons with Enter and Space? Can you operate dropdown menus with arrow keys? Can you dismiss dialogs with Escape? Can you navigate tabs, accordions, and other compound widgets? Are there any focus traps where you cannot move away from an element? Do skip links work?

How to document findings: Record the page, the element, the expected behavior, the actual behavior, and the applicable WCAG success criterion. Note the browser and operating system used for testing.

Screen Reader Testing

Screen reader testing reveals how your content is experienced by users who cannot see the visual presentation. Even pages that pass keyboard testing can fail screen reader testing if the underlying semantics are wrong.

NVDA (NonVisual Desktop Access) is a free, open-source screen reader for Windows. It is the most commonly used screen reader for accessibility testing due to its cost (free) and accuracy. Key commands: Insert+Space to toggle between focus and browse modes. Use H to navigate by headings, D by landmarks, K by links, F by form fields.

VoiceOver is built into macOS and iOS at no additional cost. On macOS, activate it with Command+F5. Use the rotor (VO+U) to navigate by headings, links, form controls, and landmarks. On iOS, VoiceOver is activated in Settings and uses swipe gestures for navigation.

JAWS (Job Access With Speech) is the most widely used commercial screen reader. It is the industry standard in many enterprise and government environments. Testing with JAWS is recommended for sites serving enterprise or government users.

What to verify with screen readers: All images have appropriate alt text announced. Headings create a navigable outline. Form fields have labels announced. Error messages are announced. Dynamic content updates are communicated. Custom widgets announce their role, state, and name. Page structure makes sense when heard linearly without visual context.

Zoom and Magnification Testing

Many users with low vision use browser zoom or screen magnification rather than screen readers. Test your site at 200% and 400% zoom.

At 200% zoom (equivalent to 320px viewport width on a standard desktop display), verify that all content remains visible and functional without horizontal scrolling. Text reflows into a single column. No content is cut off, overlapped, or hidden. All functionality remains available. This addresses WCAG SC 1.4.10 Reflow.

At 400% zoom, verify that the experience remains usable, though some horizontal scrolling may be necessary for specific content types like data tables or images.

Cognitive Walkthrough

A cognitive walkthrough evaluates your site from the perspective of users with cognitive disabilities. This is less about specific tool usage and more about asking the right questions:

Is the purpose of each page immediately clear? Are instructions explicit rather than implied? Is navigation predictable and consistent? Can users recover from errors without losing their work? Is the amount of information on each page manageable? Are processes broken into clear, discrete steps? Is important information prominent rather than buried? Does the site avoid unnecessary complexity?

User Testing with People with Disabilities

The most authentic accessibility evaluation involves observing real users with disabilities completing tasks on your site using their own assistive technologies in their own environments.

Recruitment: Partner with disability organizations, accessibility consultancies, or user research agencies that specialize in inclusive testing. Aim for diversity in disability types and assistive technology use — include screen reader users, keyboard-only users, users with motor impairments, users with low vision, and users with cognitive disabilities.

Test design: Define realistic tasks that represent the key user journeys on your site, such as finding a product, completing a purchase, filling out a form, or contacting support. Allow participants to use their own devices and assistive technology. Observe without intervening unless the participant asks for help.

Ethical considerations: Compensate participants fairly. Allow extra time. Ensure your testing environment and communication are accessible. Respect participants' expertise in their own experience.

Analyzing results: User testing reveals barriers that no automated or manual expert testing can fully capture. A screen reader user's confusion at a widget that technically has correct ARIA but behaves unlike their expectations, or a user with tremors struggling with targets that technically meet the 24px minimum but are still too small for them, provides actionable insight that drives meaningful improvements.