Most technology designers don't intend to exclude people with disabilities. They're simply not thinking about disability when they make design decisions. This unintentional exclusion may be less malicious than deliberate discrimination, but its effects can be just as harmful. Understanding how mainstream technology inadvertently excludes—and how to prevent such exclusion—matters for everyone who designs, develops, or deploys technology.
The Default User Assumption
Design proceeds from assumptions about users. Often those assumptions reflect the designers themselves—typically young, able-bodied, tech-savvy people working in specific environments. The "default user" imagined during design may have full vision, hearing, mobility, and cognition. Features designed for this user may not work for others.
This isn't necessarily conscious. Designers may never explicitly think "I'm designing for non-disabled users." But without conscious attention to disability, designs reflect the bodies and minds of those creating them. Disability becomes an edge case to be handled later, if at all, rather than a reality to design for from the start.
Personas and user stories used in design may omit disability entirely. If the imagined users are all able-bodied, design decisions won't account for alternative ways of interacting. Including disabled personas explicitly would prompt different design considerations.
Interface Design Exclusions
Visual design choices frequently exclude users with visual impairments. Low contrast text, small fonts, color-coding without other differentiation, and busy visual layouts all create barriers for users with low vision, color blindness, or visual processing differences.
Touch interfaces assume fine motor control that not everyone has. Small targets, gesture-dependent features, and multi-touch requirements may be impossible for users with motor impairments. The sleek simplicity of minimal interfaces often trades away the clear targets and multiple interaction paths that accessibility requires.
Audio-dependent features exclude deaf and hard of hearing users when alternatives aren't provided. Error sounds without visual indicators, voice-only interfaces, and audio content without captions all create barriers for users who can't hear.
Cognitive load assumptions may not match all users. Interfaces requiring working memory, reading comprehension, sustained attention, or rapid decision-making may be inaccessible to users with cognitive, learning, or developmental disabilities.
Time-Dependent Features
Features that assume particular speeds exclude users who need more time. Session timeouts, disappearing content, rapid animations, and real-time interactions may not accommodate users who interact more slowly due to disability.
Time pressure features like countdown timers, limited-time offers, and auto-advancing content create barriers beyond accessibility. But for users with disabilities affecting processing speed, these features may be completely unusable rather than merely stressful.
Allowing user control over timing—extending timeouts, pausing content, controlling playback speed—addresses these barriers without fundamental redesign. But these options aren't default, and designers must consciously include them.
Physical Interaction Assumptions
>Hardware design often assumes standard bodies. Devices that require two-handed operation, specific grip strength, or particular ranges of motion exclude users whose bodies work differently. The sleek thinness that design prizes may sacrifice the physical affordances that enable diverse use.
Wearable technology exemplifies these assumptions. Smartwatches assume wrists of certain sizes and configurations. Fitness trackers assume particular types of movement. Headphones assume particular ear shapes. Bodies that don't match assumptions may be unable to use devices everyone else enjoys.
Environmental controls—touchscreens in cars, smart home interfaces, self-service kiosks—often lack accessible alternatives. When the physical interface is the only interface, those who can't use it are excluded from whatever function it provides.
Authentication and Verification
>Security features frequently create accessibility barriers. CAPTCHAs challenge particular abilities—visual, auditory, cognitive—that not all users have. Biometric authentication assumes body parts and functions that vary. Knowledge-based authentication assumes memory capabilities not universal.
The multiplication of authentication requirements compounds barriers. Multi-factor authentication is more secure but requires multiple interactions that each present potential accessibility challenges. Security and accessibility needn't conflict, but designs often trade one for the other.
Verification processes that require phone calls, video presence, or in-person appearance assume abilities that aren't universal. When verification is mandatory—for government services, financial accounts, healthcare access—inaccessible verification processes lock people out of essential services.
Content and Communication
>Content created without accessibility in mind often excludes. Documents in inaccessible formats, images without descriptions, videos without captions, and audio without transcripts all fail some users.
Plain language isn't just accessibility—it benefits all readers—but complex jargon and convoluted sentences particularly exclude readers with cognitive or language-related disabilities. Accessible writing is clear writing, but clarity requires conscious effort.
Real-time communication features may exclude users who communicate differently. Live chats, voice calls, and video conferences work well for many but create barriers for others. Multiple communication channels, including asynchronous text options, expand who can participate.
Algorithms and AI
>Algorithmic systems can encode and amplify exclusion. If training data underrepresents disabled users, systems may work poorly for them. If optimization targets don't include accessibility metrics, accessible approaches may be selected against.
Recommendation systems may not recommend content to users with disabilities or about disability. Content moderation may flag disability-related content inappropriately. Automated decision systems may discriminate without human review catching the problem.
The opacity of many algorithmic systems makes exclusion difficult to identify and address. Users may not know why they're receiving particular treatment. Even developers may not understand how their systems behave for users whose profiles differ from the majority.
Preventing Unintended Exclusion
>Preventing exclusion requires proactive attention rather than reactive fixes. Accessibility considered from design inception produces better results than retrofitting accessibility onto finished products.
Standards and guidelines exist—WCAG for web content, platform accessibility guidelines for mobile development, Section 508 and AODA requirements for various contexts. Following established standards catches common exclusions. But compliance is a floor, not a ceiling—standards don't cover everything and meeting them doesn't guarantee good accessibility.
Testing with disabled users identifies problems that designers and standards don't catch. Diverse testing—different disabilities, different assistive technologies, different contexts of use—reveals different issues. No single tester catches everything.
Organizational accountability matters. When someone is responsible for accessibility, it gets attention. When no one is responsible, it doesn't. Accessibility owners, accessibility audits, and accessibility metrics all increase likelihood that exclusion gets caught and fixed.
Questions for Reflection
>How might design education be changed to make accessibility central rather than peripheral to how designers learn their craft?
>What incentives would effectively motivate technology companies to prevent exclusion rather than merely fixing it when caught?
>Should there be liability for accessibility failures that exclude people from important services or opportunities?