Accessibility (Principle)

The design principle that products should be usable by people of all abilities and disabilities.

stellae.design

Design Principles

Accessibility is the principle that products should be usable by people with the widest range of abilities. This includes permanent disabilities, temporary conditions, and situational limitations. It's both ethical and legal (ADA, EAA, Section 508). WCAG organizes requirements as: Perceivable, Operable, Understandable, Robust (POUR). Accessible design benefits everyone — captions help in noisy environments, high contrast helps in sunlight.

Why It Matters

Accessibility as a design principle means building products that can be used by everyone regardless of ability, disability, situation, or technology — encompassing permanent disabilities like blindness, temporary impairments like a broken arm, and situational limitations like using a phone in bright sunlight. It is not a feature to be added after launch or a compliance checkbox to satisfy legal requirements; it is a fundamental quality attribute that determines whether your product serves its full potential audience or excludes up to 25% of the global population who experience some form of disability. Products designed with accessibility as a core principle consistently outperform those that treat it as an afterthought, because the constraints of accessible design — clear hierarchy, predictable navigation, readable content, sufficient contrast — produce better experiences for all users, not just those with disabilities.

Real-World Examples

Gov.uk's accessibility-first design system

The UK Government Design System builds accessibility into every component from the ground up, with documented keyboard behaviors, screen reader expectations, and WCAG compliance levels for each pattern. Components ship with tested ARIA attributes, sufficient color contrast ratios, clear focus management, and content guidelines that ensure plain language across all government services. The result is a design system that makes the accessible path the default path, removing the possibility of individual teams making inaccessible choices when using standard components.

Microsoft's Inclusive Design methodology

Microsoft's Inclusive Design framework recognizes that designing for permanent disabilities simultaneously solves for temporary and situational limitations — designing for a one-armed user also helps someone holding a baby or carrying groceries. The methodology uses a persona spectrum that maps permanent, temporary, and situational versions of each disability category, helping designers see accessibility as a universal concern rather than an edge case. This reframing transformed Microsoft's product development culture by demonstrating that accessibility improvements benefit their entire user base.

Counter-example

Retroactively patching accessibility after a lawsuit

A major retail company builds its entire web platform over two years with no accessibility consideration, using custom div-based controls, mouse-only interactions, and images without alt text throughout. After receiving a legal complaint, they hire a consultancy to bolt on ARIA attributes and keyboard handlers to hundreds of custom components, resulting in an inconsistent experience where some elements announce correctly but behave unpredictably and keyboard navigation frequently traps users in widget loops. The remediation costs three times more than building accessibly would have, and the resulting experience still fails usability testing with screen reader users because the underlying HTML structure was never designed for assistive technology.

Role-Specific Guidance

Common Mistakes

• The most pervasive mistake is treating accessibility as a final-phase audit rather than a foundational design constraint — teams who wait until development is complete to run accessibility checks inevitably face a painful choice between expensive rework and shipping a substandard experience, because structural accessibility problems in HTML semantics and interaction patterns cannot be fixed with superficial ARIA patches. Another common error is equating accessibility with screen reader support alone, ignoring the needs of users with cognitive disabilities, motor impairments, vestibular disorders, and low vision who need clear language, generous touch targets, reduced motion options, and scalable text respectively. Teams also over-rely on automated testing tools and assume a passing score means their product is accessible, when automated scanners miss the majority of real-world accessibility barriers including logical reading order, meaningful link text, appropriate use of ARIA roles, and whether interactions actually make sense when experienced non-visually.