Web Accessibility: the Who, What, and Why
Here’s how everyone can benefit from accessible design
Mar 03, 2020

This is the first post in a multi-part series about web accessibility. Here, UX Developer Kevin Schmincke discusses the benefits of accessible design and how to test user interfaces (UIs) to see how they measure up. Keep your eye out for future posts, where we’ll dive deeper into hands-on techniques.

What is accessibility?

People often mistake accessibility for accommodation. Whereas accommodation refers to making special exceptions for people who need them, accessibility refers to creating a system designed to work for all people, including those with disabilities. There are many factors at play when it comes to each user’s experience of a website or application: physical or mental ability, age, computer literacy, screen size, browser choice, operating system… the list goes on!

Because it’s impossible to predict every combination of these factors among your user base, the only solution is to design one cohesive and robust system for all. That is the goal of accessibility.

Does accessibility really affect that many people?

Yes – according to 2010 US Census data, 56 million Americans identified as having a disability. That’s almost 1 out of every 5 people in the United States!

Disabilities fall into 4 major categories and can range from mild to severe:

  • Vision impairments include full blindness and people who have low vision due to aging or conditions like glaucoma or cataracts. These users often use a program called a screen reader to read the contents of a web page to them. Low contrast between background and text colors can inhibit readability for all users, especially users suffering from low vision.
  • Motor impairments make it difficult to grip or maneuver a mouse or a keyboard and include arthritis, Parkinson’s disease, cerebral palsy or even people who are paraplegic or missing limbs. Users with motor impairments may not use a mouse, opting instead to use only the keyboard, or another assistive device.
  • Hearing impairments make it impossible to consume auditory content. It is essential to add captions or transcripts alongside audio/visual content so that all users can access the same information.
  • Cognitive impairments are any conditions which make it difficult to understand or comprehend content. For example, people with dyslexia, attention deficit disorder, or intellectual disabilities may have difficulty understanding content or remembering all of the steps or content related to a multi-step process. Often, this category of users is overlooked when considering accessibility.

And if 56 million isn’t a big enough number, keep in mind that doesn’t include temporary disabilities. Broke your arm and now it’s in a sling for 6 weeks? That’s a temporary motor impairment. Just came from an eye appointment and your pupils are dilated for the next couple of hours? Temporary vision impairment. Have a baby at home and surviving on an average of 4 hours of sleep a night? I’m experiencing this right now, and it is definitely a (hopefully temporary) cognitive impairment.

Why should I care about accessibility?

  • Accessible design benefits all users, even if they don’t have a disability: Ever tried to use the Tab key to move through a form online? That’s a core accessibility principle! Power users, for instance, enjoy using only the keyboard and often find it faster than using the mouse. So, designing a single robust system means removing barriers for some will improve the experience for all.
  • It’s the law: In 1998, Congress amended the Rehabilitation Act of 1973 to include Section 508, which mandates that federal US agencies make all digital content accessible to people with disabilities with the goal of removing barriers to entry. In addition to Section 508, the Americans with Disabilities Act (ADA) states that businesses can’t discriminate against people with disabilities. While the ADA doesn’t explicitly call out web content as being subject to its mandates, recent court rulings have set precedence for applying the law to digital space. In fact, in 2018 there were 2,258 lawsuits filed in response to web inaccessibility.
  • It can save time and money: Accessibility practices lead to better code which is more readable, maintainable, and self-documenting. In many cases these practices can even mitigate future work. Imagine you’re building a house: if you build the entire house first, then run wiring for electricity, it’s going to cost a lot more than running wires from the beginning. Accessibility is the same way; it’s far more expensive to retrofit an interface for accessibility than it is to include it at the design phase. In fact, as you move accessibility integration closer to the beginning of your project, the cost approaches zero.

Now, let’s look at a practical example.

Say we want to make a button.

I’m going to make it out of a non-semantic div element. I can just use CSS to make it look like a button later, right?

HTML code: a button made from a div element with the text

Oh no, the accessibility police are here. OK, I guess we have to add an ARIA role so that screen readers know they’re looking at a button and not just a random text node?

HTML code: the same button as before now with role=

What’s that? I also have to make sure the button is focusable via keyboard?

HTML code: the previous button now with tabindex=

I have to make sure it can be activated with a keyboard too? Ugh, fine.

HTML button now includes JavaScript event listener to allow the Enter key to click the button, about 14 total lines of code

Man this accessibility stuff is hard! Look at all that extra code I had to type out! This stuff isn’t worth my time. I’m going back to the important work like writing ansible scripts.

But wait! By following proper accessibility practices, we could have made one very easy change at the start and avoided all this extra work: we could have simply made this button from a <button> element.

HTML code: a button made from a button element, a single line without the extra attributes added before

If you tell the browser your element is a button ahead of time, it will automatically make it focusable, add keyboard controls, and use the proper ARIA role: all that stuff we had to add in ourselves!

OK I’m convinced. But how do I make my product accessible?

One of the difficulties is figuring out what makes a website accessible in the first place. Fortunately, that work has been done for us by the World Wide Web Consortium (W3C). They’ve helpfully published the Web Content Accessibility Guidelines (WCAG) so that we can organize and measure accessibility for our sites.

These guidelines are organized into four main categories:

  • Perceivable: content and UI elements must be presented in ways a user can easily see or hear
  • Operable: a site should be usable by a variety of input modes
  • Understandable: content and functionality must be presented in easily read and understood ways for users
  • Robust: a site must work with a variety of platforms, browsers, devices, and assistive technology

The WCAG also provides varying levels of conformance for each success criterion: A, AA, and AAA. The AA level is typically used as a standard for conformance for organizations and governments. In fact, in 2017 Section 508 was amended to adopt WCAG at AA conformance levels for the US federal government, effectively turning WCAG from guidelines into a mandate.

Our upcoming posts will take a deeper dive into the how-to of accessibility. In the meantime, for a quick overview on best practices, we created an accessibility standards guide complete with code examples along with do’s and don’ts.

How do I know if my website or application is accessible?

Try using your solution the way someone with a disability might use it. And, get creative! Sit on your dominant hand and try to navigate with only your non-dominant one. Unplug your mouse or cover your trackpad. Turn your monitor off and navigate your site by screen reader only. Zoom your browser up to 200% and try to use the interface. Disable all CSS to see the page the way assistive technology sees it and verify the structure is logical. These exercises will reveal shortcomings in your UI very quickly.

Ultimately, the best way to test accessibility is to find real users of your product that have a disability. As with usability, there are basic principles guiding what makes a website accessible, but there are a lot of gray areas which can only be sorted out by observing a user interact with your interface. Only this strategy can give you the deepest insights about the accessibility of your product.

Accessibility just makes sense.

It’s a no-brainer — accessibility makes good business sense, saves you from lawsuits, improves your code, and advances an inclusive world. At its core, accessibility design isn’t about knowing the full WAI-ARIA spec backward and forward, or knowing every shortcut command a screen reader offers. It’s about considering other types of users at the design phase. Accessibility principles ensure that the widest possible range of users can access your tool or site. The reality is, ignoring accessibility sends the message that you don’t care about your users.

So, the next time you develop a feature, ask yourself: how would users — all users — use this, including groups you might not have thought of immediately? Once you get into the habit of thinking through the wider lens of inclusivity, the rest will come a lot more easily.