Why I care about WCAG

I’m a frontend specialist.

And I’m colorblind.

Yes. A colorblind frontend specialist. The universe has jokes.

For years, I’ve bumped into the same tiny, dumb, avoidable problem: products that communicate important meaning using red/green alone.

Green means “good”.

Red means “bad”.

And I’m sitting there like: Cool story. Which one is which again?

Most of the time it’s not a crisis. It’s just friction.

But it’s friction in places where nobody around me even notices there’s a problem.

And that detail rewired my brain.

If my small handicap can create real confusion in everyday UI…

…what does the web feel like for someone with a bigger one?

Someone who can’t use a mouse.

Someone who navigates by keyboard because it’s faster — or because they have to.

Someone using a screen reader.

Someone with low vision.

Someone who gets cognitive overload when the interface keeps shifting state without warning.

That’s when WCAG stopped being “a checklist” for me.

It became reliability.

Accessibility is just reliability for humans

We’re great at building reliability practices for systems:

• strict TypeScript flags to catch bugs at compile time
• tests that prevent regressions
• monitoring so we can see what breaks in production

We do all this because failure modes are expensive.

WCAG is the same mindset, just pointed at a different kind of failure:

“The UI worked… for me… with my eyes… and my mouse… on my screen… on a good day.”

Accessibility asks: does it still work when those assumptions are false?

Because in real life, they often are.

The quiet exclusion nobody intended

Here’s the uncomfortable truth: most accessibility problems aren’t created by evil people.

They’re created by invisible assumptions.

• “Everyone can see the red badge.”
• “Everyone can click the tiny X.”
• “Everyone will understand the icon without text.”
• “Everyone can track focus when we open a modal.”
• “Everyone can tell that a dropdown opened.”

Those assumptions feel harmless… until you’re the person they don’t fit.

That’s why I’m increasingly allergic to “but it’s fine.”

Fine for who?

My personal rule now

Over the last year I’ve gone all-in on this:

Everything I build should meet the highest practical WCAG standard.

Not because I want trophies.

Not because I want to shame teams.

Not because I enjoy adding ARIA attributes for sport.

Because excluding people through accidental design choices is the opposite of boring reliability.

If a component can’t be used without perfect vision, perfect dexterity, and the “correct” input device…

…then it’s not reliable.

It’s fragile.

And fragile UIs create support tickets, drop-offs, workarounds, and wasted time.

WCAG isn’t just ethics.

It’s quality.

The tiny trick that changed how I build components

Once you start caring about WCAG, you start noticing the boring stuff that actually matters:

• focus management (where does focus go when something opens? when it closes?)
• keyboard contracts (Enter, Escape, Arrow keys, Tab)
• clear semantics (name, role, state — not vibes)
• meaning not encoded by color alone
• predictable behaviour, even under stress

This is the kind of frontend craftsmanship that rarely shows up in screenshots.

But it shows up in real life.

If you want one place to start

Start with the components that love to fail silently:

• modals
• dropdowns
• menus
• custom inputs

I’ve been writing small, practical WCAG pages with live demos and checklists — not theory.

One example: a keyboard‑navigable dropdown that doesn’t trap users and actually behaves like a grown‑up component.

The punchline

I didn’t start caring about WCAG because I wanted to be virtuous.

I started caring because the web kept reminding me, in tiny ways, that it wasn’t built for everyone.

And if my little colorblindness is enough to make things harder…

…then I don’t want to ship interfaces that make life harder for people with much larger barriers.

Boring reliability is supposed to include humans.