As I and several other a11y advocates know, getting others to care about accessibility isn't easy. It should be, considering the many moral and business arguments for it, but it isn't. I've repeated these arguments many times online. Sometimes as direct responses, other times as painful screams into the void. There's still much work to do.
To make this easier, I decided to write some answers in advance. Below are five common arguments against accessibility I've heard, and my counterarguments. I write them so I and others can link to them next time someone online pesters us for answers to save us time and energy.
Let's get to it!
1) Most of Our Users Don't Need Accessibility
This is the most common response I've seen online, almost always from white guys. Why is that? My guess is it seems logical on the surface - if most people don't use it, why include it? Accessibility is like secret alligator pits. Few people use them in their apartments, so no apartments offer them. This makes sense and made it that much harder to find a place to live.
But that's based on the false idea that accessibility only helps people with constant or visible disabilities. Some people do benefit more from an accessible site, but everyone benefits to some extent.
A big point in one accessibility post I wrote is remembering stress cases. Stress cases aren't only about what we see as disabilities, like blindness. They include temporary or environmental conditions that affect everyone. Even the privileged, able-bodied app's audience will deal with stress cases like:
- Breaking an arm
- Damaged or degrading eyesight
- Using the app on unexpected screen sizes
- Being in poor, or harsh, lighting
- Be on medication that hampers their cognitive functions
- Using bad wifi since they're on the run from bandits who didn't fall for the alligator pit traps
When someone points to their audience as a reason to ignore accessibility, they're wrong. **That group doesn't need an accessible site now, but they will. At some point everyone does. **Not building an accessible site means you risk alienating everyone (and losing their business).
2) We'll Add it Once We Need It
To be blunt, I see this as only an excuse to avoid accessibility altogether. I've been telling myself I'll replace the alligator pits' false carpeting, but I never did and look where I am now! (Please don't actually look since I need to lay low).
Back to the point, putting off accessibility doesn't work since it needs to be a priority early on. Many parts of every site will need to be redone if accessible markup and styling get added late. At that point, someone will then say "we can't change these components now, so we'll have to skip this." If someone complains about accessibility when the site's live, it's the same response. "It would change too much of the design, so we can't do anything."
This is like someone painting a room the color of blood and they'll change the color later if it creeps people out. When people get crept out the same person says repainting the room is too big a change to manage. It's a cop-out that lets someone blame a (usually) fake lack of bandwidth instead of it being a choice they made.
This is why it's important to get accessibility buy-in early on. The later it gets made a priority, the harder it is to work it on without disrupting what you built.
3) They Can Contact Customer Service With Issues
I heard this in a chat before and recently saw it play out on Twitter.
This falls apart since it violates a core tenet of programming: automating boring, repetitive tasks. Compare the two below options and tell me which sounds more efficient.
- Take an hour or two to build an accessible interface
- Make your customer service staff waste hours each month handling complaints. They repeat the same interactions, making otherwise basic processes drawn-out and frustrating. Customers who don't call will give up and go to a competitor.
Yeah, the second one isn't ideal. Time and energy are down the drain when accessible interfaces could have saved them. This is cruel to customers, your coworkers, and your bottom line.
4) It's Too Difficult
Many developers have told me semantic HTML and testing stress cases are "too tough to bother with."
This is easy to knock down since accessibility can be tough, but being a web developer is also tough. Get used to it.
Good CSS is tough. Designing a database is tough. Taming alligators without alerting your landlord is tough. But doing tough things is what we're paid for.
JavaScript is tough, but developers know it's worth learning its rules and trade-offs. Accessibility is the same, only with different rules and trade-offs.
In a recent work project, it was tough to make an accessible dropdown menu since it needed:
- To expand and collapse with the mouse and keyboard
- Menu items that only have keyboard navigation when expanded
- Display right on mobile
- Not clash with other elements in the semantic markup, including a logo link and title
- Not break due to dynamic menu items
It was tough to handle this and other accessibility needs. But our job was to make it accessible. We did the research, wrote the code, put in the time, and made it work. Because it was our damn job.
5) It Doesn't Matter
This is one of the harshest if honest responses: they don't give a crap about accessibility. I'll skip over the moral issues I find with this response, such as:
- Writing off huge numbers of people as "not worthy" of their site or project
- How the premise of the Internet is greater access to information and communication. Inaccessible sites ruin what makes it great.
I don't use these arguments against people who don't care about accessibility though. They're like people who somehow survive death via alligator traps. Their minds are angry, set in stone, and changing it is pointless without a tranquilizer. So until I perfect my tool to launch them at people through Twitter, I'll save my energy.
A better response is how accessible websites help a lot from a business sense too. Inaccessible websites hit these people in they definitely care about: their wallet.
I covered these in my past accessibility article too, but the three business benefits are:
- A bigger audience, which means more customers and data. Inaccessible sites force users to the competition.
- Fewer resources to customer service. You can reinvest these into expanding the company and the site's features.
- Protection from getting sued over inaccessible websites. Lawsuits against websites violating the Americans with Disabilities Act are only increasing.
No matter their feelings on accessibility, no one can ignore how it affects profits.
I'd prefer to persuade people with the "don't be a dick to others" argument. But I long learned some people don't care about morals or treating other groups well. The money argument is an unfortunate but effective way around that.
Wrapping Up
Please remember this post next time someone pushes back against accessibility, online or in person. I encourage you to use it as a reference (or send them a link to save more time).
Our time is better spent on productive tasks like improving our accessibility knowledge, building better interfaces, and losing the trail of people who need to get over their alligator bites. Seriously, they'll heal in a few months. Move on!
Have any other anti-accessibility arguments you've heard and the counter-arguments you gave? Please comment with them below!
Top comments (30)
I appreciate the article, especially the part about how anyone can be temporarily disabled. Accessibility is like globalization. Not only do you need to plan for it up front, but taking it into account leads to better design.
Please, trust me that I'm not one of those people who takes offense when someone talks about white guys. I'm not into the whole "proud to be a white guy" thing at all. Your statement doesn't offend me and didn't stop me from enjoying what you had to say.
But still, why? You wrote an excellent article on an important subject, so why unnecessarily politicize it? Does it add anything?
As per the "white guys" point, I'm simply stating what I've observed in my experiences. My own guess as to why this is that, as one of the groups discriminated against the least in modern society compared to historically marginalized groups, its easiest for us to overlook the needs of other groups. It takes more effort for groups near the top to remember things are different others, and it takes further effort to remember this and create long-lasting change.
So yes, I think it adds something, is worth talking about, and isn't "unnecessary politicization" for a topic like this. If I used this post to rail against how how American infrastructure has languished due to gasoline taxes not increasing with inflation due to consumer pressure, then that'd be unneeded politicization :P I will remember to add some more details in later posts so it doesn't seem like just a throwaway comment, so thanks for the feedback!
Here's an exercise for you to check if it's appropriate to use "white guys" in an article: replace the "white guys" with "black guys", "jews", and "women". Then read each sentence out loud. If it sounds OK, go ahead an use it. If it strikes the wrong chord, you might have a bias.
See my previous response, thanks! 😊
See my previous response, thanks! 😊
And they felt like it wasn't because they wanted to add a personal anecdote. It's very necessary.
Or maybe it's because our industry "white guys" are the largest group by far (at least in North America and Europe), so it's unsurprising that they give most of the feedback. In that regard, your statement is technically true but it adds nothing to the story and it's actually distracting from the main point.
I could reply that I've heard the same remarks from women, proportionally to their presence in IT, but it'd be a throwaway comment as well, because I'd need numbers to support my thesis. You will need too, if you plan to clarify your statement (I'd welcome your effort).
Sure. We can all agree on that. But how does the information that remarks against accessibility usually come from white men help us in that regard? Do we need to prepare to debate with them in special ways? Can we ignore such arguments if they come from, say, an Asian woman? What about countries where white men are a minority?
I personally don't think it's politicizing the topic, but on the other hand if you say that "it adds something", I reply that it's not clear how, and the risk is that it could flame the discussion with off topic remarks and without any deliberate goal.
It doesn't politicize the topic. It politicizes the article about the topic.
The quoted line simply highlights the fact that a disproportionate number of developers fall into the category of "white guy" (guilty as charged); many of whom seem incapable of seeing beyond their personal experiences (hopefully not entirely guilty). Whilst that's not necessarily a demonstration of conscious bias on their part; it is a significant contributor to why the tech industry repeatedly makes mistakes that adversely affect "minorities" - most of whom are not actually minorities. The perceived "default" ("white guy") is not representative; and so the needs of others are not properly considered: e.g. "Most of Our Users Don't Need Accessibility"...
For those who are affected the issue is political.
Read Technically Wrong if you want some illustrations of this issue.
I helped open this can of worms, so I'll add this helpful Vulcan proverb. I'm not a Trekkie and I'm embarrassed to know a Vulcan proverb.
Thanks for writing this up, this is great.
It's so infuriating that this is something we need to fight for. I get that some people aren't familiar with what accessibility is, and still need to learn. I've been there!
But for those that do know, I don't understand how it's seen as a valid option to shamelessly discriminate against people. We shouldn't have to come up with a bunch of different angles to convince people to do the right thing.
I know the feeling, part of me loved writing this post and another part of me hated that it needed to be written. Especially since for many counterarguments, I had to take into account that many people won't care about how much it helps people and need to hear arguments purely in terms of business and lost dollars.
I don't want accessibility to only be accepted for the economic benefits, but sadly for many people that's all they'll listen to. Trying to encourage more positive change, to me, means accepting that and working with it when needed. Not easy, but hopefully it helps the change come sooner.
Yup, totally agree. I actually do like highlighting all the other benefits you get from accessibility - there's a lot of great stuff that comes along with it! And I try to understand where people are coming from, rather than shutting down and getting upset that they don't care. It just gets to me sometimes.
Awesome article, bookmarked for later use.
Google has an awesome Udacity course on Web Accessibility, and the first lesson is a very straightforward overview of what a11y is and why everyone needs it, including the points you made about temporary injuries and other short-term conditions leading to literally everyone needing accessibility features at some point. I seriously recommend every web dev just take like 15 minutes and do the first lesson at least: Accessibility Overview
Whole course is here:
classroom.udacity.com/courses/ud891
I had the privilege of retrofitting accessibility into a fairly large application that had omitted accessibility for version 1, version 2, and version 3.
Version 4 had accessibility. But in order to put in accessibility, we pretty much had to rearchitect the entire application from stem-to-stern. It was a herculean effort.
The interesting thing, to me, was that the application would have been better architected -- better separation of concerns, better abstraction, better M-V-VM -- from the get-go had it had accessibility in version 1. Why? Because accessibility can be thought of as a second UI.
And if you have 2 UIs on the same engine, you will -- by necessity -- have better architecture. And that better architecture is basically free in version 1. Then version 2 will be based on a better foundation. And version 3 will be based on a better foundation. (There's more to clean code than merely adding in accessibility, but just having 2 UIs puts pressure to have a better architecture.)
And most importantly, you won't need to devote 20 developer years of effort to fix the mess for version 4.
(This was a C#/WPF/.NET application, so was using UIA, and had to be MSAA compatible. And as a free bonus, we got bona fide automation capability as well. Accessibility for websites is a different domain, and has its own conventions to address the accessibility needs. I got to work in that area too -- and for HTML/CSS/JS being mindful for accessibility isn't even hard.)
Thank you so much for sharing this anecdote! I agree, having a good focus on accessibility earlier on can create better and cleaner architecture throughout an application. And as you've shown, the effort to make something accessible multiples exponentially the longer you put it off.
When you start off early, accessibility isn't really that tough. It's just a different mindset and knowing what common mistakes to avoid :)
These are all the same arguments I imagine small business owners made in the push back before handicapped accessible parking spaces but all it would take to implement most likely is a stencil, measuring tape and some paint.
Quote of the year
Seeing you write it that way makes me want to make an anime quote image from it.
So I did 😛
In case anyone needs it, I created bit.ly/EVERYONENEEDSIT to easily point people back to this post.
Use freely & aggressively.
That is so simple and incredible, thank you!
On the first point, maybe a lot of your users don't need accessibility because the people who need it can't become users right now because you don't have it? 🤔I think that's an important argument to be made too.
Great article! I will treasure your counter arguments.
But on the other hand, in my case they also reply that "it's a web application that's going to be used internally only, so we don't need accessibility".
How can I reply to that? 🤔
I work on internal apps as well, and I'm our accessibility person more often than not in workplaces I end up. Here are some of the points I like to use to explain that to folks:
Relating accessibility in terms beyond disability but to common every day situations we all face even on a temporary basis is a very helpful tactic to make sure accessibility doesn't get left behind for internal projects.
Nice write-up.
I also see #2 & 4 being used against security as well as accessibility. Which is probably why I'm taking on both as my main championing points in my Web Developer growth plan.
Security and accessibility are both needed from the start, even if you think your audience won't need/use it. Adding them in later on is always harder later down the road, which is why they are just dropped.
And yes, building security into the app/website/whatever is also often seen as 'too hard', when in fact, it's really just about considering all use cases and planning/coding for it (same for #a11y).