The Newbie’s Introduction to Web Accessibility

Accessible websites should be as ubiquitous as ramps on sidewalks. Why do so many lack access to the internet, and what can you do to help?

This article is a part of the Tech in Policy publication. TiP focuses on technology being used for good and shines a light on its more malicious or neglectful implementations. To read more, visit this link.

If you’re new to the world of web development like I am, you’ve probably heard of “web accessibility.” I had too, but this summer I attended a coding bootcamp where I learned how to create web apps, and I found myself starting my first projects without a thorough understanding of what accessibility on the internet really meant. Before the course, I had no programming or CS experience. I spent 553 hours listening to lectures, working through assignments and building websites. Not one of those hours was dedicated to learning about web accessibility. I’m surely not the only one who’s been in that situation, so I decided to do some digging and share my findings.

We’re all aware of the importance of the internet, especially in the midst of a global pandemic. Unless you’re an essential worker (and even if you are), you probably rely on the internet throughout much of your day. Access to the internet is a human right, and now more than ever, lack of access can be not only exclusionary but potentially deadly. With many companies’ online offerings replacing their in-person services, it’s just as important for their websites to be accessible as it is for their physical stores.

The World Wide Web Consortium (W3C), the organization that upholds the Web Content Accessibility Guidelines (WCAG), states that websites should be designed so that all people with disabilities can “perceive, understand, navigate, and interact with the Web” and “contribute to the Web.” Ideally all websites would adhere to these guidelines, but the beauty (and danger) of the internet is that anyone can create anything. There’s no way to block websites from being published for not following proper accessibility guidelines.

Although there’s currently no enforced review process for website accessibility, companies in the US are finding themselves increasingly aware of the importance of building accessibility into their sites. When Guillermo Robles, a blind man living in California, tried to order a pizza online, his screen reading software was unable to function properly on the Domino’s website. He wasn’t able to place the order, and sued Domino’s for violation of the ADA — a lawsuit that’s now recognized as one of the more prominent web accessibility cases in this country. Title III of the ADA “prohibits discrimination on the basis of disability in the activities of places of public accommodations.” The Supreme Court’s 2019 decision in Robles’ favor notified the public that the ADA definition of “places of public accommodations” could include companies’ online presences as well as their brick and mortar locations. This meant that companies not only had to be responsible for providing proper accessibility accommodations in their stores, but also on their websites.

The Robles case was not out of the ordinary. In 2019, there were 2,256 web accessibility lawsuits filed against companies whose sites weren’t up to par with Title III of the ADA. The number of suits of this type has been increasing drastically year-to-year, although the curve seems to have flattened in 2019.

ADA Title III Website Accessibility Lawsuits in Federal Court 2017–2019 (2017: 814; 2018: 2,258; 2019: 2,256)

Everyone should be able to access the internet. Why are there so many digital accessibility lawsuits filed every year, causing companies to lose large sums of money time and time again?

Like I mentioned above, I didn’t learn the first thing about web accessibility when I learned how to code websites. Inadequate training is one of the many reasons software engineers fail to meet their responsibility to build accessible products. Another reason is a lack of diverse perspectives within the types of people who are creating websites. If engineering teams are made up of a single type of person, their products will only be built for that type of person. Although the responsibility to teach and prioritize web accessibility falls on the larger institutions involved, software engineers should take it upon themselves to learn the fundamentals of web accessibility. For an intro to making accessible websites, keep reading.

First, let’s talk about how to test for web accessibility. Open another tab and follow these steps to try it out!

• Choose a website to test, any website at all. Navigate to that URL in your Chrome browser. I’ll use a11y.coffee for my example.
• Right click anywhere on the page and click “Inspect” to open up Chrome DevTools.
• Click on the “Lighthouse” tab of your DevTools.

a11y.coffee, a collection of information and resources about web accessibility, with Chrome DevTools open

• Feel free to adjust the selected categories, just be sure to include “Accessibility.” Click “Generate Report” and check out the score!

a11y.coffee’s Lighthouse accessibility score of 100%

There are, of course, other standards for assessing the accessibility of a website. WCAG 2.0 measures the success of a site’s accessibility in four principles: Perceivable, Operable, Understandable and Robust (POUR). There are also other methods of performing accessibility tests. For example, Lighthouse (the tool we used in the demo above) can be incorporated into a continuous integration workflow, meaning these audits would run automatically at every step of the development process, rather than being run in the browser. There are many other tools to test accessibility, but you shouldn’t rely too heavily on them. A website will get a score of 100 if it doesn’t fail any of the Lighthouse audits, but that doesn’t necessarily mean the site is 100% accessible to all people. WCAG states that “professional reviews utilizing recognized qualitative heuristics are important in achieving accessibility for some audiences.”

Although you and I might not have the resources to run extensive user testing on a side project to ensure it’s adequately accessible to all audiences, here are a few steps I gathered from MDN that we can all take as web developers to create more inclusive online spaces:

HTML

• Use the most appropriate element tag for the job. Don’t CSS your <div> into a functioning button, use a <button> tag. Using improper tags (non-semantic HTML) in your code can cause issues for assistive devices like screen readers.
• Take a look at the following code. Fill in your name: <input type="text" id="name" name="name"> Devices that use HTML to convey the contents of the page might not be able to tell that this input is associated with this label, resulting in an input field without a description. Instead, associate your form inputs with their given labels like so:

<div>
  <label for="name">Fill in your name:</label>
  <input type="text" id="name" name="name">
</div>

• Giving your <html> tag a lang attribute and including a <title> element in your <document>are central to ensuring that users with visual impairments can use the website.

CSS

• Be sure to always maintain a high color contrast between elements on your page. If the text color is too similar to the background color, certain users won’t be able to read it.

JavaScript

• It can be difficult for certain assistive devices to parse web apps whose HTML and CSS were programmed using JavaScript. Try to avoid generating these parts of your site with JS if at all possible.
• Certain users with disabilities interact with the web through keyboards rather than the mouse. Listening for events such as mouseovr and dblclick in JavaScript event listeners excludes such users from those features. When writing event listeners, include relevant keyboard actions to listen for as well, such as onfocus and onblur.

These steps just begin to address the many ways we as developers should be thinking about accessibility. While we definitely have a responsibility to write accessibility into our code from the start, it’s also the responsibility of tech companies to prioritize it in their workflows, of coding bootcamps and Computer Science programs to teach its importance, and of the government to protect users with disabilities’ access to the internet. After all, building accessible websites doesn’t ever harm anyone. It’s beneficial to all parties — if you’re not familiar with Universal Design, read up! W3C provides a list of some of the cases where built-in accessibility also helps users beyond the predicted range:

• People using mobile phones, smart watches, smart TVs, and other devices with small screens, different input modes, etc.
• Older people with changing abilities due to aging
• People with “temporary disabilities” such as a broken arm or lost glasses
• People with “situational limitations” such as in bright sunlight or in an environment where they cannot listen to audio
• People using a slow Internet connection, or who have limited or expensive bandwidth

Web accessibility is not only essential for certain users (which is reason enough to implement), but it can also aid other users and save companies lots of money in lawsuit settlements. Take some time to run an accessibility test on your website and think about what you can do to implement accessibility moving forward. For more information, poke around a11y.coffee and take a look at WCAG 2.0.