Accessibility isn't a feature. It's the foundation. Most articles give you inspiration. This one gives you something to actually do tomorrow morning.

Let's start with two facts that nobody argues with:

  • Designers are decent people. I've never heard a designer say they don't care if someone can't read the text, can't use the device, or gets confused.
  • And yet, some designs exclude people. You've watched someone squint at a site you built. You've seen a user abandon a checkout flow. You've witnessed that moment of pure confusion.

So what's the gap between intention and outcome?

This Is Life-or-Death Stuff

Aral Balkan, in his essay This Is All There Is, makes the point bluntly: almost everything we design touches life events and death events. Even a bus timetable app. Design it badly, and someone misses their daughter's fifth birthday party. Or misses the chance to say goodbye to a dying grandmother.

That's the stakes.

Why Does Exclusion Still Happen?

We know the basics: not everyone sees perfectly, hears perfectly, thinks the same way, or moves the same way. So why do exclusionary designs keep shipping?

I think the real culprit is cognitive overload. There's too much to remember. Designers are expected to hold usability guidelines, accessibility specs, platform conventions, business requirements, and stakeholder feedback all in their heads at once. That's not realistic.

One Practical Fix: Recognition Over Recall

Jakob Nielsen's 10 Usability Heuristics date back to the mid-1990s. Heuristic №6 — Recognition rather than Recall — says that for users, information needed to use the design should be visible or easily retrievable. Let's flip that for designers: the information needed to produce the design should be visible or easily retrievable when needed.

In plain English: make it easy to spot accessibility issues while you're designing, not after.

Meet Your Users (They're Free)

Sarah Horton and Whitney Quesenbery's book A Web for Everyone includes personas that do exactly this. Even better: those personas are now available for free on the companion site for What Every Engineer Should Know About Digital Accessibility by Sarah Horton and David Sloan.

Here they are:

  • Vishnu – engineer, global citizen, low vision. “If I can adjust my screen, I can read comfortably.” “Translating in my head is easier with simpler sentences.”
  • Trevor – high school student, autism. “When I can learn the pattern, I can find my way.” “Reading is hard for me.”
  • Steven – deaf graphic artist, ASL speaker. “Without captions, it's meaningless to me.”
  • Maria – bilingual community health worker. “When a site is confusing, I just leave.” Fair enough, Maria.
  • Lea – editor, lives with fatigue and pain. “Don't make me work so hard.” (Please, no dropdowns for this woman.)
  • Jacob – blind paralegal, bit of a geek. “The right technology lets me do anything.”
  • Emily – cerebral palsy, lives independently. “Simpler screens are easier screens.” Hell yeah, Emily.
  • Carol – grandmother, macular degeneration. “Why can't the text be just a little bit larger?”

And one more: Cennydd Bowles, who wrote the book on Future Ethics, suggests creating Personas Non Grata. For every design, ask: what could a bad actor do with this? And who would that hurt?

How to Use These in Real Projects

Eric Meyer and Sara Wachter-Boettcher, in Design for Real Life, suggest the Designated Dissenter role. For each project, assign one team member to ask: “Will this work for Vishnu? How's Trevor going to get on with this?”

Once you've identified the issues — and you will, because these personas make them obvious — turn to the platform-specific guidelines:

  • Web Content Accessibility Guidelines (WCAG) 2.2
  • ARIA Authoring Practices
  • Platform accessibility docs (iOS, Android, Web)

For businesses on Cyprus or in the EU, this isn't theoretical. GDPR compliance, EL/EN/RU multilingual sites, and local competition mean that an inaccessible site isn't just exclusionary — it's a liability. A site that works for Carol, Trevor, and Vishnu also works for your customers in Limassol, Nicosia, and beyond. Budget for it upfront. It's cheaper than a redesign.

Good designers build bad websites because they're trying to remember too much. The fix isn't more training. It's better tools — starting with personas that make the invisible visible.