As someone brand new to learning about accessible design, I admit I had a few misconceptions about accessible web design. I’ve been a software developer for just over a year, and have been learning development for around three years. Though I still have tons more to learn, I’ve learned a fair amount about programming languages, frameworks, patterns, editors, tools, and more. One thing I have learned almost nothing about — web accessibility.
That changed recently when I attended an event hosted by a local tech group, Refresh Detroit. The event featured a series of lightning talks, and the lightning talk by group co-organizer Deborah Edwards-Onoro (Lireo Designs) discussed web accessibility.
The more research I did into the topic, I noticed others had a few misconceptions as well. Here are a few of the main misconceptions I came across.
“It only helps a few people”
When I would hear the term “accessibility”, my mind would go to very specific accommodations — a wheelchair-accessible entrance or restroom, for example. I carried this same belief into how “accessibility” was designed. It was specialized for a relatively small group of people. Turns out I needed to be thinking bigger.
Abilities of Web Users
Sources: http://www.statisticbrain.com/number-of-american-adults-who-cant-read, https://www.census.gov/newsroom/releases/archives/miscellaneous/cb12-134.html
Melanie Myers, 2017
Web Accessibility actually casts a very broad net. It helps people with physical, mental, vision, hearing challenges and more. It also helps low literacy and new language learners. That’s a lot of different groups!
Sometimes, those of us who aren’t currently dealing with a disability tend to create an “us” vs. “them” mindset. We think that we’re in the “no disability” camp and that’s where we’re staying. But the cold hard truth is that all of us (gulp) are going to grow older. And with advancing age can eventually come lessened abilities. We may have a great vision now, but in our 80’s or 90’s it may be a little different. Won’t you want to still use websites then? So accessibility really is for everyone. We can’t be so quick to think of it as for “others”. The more I learn about accessibility, the more I see the need for it. For example, I learned about users that may have physical challenges that prevent them from using a keyboard or mouse or people who are learning English as a second language who would benefit from captions or the ability to slow down a video’s playback speed.
W3C’s Web Accessibility Initiative has a fantastic overview of the varying disabilities of web users.
“It’s less important than functionality”
So what is functionality? If a site or app is not usable by nearly 30% of the potential user base, can it still be called functional?
Learning about accessibility has encouraged me to ponder these questions. Very often in development, we are focused on the “MVP” (minimum viable product). Accessibility is almost never a part of this discussion. But are we accumulating even more technical debt by not addressing accessibility from the start? Teams need to consider if they are going to be proactive and discuss accessibility from the start, or if they will be reactive and discuss accessibility after the foundational code is already in place. Waiting to discuss and address accessibility may cost more time in the long run.
Check out Apple’s page on how they incorporate accessibility with functionality.
“It’s really time-consuming”
Accessibility sounds cool and exciting until the software team starts thinking about the actual application of accessible design principles. We have to change these images, alter this color scheme, add captions here, increase the font size here. The list can seem endless. It can be tempting to put it on the backlog while working on other aspects of the site or app.
But as I’ve learned about software teams incorporating accessibility into their products, I’ve learned that accessibility can be treated just like any other feature or design principle for your product. Define team guidelines, break it down into tasks, and chip at it one piece at a time.
There are a lot of tools available to help with intensive tasks such as captioning videos (just make sure to go over them with a human eye as well). It’s also a great project for someone new to web design or development that wants to get his or her hands on a piece of the work.
For some examples of free services that do captioning, check out University of Washington’s list.
The Blink UX team wrote a great blog post about the process of making their existing website more accessible.
“It’s Optional”
In a lot of cases, it’s legally not optional. Many companies and organizations are officially required to have a certain level of accessibility for their web content.
Certain types of organizations, such as those in the government, education or some non-profits, are more likely than others to be required to comply with disability and accessibility laws. Additionally, whether you need to follow these laws can also be based on whom you do business with- for example, a private sector company that has government contracts. Whatever the case, I’ve learned it is best to do research on your specific situation.
W3’s Web Accessibility Initiative has a great overview of legal requirements regarding digital accessibility to get you started.
“If it’s accessible, it can’t be pretty”
This is a big one. A lot of digital designers think of accessibility and automatically think of limits.
I’m beginning to learn that accessible design can be about getting to do more instead of less. It doesn’t mean you can’t have the color combination you think looks pretty amazing, you just need to add tools so that color blind or visually challenged users can still use the page—such as numbering or underlining.
Truth is, an accessible website has the same potential to be gorgeous or scary-ugly as any other website. If you feel accessibility is limiting you in the design area, try re-evaluating your design strategy or purpose.
I wonder, what if we used this excuse in the rest of the world? Would we so easily dismiss the need for accessibility in the name of good design in other non-web spheres? For example, what if an interior designer wants to make a door narrower, a counter higher, or a ceiling lower for purely aesthetic reasons? I can’t imagine that would go over very well. The response may be “sure it looks nice but it’s not functional.” We could say the same about web design. And even accommodating for function and disabilities, we have still seen many beautiful buildings designed and built. The same can be said for websites.
Because color contrast is an important aspect of accessibility, some designers assume they have to sacrifice vibrant colors for dull ones. Not true says Usability Matters in their blog post about tools and tips for making beautiful and accessible designs. They recommend using the Web AIM Color Contrast checker and remembering that you don’t necessarily need to sacrifice vibrant colors for dull ones in the name of accessibility.
Here are some great examples of beautiful AND accessible sites:
Niels Matthijs says:
Agree with what’s being said here, though I think the second point needs a bit more nuance.
When it comes to functionality, functionality for 70% is better than no functionality for that same 70%. It’s a weighed decision, based on how hard it is to make a certain function accessible, whether it’s a core functionality and how relevant it is to people making use of accessibility software.