You don’t need to care, just make your products accessible

I found out about accessibility in college, eight or nine years ago, and loved it so much it became my thesis. From then on, I was often the only person in the room excited enough to talk about it – I persisted, advocated, learned more, and fought to raise awareness.

Rarely did anyone listen, it wasn’t important. Until last year.

When the European Accessibility Act became law, suddenly everyone wanted to talk about accessibility. I was in meetings, resources were finally allocated, and the thing I’d been shouting about for nearly a decade was at last… important.

I should have been thrilled. Instead, I felt nothing.

Anyone, anywhere, should be able to use the web

Tim Berners-Lee said:

The power of the Web is in its universality.

I believed it in college, and I still believe it today: the web should be accessible to everyone. That’s the foundational principle behind the platform we build every day.

But for most of my career, that principle wasn’t even on the radar. I watched us build walls in a medium meant to have none and I kept speaking up anyway, because someone had to.

I‘d won the battle and lost the war

Then 2025 arrived – the European Accessibility Act. Accessibility wasn’t optional anymore, it was a legal requirement. And suddenly, people listened.

Finally, I was having real conversations about accessibility – the thing I’d wanted for eight years. But it wasn’t because most people truly cared, they were asking only because they had to.

For the most part, few conversations focused on the 15% of users who experience the web differently. Most discussions were about checkboxes, compliance audits, and legal exposure, rather than creating experiences that work for everyone.

I’d won the battle and lost the war: accessibility was happening, but the why (the empathy, the principle, the universality of the web) was missing.

Let’s fix something that isn’t broken

You know what’s funny? Everything was fine for a while.

Native HTML elements come with accessibility built in. A <select> is usable by default, and a <button> handles keyboard interaction automatically – HTML was designed with accessibility in mind. The challenge comes when we want to style them: for example, dropdowns are notoriously hard to customize, so they often end up looking like the browser’s default, which can feel “ugly” compared to the rest of our design.

So we built custom ones and this where we start to lose accessibility. We didn’t mean to, we just wanted things to look better. But in chasing the shiny new, we broke what worked.

I guess it got to the point where enough people with disabilities were heard, and finally someone started to care. And now here we are, trying to fix what we broke with our shiny new toys. I’m glad we’re here. If we can, we should take everyone into consideration. It’s also good for business or something—I don’t know, I’m just a developer 😅

But here’s what I do know: ship fast, yes, but don’t skimp on quality. Every commit carries your name, and that matters.

Accessibility automated – no brain cells required

So here I am: building accessible components, creating tools to automate accessibility, and teaching AI to check WCAG compliance. The idea: make accessibility so easy developers don’t have to think about it. Use our Bepo components – get compliance for free, ship accessible products, no explanations required.

After eight years of trying to get people to care, I’m now building systems so they don’t have to. The irony isn’t lost on me.

We’ve built Navigation with a ton of keyboard interactions developers never had to write. Broadcast with ARIA patterns they never had to learn. Color contrast decisions made at the token level. Focus management handled automatically. Claude Code plugin that catches accessibility issues in code review.

It works. Users benefit. Rarely anyone understands why. And that haunted me.

And still, I couldn’t sleep at night

I wrestled with it for months. Had I traded education for efficiency? Made accessibility just a checklist, a tool, not a principle? Where was the empathy in automation?

We’re not just building components, we’re building experiences. Real experiences for real people: those who navigate with keyboards, rely on screen readers, need high contrast, struggle with complex interactions, or depend on assistive technologies.

How do you automate caring about those people?

I thought I understood select… until I actually built one

Until recently, I didn’t really understand the difference between Select and Combobox. I thought I did, I could cite the ARIA spec, but I didn’t. I’d accepted what authorities said without questioning it. In our design system, they were just one Select component… like in many UI libraries. So I never questioned it.

There’s really no difference in what a screen reader announces – Select and Combobox have the same role. I guess Select came first and ARIA later, so the role applies to both. So having just one component… almost the same, right?

Except if you care about the structure of these elements, what it means, and why you can’t fully follow the pattern with just one component. That’s the tricky part 😅

I didn’t really know about the Combobox, until frustration made me curious.

I dove into building a “vanilla” Select from scratch – ARIA patterns, screen reader testing, understanding user expectations, the whole thing. And I realized: modern components don’t really follow patterns. Some tools are technically correct, but they feel… wrong. Clunky. Not what users expect.

Bridging UX gaps is about making interfaces seamless, accessible, and human-first

This is the UX gap. We want custom, modern, polished, and accessible but there’s a bridge missing between the spec and good UX.

I realized: we can have almost all of it if we build with the experience in mind. Combine patterns. Use micro knowledge (like tabbing to inputs or arrowing through options) to make the Select feel as clear as native. Screen reader and keyboard should just make sense.

Average users don’t know about triggers. They just want to open the Select and pick an option. Keep it simple.

As a frontend developer, I see myself as a bridge between users and what I build. It’s my responsibility to make interfaces the best they can be, and to care about them.

You know what I had the most fun with while building my Select? Focus and keyboard interactions. It’s seamless, it works beautifully, exactly as I expect.

I see it in chunks: arrows navigate options, tab moves to buttons, links, inputs. But here’s the twist: if a Select has a custom footer with action buttons, arrows should still navigate options. The footer isn’t part of the pattern; it’s our addition. That’s where we bridge the gap. Or, as the Brits say: mind the gap.

This is the space for custom solutions, where language standards and patterns meet usability, inclusivity, and the full interaction experience.

Building that Select taught me the difference between patterns, user expectations, and implementation flexibility. It was so much fun.

I’ve always loved HTML and CSS – the right semantic element, the right ARIA role, perfect keyboard navigation. It’s craftsmanship. Most users won’t notice, they’ll just use the Select. That’s the point: good infrastructure and accessibility are invisible. You only notice when it’s missing.

We need the knowledge, the understanding, the empathy. UX gaps can’t be automated. Someone has to know what they’re building and who they’re building it for. That’s deep work. And it matters.

The accessibility reconciliation that gave me peace

Then I realized something:

I don’t need everyone to care the way I care, I need everyone to build accessible products. Those aren’t the same thing. And pretending they are was making me miserable.

Here’s the mental model that gave me peace:

Tier 1: The Foundation

• Use accessible components correctly
• Trust the automation
• Get accessibility “for free”
• Ship accessible products without deep expertise

This is how we scale accessibility: give people the right tools and let them use them.

Tier 2: The Curious

• Understand the patterns and why they work 
• Can compose components accessibly
• Catch edge cases automation misses
• Teach others

This is where cultural change happens: people see when automation isn’t enough, ask why, learn deeper patterns, and build better products for their users.

Tier 3: The Champions

• Deep expertise
• Build the infrastructure
• Advance the field
• Fight the eight-year battles

This is where I live, building the tools that make Tier 1 possible.

For eight years, I tried to push everyone to Tier 3, make everyone care as much as I did. I failed. I was exhausted. And I’ve realized I can’t make everyone care, but I can build the infrastructure, play the long game, and ship accessible products anyway. Maybe some will get curious, maybe they won’t, but by making accessibility the default, we create space for learning and a future where it’s just how things work.

Automation doesn’t give up; it accepts that people engage differently.

The door is always open: use components (Tier 1), get curious (Tier 2), contribute patterns (Tier 3). Or stay at Tier 1. That’s fine. That’s success. That’s an accessible product shipped.

You don’t need everyone to care, but everyone can benefit from what you build

If you build accessibility infrastructure, your work matters, even when it’s invisible. Build the safety net, automate what you can, and leave the door open for those who want to see how it works.

If you’re a developer: Tier 1 is enough: use the accessible components, trust the tooling, ship accessible products. Tier 2 is there if you’re curious: learn the patterns, understand your users, make better products. Tier 3 is there if you’re passionate: join us. We’ve been out here a while; it’s lonely sometimes, and we’d love the company.

After eight years in the wilderness, I’m finally building the tools – tools that make accessibility easy, scale empathy, and create experiences for everyone. That’s the infrastructure that matters. And that’s enough.