From Good Intentions to Inclusive Design: A Q&A on Accessibility

Designers are inherently good people—no one sets out to create an exclusionary experience. Yet we all encounter websites, apps, or physical products that are confusing, hard to read, or simply unusable. The gap between good intentions and bad outcomes often stems from one simple problem: there is too much to remember. With countless guidelines, best practices, and ever-evolving technologies, even the most conscientious designer can overlook accessibility. This Q&A explores a practical solution inspired by Jakob Nielsen's usability heuristics: making design requirements visible and easily retrievable so that inclusive choices become second nature.

1. Why do good designers create bad websites?

Designers are dedicated professionals who genuinely care about their users. You'll never hear a designer say, "I don't care if someone can't read this text," or "It's not my fault if this interface is confusing." Yet despite their good intentions, many designs end up excluding people. The root cause isn't malice or laziness—it's overload. There are simply too many things to recall at once. Designers must juggle visual aesthetics, interaction patterns, content strategy, performance, and a growing list of accessibility requirements. With so much information to hold in mind, it's inevitable that some aspects slip through the cracks. The result: beautiful, well-intentioned designs that inadvertently create barriers for users with limited vision, hearing, cognition, or mobility. The solution isn't to try harder, but to make the right information easier to access during the design process.

2. Is accessibility really a life-or-death issue?

Yes. Aral Balkan's essay This Is All There Is makes a compelling case that almost every design decision can affect life events and death events. For example, consider a simple bus timetable app. If the text is too small or the interface is confusing, someone might miss a bus that would have taken them to their daughter's fifth birthday party—a life event. Worse, they might miss a chance to say goodbye to a dying grandmother—a death event. Accessibility isn't just about compliance; it's about real human impact. When we design poorly, we don't just frustrate users—we can alter the course of their lives. Recognizing this stakes elevates accessibility from a nice-to-have feature to an ethical imperative.

3. Why do some designs still exclude people despite our knowledge?

We know that not everyone sees perfectly, hears perfectly, thinks the same way, or moves the same way. Designers have access to extensive guidelines, articles, and tools covering accessibility. Yet exclusion persists. The frustrating answer is that there is too much to recall. Consider the vast range of topics covered by publications like A List Apart: typography, layout, interaction, animation, performance, security, and on and on. Designers are expected to absorb all that guidance plus every accessibility requirement. That's an unrealistic cognitive load. Even with the best intentions, designers simply cannot keep everything in their heads. The issue isn't knowledge—it's memory. What we need is a system that surfaces the right information at the right time, reducing reliance on recall.

4. What's the problem with relying on designer memory?

Jakob Nielsen's 10 Usability Heuristics include a principle called Recognition rather than Recall. For users, this means that all necessary information should be visible or easily retrievable when needed. I propose we apply the same principle to designers. Currently, designers are forced to remember accessibility guidelines from memory while working on a project. That's effectively recall, which is error-prone and mentally exhausting. The alternative is recognition: make guidelines, examples, and checklists visible right in the design environment—like a quiet companion that prompts you at key moments. By shifting from recall to recognition, we reduce cognitive load and make inclusive design more achievable. This isn't about dumbing down; it's about smart support.

5. How can we make accessibility issues recognizable during design?

Inspired by Nielsen's heuristic, we can tweak it for creators: the information required to produce the design should be visible or easily retrievable when needed. Practical methods include integrating accessibility checklists into design tools, providing inline tips, or using pattern libraries annotated with accessibility notes. For instance, a color palette picker could flag low-contrast combinations. A wireframe tool could remind you to add focus indicators. This approach is outlined in Sarah Horton and Whitney Quesenbery's book A Web for Everyone. The goal is to embed accessibility into the workflow so that designers don't have to remember everything—they can simply see what's needed. This makes inclusive design the default, not an afterthought.

6. What's the key proposal from the original article?

The original article proposes applying Nielsen's sixth heuristic—Recognition rather than Recall—directly to the design process itself. Just as users benefit from visible controls and cues, designers benefit from visible accessibility requirements. The idea is to reduce the mental load on designers by making crucial information part of the design environment. This could take the form of in-tool checklists, real-time accessibility warnings, or curated references that appear contextually. Instead of relying on memory, designers can rely on recognition. This small shift in approach could dramatically reduce exclusionary designs. It's a practical, human-centered solution that acknowledges the realities of design work without blaming professionals for gaps in knowledge.

• Focus on recognition over recall
• Embed accessibility in design tools
• Make guidance easily retrievable
• Reduce cognitive load on designers

7. How does the bus timetable example highlight the importance of inclusive design?

The bus timetable example from Aral Balkan shows that even a simple app can have profound consequences. A person with low vision might struggle to read tiny text; a person with cognitive disabilities might get confused by complex navigation; a person with motor impairments might not be able to tap small buttons. If the app is poorly designed, that person might miss a bus. Missing that bus could mean missing a daughter's birthday party (a life event) or missing a final goodbye to a grandmother (a death event). This isn't hyperbole—it's a realistic scenario. The example underscores that accessibility isn't just about disability; it's about ensuring that everyday tools don't rob people of meaningful moments. Designers hold that power, and with it comes responsibility to include everyone.