Accessibility Testing: Considering the User's Perspective of Accessibility

Most people now use the internet for everything from work to shopping to news to social connection — but for the roughly 1 in 4 US adults (CDC, 2023) and over 1.3 billion people globally (WHO, 2023) living with some form of disability, the experience is shaped entirely by whether the sites they visit were built with their needs in mind. This guide covers accessibility from the user’s perspective: how people with different disabilities navigate the web, what assistive technologies they rely on, where things break down, and what design and testing practices ensure your site actually works for them.

The internet has been transformative for many users with disabilities. Newspapers, once impossible for blind people to read independently (Braille printing was expensive and bulky; readers depended on family or audio recordings), are now available via screen readers — software that converts text to synthesized speech. People with motor disabilities use eye-tracking, switch access, voice control, and adaptive keyboards to interact with content that would be physically inaccessible in print. Deaf and hard-of-hearing users benefit from captions and transcripts. The web’s potential for accessibility is enormous; what matters is whether individual sites realize it.

Why build accessible content

Three motivations consistently drive accessibility investment, in roughly increasing levels of urgency:

1. Human-centered — improving the lives of people with disabilities. The original and most important reason: equitable access to information and services is a basic ethical commitment.
2. Economic — reaching a wider audience. The 1-in-4 figure isn’t theoretical; it’s the size of the audience excluded by inaccessible sites. Conversion losses at that scale dwarf the cost of fixing accessibility.
3. Legal and reputational — avoiding lawsuits and regulatory enforcement. ADA Title III lawsuits have run 8,000-11,000 per year through 2024 in the US. The European Accessibility Act has required private-sector compliance across EU member states since June 28, 2025. The DOJ’s April 2024 Title II Final Rule (with deadlines extended by the April 20, 2026 Interim Final Rule to April 26, 2027 / April 26, 2028) sets WCAG 2.1 AA as the standard for state and local government sites.

Whatever the starting motivation, the work itself is the same: design with real users in mind, test against the standard, and improve continuously. See our US web accessibility laws and international accessibility laws guides for full legal context.

The four principles of accessibility (POUR)

The W3C’s Web Content Accessibility Guidelines (WCAG) — currently WCAG 2.2 (published October 5, 2023) — organize web accessibility around four principles, summarized as POUR:

• Perceivable — users can perceive the content. Text alternatives for non-text content, captions for audio, sufficient contrast, content that adapts to user preferences.
• Operable — users can operate the interface. Keyboard accessibility, adequate time for tasks, no seizure-triggering content, navigable structure.
• Understandable — content and interface make sense. Readable language, predictable behavior, clear error handling.
• Robust — content works with current and future assistive technologies. Semantic HTML, valid markup, ARIA used correctly.

WCAG specifies three conformance levels — A (minimum), AA (standard target), AAA (enhanced). Level AA is the practical target required by virtually every major accessibility law worldwide. WCAG 2.2 AA satisfies WCAG 2.1 AA automatically, since the new 2.2 success criteria are additions rather than replacements.

Disability types and how users navigate the web

Disability is highly heterogeneous, and the design considerations vary by category. Five major groups affect how people interact with web content.

Vision disabilities

Vision disabilities include total blindness, low vision (partial sight), and color vision deficiencies. Each has distinct accessibility requirements.

Blind users rely on screen readers — software that converts on-screen text to synthesized speech. Major options:

• NVDA — free, open-source, Windows; widely used.
• JAWS — commercial, Windows; long-standing in enterprise environments.
• VoiceOver — built into macOS, iOS, and iPadOS.
• TalkBack — built into Android.
• ChromeVox — built into ChromeOS.

Screen readers do more than read text aloud. They navigate by headings, by landmarks, by links, by form fields. They depend on semantic HTML, descriptive alt text on images, proper heading hierarchy, programmatic form labels, and ARIA attributes when native HTML doesn’t carry the needed semantics. They cannot interpret images without alt text, cannot describe visual layout, and read content in DOM order — so a logical content sequence in source code matters even when CSS rearranges visual presentation.

For deaf-blind users, refreshable braille displays render text tactilely — small pins raise and lower to form braille characters from the same content the screen reader would speak.

Screen reader users navigate primarily by keyboard. Sites that depend on mouse-only JavaScript event handlers (mouseover, mouse-click without keyboard equivalent) are entirely inaccessible to them. Modern frameworks make keyboard support straightforward; the remaining failures are usually careless rather than technical.

Low-vision users use screen magnifiers — software that zooms in on portions of the screen. ZoomText is the long-standing commercial option; built-in OS magnifiers (Windows Magnifier, macOS Zoom) are also widely used. WCAG 1.4.4 (Resize Text) requires content to remain usable at 200% zoom; WCAG 1.4.10 (Reflow) extends this to 400% zoom without horizontal scrolling on a 320-pixel viewport. Text-as-image (an image file containing text) becomes pixelated at high zoom; text in HTML stays sharp.

Forced Colors Mode (Windows 11’s Contrast themes, formerly High Contrast Mode) lets users override site colors with their chosen palette. Sites that hard-code colors can lose information here — bordered buttons disappear, status indicators turn invisible. WCAG 1.4.3 requires 4.5:1 contrast for normal text, 3:1 for large text; WCAG 1.4.11 (Non-text Contrast) extends 3:1 to UI components and graphical objects.

Color vision deficiencies affect roughly 8% of men and 0.5% of women globally. Red-green deficiency is most common. WCAG 1.4.1 (Use of Color) requires that information never be conveyed by color alone — pair color with text, icon, or pattern.

Hearing disabilities

Hearing disabilities include deafness, hard-of-hearing, and auditory processing disorders. Web content with audio or video components is the primary friction point. Accessibility requirements:

• Captions for all pre-recorded video with audio (WCAG 1.2.2). Synchronized, accurate, speaker-identified. Auto-generated captions are a starting point but require human correction for accuracy.
• Transcripts for audio-only content like podcasts. Bonus: transcripts are crawlable for SEO and AI search.
• Live captions for live video (WCAG 1.2.4 Level AA).
• Sign language interpretation (WCAG 1.2.6 Level AAA) for premium accessibility.
• Audio descriptions for video where visual content conveys meaning not in the audio (WCAG 1.2.5).
• Visual alternatives to audio cues — don’t rely on sound alone to convey notifications.

The US 21st Century Communications and Video Accessibility Act (CVAA), signed October 8, 2010, adds specific captioning requirements for internet-distributed video that was previously captioned on TV.

Motor and mobility disabilities

Motor disabilities affect the ability to use a mouse, touchscreen, or standard keyboard. Conditions span temporary (broken arm, post-surgery), progressive (Parkinson’s, ALS, MS), and permanent (cerebral palsy, spinal cord injury). Assistive technologies in this space have evolved substantially in the last few years:

• Keyboard-only navigation — the foundational accommodation. Tab, Shift+Tab, Enter, Space, Arrow keys, Esc. Every interactive element must work via keyboard alone.
• Voice control — Dragon NaturallySpeaking (commercial), Windows Speech Recognition, macOS Voice Control, iOS/Android voice navigation. Quality of voice accessibility depends on accurate labels and visible click targets.
• Eye-tracking — increasingly mainstream. Tobii’s hardware has dominated the assistive market; Apple introduced built-in Eye Tracking on iPadOS 18 and iOS 18 in 2024, dramatically expanding access. Users navigate with gaze and select with dwell or blink.
• Switch access devices — single-button activation (head switch, sip-and-puff, etc.) for users with severe motor impairment. Switch software simulates mouse/keyboard events based on timing.
• Alternative keyboards — head pointers, mouth sticks, joystick mice, on-screen keyboards.

Critical practices: keyboard accessibility for everything (WCAG 2.1.1), visible focus indicators (WCAG 2.4.7), no keyboard traps (WCAG 2.1.2), interactive targets at least 24×24 CSS pixels (WCAG 2.5.8 Target Size Minimum, new in WCAG 2.2), avoid requiring complex gestures (WCAG 2.5.1 Pointer Gestures), and never time out interactive operations without warning (WCAG 2.2.1).

Cognitive and learning disabilities

Cognitive disabilities cover a broad range: dyslexia, ADHD, autism, memory impairments, processing disorders, traumatic brain injury, and many others. Accessibility for cognitive disabilities is the most diffuse area — what helps one user may not help another, and the design implications are often subtle. Practices that help most users with cognitive disabilities:

• Clear writing at an appropriate reading level (often 8th–10th grade for general audiences). Short sentences, simple vocabulary, active voice. WCAG 3.1 Readable.
• Consistent layout and navigation — predictable patterns reduce cognitive load. WCAG 2.2 added 3.2.6 Consistent Help, requiring help mechanisms to appear in the same relative position across pages.
• Clear error messages that explain what went wrong and how to fix it.
• Adequate time for reading and completing tasks. WCAG 2.2.1 requires adjustable timeouts. WCAG 3.3.7 (Redundant Entry, new in WCAG 2.2) requires previously-entered information to be reused rather than re-requested.
• Multiple content formats — text plus video plus audio. Users can choose what works for them.
• Minimal distractions — auto-playing video, excessive animation, intrusive ads all increase cognitive load.
• Accessible authentication (WCAG 3.3.8, new in WCAG 2.2) — login should not require a cognitive test that cannot be passed by assistive technology. Support password managers, biometrics, or other alternatives.

Cognitive disabilities can be functional (general impact on everyday tasks) or clinical (specific diagnosed conditions). Design that supports cognitive accessibility tends to support every user — power users included.

Seizure and photosensitive disorders

Roughly 3% of people with epilepsy have photosensitive epilepsy — flashing or strobing content can trigger seizures. WCAG 2.3.1 (Three Flashes or Below Threshold) prohibits content that flashes more than three times per second within general flash thresholds. Practices:

• Avoid flashing content where possible. If flashing is genuinely necessary (e.g., live news footage), warn users before showing it.
• Provide pause/stop controls on auto-playing animation (WCAG 2.2.2).
• Respect prefers-reduced-motion CSS media feature so users can opt out of motion via OS-level settings.
• Avoid relying on parallax, infinite scroll animation, or aggressive transitions as primary design elements.

Design considerations for accessibility

Two broad design philosophies apply to accessibility, and the choice between them shapes the rest of the work.

Universal design vs. personalized design

Universal design aims to create one experience that works for the widest possible audience. The seven principles of universal design — equitable use, flexibility, simple and intuitive use, perceptible information, tolerance for error, low physical effort, size and space for approach and use — guide the approach. Universal design is the dominant philosophy because it scales: the same effort benefits every user, and updates apply once rather than per-variant.

Personalized design creates multiple experiences targeted at specific user needs (a separate text-only version, a separate large-print version, a separate high-contrast version). It can deliver superior experiences for specific users but introduces real costs: more variants to maintain, more places for content to drift out of sync, and inevitably some user groups left out (you can’t design a separate version for every disability combination). Different users with the same disability also have different preferences — some screen reader users prefer navigation links at the top of the page, others at the bottom; some low-vision users prefer black-on-yellow, others white-on-black.

The pragmatic answer for most organizations is universal design as the default, with selective personalization for specific high-value scenarios where users need it (e.g., dark mode, font size preferences, reduced motion).

The “text only” myth

One persistent myth: “I’ll just publish a text-only version and that solves accessibility.” It doesn’t. Text-only versions consider only one user group (typically screen reader users) and ignore others — including users with cognitive disabilities, who often benefit from images and visual structure that explain concepts the text alone doesn’t, and dyslexic users who benefit from carefully chosen visual presentation. Graphics and visual design aren’t barriers to accessibility; they’re tools for accessibility when used correctly. The job is well-designed graphics with proper alt text and semantic markup, not removed graphics.

Summary by disability type

Putting the per-category considerations together as a designer’s quick reference:

Blind users

• Cannot see images, graphics, or visual layout.
• Listen to content via screen reader.
• Navigate by Tab key and headings; rarely use a mouse.
• Need alt text on every meaningful image.
• Need logical heading hierarchy and landmarks.
• Cannot interpret data tables and graphs visually — provide text summaries.
• Color is not usable for conveying meaning.
• Reading order in code matters; visual rearrangement via CSS doesn’t carry to screen readers.

Color vision deficient users

• Difficulty distinguishing colors of similar contrast or specific color pairs (especially red/green).
• Need 4.5:1 contrast for normal text, 3:1 for large text and UI components.
• Color cannot be the only way information is conveyed — pair with text, icon, or pattern.

Low-vision users

• Use screen magnifiers up to 400% zoom.
• Limit horizontal scrolling — use relative units (em, rem, %, viewport units) rather than fixed pixel widths.
• Avoid text-as-image — text within graphics gets pixelated when enlarged.
• Support Forced Colors Mode by avoiding hard-coded colors.

Deaf and hard-of-hearing users

• Cannot use audio content — need captions for video and transcripts for audio.
• Sign language interpretations are preferred where feasible.
• Don’t rely on sound alone for notifications or alerts.

Motor-impaired users

• May not be able to use a mouse; rely on keyboard, voice, eye-tracking, or switch devices.
• Every function must work via keyboard alone (Tab, Shift+Tab, Enter, Space, arrows, Esc).
• Tab order must be logical and match visual order.
• Visible focus indicator at all times.
• Targets at least 24×24 CSS pixels (WCAG 2.5.8).
• Avoid timeouts that can’t be extended.

Cognitive-disabled users

• Confused by complex layouts and inconsistent navigation.
• Difficulty focusing on long passages of dense text.
• Benefit from simple layout, consistent navigation, plain language, manageable chunks of content.
• Benefit from supplemental illustrations or video for complex concepts.
• Need accessible authentication (WCAG 3.3.8) and adequate time (WCAG 2.2.1).

Frequently asked questions

What’s the most common accessibility mistake?

Failing keyboard navigation. A surprising number of otherwise-well-designed sites have menus that only open on hover, buttons that only respond to clicks (not Enter or Space), or focus indicators that are invisible. Keyboard testing is the single highest-signal accessibility test — unplug the mouse for 10 minutes and try to use your site.

Is automated testing sufficient?

No. Automated tools (axe DevTools, WAVE, Lighthouse) catch 30–50% of WCAG issues. The remainder requires manual testing — keyboard navigation, screen reader use, zoom testing, forced-colors testing, and ideally user testing with people who have disabilities. See our manual accessibility testing guide for the practical methods.

Should we hire users with disabilities for testing?

Yes if feasible. Real-user testing with people who have disabilities is the gold standard — services like Fable, Applause, and UserTesting accessibility panels provide structured access to participant pools. The findings consistently surface issues automated tools and able-bodied testers miss.

How do I avoid the “accessibility overlay” trap?

Skip them entirely. JavaScript widget overlays (accessiBe, UserWay, AudioEye, EqualWeb) cost $50–$500/month, do not deliver real accessibility, and can themselves attract litigation. The FTC’s January 2025 consent order against accessiBe ($1M plus a ban on deceptive performance claims) formalized what accessibility practitioners had said for years. Spend the same money on real remediation work or training.

What’s the right WCAG level to target?

Level AA is the practical compliance target — required by virtually every major accessibility law (DOJ Title II Rule, EAA, EN 301 549, Section 508). Targeting WCAG 2.2 AA satisfies 2.1 AA automatically and positions the organization for forthcoming regulatory updates that reference 2.2.

How often should we re-test?

Automated checks on every deploy via CI. Manual keyboard testing on critical paths quarterly. Full accessibility audit annually or before any major launch. User testing with people who have disabilities periodically — at least once per major redesign cycle.

Bottom line

Accessibility from the user’s perspective comes down to recognizing that “the web” is not one experience — it’s a different experience for every disability category and assistive technology that engages with it. Build for the breadth of users your site actually serves: blind users navigating by screen reader, low-vision users magnifying content, deaf users reading captions, motor-impaired users tabbing through with keyboard or gaze, cognitively-disabled users following clear text and consistent navigation. WCAG 2.2 Level AA is the technical standard; universal design is the philosophy; real-user testing is the validation. Get those right and your site works for the 1 in 4 users with disabilities who currently get shut out by sites that didn’t take the time. The work returns dividends in conversion, brand reputation, search performance, and — increasingly — legal protection.