The not-so-simple world of accessibility: Part 1

Enter part 1

Let’s dig into it – there’s no one-size-fits-all solution for accessibility. Making digital experiences inclusive requires more than just checking boxes. You need to understand how design, development, research, and testing all interact. You need to spot gaps across teams, evaluate technical and design debt, and then find ways to fit real accessibility into a system that may not have been built for it. That’s why accessibility is hard—and why shifting left is so critical.

A personal story – Practicing accessibility within limits

I remember joining an accessibility audit for a product where the design system was already locked in. Everything looked clean and consistent, but many components hadn’t been built with accessibility in mind. Colors had low contrast, form fields were missing labels, and several interactive components didn’t support keyboard navigation.

When I brought these concerns to the dev team, they said, "That’s how our design system works." I realized then that the real work wasn’t just fixing one issue at a time—it was helping the team understand where their system was lacking and why accessibility had to push beyond default settings.

We worked together to build enhancements that didn’t break consistency but improved usability. It was a slow, sometimes frustrating process, but it showed me that accessibility isn’t just about testing—it’s about education, negotiation, and knowing how to work around constraints.

Elevate the vibe – Why accessibility is complex

It’s not just about design

Designers need to think beyond style guides. They need to know how visual choices impact usability for people with disabilities. That means considering contrast, visual hierarchy, interaction feedback, and motion sensitivity from the very beginning.

It’s not just about code

Developers need to know more than how to build something that works. They need to understand the DOM, focus management, semantics, ARIA, and assistive technology. Accessibility bugs aren’t just visual—they’re often hidden in the structure and behavior of the code.

It’s not just about testing

Testers need to know how to use screen readers, test keyboard-only flows, and check color contrast. Automated tools catch only part of the problem. Real accessibility testing requires time, knowledge, and often manual effort.

It’s not just about the present

You also need to understand past research. What design decisions have already been made? Where have people previously struggled? What feedback has been ignored? Accessibility requires knowing the history of a product to avoid repeating mistakes.

And it’s definitely not easy in a pre-built system

Design systems help teams move faster—but if they weren’t built with accessibility in mind, they become a barrier. It takes experience to know when to stick with the system and when to customize. And every customization needs to be weighed, documented, and discussed with the team.

Self-reflection – Are you thinking about accessibility early enough?

Ask yourself:

Am I being reactive or proactive when it comes to accessibility?

Do I understand how each team’s choices impact accessibility?

Have I mapped out where accessibility is breaking down?

Am I working around a flawed system, or helping improve it for everyone?

If any of these made you pause, that’s the signal. You need to shift left.

Vibe in action – Why shifting left matters

1) Catch problems early

When accessibility is built into design and development from the start, fewer issues slip through. That saves time, reduces frustration, and leads to better products.

2) Avoid retrofitting

Trying to fix accessibility after launch is like remodeling a house after you’ve moved in. It’s harder, slower, and more expensive. Shifting left avoids that trap.

3) Empower your team

When designers, developers, and testers understand accessibility, they make better decisions without always waiting for feedback. Accessibility becomes a shared responsibility—not an afterthought.

4) Build better systems

Design systems should support accessibility out of the box. Shifting left means making sure those systems are inclusive before everyone starts using them.

Vibing out

Accessibility isn’t simple because it touches everything—code, design, testing, research, and team culture. And when you're working inside a system that wasn’t built with accessibility in mind, it takes even more creativity, patience, and collaboration.

That’s why shifting left isn’t just a best practice—it’s the only sustainable way to build truly inclusive products. When we bring accessibility in early, we stop patching problems and start preventing them.

Let’s keep going. Part 2 is on the way.