Accessibility Testing: A Complete Guide for Blind, Partially Sighted, Deaf, and Motor-Impaired Users

The short answer: Accessibility testing means testing for real people with real disabilities — not running a scanner and declaring compliance. Approximately 14 million people in the UK live with a disability. 2 million have sight loss. 12 million have some degree of hearing loss. Millions more have motor impairments, cognitive differences, or multiple conditions. Each group uses your product differently and encounters different barriers. This guide covers how to test for each disability category properly.

Why Automated Scanners Are Not Sufficient

Axe, WAVE, Lighthouse, and other automated accessibility tools catch approximately 30–40% of WCAG failures. They are excellent at identifying missing alt text, colour contrast failures, missing form labels, and obvious structural issues. They are blind to:

Whether a screen reader announces dynamic content updates correctly
Whether keyboard focus order makes logical sense when navigating a complex form
Whether a magnified layout at 400% zoom remains coherent and navigable
Whether caption quality is accurate enough to be understandable
Whether a keyboard trap exists in a custom modal component
Whether cognitive load is appropriate for users with memory or attention differences

Automated testing is the foundation, not the conclusion. Manual testing with assistive technologies and human judgment is required for genuine accessibility.

Testing for Blind Users

Blind users navigate entirely via screen reader. They do not see the visual layout — they hear (or read via braille display) a linear stream of text announcements as they navigate through interactive elements. The visual design is completely irrelevant to their experience. What matters is the semantic structure of the HTML, the quality of accessible names and descriptions, and the behaviour of dynamic content.

Screen Readers to Test With

JAWS (Job Access With Speech): The most widely used screen reader in professional and enterprise contexts in the UK. JAWS + Chrome and JAWS + Edge are the most common pairings. JAWS has the highest market share among blind users in professional environments and is the standard for enterprise accessibility compliance testing.

NVDA (NonVisual Desktop Access): The most widely used free screen reader. NVDA + Chrome is the most common configuration. NVDA is particularly prevalent among users who cannot afford JAWS licences. Testing with NVDA is essential for consumer-facing applications.

VoiceOver (macOS): Apple's built-in screen reader. Required for testing on macOS and for web testing in Safari. VoiceOver behaviour differs meaningfully from JAWS and NVDA — particularly for ARIA live regions, form validation, and custom components.

VoiceOver (iOS) and TalkBack (Android): For mobile applications. iOS VoiceOver has very high adoption among blind mobile users — Apple's accessibility implementation is considered the most polished. TalkBack is the Android equivalent.

What to Test With a Screen Reader

Navigation structure: Can a screen reader user navigate your page efficiently using headings (H key in JAWS/NVDA), landmarks (D key), and links (K key)? Heading hierarchy should reflect document structure — H1 for the page title, H2 for major sections, H3 for subsections. Landmark regions (main, nav, header, footer, aside) should be present and correctly labelled.

Interactive elements: Every button, link, form control, and custom component must have an accessible name that accurately describes its purpose. "Click here" and "button" are not accessible names. "Submit payment form" and "Close dialog" are.

Form validation: When a form submission fails, are errors announced to the screen reader? Are error messages associated with the specific fields they relate to (via aria-describedby)? Is focus moved to the error summary or the first failing field?

Dynamic content: When content updates without a page reload — modal dialogs opening, loading states, error messages appearing, cart counts updating — are these changes announced to screen reader users? Use ARIA live regions (aria-live="polite" or aria-live="assertive") appropriately.

Custom components: Datepickers, carousels, accordions, tabs, and other custom interactive components are the most common source of screen reader failures. Each must implement the appropriate ARIA pattern (WAI-ARIA Authoring Practices) and be tested exhaustively with at least two screen readers.

Testing for Partially Sighted Users

Partially sighted covers a wide spectrum — from mild contrast sensitivity reduction and early-stage macular degeneration to legally blind levels of vision. Users in this category typically retain some useful vision and use visual interfaces, but with significant modifications.

Magnification Testing

Browser zoom: Test your application at 150%, 200%, 300%, and 400% browser zoom. WCAG 1.4.4 requires that content can be resized to 200% without loss of content or functionality. At 400% zoom, the application should reflow into a single-column layout (WCAG 1.4.10, Reflow).

Common failures at high zoom:

Horizontal scrollbars appearing because fixed-width layouts don't adapt
Overlapping content as elements don't reflow correctly
Fixed-position elements (navigation bars, cookie banners) consuming a disproportionate amount of the visible viewport
Text truncating with ellipsis in containers that don't expand

ZoomText: The most widely used screen magnification software for partially sighted users. ZoomText offers magnification from 1.5x to 36x with a range of enhancement features (focus following, cursor enhancement, colour enhancement). Test your application with ZoomText at 4x and 8x magnification, checking that the focus-following feature correctly tracks keyboard and mouse focus.

Windows Magnifier and macOS Zoom: Built-in OS magnification tools used by users who can't afford or don't need commercial software. Test at high magnification levels (6x+) to ensure interactive elements remain operable.

Low Vision Colour and Contrast

Colour contrast: WCAG 2.2 AA requires 4.5:1 contrast ratio for normal text and 3:1 for large text (18px+ or 14px+ bold). Check every text/background combination in your design system. Placeholder text, disabled state text, and secondary information frequently fail contrast requirements.

High contrast mode: Windows High Contrast mode and macOS increased contrast override your application's CSS colours with system high-contrast colours. Test in both Windows High Contrast Black and Windows High Contrast White. Applications that use CSS background images for important content, or that rely on colour alone to convey information, frequently break in high contrast mode.

Colour-alone communication: Information must not be conveyed by colour alone (WCAG 1.4.1). Red/green status indicators, orange warning messages, and colour-coded charts all fail this criterion unless a non-colour indicator (icon, text label, pattern) is also present.

Testing for Deaf and Hard of Hearing Users

Deaf and hard of hearing users are the disability group most commonly overlooked in accessibility testing, yet many of the required fixes are among the easiest to implement.

Audio and Video Content

Captions (subtitles): All pre-recorded video with speech must have captions (WCAG 1.2.2, Level A). Live video with speech must have real-time captions (WCAG 1.2.4, Level AA). Test caption accuracy — auto-generated captions from YouTube or similar tools are frequently inaccurate and may not meet the legal standard. Caption positioning must not obscure other important visual content.

Audio description: Pre-recorded video must have audio description for visual information that is not conveyed in the dialogue (WCAG 1.2.5). This is commonly missed for product demonstration videos, tutorials, and data visualisations presented in video format.

Transcripts: Pre-recorded audio (podcasts, audio guides) must have a text transcript (WCAG 1.2.1). Transcripts should be placed in proximity to the audio content and linked clearly.

Audio Alerts and Notifications

Any alert, notification, or status change that is communicated only by audio must have a visual equivalent (WCAG 1.1.1, 1.3.3). Common failures:

Form submission success/failure communicated by a sound effect with no visible confirmation
Incoming message notifications that are audio-only
Error states indicated by a beep without any visual error message

Communication and Contact

Deaf users cannot use phone support. If your only support contact option is a phone number, you are excluding deaf users. Provide email, live chat, or web form alternatives for all support functions.

Testing for Motor-Impaired Users

Users with motor impairments may be unable to use a standard mouse or touchscreen. They rely on keyboard navigation, switch access devices, eye tracking, or voice control software. The common thread is that these users need to operate your application without pointer input.

Keyboard Navigation Testing

Keyboard testing is the foundation of motor accessibility. The test is straightforward: unplug the mouse and navigate your entire application using only Tab, Shift+Tab, Enter, Space, and arrow keys.

Every interactive element must be reachable via Tab. If you can't focus a button, link, or control via Tab, it is inaccessible to keyboard users.

Focus must always be visible. WCAG 2.4.7 (Level AA) requires a visible focus indicator on all interactive elements. WCAG 2.4.11 (Level AA, new in WCAG 2.2) requires that the focus indicator meets minimum size and contrast requirements. Test in Chrome without any custom CSS — if the focus indicator is invisible, it has been suppressed.

No keyboard traps. If keyboard focus enters a component and cannot be moved out using keyboard alone (without reloading the page), that is a critical failure. Modal dialogs are the most common source of keyboard traps — ensure that modals can be closed with Escape and that focus returns to the triggering element when the modal closes.

Logical focus order. The Tab order should match the visual and logical reading order. Random Tab sequences caused by incorrect DOM order or inappropriate tabindex values create an unusable experience for keyboard users.

Switch Access Testing

Switch access allows users with severe motor impairments to control a device using one or two switches (physical buttons, breath activation, eye blink). iOS Switch Control and Android Switch Access both implement automatic scanning — the interface highlights interactive elements sequentially, and the user activates their switch to select the highlighted element.

Applications that fail keyboard accessibility will also fail switch access — fix keyboard access first. Additional switch-specific considerations:

Interactive element grouping (iOS Switch Control groups elements to reduce the number of scan cycles required)
Custom gestures that cannot be performed via switch (pinch to zoom, swipe-based navigation)

Voice Control Testing

Dragon NaturallySpeaking (Windows) and Voice Control (macOS/iOS) allow users to control their device by voice. These tools work by overlaying numbers or interactive element names on the visible interface — users say "Click Submit" or "Click 3" to activate elements.

For voice control to work correctly, interactive elements must have visible or accessible text labels that match what the user would naturally say. A button labelled with an icon only (no text, no accessible name) cannot be activated by voice. Test with Voice Control on macOS or iOS for quick coverage of the most common voice control scenarios.

Cognitive Accessibility

Cognitive accessibility covers users with dyslexia, ADHD, memory impairments, anxiety disorders, and other conditions that affect how users read, process, and interact with digital content. WCAG 2.2 introduces COGA (Cognitive Accessibility) guidance, and WCAG 3.0 will expand this significantly.

Key cognitive accessibility considerations:

Plain language: Write at a reading level appropriate to your audience. Avoid jargon, long sentences, and complex passive constructions.
Consistent navigation: Navigation must be consistent across pages (WCAG 3.2.3). Users who rely on pattern recognition to navigate are disrupted by inconsistent layouts.
Error prevention and recovery: Forms should prevent errors where possible (input masks, confirmation steps for destructive actions) and make error recovery straightforward.
Session timeout warnings: If sessions expire, users must be warned before timeout and given the option to extend (WCAG 2.2.1).
Reducing cognitive load: Limit the number of choices presented at once. Provide progress indicators for multi-step processes. Avoid auto-playing media and animations that cannot be stopped.

Key Takeaways

Automated scanners catch 30–40% of accessibility failures — manual testing is required for genuine compliance
Blind users navigate via JAWS, NVDA, or VoiceOver — test with all three for comprehensive screen reader coverage
Partial sight testing requires browser zoom testing at 200–400% and screen magnification software (ZoomText)
Deaf and hard of hearing testing focuses on captions, transcripts, visual alternatives to audio alerts, and non-phone contact options
Motor impairment testing starts with full keyboard navigation testing — if keyboard fails, switch access and voice control will also fail
Cognitive accessibility (plain language, consistent navigation, error prevention) is a growing legal and ethical requirement