Guide: WCAG 2.1 AA for Beginners

It’s time to finally get serious and figure out WCAG 2.1 AA.

To create or fix a website to be optimized for accessibility, you need to start by working towards WCAG 2.1 AA conformance but what does that even mean?

Background (6 seconds):

WCAG stands for the Web Content Accessibility Guidelines which is a set of standards authored by the Web Accessibility Initiative (WAI) under the W3C.

There are currently three* versions of WCAG (1.0, 2.0, 2.1) and three conformance levels (A, AA, AAA).

*Version 2.2 is coming very soon.

Most entities should strive to make their websites, mobile apps, and other digital assets conformant to WCAG 2.1 AA.

So how do you it?

Here’s a lightning quick WCAG 2.0 AA checklist created by yours truly:

Section 1: Alternatives

• Alt text (1.1.1): All images and non-text content needs alt text (there are exceptions)
• Video & Audio alternatives (1.2.1): All video-only and audio-only content has a text transcript. Transcripts are clearly labeled and linked below the media.
• Closed captioning (1.2.2): All video with sound contains accurate closed captioning.
• Audio description (1.2.3): For any video with relevant information not conveyed by audio, add an audio description of information conveyed visually or include a text transcript.
• Live captions (1.2.4): Any more formal, live presentations must have closed captions.
• Audio description (1.2.5): An audio description is optional under 1.2.3 level A but not in 1.2.5 AA.

Section 2: Presentation

• Website structure (1.3.1): Use proper markup techniques to structure your website’s content (e.g. use correct heading tags and HTML for ordered and unordered lists)
• Meaningful order (1.3.2): Present content in a meaningful order and sequence so that it reads properly.
• Sensory characteristics (1.3.3): When providing detailed instructions, make it so they aren’t reliant on a single sensory ability.
• Use of color (1.4.1): Do not rely on color alone to convey information.
• Audio control (1.4.2): Any audio must be able to be paused, stopped, or muted.
• Color contrast (1.4.3): There must be a color contrast ratio of at least 4.5:1 between all text and background.
• Text resize (1.4.4): Text must be able to be resized up to 200% without negatively affecting the ability to read content or use functions.
• Images of text (1.4.5): Do not use images of text unless necessary (e.g. logo).

Section 3: User Control

• Keyboard only (2.1.1): All content and functions on a website must be accessible by keyboard only (i.e. no mouse).
• No keyboard trap (2.1.2): Keyboard-only users must never get stuck on any part of the website; they must be able to navigate forwards and backwards.
• Adjustable time (2.2.1): If there any time limits on a website, users have the ability to turn it off, adjust it, extend it.
• Pause, stop, hide (2.2.2): If there is content that blinks, scrolls, moves, users must have the ability to pause, stop, or hide it.
• Three flashes or below (2.3.1): Web pages do not contain anything that flashes more than three times in any one second period.
• Skip navigation link (2.4.1): A “Skip to Content” or “Skip Navigation” link allows users to bypass the header / navigation menu and go straight to the main content.

Section 4: Understandable

• Page titles (2.4.2): Each page of a website needs to have a unique and descriptive page title.
• Focus order (2.4.3): Users must be able to navigate through a website in a logical sequential order that preserves meaning.
• Link anchor text (2.4.4): The purpose of each link should be clear based on its anchor text (e.g. don’t use “click here”)
• Multiple ways (2.4.5): There are multiple ways to access different pages/information on a website (e.g. search bar, nav menus, sitemap, breadcrumbs, helpful links after content).
• Descriptive headings and labels (2.4.6): Headings and programmatic labels must be clear and descriptive. They do not need to be lengthy.
• Focus indicator (2.4.7): Any “user interface control” that receives focus from a keyboard user should indicate that focus on the current selected element (e.g. add a visible border around a text link).
• Website language (3.1.1): Set the language for your website.
• Language changes (3.1.2): Indicate any language changes for an entire page or within the content.

Section 5: Predictability

• No focus change (3.2.1): Nothing changes merely because an item receives focus; a user must actively choose to activate an item (e.g. hit enter to submit) before a change takes place.
• No input change (3.2.2): Nothing changes just because information is inputted into a field (e.g. form doesn’t auto submit once all fields are filled out).
• Consistent navigation (3.2.3): Keep navigation layout consistent throughout all pages of the website (e.g. same links in the same order).
• Consistent identification (3.2.4): Components that have the same function within a website are identified consistently (but not necessarily identically) (e.g. two check marks can indicate two different things as long as their function is different — one indicates “approved” on one page but “included” on another).
• Error identification (3.3.1): Make any form errors easy to identify, understand, and correct.
• Form labels and instructions (3.3.2): Programmatically label all form or input fields so that a user knows what input and what format is expected.
• Error suggestions (3.3.3): If an input error is automatically detected, then suggestions for correcting the error should be provided.
• Error prevention on important forms (3.3.4): For pages that create legal commitments or financial transactions or any other important data submissions, one of the following is true: 1) submissions are reversible, 2) the user has an opportunity to correct errors, and 3) confirmation is available that allows an opportunity to review and correct before submission.
• Parsing (4.1.1): Make sure HTML code is clean and free of errors, particularly missing bracket closes. Also, make sure all HTML elements are properly nested.
• Name, role, value (4.1.2): For all user interface components (including forms, links, components generated by scripts), the name, role, and value should all be able to be programmatically determined; make sure components are compatible with assistive technology.

By the way, my WCAG Course includes an Excel spreadsheet checklist and will train you on WCAG 2.1 AA and the new WCAG 2.2 AA — even if you’re completely new to WCAG and no nothing at accessibility.

You can find out more at WCAGCourse.com.

WCAG, Legally

Here’s how to view WCAG in a legal context:

Some laws incorporate WCAG (e.g., Section 508, AODA, EN 301 549, etc.). For compliance with those laws, you must be WCAG conformant.

But the primary law most private entities are concerned with is the Americans with Disabilities Act (ADA).

Under Title III of the ADA, the standard for accessibility for places of public accommodations is meaningful access.

Because most courts have interpreted the ADA (or other parallel anti-discrimination laws) to apply to websites, your website needs to be meaningfully accessible.

But how do we know when a website has reached the meaningfully accessible threshold?

We don’t.

There are no explicit mandates set out by law or regulation.

So the courts and other legal entities look to the Web Content Accessibility Guidelines (WCAG) as a reference.

If you meet all 50 success criteria under WCAG 2.1 AA (success criteria are the different accessibility items called for under the guidelines) then your website will be considered accessible by every law — both U.S. and internationally (unless there is some practical issue preventing access more broadly).

However, strict conformance isn’t necessary to provide meaningful access.

While some success criteria can be essential to access (depending on who is accessing the website), others are more in place to ensure an optimal experience.

Now we get into what I call practical and technical compliance.

Practical compliance is what most people are immediately concerned with: how to I not get sued for having an inaccessible website?

To avoid litigation, you have to understand what plaintiffs lawyers are looking for and there are 15 issues that plaintiffs lawyers claim continually in litigation.

These are the issues to prioritize and resolve on your website.

By the way, I have an entire course on how to prevent website accessibility lawsuits called the ADA Compliance Course.

You can learn more about it at ADACompliance.net.

Technical compliance means you follow best practices for ADA compliance as extracted for the Department of Justice settlements over digital accessibility.

Basically this comes down to full conformance with WCAG 2.1 AA and publishing an accessibility statement with multiple contact methods for feedback and support.

Technical compliance is where you want to be after you’ve become practically compliant.

In a Nutshell

The Web Content Accessibility Guidelines are international standards for accessibility.

Basically, they help the web become more accessible by setting out the different considerations we can incorporate into our web assets to make them accessible to people with disabilities.

Although WCAG is not the law, it’s extremely important for preventing lawsuits and, ultimately, compliance with different laws.