The Site Nobody Could Use

It was supposed to be a good day. The kind of day that marked a fresh start for the business. After months of planning, budgeting, development, and late-night coffee-fueled Zoom calls, the new website was live.

Everyone at the company had been hyped. The marketing team scheduled a campaign blitz. Product leads had aligned everything for the launch. Developers were ready to squash bugs. Maya, the lead designer, finally exhaled after what felt like two months without blinking.

And then—crickets.

Hours passed. Traffic was steady. Analytics showed sessions ticking upward. But conversions? Zero. Not low. Zero.

Then the emails started rolling in. Most were vague: "site not working," "can’t find what I need," "this is broken." Then one, sharp as a scalpel:

"Your site is completely unusable with a screen reader. I literally can't buy your product."

Maya stared at it for a long time.

________________________________________

Phase 1: Panic

The CEO didn't panic. Not visibly. But his Slack message was pure adrenaline: "Fix it. Whatever it takes."

Maya did what most people do when they're out of their depth: she Googled. That's how she found the overlay vendor.

*"Instant accessibility! Just install one line of code!"

Sounded perfect. And it was—for about two days.

Then the complaints doubled. Blind users reported menus still inaccessible. Keyboard users couldn't reach checkout. One user said the overlay's menu blocked screen reader access entirely. The vendor claimed compliance, but real people still couldn't use the site.

They had stats. They had dashboards. But they didn’t have usability. What they had was lipstick on a broken UI.

There were also issues nobody expected—like the overlay interfering with loading times. Or mobile screen readers crashing entirely. One customer’s screen reader froze halfway through checkout, and they had to restart their phone. Twice.

________________________________________

Phase 2: Curiosity

Maya wasn’t a rookie. She knew good design was more than looking nice. But this was new territory.

So she decided to simulate it. She installed NVDA, a free screen reader, closed her eyes, and tried navigating her own homepage.

It was a mess. Headings weren't structured. Images had random alt text like "image1234." The navigation looped endlessly. It felt like trying to walk a hallway with no floor.

She realized something she never wanted to admit: the site wasn’t broken for some people. It was never built for them in the first place.

She tried keyboard-only navigation. Tabbing was a nightmare. Interactive elements weren’t highlighted. Dropdowns opened unexpectedly. Focus order skipped all over the page like a drunk squirrel.

________________________________________

Phase 3: Listening

She reached out.

A local disability advocate connected her to a blind user named Ren. They scheduled a call. No filters, no sugar-coating.

“Overlays don’t help me. They try to fix broken code with more broken code. You want real accessibility? Fix your site the right way.”

Ren wasn’t angry. He was exhausted. Maya got it.

Then she kept listening. She spoke to a keyboard-only user. A dyslexic blogger. Someone who uses voice navigation. Each one had their own pain points. Maya documented every bit of it.

One told her the CAPTCHA blocked them entirely. Another said the contrast on the product cards gave them eye strain. Someone else couldn’t tell which error message applied to which input field.

The deeper she went, the more she realized the issue wasn’t just technical—it was cultural. The site was designed with a narrow definition of “user.”

________________________________________

Phase 4: Doing It Right

The company wasn’t happy about the extra cost, but she got the green light.

She brought in accessibility specialists. Real ones. People who audited manually, tested with screen readers, validated against WCAG, and provided detailed, actionable feedback.

They didn’t patch the code. They restructured it. Rebuilt semantic navigation. Rewrote alt text. Fixed label associations. Even things that looked fine on the surface got tossed.

For example, a carousel with custom JavaScript? Gone. Replaced by native controls. Color contrast that passed but still confused users? Adjusted. Link text like “click here”? Rewritten for clarity.

They also did real user testing. Not just developers pretending to be users. Actual people with lived experience. They found things the audit missed. They always do.

One tester flagged the dropdown filter menu as inaccessible. Another found an issue with focus trapping in modals. None of this was in the automated report.

Maya’s team started keeping a shared doc: Things Automation Missed. It grew fast.

________________________________________

Phase 5: Results

The difference was night and day.

Ren came back and tested the new version himself. He sent one line back: "Now this is usable."

Sales ticked up. Not massively, but steadily. The lawsuit threat vanished. The team started baking accessibility into their process instead of bolting it on.

But more than anything else, the feedback changed.

“Thank you for making this usable.”

“I haven’t been able to read this blog in months. Now I can.”

“I wish more companies did what you did.”

Internally, the devs were skeptical at first—but they came around. One backend engineer admitted the accessibility updates improved their codebase. “Cleaner, more semantic. Easier to maintain.”

Even SEO scores improved. The site was leaner, faster, and better indexed.

________________________________________

Why Automation Isn’t Enough

Automated tools aren’t evil. They catch things. They surface quick fixes. But they don’t think. They don’t empathize. They don’t account for context. And they absolutely don’t represent your users.

Accessibility isn’t binary. A site isn’t either “compliant” or “inaccessible.” It exists on a spectrum. And automation doesn’t measure that spectrum. It just checks boxes.

For example:

• A tool can say you used ARIA attributes. But not whether you used them right.

• It can say a button has alt text. But not whether the text makes sense.

• It might think your menu works. But it doesn’t try tabbing through it like a human.

Some overlays even override browser accessibility settings—causing more harm than good. Others add floating widgets that block core content or confuse screen readers. It’s a mess.

________________________________________

What Maya Learned

She learned that accessibility is a moving target—and that’s a good thing. Because people change. Tech evolves. Best practices adapt.

She also learned that inclusion doesn’t start with tools. It starts with mindset. That the question isn’t “What does WCAG require?” It’s “Who’s being left behind?”

Accessibility isn’t a one-off fix. It’s a process. A commitment. And yeah—it’s work. But it’s the kind of work that makes everything better for everyone.

Forms became easier to use. Navigation got simpler. Mobile flows improved. Search got clearer. Everyone benefited.

And Maya started asking accessibility questions earlier. Before wireframes. Before development. Sometimes even before copy.

She also started mentoring others. Accessibility wasn’t just a checkbox for her anymore—it was her cause.

________________________________________

Today

Six months later, the team doesn't think of accessibility as a checklist. They think of it as part of design. Of performance. Of SEO. Of user experience. Because that's what it is.

They hold monthly reviews. They use a mix of automated tools and manual reviews. They include disabled users in feedback cycles. They even started hosting accessibility office hours for anyone in the company who wants to learn more.

They added a section to every design brief: Accessibility Considerations. It forced teams to think upfront. To slow down. To plan.

They weren’t perfect. But they were moving in the right direction.

And Maya? She became the unofficial accessibility lead. Not because she asked for it—but because she earned it.

________________________________________

Accessibility Isn’t Magic. It’s Work.

Automated tools have their place. They catch low-hanging fruit. They speed up checks. But they don’t replace human judgment. And they definitely don’t replace listening to the people who actually use your product.

If Maya had stopped at an overlay, she might've had a compliant-looking site. But it wouldn’t have been usable. And compliance without usability is just performative.

She didn’t want that. Her users deserved better.

________________________________________

This story was created with the assistance of AI and informed by real-world experiences and practices used by EqualWeb, a leader in hybrid accessibility solutions.

If you want accessibility that goes beyond checklists and truly works for everyone, check them out.