I need to tell you about a moment that changed how I think about building software.

A few years ago, I watched someone try to use a website we'd built. Nothing complicated. Just a standard service directory for a community organisation.

Except this person couldn't use a mouse. They navigated everything with a keyboard, tabbing from link to link, moving slowly and deliberately through the page.

Our site looked beautiful. The design was clean. The colours were on brand. Everything was exactly where it should be.

And it was completely unusable for them.

The tab order jumped around unpredictably. Focus indicators had been removed because someone thought they "looked messy." Interactive elements weren't properly labelled, so screen readers announced them as "button" with no context.

I sat there, watching someone struggle with something I'd helped build, and felt absolutely terrible.

That person left the site. They probably found what they needed elsewhere, or maybe they gave up. I'll never know. But I've never forgotten what that moment taught me.

Accessibility Isn't A Feature

Here's the mistake too many teams make. They treat accessibility like a checkbox. Something you test at the end, fix a few issues, and call done.

That's not how it works.

Accessibility isn't a layer you add after the fact. It's not a list of WCAG guidelines you run through before launch. It's not even primarily about disabled users, although that's where the conversation usually starts.

Accessibility is about building things that work for everyone, regardless of how they interact with technology.

Someone using a screen reader because they're blind. Someone using keyboard navigation because they have a motor impairment. Someone increasing font size because their eyes are tired. Someone on a slow connection in a rural area. Someone with a temporary injury, a broken arm, a forgotten pair of glasses.

All of these people are your users. All of them deserve a site that works.

The Business Case Nobody Talks About

I could give you the moral argument for accessibility. Build inclusive stuff because it's the right thing to do. That's true, and it matters.

But let me give you the business argument too.

Approximately one in five people in the UK has a disability. That's potential users, customers, donors, volunteers, who will bounce off your site if it doesn't work for them. You're not reaching them. Your competitors aren't either, which means there's an opportunity sitting right there.

Beyond that, accessible design is just better design. The same principles that help someone with a screen reader also help someone trying to use your site on a smartwatch, or in bright sunlight, or with one hand holding a toddler. Clear navigation, readable text, logical structure, those things benefit everyone.

I've never met anyone who complained that a site was too easy to use.

What Good Looks Like

Let me tell you about a client who got this right.

They run a mental health support service. Their users are often in distress, looking for help quickly, sometimes accessing the site on old phones or limited data plans. Getting it right wasn't optional for them. It was central to their mission.

We built their site with accessibility baked in from day one. Not as an afterthought, but as a fundamental requirement.

That meant proper heading structure so screen reader users could navigate easily. Good colour contrast so text was readable. Keyboard-friendly navigation for people who couldn't use a mouse. Simple, clear language because cognitive load matters when you're already struggling.

The site launched and worked fine. Nothing dramatic happened. But here's what didn't happen.

Nobody complained they couldn't use it. Nobody got frustrated and left. Nobody called support because they couldn't find what they needed. The site just worked, for everyone, quietly and consistently.

That's the goal. Not praise for being accessible. Just no one ever having to think about it because it's never a problem.

The Question You Should Ask

Right now, go to your website or your app. Unplug your mouse. Try to navigate using only your keyboard.

Can you reach everything? Can you tell where you are? Does anything get stuck?

Now try it on your phone with the screen zoomed in. Try it with the brightness turned way down. Try reading it after three hours of sleep when your brain is foggy.

If any of those experiences are painful, you've found your accessibility issues. And those issues aren't edge cases. They're real people, trying to use your thing, right now.

Where We Come In

At ALWAYS 49, we don't treat accessibility as a compliance exercise. We build it into everything from the start, not because we're saints, but because we've learned that accessible design is simply better design.

We test with real users, including people who navigate differently. We check our work against standards, but we don't stop there. We ask whether things actually work, not just whether they technically meet requirements.

If you're building something new, or if you suspect your current site is leaving people behind, let's talk. Not about checkboxes and compliance reports. About building technology that actually works for everyone who needs it.

Because someone out there is trying to use your site right now, and they're struggling. You might not know it. But they do.

Wonder if your site is leaving people behind? [Talk to ALWAYS 49] about building technology that works for everyone.