The primary question I get from developers is “How do I get my clients on board” or sometimes “How do I convince my boss that it’s worth investing in?” I was asked this once at a panel, and my response was “I don’t, I just do it.” Because I understand accessibility pretty well and build with accessibility in mind from the start, I am usually able to solve accessibility problems relatively quickly without people even noticing that I spent extra time on it. But when developers who are still newer to accessibility are trying to convince their bosses, sometimes they clap back that “this is a low priority” or “that is an edge case.”
Oh goodness, nothing gets my blood boiling more when someone dismisses the needs of their users. If your product or website doesn’t work for any one person who wants to use it, it’s not an edge case. It’s a severe usability problem that is costing you money and potentially a lawsuit.
I’ve brought up issues on accessibility before to clients, and they ask me how much time it would take to fix it. I understand that their budgets are limited; however, it’s ultimately less expensive to fix the problem than the lost business, or even a lawsuit. While I personally am motivated from an empathetic nature, it usually doesn’t go over well to tell your client or boss “Why can’t you just care about people, this isn’t an edge case!”
Below I’ve come up with the 3 main reasons why accessibility is NOT an edge case.
Business
Let’s think of a simple user experience exercise. In my post about the Negative Impacts of Withholding Form Labels, I wrote about how back in 2016 that I did an audit of the 2 candidates donation sites. While that’s technically not a business, it’s still a place where they are asking for your money.
My main point was if their sites are not accessible, particularly in an area where they are asking for your money, how much time do you think your users are going to spend on figuring it out before they give up? If you are a UX expert, you probably have some specific metric that you could tell me, but my guess would be…pretty quickly.
The thing I find shocking is how many e-commerce sites fail miserably with accessibility. For example, I happen to be on Rent the Runway's website looking for a dress to rent, and I pulled up the Wave tool, and as of this writing, it has detected 54 errors. Not alerts or warnings, errors. I also cannot access their navigation with my keyboard, and the focus states are missing.
Approximately one of every five people suffer from a disability, which means that you are potentially losing out on 20% of your target audience. If your business had $500,000 of revenue in a month and the site wasn’t accessible, you may have lost out on over $125,000 in potential revenue. That’s a large piece of the pie that I would want a part of. The numbers go even higher when your business is a multi-million dollar business.
Legal
There have been three lawsuits that come to mind when I think of the legal implications of accessibility. Most recently is the Beyoncé lawsuit for her site being inaccessible for visually impaired users. There was also the Target lawsuit and the Winn Dixie lawsuits. There has always been Section 508 of the Rehabilitation Act that enforces United States government agencies to be accessible. But these lawsuits bring into question what does the ADA cover concerning the web. After the Winn Dixie lawsuit, Title III got added to the ADA and includes Web accessibility concerning public accommodations. And while your site may not technically be breaking the law, wouldn’t you rather save money on lawyers and settlements? While I could go on about all three, this post would get really long. I’m primarily going to go over the most recent Beyonce lawsuit and provide links to learn more about the Winn Dixie Lawsuit.
Beyoncé.com lawsuit
Mary Conner, a woman described as having no vision, was unable to buy a hoodie from beyonce.com for several reasons. One is that there no way to make a purchase without using a mouse. Another being “she wasn’t able to choose the size of a certain product or get confirmation that it had been added to her shopping cart” (quote directly from the article linked below).
I admire Beyonce, so it’s disappointing to learn that her website is not accessible to blind fans. I’m hoping her team fixes this. To all artists: please make your websites accessible. https://t.co/inGMDjvdEk
— Haben Girma (@HabenGirma) January 6, 2019
While this makes me really sad from an emotional standpoint, it also makes me sad that visually impaired users who love Beyoncé as much as I do would struggle to even learn about buying tickets to see her, which is also another business case for it.
This also helps me remember that we absolutely cannot sugar coat the implications of ignoring it. At a former company, I was once telling a Program Manager that there were potential legal implications for ignoring the issues I brought up. He was hesitant about allowing me to use the word legal because he was afraid I was fear mongering. I told him that it would not be responsible especially if it could get them into legal trouble. This is one example of how fixing a few issues would cost a company far less money and negative publicity.
Source: Beyonce.com Lawsuit Reminds Us How Shitty the Web Is for Users With Visual Impairment
Links about Winn Dixie and Target Lawsuits
- W3C WAI - The Business Case for Digital Accessibility (go to the minimize legal risk section)
- Ars Technica - Target to pay $6 million to settle site accessibility suit
- Defendants Fighting Website Accessibility Cases Face An Uphill Battle In 2018
- First-Of-Its-Kind Trial Goes Plaintiff's Way; Winn-Dixie Must Update Website For The Blind
Good HTML
I am going to cut to the chase and be an opinionated developer. If you say that HTML is easy, you are wrong. It’s syntactically simpler than other languages, but it requires strategy, semantics and proper naming just like most programming languages. Most of the people I see minimize HTML are the ones who are misusing it.
Even the MDN docs make a strong case with tons of documentation. Instead of repeating their documentation, I am going to highlight my favorite parts:
- Using the HTML
<button>is better than using a<div>for a button because they have built-in keyboard accessibility. No need to add an additional JS event to make it work with an Enter keypress! It will work with a click! - Their section on good semantics really helps educate people on how to iterate through accessibility and really focus on semantic HTML when making improvements above all else.
- I love how they position that it’s easier to develop with. It is designed to be more helpful for not only your users but also your developers.
Conclusion
As you can see, there are many reasons why this is not an edge case. “Just make it work” is subjective, and that bias can end up costing you a lot of money along the line and alienate your users. Remember that your target audience always has some folks from these communities, so it’s best not to ignore them.
How do you talk to your stakeholders about accessibility? Let me know on Twitter or tweet me if you have questions about this blog post.
Top comments (29)
It's too bad that the legal angle is currently the most likely way to get buy-in from management.
It's also unfortunate what these legal disputes could do if used as a weapon to shut down small teams with less resources, when wieled by corporate legal teams. I'm thinking of teams of devs that are already under pressure and don't have the tools or know-how to quickly implement accessibility into their projects. They could be shut down too easily.
There's a big need and a big opportunity here: to make accessibility easier to implement for every developer by making the knowledge more available and by building dev tools that can help make the job easier.
I'm really thankful for auditing tools such as Google's Lighthouse. I had read about accessibility but it seemed very complicated to me. ARIA attributes, form labels, contrast ratios?? But when you're able to click one button and get an itemized list of everything to fix and how to do it, suddenly it's not so hard. I was able to get a site which was not created with accessibility in mind at all, to 100% compliant, in an afternoon 😀
YAY! I love hearing that!!!
I'm thinking of challenges like understanding the various ARIA roles and the differences between them, and many developers don't even know that ARIA roles exist because they've never needed to implement them.
Then knowing which ones to use for each of your custom UI controls, and maintaining it all as your UI changes.
What happens if the accessibility attributes get out of sync with the UI because a new developer hasn't been onboarded about accessibility yet? Are incorrect accessibility attributes worse than not having accessibility attributes at all? This is the kind of question that's on my mind when I think about the potential difficulties.
@marek , I am working on creating some course content on this, but I also did an ARIA presentation a year or so ago about some of this nuance.
Amazing, thank you for sharing that.
Out of curiosity, what do you find difficult about implementing accessibility?
I find it very simple to implement because a large part of accessibility is using semantic HTML. There's also plenty of dev tools that already exist!
Thanks for sharing!
Thank you for adding your voice to this issue. Accessibility is the right thing to do, always.
Did that happen with the IRL ADA?
long-time lurker here! I joined dev.to specifically so I could comment on your post.
The most effective way I have found to get buy in is to get devs and stakeholders into an environment where they're using a screenreader to navigate their own website.
I agree with all your points - and I'll add to your last. Accessible HTML affects all your users. Google's SEO looks at alt tags, which is a necessity for screen readers but will also help bubble up your website in search results.
Yes, very true! I want to learn more about SEO in general so I can start making more parallels for this!
Also thank you for being a reader! Love hearing feedback :)
Thank you for this. I’m a mobile developer wanting to make my iOS app as accessible as possible, but I find myself stumbling not on the technicalities of coding it, but the actual verbiage I should be using to describe UI elements to the vision impaired... do you know of any good articles on this? As a person without sight issues, I don’t feel like I’m qualified to say what would be most helpful for these users.
Hey Cary,
Honestly, instead of using Articles, I would try turning on Voiceover on if you're using an iPhone.
This is a good video of learning to get started on how to use it and how to turn it on. It's built into iOS :)
Thank you for the reply! The video is definitely helpful, but I guess I'm wondering if there's any info out there written by folks with visual disabilities, about how to name UI elements etc, so that an app or webpage is easy to use for them?
I feel like i'm missing the non-technical part of the discussion—which naming conventions, etc, I should use for my UI elements. ie, do I describe what a button does, or just call it a "completion button." The nitty-gritty stuff of actual implementation I guess.
To be honest, I am not an iOS developer, so I hope this doesn't get lost in translation. But I would say try your best to not overanalyze how elements render. Ultimately, whatever you do the best thing you can do for a11y is to render things that are semantic. For example,
<button>and<main>are semantic and<div>is not. If you use the most semantic rendering, screen readers tend to take away a lot of the heavy lifting for you.There is some nuance with more custom components and this is where manual testing and learning common screen reader commands come in handy. (Stay tuned for this, this will be my next post)
Thank you! I look forward to your next post!
A great defence of accessibility!
I think this should be $100,000 loss unless I've misunderstood.
I am talking about if you look back at the month with an inaccessible site and you made $500,0000. If you made that accessible you could be making more in potential revenue. That would make the 500k 80% of the revenue they could have had.
Yes, of course. I was working it out backwards 😅
haha yeah I get that!
Thanks Lindsey! Definitely going to refer to this post at some point in the future, since accessibility has often been an afterthought in my past experience :-/
How's the accessibility level of major CMS systems? Do you have some data about that? A lot of webpages out there are built with those and it would help a lot if such tools and their plugins were accessible by design.
I know that it's a high priority for the Drupal Core team (as I used to be a Drupal Developer). They did their best to make things accessible out of the box which I appreciated!
Here are a few links on Drupal a11y
WordPress I am not quite as certain about, but I do know that the WordPress Accessibility Lead resigned due to major accessibility flaws with Gutenberg that weren't getting resolved. I don't know what the progress has been since then.
Unfortunately, a lot of accessibility flaws are introduced when people start custom theming things. It might not matter how accessible it is out of the box if someone still customizes it without accessibility in mind.
Nice!
Yeah, there's that 😞
You should mention also WCAG authoring practices. They are very useful.
Yep! WCAG is what I use for everything now.
This is awesome, accessibility is so important, this is a great distillation of why!
Also, by the way, the timing of my post is interesting, because Dominoes lost an a11y legal case for their app and site being inaccessible.