Why Accessibility Isn't Optional: How We Build a Kinder Web

For developers who want to build better, human-first websites, and finally understand what real accessibility looks like.

You never forget the first time you hear the web. Not see it. Hear it.

That moment during the accessibility workshop when someone who was blind used a screenreader to navigate a website, I realised: everything we build gets read out loud, every repetition, every empty label, every meaningless image, image, image...

The internet, read aloud, can feel like a chaotic avalanche of noise. Until, suddenly, we land on a well-built page, and the sigh of relief is almost tangible. Structure. Flow. Sense. A little peace in a jungle of bad markup.

Accessibility isn't a bonus. It's a baseline. And it's time we act like it.

---

What accessibility really means (and for whom)

Accessibility isn't just for blind users. It's for anyone who struggles to access or interpret the content we build.

Think of someone with dyslexia, who finds long paragraphs overwhelming. Or a user navigating with a keyboard because their hands tremble too much to use a mouse. Or an older visitor with fading vision and cognitive processing speed. Or someone with ADHD (or ADD, like myself), overwhelmed by flashy animations and endless dropdowns.

Accessibility means:

• people with dyslexia, ADHD, or cognitive overload
• people with low vision or colour blindness
• older users with declining motor skills
• anyone navigating via keyboard, voice, or braille
• users with sensory sensitivities or mental health challenges

In short: it's for people. All users. Also yours, and ours.

During the workshop, I found myself wondering: can blind users also have dyslexia? It felt like an odd question at first, but after looking into it, the answer was yes. Unexpected, but true. Human brains are complex. And the web we build should meet them where they are.

---

Real-life frustration: how the web can overwhelm

Here's a scene from the workshop: we're watching a screenreader user try to navigate a site. They hit tab, again, and again... and again. Each press brings a new link with the same label: "Read more." The same heading repeats five times. Then: "image." Another "image." No description. No clue. No orientation.

It's like walking into a building with no signs, no lights, and a looping elevator voice that just says "floor."

For someone using a screenreader, that's not just frustrating. It's exhausting.

We heard and saw:

• repeated phrases and headings without purpose
• alt-text that simply says "image"
• buttons that say "click here" with no context
• no way to skip repetitive menus

It’s like picking up ten markers that all look identical. You have to scribble with each one to find out if it’s red, blue, or green. That’s what it’s like navigating a site with no clear labels or structure.

---

What we can do, starting today

You don't need to rewrite the entire front-end universe. You just need to start thinking about what you're really building:

A page? Or a pathway?

Here’s how to build one worth walking:

• Use semantic HTML: nav, main, section, h1–h6, ul, button, label. They're not optional. Native HTML is better than ARIA. Use ARIA only when necessary, and always test it.
• Add meaningful alt-text: If you were explaining the image to someone over the phone, what would you say?
• Ensure keyboard navigation: Try tabbing through your own site. Can you get everywhere you need to go?
• Include a "Skip to main content" link at the top of your page
• Use focus outlines: They're not ugly. They're lifelines.
• Validate forms accessibly: Use clear error messages, visible and screenreader-friendly
• Test your site with a screenreader or simulator: You'll learn more in five minutes than from five articles.
• Structure pages with clear headings and hierarchy: Not for SEO, but for orientation
• Check contrast, but don’t blindly trust tools. Some text passes the checker but still feels unreadable. Subtle backgrounds can trick the algorithm. A few pixels one way or another, and it fails.
  Use tools like WebAIM’s Contrast Checker as a guide, but when in doubt, ask a real person.

Tip: If a user turns off their screen and still understands your content, you're on the right track.

---

What the guidelines (and law) say

The WCAG 2.1 is still the gold standard. It shows us how to build with inclusion in mind.

But in the EU, that’s no longer just a nice-to-have.
The European Accessibility Act is coming into full effect, and it’s the whole reason we were in that workshop. Because suddenly, accessibility knowledge isn’t something you can skip anymore. If you're building websites, apps, or digital services, it's no longer optional. It’s essential.

According to the W3C, accessibility isn’t just a technical checklist. It’s a moral imperative.
And a 2023 audit by the European Commission found that over 70 percent of public-facing sites still fail basic accessibility checks.

So what does that mean for us?

• Existing websites must gradually become accessible
• New websites must meet accessibility standards before going live
• Public and commercial services are both affected

If you build digital products in Europe, accessibility isn’t optional.
It’s mandatory, and long overdue.

---

Final thoughts

What struck me most in the workshop was this: when the screenreader finally landed on a clean, accessible site, the voice changed. The tension dropped. It was easier. That is the power of accessibility.

We build for people we may never meet.
Some users hear our code. Some feel it through braille. Some depend on it.

Accessibility is not just a feature, it's the foundation of a web that welcomes everyone.