The Most Common Accessibility Mistake? Thinking It’s a One-And-Done.

Why is website accessibility important?

The clearest way I've found to explain web accessibility's importance is through the the lens of audiobooks.

I fell in love with audiobooks as a kid, and the thing that stuck with me was that being read to is a different experience than reading. When you listen, you're leaning on the narrator's delivery, their pacing, their emphasis. When you read, the interpretation is yours alone.

Think of your website as the book. Accessibility features are the audiobook: an extension that lets someone experience it when the original form doesn't work for them.

Keyboard navigation isn't a workaround bolted on the side; it's an interpretation of how the site functions for a different audience, like, for instance, people who can't use a mouse or trackpad.

Once you see accessibility as an extension of the work rather than a box to check, the way most companies talk about it starts to feel off.

Because, the most common thing I hear when companies talk about website accessibility?

“We already handled it.”

Usually what that means is one of three things:

1. A widget was installed.

2. An audit happened years ago.

3. Or accessibility was considered during launch and assumed to then be "finished."

That’s because most companies think of accessibility as a task: something you complete, document, and move on from.

But accessibility doesn’t really work that way. It is less like a certification and more like a process of ongoing maintenance. In other words, it’s never done. It requires ongoing partnership between the team that built the site and the team that runs it. It's not a handoff, it's a shared commitment.

What Accessibility Looks Like When It’s Built In

At Bear, we believe the strongest accessibility features don’t look dramatic.

They look like systems.

Design teams checking contrast before approval. Developers working from accessible component patterns instead of reinventing interactions from scratch. Content teams understanding how link language affects usability. QA that includes keyboard testing, not just visual review.

In other words: accessibility becomes part of how the site gets made.

That doesn’t mean perfection. Standards evolve. Websites change. New issues emerge.

The goal isn’t a mythical state of “done.”

It is making accessibility resilient enough to survive the next hundred updates.

The Non-Compliant Items We Typically Find

Accessibility sits at the intersection of design, copy, and code, and it's easy for any one of those to introduce new problems. After working on accessibility across hundreds of eCommerce sites, some issues come up again and again.

Here are the big ones we see all the time:

Copy that means nothing to a screen reader
"Read more" and "click here" are everywhere. They provide zero context for someone navigating without a mouse. Every link needs to be descriptive enough to stand alone.

Brand colors that fail contrast checks
A lot of brands have color palettes they love, and those colors don't meet WCAG contrast ratios on screen. Orange and white is a classic example. It's not about making your site boring; it's about making the text readable.

Alt text that’s missing, wrong, or an afterthought
"Why do I need that?” is a question I still hear often. The answer: someone using a screen reader is relying on it to understand what’s on the page. The nuance worth knowing: not every image needs a description. Decorative images should have an empty alt attribute (​alt=""​), not a missing alt (which is a violation), but an intentional empty value that tells assistive technology to skip it. The W3C maintains an alt text decision tree that walks through exactly when and how to write alt text correctly. It’s the clearest guide I’ve found.

Keyboard navigation that just doesn't work
This one is particularly common on sites with a lot of custom components. We've inherited sites before where a user tabs into a search field and literally can't get out of it. That's a focus trap, and it makes the site unusable for a significant portion of visitors.

Heading hierarchies that are broken
Developers (and theme creators) sometimes use heading tags for styling rather than structure. An h4 nested inside an h1 area isn't just semantically wrong; it confuses every assistive technology that relies on that hierarchy to help users navigate.

The “Set It and Forget It” Widget Problem

There's a category of tools that promise to make your site accessible with a single script install. The pitch is appealing: plug it in, check the compliance box, move on. I understand why it's tempting.

But these tools don't fix your code. They layer something on top of it. They can't address contrast issues that live in your CSS. They can't fix copy. They can't resolve broken keyboard behavior. They can adjust some things on the fly (and for some very specific use cases, they might help) but they are not a substitute for building accessibility the right way.

One of the most common misconceptions I run into is a client who genuinely believes that if they have a widget installed, they're compliant. But, I’m here to tell you that simply having a widget doesn't make you compliant. Building the site accessibly does.

There's also a practical problem here: the moment your team makes a change that these tools haven't specifically accounted for, you're back to square one.

Ready to Up Your Accessibility Game?

If you don't know where your site currently stands, that's the first thing to figure out.

A comprehensive assessment gives you a prioritized list of what needs attention, what can wait, and what's going to be the most impactful to fix first.

And once you have it, the work is a lot more manageable than you might expect.

Frequently Asked Questions

Do accessibility widgets or overlays make a website ADA compliant?

No. A widget layers a script on top of your site — it doesn't change the code underneath. It can't fix contrast ratios that live in your CSS, it can't rewrite "click here" link copy, and it can't repair broken keyboard behavior. Plenty of teams believe the install checked the box, but having a widget installed doesn't make you compliant. Building the site accessibly does.

How often does a website need to be checked for accessibility after launch?

Accessibility isn't on a schedule — it's part of every release. Standards evolve, sites change, and one new component can undo a year of work. At Bear Group, that looks like design checking contrast before approval, developers working from accessible component patterns, content teams watching link language, and QA running keyboard tests instead of visual review alone. The goal isn't "done." It's accessibility resilient enough to survive the next hundred updates.

Do we have to change our brand colors to meet WCAG contrast requirements?

Not necessarily the whole palette — but the places it fails contrast, yes. A lot of brands have colors they love that don't meet WCAG contrast ratios on screen, and orange on white is the classic example. It's one of the issues we find most often across the hundreds of eCommerce sites we've worked on. This isn't about making your site boring. It's about making the text readable.

Does every image on a website need alt text?

No, but every image needs an alt attribute. Decorative images should carry an intentional empty value — alt="" — which tells assistive technology to skip them. A missing alt attribute is a violation; an empty one is a decision. The W3C's alt text decision tree walks through exactly when an image needs a description and when it doesn't, and it's the clearest guide out there.

Why does keyboard navigation break on sites with a lot of custom components?

Because custom interactions get built from scratch instead of from accessible patterns, and focus management is the first thing to get skipped. We've inherited sites where a user tabs into the search field and literally can't get back out. That's a focus trap, and it makes the site unusable for anyone navigating without a mouse — one more reason a custom or headless front end needs someone who owns it.