5 Accessibility Myths
Published on
During my preparation for the WAS exam I touched on the following myths about accessibility (Day 87: Guidelines, Laws, and Myths), but this time around I'll go into greater detail from the Deque course I'm taking. You can also read Carie Fisher's wonderfully written article (with great visuals!): 5 Digital Accessibility Myths Busted, which is also from Deque.
Accessibility only benefits a small minority
Permalink for "Accessibility only benefits a small minority"Misleading. As I stated in Benefits of Accessible Design, accessibility benefits more than just people with disabilities (note: they are a significant 20% of the population). Accessibility often makes sites and products more usable (see Usability and Accessibility), which is good for everyone. Other specific benefits for everyone:
- improved mobile device experience
- improved browsing experience for people who don't use the latest and greatest browser, operating system, or computer
- improved web indexing and search engine optimization (SEO) with increased findability
- improved user experience for an aging population
- consistent experience for people who acquire a temporary disability
Accessibility is a short-term project
Permalink for "Accessibility is a short-term project"Laughable! We would all love to have every aspect of our work be a short-term project. One-off and done, right? Accessibility is no exceptions. It's an on-going design requirement that deserves just as much attention as security and performance each time a new roll-out happens. That means that accessibility needs to:
- be part of the design process from start to finish (see Day 31: A11y throughout a Product’s Lifecycle, Waterfall vs. Agile)
- be part of company culture (remember, an organization is only as strong as the weakest link in their chain)
- have committed resources & jobs within an organization
- involve actual people with disabilities, like adding people with disabilities to teams (nothing about us, without us)
Accessibility should be the last step
Permalink for "Accessibility should be the last step"Oh myyy. I've spent the last couple years teaching co-workers how to remediate inaccessible documents and webpages. Please, please please... don't save accessibility as the last step. Otherwise, you will have a lot of frustrated and angry people on your hands.
Accessibility may seem like it takes more time at the beginning, but really it's the forethought that intimidates people. Users will thank you for that forethought, though. Bolting on accessibility at the end is what really costs you more time (and sometimes money) after you realize the late solution didn't work (fit) and has to be fixed again (and again). Not to mention, accessibility often gets neglected more when it really does get hard during retrofitting, which then puts the organization at risk of facing a lawsuit.
Accessibility is hard & expensive
Permalink for "Accessibility is hard & expensive"Speaking of hard (and expensive), let's address that issue, which should be a non-issue. Accessibility isn't free, but the cost of implementation is reasonable compared to the cost of its alternatives. Why?
- Consistent maintenance is cost-effective (especially when including accessibility from the start).
- Lawsuits are expensive.
- Bad publicity and ruined reputation is costly.
Accessibility is ugly
Permalink for "Accessibility is ugly"Aesthetics versus accessibility seems like one of the most controversial points recently. I've definitely got some strong feelings about it, myself. In reality, inaccessible designs are a lack of creativity rather than a barrier due to accessibility. To further address this battle between design and accessibility, my experience is that people don't fully understand what makes a site or app accessible when they argue for a "prettier" design. So much of accessibility is invisible to people who don't use assistive technology or adaptive strategies as a way to use the internet. Text alternatives, semantic markup, keyboard operability, reading order, captions, audio description, label and input association, headers and captions for data tables, and defined page language are things that ask nothing at the expense of aesthetics. If all a designer cares about are rigid color palettes and hiding "ugly" functionality and content (e.g. skip to main content link, acronym expansion, or text & image balance), then the medium of the web may not be the best place to practice design. The web is for everyone.