If you build websites for a living, you’ve probably had opinions about accessibility. Maybe you have felt overwhelmed by WCAG. Maybe you’ve wondered how many users are actually affected. Maybe you’ve pushed back on a deadline to raise an accessibility concern and gotten blank stares in return.
Developers have a lot of thoughts about accessibility. Some of them spot on, some of them way off base. And as someone who’s spent over 25 years doing this work, I want to address both honestly. Not to lecture, not to shame. Just to set the record straight on a few things I keep hearing, and to give credit where it’s due.
What developers get wrong
“It only affects a tiny percentage of users.”
If your site is inaccessible, your analytics won’t show disabled users. They already left.
This is probably the most common misconception I hear, and the numbers developers throw around are almost always wrong. Some say 5%, some say less than 1%. The real number? Roughly 25% of adults have some form of disability. In the US alone, that’s over 70 million people. Globally, it’s 1. 3 billion.
And that’s before you factor in temporary and situational disabilities – a broken arm, an ear infection, using your phone in bright sunlight, navigating one-handed while holding a baby.
If your site is inaccessible, your analytics won’t show disabled users. They already left. A study found that 71% of people with disabilities will leave a difficult-to-use site and never come back. So when you look at your data and think, “we don’t have users with disabilities,” you might be looking at a self-fulfilling prophecy.
“Accessibility and business goals are at odds.”
They’re not. This is a false choice.
Accessibility improvements don’t just help users with disabilities. Better structure improves SEO. Captions help non-native speakers. High contrast helps everyone read in bright sunlight. Clear navigation benefits every single user. When you make a site easier to use for people with disabilities, you make it easier to use for everyone.
And sometimes the “business win” that ignores accessibility isn’t even a win. Auto-rotating carousels are a good example. Teams love them because they feel dynamic and they let you showcase more content. But the data tells a different story. Carousel click-through rates are dismal, with the vast majority of clicks going to the first slide and almost none to the rest. They can also cause dizziness, trigger motion sensitivity, and interrupt screen readers. That’s not a CRO (Conversion Rate Optimization) win. That’s a bad design decision wrapped in a good-sounding metric.
“We can always add it later.”
This one hits close to home because I’ve watched it play out so many times. A feature ships to thousands of users and nobody asks about accessibility until launch day. When one person finally raises the re question, the response is, “we’ll deal with that later.”
But later almost never comes.
And when it does, it’s expensive. Retrofitting accessibility is harder, slower, and more disruptive than building it in from the start. It’s the same as responsive design. Nobody would dream of building a site and adding in mobile support at the end any longer. We learned that lesson. And accessibility needs the same shift.
“The real problem is predatory lawyers, not inaccessible sites.”
I understand the frustration here. Serial ADA litigation is real, and the way some of it plays out feels more like a shakedown than advocacy. Developers and business owners are right to be annoyed by that.
But here’s a reframe: if the sites were accessible, there would be nothing to exploit. The enforcement mechanism isn’t the core problem. The inaccessible sites are the core problem. And the people being shut out of digital life, from healthcare portals to digital shopping, deserve more of our attention then the laywers do.
“Blind people don’t rent cameras.”
You don’t get to decide who your users are.
Yes, a developer actually said this. And it reveals a deeper assumption that’s worth examining: the idea that you can predict who your users are and what they need based on their disability.
People who are blind have friends and family who are sighted. They have jobs and colleagues. They have jobs that involve purchasing decisions. They use the web for the same reasons everyone else does. And “blind” is just one of hundreds of disability experiences – many of them invisible.
You don’t get to decide who your users are. Your job is to build something that works for as many people as possible.
What developers get right
It’s not all misconceptions. There’s a lot that developers are saying about accessibility that deserves to be heard.
“Nobody taught me this.”
This one is valid. Most Computer Science programs and coding bootcamps barely touch accessibility, if they cover it at all. That’s a systemic failure, not an individual one. You can’t blame someone for not knowing something they were never taught.
That said, once you know the gap exists, it’s yours to close. The good news is that accessibility isn’t as mysterious as it might feel. Start with the basics: semantic HTML, alt text, form labels, color contrast, keyboard navigation. You don’t need to memorize WCAG. You just need to start building the habit.
“The basics aren’t hard, but complex apps are genuinely challenging.”
The basics aren’t hard. They’re just not habits yet.
Both of these things are true at the same time, and I wish more people in the accessibility space would say so.
Adding alt text to images isn’t hard. Making sure your form fields have labels isn’t hard. Checking color contrast isn’t hard. Handling reduced motion preferences can be done in a few lines of CSS. The basics aren’t hard. They’re just not habits yet.
But building a fully accessible single-page application with custom components, dynamic content, and complex state management? That IS harder. And it’s okay to say so. Acknowledging that complexity isn’t the same as giving up – it’s being honest about the work involved so you can plan for it properly.
Remember when responsive design felt this way? It was overwhelming at first. Then teams started building it into their process – mobile-first design, device testing, mobile emulators, QA changes, management accountability. It became normal. Accessibility needs that same cultural shift, and it’s already starting to happen.
“I want to do this right. I just need a starting point.”
This is the developer I’m rooting for. And there are more of them than the loud cynics suggest.
If that’s you, here’s your starting point: learn to test with your keyboard. Disable your mouse and navigate your site. Can you reach every interactive element? Can you see where focus is? Can you operate menus, forms, and buttons? That one exercise will teach you more about real-world accessibility than reading any spec.
Then run a scan. Fix the low-hanging fruit – the six types of issues that account for over 96% of automatically detectable accessibility errors: low contrast text, missing alt text, missing form labels, empty links, empty buttons, and missing page language. These are well-understood problems with clear solutions.
Then keep going. Build the muscle. I wrote about this in January – small, consistent actions compound over time. You don’t have to fix everything at once. You just have to keep showing up.
The conversations give me hope
For every developer dismissing accessibility as a waste of time, there are others sharing practical solutions, correcting misconceptions, and genuinely trying to figure out how to do better. That’s the community I want to build with.
Accessibility isn’t about being perfect. It’s about caring enough to start and being committed enough to keep going.
Ready to start?
AAArdvark makes it easy to find accessibility issues, understand what’s wrong, and learn how to fix them – with plain-language guidance on every issue. Start with your homepage for free and see where things stand.
No credit card required.
