Accessibility is often an afterthought, even among well-intentioned designers. This article explores why exclusion happens despite good intentions and how we can shift our approach to make accessibility a natural part of the design process. Below, we answer key questions about this paradox and offer a concrete solution rooted in usability heuristics.

What is the main argument about accessibility in design?

Designers are inherently good people who care about their users—no one intentionally sets out to exclude. Yet, time and again, we see websites and apps that are hard to read, difficult to navigate, or impossible for certain people to use. The central argument is that this contradiction stems not from ill will but from an overwhelming amount of information. Designers must juggle countless guidelines, visual trends, technical constraints, and business requirements. Accessibility guidelines add yet another layer. When there is too much to remember, even the best designers inadvertently create barriers. The real challenge is not a lack of empathy but a lack of usable, accessible knowledge during the design process. The solution, then, is to make accessibility information easier to recognize at the moment of designing, rather than relying on memory or after-the-fact audits.

Why do some designs still exclude people despite good intentions?

The root cause is cognitive overload. Designers are expected to recall a vast array of principles: visual hierarchy, color theory, typography, user flows, brand guidelines, and accessibility requirements like contrast ratios, screen reader compatibility, and keyboard navigation. As discussed below, the problem is that human memory is limited. When faced with dozens of competing priorities, accessibility often slips through the cracks—not because it's unimportant, but because it's one of many things to keep in mind. Additionally, many designers lack formal training in inclusive design; they may not know what they don't know. The result is environments that work for the average user but fail for people with disabilities. The solution isn't to blame designers but to change the system so that accessibility hints are visibly present during the creative process, much like a checklist in a cockpit.

How does the bus timetable app example illustrate the life-or-death stakes?

Aral Balkan, in his essay "This Is All There Is," argues that every design decision can have profound consequences. A bus timetable app might seem trivial, but if it's confusing or inaccessible, someone could miss a bus—and that missed bus might mean missing a daughter's fifth birthday party (a life event) or being unable to say goodbye to a dying grandmother (a death event). This example strips away the abstraction: accessibility isn't just about compliance or convenience; it directly affects people's ability to participate in fundamental human experiences. When designers realize that poor accessibility can lead to missed life milestones or final farewells, the urgency becomes clear. It's not hyperbole—it's a chain of cause and effect. Every touchpoint, from a cluttered interface to tiny buttons, can derail someone's day or change their life. This perspective transforms accessibility from a "nice-to-have" into a moral imperative.

What is the proposed solution to help designers remember accessibility?

The article proposes adapting Jakob Nielsen's usability heuristic #6: "Recognition rather than Recall." Originally applied to users, this heuristic says that information needed to use a design should be visible or easily retrievable. The twist: apply it to designers. Instead of expecting designers to memorize every accessibility guideline, make that information visible and easily accessible within their design tools and workflows. For example, a design system could include contrast checkers, font-size guides, and alternative text prompts directly in the component library. Or a wireframing tool could highlight areas where color-only communication might fail. By shifting the burden from recall to recognition, we reduce cognitive load and make inclusive design more automatic. This doesn't require new knowledge—just a smarter way to surface existing knowledge at the moment it's needed. The result: fewer oversights and more consistently accessible outputs.

How can Jakob Nielsen's usability heuristic be applied to designers?

Jakob Nielsen's 10 Usability Heuristics for User Interface Design, from the mid-1990s, are still relevant. Heuristic #6 states that users should not have to remember information from one part of an interface to another; instead, options should be visible. To apply this to designers, we reframe it: designers should not have to remember all accessibility guidelines; instead, the guidelines should be visible or easily retrievable during design. Concrete applications include: embedding accessibility reminders in design systems, using plugins that flag low-contrast text or missing alt attributes, and creating persona cards that highlight diverse user needs. The key is to move from an abstract checklist to an integrated part of the design environment. For instance, a color picker could show a warning when the chosen color combination fails WCAG standards. By making these cues recognizable rather than relying on recall, designers can catch issues early and naturally incorporate accessibility into their workflow.

What is the value of the book "A Web for Everyone" in this context?

"A Web for Everyone" by Sarah Horton and Whitney Quesenbery is a comprehensive guide that operationalizes inclusive design. The article references it as an example of a resource that could be integrated into a recognition-based system. Instead of expecting designers to read the entire book and remember its principles, the book's insights can be distilled into checklists, design patterns, and in-tool prompts. For example, the book covers how to write meaningful alt text, structure headings for screen readers, and ensure keyboard accessibility. If these bits of knowledge are surfaced automatically—say, as tooltips in a content management system or as validation rules in a prototyping tool—designers benefit without extra mental effort. The book's value lies in its practical, user-centered approach. It bridges the gap between theory and practice. By making its lessons visible at the right moments, we honor the book's intent: creating experiences that work for everyone, regardless of ability.

What practical steps can designers take to recognize accessibility issues?

First, audit your design tools: do they have built-in accessibility checks or plugins? If not, add them. For example, Figma plugins like Stark check contrast and simulate color blindness. Second, create a "designer's dashboard" with key heuristics, such as ensuring all interactive elements are keyboard-accessible or that text can be resized. Third, integrate accessibility into your design system: define accessible color palettes, provide templates with proper heading structure, and include alternative text placeholders. Fourth, use personas that represent a range of abilities—not just an "average" user. Fifth, perform quick checks before finalizing any design: zoom in to 200% to see if text becomes unreadable, tab through to see if focus order makes sense, and run automated tools to catch common issues. Finally, foster a culture where accessibility is a shared responsibility, not just a checklist item. By embedding these practices into daily routines, designers shift from recalling to recognizing accessibility needs naturally.