Marcell CD

The Wake-Up Call That Changed How We Build Software

Picture this: You’ve just launched what you think is a sleek, modern web application. Your team is proud of the smooth animations, the clever interactions, and the cutting-edge React architecture. Then someone asks a simple question that stops you cold: “Can a blind person use this?”

That uncomfortable silence? That was us, one year ago.

The Rude Awakening

We were happily building features in our accessibility bubble when the European Union dropped a bombshell: all e-commerce applications must meet accessibility standards by June 2025. No exceptions. No “we’ll get to it later.”

My first reaction? Panic. My second? “How hard could it be to add some alt tags?”

Spoiler alert: I was hilariously wrong.

What We Thought We Knew vs. Reality

What we thought accessibility meant:

What accessibility actually means:

The list goes on. And on. And on.

The Humbling Audit

We hired an accessibility consultant to audit our application. The results were… educational. Here are some of my favorite discoveries:

Our “Intuitive” Navigation Was a Maze

Our fancy hamburger menu that looked so clean? Screen reader users had no idea it was a menu. Our breadcrumbs that seemed obvious? They were just decorative text to assistive technology.

Our Forms Were Hostile

Error messages that appeared in red text meant nothing to screen readers. Our custom dropdown components were completely unusable with keyboards. Password strength indicators were invisible to anyone not using a mouse.

Our Animations Were Barriers

That smooth page transition we were so proud of? It triggered motion sickness for users with vestibular disorders. Our loading spinners provided zero feedback to screen readers, leaving users wondering if the app had crashed.

The Plot Twist: Accessibility Made Us Better Developers

Here’s what nobody tells you about accessibility: it forces you to write better code.

Semantic HTML Became Our Best Friend

Instead of <div class="button">, we started using actual <button> elements. Suddenly, keyboard navigation worked for free. Focus management became predictable. Our HTML started making sense again.

We Discovered the Power of Progressive Enhancement

Building for screen readers first meant our app had to work without JavaScript. This constraint led us to create more resilient architectures and faster loading experiences for everyone.

Our UX Improved Dramatically

When you design for someone who can’t see your interface, you’re forced to think about information hierarchy, clear labeling, and logical flow. These improvements helped all our users, not just those using assistive technology.

Real Stories, Real Impact

Three months into our accessibility journey, we received an email that changed everything:

“I’ve been trying to order from your site for months but couldn’t get past the checkout. Today I successfully placed my first order. Thank you for making this possible.”

This wasn’t just about compliance anymore. We were literally removing barriers that prevented people from using our product.

The Unexpected Benefits

1. Our Code Reviews Got Better

Questions like “Is this keyboard accessible?” and “How will a screen reader announce this?” became standard. Our code quality improved across the board.

2. We Simplified Complex Features

That elaborate multi-step wizard we built? Turns out it was confusing for everyone, not just screen reader users. We redesigned it to be clearer and more straightforward.

3. Our Team Became More Empathetic

We started using our own app with screen readers, keyboard-only navigation, and various accessibility tools. This firsthand experience fundamentally changed how we approach design decisions.

4. Performance Improved

Accessible code tends to be leaner code. We removed unnecessary JavaScript, simplified our DOM structure, and improved loading times.

The Hard Truths

Let me be honest about the challenges:

It’s Not a One-Time Fix

Accessibility isn’t a feature you ship and forget. Every new component, every design change, every interaction needs to be evaluated through an accessibility lens.

It Requires Cultural Change

Getting designers to think about focus states, convincing product managers that accessibility is a priority, and training developers on ARIA patterns—it all takes time and persistence.

Some “Cool” Features Had to Go

We killed several flashy animations and complex interactions that couldn’t be made accessible without compromising the experience for everyone else.

What We Learned About Tools and Testing

Automated Testing Is Just the Beginning

Tools like axe-core and Lighthouse catch obvious issues, but they miss the nuanced problems that real users face. We learned to combine automated testing with manual testing using actual assistive technology.

User Testing Is Everything

We started including users with disabilities in our testing process. Their feedback was invaluable and often surprising. What seemed accessible in theory didn’t always work in practice.

Screen Readers Are Quirky

Different screen readers behave differently. What works perfectly in NVDA might be confusing in JAWS. We learned to test across multiple tools and platforms.

The Ongoing Journey

A year later, we’re still learning. Accessibility isn’t a destination—it’s a fundamental shift in how we think about building software.

Our New Development Process

  1. Design with constraints: Every mockup includes focus states and keyboard navigation flows
  2. Code with semantics: HTML structure comes first, styling comes second
  3. Test early and often: Accessibility testing happens alongside functional testing
  4. Iterate based on real feedback: We regularly test with actual users of assistive technology

Measuring Success

We track more than just compliance metrics:

The Ripple Effect

Our accessibility work has influenced other teams in our organization. The design system we built with accessibility in mind is now used across multiple products. Our documentation includes accessibility guidelines. New hires learn about inclusive design from day one.

Looking Forward

The June 2025 deadline that initially terrified us now feels like a milestone rather than a finish line. We’ve realized that accessibility isn’t about checking boxes—it’s about building technology that truly works for everyone.

What’s Next

The Bottom Line

If you’re reading this and thinking “we should probably look into accessibility,” don’t wait for legislation to force your hand. Start now. Start small. Add alt text to your images. Make sure your forms work with keyboards. Test your app with a screen reader.

You’ll be surprised how much it improves your product for everyone.

And who knows? You might just discover that the constraints of accessibility unlock creativity you never knew you had.

Want to learn more about our technical implementation? Stay tuned for my next post where I’ll dive deep into the tools, techniques, and code patterns that made our accessibility transformation possible.

Resources That Helped Us