August 18, 2017
Web accessibility is important, and there are two reasons why you should care. First: All people should have equal access to digital content regardless of their physical or mental abilities. Secondly: You could get sued if you don’t. Both, I believe, warrant your attention.
In the past, we’ve had clients call Elevate, scary-looking legal document in hand, and ask for assistance with “ADA compliance.” The documents often speak vaguely about the ways in which a site fails to be accessible, but they contain little context regarding the exact standards by which compliance is being measured. Where did the scary document come from? It was potentially served by someone with too much time on their hands looking for a quick way to make some cash (à la patent troll). However, let me be clear: Although not everyone’s motivations for enforcing these guidelines are fully pure, the subject of their fixation is very real in the daily lives of many people.
ADA Compliance vs. WCAG 2.0
ADA compliance, specifically as it relates to the web, is a bit of a misnomer. ADA refers to the Americans with Disabilities Act of 1990, which is an American civil rights law prohibiting discrimination based on disability. It is a piece of legislation that reaches far beyond the web and into the design of physical objects and facilities as well. The more accurate language to describe what we are talking about is “web accessibility,” which generally refers to the degree to which a website complies with an established set of standards and guidelines. There are two main sets of guidelines to pay attention to: WCAG 2.0 and Section 503. Unless you are a government agency, you should focus specifically on WCAG 2.0.
WCAG 2.0 is a set of standards created and maintained by an international standards organization called the World Wide Web Consortium (W3C). While their organization is focused on standards much broader than accessibility, they are the group responsible for defining the recommendations and requirements for web accessibility compliance.
Where to Begin
Web accessibility helps ensure that people with visual, auditory, motor, or cognitive disabilities have equal access to content. It is a practice that finds its roots in clean, semantic markup (i.e., the code on your site) and proper contrast in visual design. If you are part of an organization that is beginning to explore what this means for you, it can be hard to know where to start. First, you need to understand that there are two components to web accessibility: how computers interpret a website and how people interpret a website.
The nature of code is that a computer will read it exactly as it’s written. Computers don’t (yet) have the ability to make decisions of their own volition, so they’re bound by the way we tell them to behave. Many people use screen readers to navigate websites, and these screen readers rely on the page’s code in order to understand what to do. The screen reader “reads” what’s in the page’s code and dictates it to the user. There are many examples that we could review, but one of the most common issues we see when working with clients is missing “image alt text.” Alt text helps screen readers (and search engines) better understand the content of an image. Therefore, if a user is unable to see an image, the screen reader needs to know its contents in order to tell the user. This alt text should be descriptive and explain the content reflected in the image in plain language. There are many nuances to alt text, including varying rules for decorative imagery, but the overall concept is to ensure that all users can contextually understand image content.
While there are automated tools to test how screen reader-friendly a website is, there are also aspects that require manual effort to review. The biggest of these is color contrast. As a colorblind person myself (see related blog post), I greatly appreciate when websites are designed with this in mind. There are recommended contrast and type ratios to maintain so that users can easily visually distinguish between text and background. There are a variety of tools that can be used for this, one of which is WebAIM’s Color Contrast Checker.
If you’re building a new site, I’d recommend you aim for compliance with WCAG 2.0 AA standards. A blank slate is one of the best opportunities to meet compliance standards. If you have an existing site that you’re looking to update, still aim for level AA, but know that it may be a challenge. Enlist the help of an expert (shameless plug for Elevate) to guide you in the right direction. While there’s a lot that you can do on your own to make significant strides, web accessibility can be a daunting topic. If you don’t believe me, just visit the W3C’s guide to understanding and implementing Web Content Accessibility Guidelines 2.0. It’s not exactly light reading.
Below is a list of resources to help you get started:
- Powermapper: A paid automated testing tool.
- W3C Techniques for WCAG 2.0.
- WebAIM color contrast checker.
- The A11Y Project: “A community-driven effort to make web accessibility easier.”
To further illustrate the point of difference between ADA compliance and compliance with WCAG 2.0, I performed a web accessibility test on ada.gov. It fails miserably for WCAG 2.0 and is noncompliant with 28 Level A success criteria. While the overarching concept of accessibility is to help organizations comply with the Americans with Disabilities Act (a law), it’s guidelines such as WCAG 2.0 that organizations should focus on specifically for the web.