Accessibility: 508, ADA, WCAG – Essential Knowledge and Actions

With help from high-profile initiatives like Microsoft’s Inclusive Design and a 16 percent increase in ADA Title III lawsuits in 2017[1], web accessibility has steadily been rising to the forefront of designers’ and developers’ minds. So what do you need to know to better understand the current landscape? In this article, we’re going to briefly explain the key laws and guidelines that are involved, share some practical reasons why accessibility matters, and finish up with some tips on how to start considering accessibility in your projects today.

Why it Matters

There are several commercial, ethical, and legal justifications for incorporating accessible practices in your design and development workflow.

  • Federal law mandates that all government and federally-funded projects are made accessible; there could also be legal ramifications for private businesses (e.g. National Federation of the Blind v. Target Corp lawsuit).
  • Removing barriers to your website can increase user satisfaction and customer engagement, and allow a wider range of potential new users.
  • Increased accessibility benefits all users, not just the disabled. Everyone at some point in their lives will be disabled, even if it’s just temporarily or situationally. For example, a device designed for a person who has one arm could be used just as effectively by a person with a temporary arm injury or a new parent holding an infant.
  • With WCAG 2.1 scheduled to be published as a standard in 2018, the time to think about web accessibility is now.
  • To put it simply - If you have a website, you need to consider its accessibility to disabled users.

Key Laws and Guidelines

TL;DR

In the context of web accessibility, Section 508 requires federal agencies and those receiving federal funds to make web content accessible to those with disabilities including meeting WCAG 2.0 AA compliance. There is currently no concrete law in the U.S. that legally requires private businesses to meet specific accessibility requirements, but it's widely considered advisable to meet WCAG 2.0 AA voluntarily or risk a lawsuit under Title III of the ADA.

ADA

A federal civil rights law that prohibits discrimination based on disability, requires covered employers to provide reasonable accommodations to employees with disabilities, and imposes accessibility requirements on public accommodations. Separated into five sections called titles, the third of which is most applicable to web accessibility and covers public accommodations. There is some ambiguity on whether websites and mobile apps are considered "places of public accommodation” and if so what standards need to be met in order to be considered compliant. The Justice Department has long considered Title III and its implementing regulation to apply to the online services and communications of public accommodations, but has not amended the ADA to specify this directly.

Section 508

In 1998, Congress amended the Rehabilitation Act of 1973 with Section 508. Under this law, all federal agency’s full range of public-facing content, including websites, documents and media, blog posts, and social media sites must adhere to WCAG 2.0 AA guidelines. This law does not require private websites to comply unless they are receiving federal funds or under contract with a federal agency.

WCAG

The Web Content Accessibility Guidelines is a W3C specification of recommendations for making Web content more accessible. It's comprised of four principles, each with a set of guidelines that contains specific testable success criteria. These guidelines are also split between three levels of compliance from A to AAA, with the middle AA level considered the advisable goal of compliance. You’ll often notice WCAG 2.0 or 2.1 versions noted specifically. The former was an overhaul of the guidelines completed in 2008 and currently considered the standard to follow, the latter is an extension to 2.0 and was just published as a recommendation on June 5th 2018. Here’s a handy quick reference tool of all requirements, organized and filterable by the four principles.

Some guideline examples:

  • Alt Text for Images: Making sure images on websites have text describing the image so it can be read by a screen reader.
  • Keyboard Input: Accounting for people who are unable to use a mouse, trackpad, or other similar input devices. Keyboard input enabling also allows for disabled people to be able to use other input devices that mimic keyboards, such as speech input and a refreshable braille display.
  • Audio Transcripts: Providing a text transcript of audio information to make it accessible to those that are deaf or hard of hearing is cheap and easy, as there are already many transcription services that create transcripts in HTML.
  • Contrast Checks: Some people with visual impairments cannot read text if there is not sufficient contrast between the text itself and the background it’s sitting on. Creating high-contrast text, such as using bright text on a dark background, can increase the readability of the content.

Getting Started

If you’re working with a designer or agency, ask about their plans for web accessibility, questions like:

  • Could you perform an accessibility audit of our site and report your findings?
  • How do you incorporate accessibility into your design and development process?
  • What is the right level of compliance for our project and how do we get there?

If you’re designing a web project:

If you’re developing a web project, you’ll save time in the long run by starting a project applying accessibility best practices rather than applying all at once at the end. To do that:

  • You’ll need a good understanding of the WCAG requirements and how to satisfy them.
  • The automated testing browser plugins noted in the Tools & Plugins resource section below will help tremendously.

If you’re concerned about the accessibility of an existing website:

  • Free tools are available to help you audit pages for a better idea of whether accessibility had been addressed.
  • We recommend completing this Easy Checks checklist as a good first step toward basic accessibility. The browser plugins noted in the Tools & Plugins resource section below can help automate some of these steps.

Resources

Tools & Plugins

  • axe: the Accessibility Engine - Axe is an open source rules library for accessibility testing. Has browser plugins for Firefox and Chrome.
  • Google Lighthouse - Built into Chrome and integrates Axe core, helps to automatically identify common accessibility as well as performance and user experience issues.
  • WAVE - Similar to Axe, has browser plugins for Firefox and Chrome and can evaluate the rendered page for accessibility issues.

Online

Books

---

[1] Source, ADA Title III reference: https://www.adatitleiii.com/2018/02/ada-title-iii-lawsuits-increase-by-14-percent-in-2017-due-largely-to-website-access-lawsuits-physical-accessibility-legislative-reform-efforts-continue/ 

Share This

About the Author:

Steve is a full-stack developer with years of industry experience architecting, building, and managing web applications. With a focus on responsive design systems and modern technologies, he's dedicated to solutions that can stand the test of time.

Previous Article|Next Article