Go to Menu
Celebrating 25 Years of Voice! 🎉

The Simplified Web Accessibility Guide: Understanding WCAG

It’s hard to know where to start with WCAG. This simple web accessibility guide can help.

February 27, 2023 by Amy Foxwell
The Simplified Web Accessibility Guide: Understanding WCAG

If your organization has a website, that website needs to be accessible for people with disabilities. Ethically, you have a responsibility to accommodate as many users as possible—and there’s no good reason to ignore a sizable portion of your audience. That’s true for all public and private websites, whether you run a business, school, government agency, or any other institution.

According to the World Health Organization (WHO), more than 1 billion people worldwide live with at least one disability. That may be an underestimate. The Centers for Disease Control and Prevention (CDC) estimates that 26% of U.S. adults have disabilities, and the number is expected to rise due to demographic trends.

The goal of digital accessibility is to provide a better experience for as many people as possible. That includes people with a wide range of disabilities such as:

  • Deaf users and people with hearing disabilities
  • People with vision disabilities
  • People with neurocognitive differences
  • People with physical disabilities
  • People with mental health conditions

How can a website accommodate all of these users—and how do you test your content to make sure you’re on the right track?

Good news: There’s a rulebook. The Web Content Accessibility Guidelines (WCAG) are published by the World Wide Web Consortium (W3C), an international organization that also creates standards for HTML and CSS programming languages. Below, we’ll explain how following WCAG can help you reach more people—and improve compliance with the Americans with Disabilities Act (ADA) and other laws.

The Role of WCAG in Accessibility Compliance

Many disability-rights laws cite WCAG directly, and others (such as the U.S. government’s own Revised Section 508 Standards) incorporate the guidelines by reference. We’ll discuss those laws in a moment; first, we’ll briefly explain how WCAG is structured.

WCAG consists of pass-or-fail statements called success criteria that can be used to test content for digital accessibility. The guidelines are designed to be applicable to virtually all types of online content including mobile apps and web-delivered documents (such as Adobe PDFs).

Success criteria are organized into three levels of conformance. “Conformance” means voluntarily following the guidelines. Here are the three levels of conformance to WCAG success criteria:

Schematic image of the WCAG Success Criteria. These are discussed one-by-one in the text of this blog following this image.
  • Level A includes the most essential (and least strict) requirements.
  • Level AA includes additional criteria. Most websites should aim for Level AA conformance.
  • Level AAA includes the most strict requirements. Some types of content may be unable to meet all Level AAA success criteria.

Each level includes all of the success criteria from the previous level. In other words, to conform with WCAG Level AA, you’ll also need to follow all WCAG Level A requirements.

Under Title III of the ADA, all places of public accommodation must provide reasonable accommodations for customers with disabilities. Per the Justice Department, websites qualify as places of public accommodation, and thousands of U.S. businesses faced ADA web accessibility lawsuits in 2022 alone.

Of course, the ADA became law in 1990, long before the creation of the internet as we know it, so the ADA doesn’t include specific rules for digital accessibility. That said, the Justice Department recommends testing content against WCAG Level AA.

To put that another way: If your site follows WCAG, it’s reasonably accessible—and likely compliant with the ADA.

But what if your business isn’t based in the US? If you operate in the US, you have an obligation to follow the ADA—and many international disability-rights laws have similar requirements:

This isn’t a comprehensive list. But while laws (and penalties) vary by country, WCAG is a simple framework for improving digital compliance. It’s also a powerful tool for building inclusive, marketable content: Accessible websites tend to rank higher in search results and provide users of all abilities with better experiences. Following WCAG simply means following the best practices of web design—and thinking about how users with disabilities will experience your content.

WCAG 101: The Four Foundational Principles of Accessibility

Now that we’ve explained why WCAG is important, let’s talk about how it works. At first glance, WCAG can appear overwhelming—but it breaks down into small, logical guidelines, organized by four overarching principles. By approaching each of these elements in turn, you can avoid confusion and improve accessibility on a continual basis.

At first glance, WCAG can appear overwhelming—but it breaks down into small, logical guidelines, organized by four overarching principles.

As we’ve noted, disabilities can affect people in extremely different ways. Some people with vision disabilities use screen-reading software, while others may use a screen magnifier. People with neurocognitive conditions might change their browser settings to view content with a specific font, while those with physical disabilities might prefer to use a keyboard alone for navigation.

Disabilities affect people in a variety of ways. So how can a single set of standards improve experiences for virtually every user with disabilities?

WCAG success criteria are organized around four basic principles, which create a strong foundation for accessible-first design. By applying those principles when designing your website (or mobile app, or any other digital product), you create better content.

Don’t ignore the principles of accessibility. They’re essential for understanding and applying WCAG’s recommendations. When your business makes a commitment to these principles, you can build a sustainable strategy.

You can remember the four principles of accessibility with the mnemonic “POUR:” Content must be Perceivable, Operable, Understandable, and Robust. Below, we’ll provide WCAG’s definition for each principle, along with our interpretation.

Schematic image of the four principles of accessibility. These are discussed one-by-one in the text of this blog following this image.

1. Perceivable

“Information and user interface components must be presentable to users in ways they can perceive.”

This means that your content doesn’t rely on a single type of sensory perception. For example, if your website includes a video with no captions or audio descriptions, that video isn’t perceivable for people with vision disabilities.

2. Operable

“User interface components and navigation must be operable.”

People must be able to operate your website, regardless of the methods they choose to use. For example, many people use a keyboard to browse the internet (they don’t use a mouse).

If your website isn’t accessible for keyboard users, it isn’t operable for those users. It requires an interaction that they cannot perform. For examples of operable keyboard navigation, see our guide to keyboard accessibility for the ReadSpeaker webReader tool.

3. Understandable

“Information and the operation of [the] user interface must be understandable.”

Let’s say that your website is accessible with a keyboard, but thanks to some fancy JavaScript, users must press the Enter key instead of the Tab key to scroll down the page.

That’s not great for accessibility, because it isn’t what users expect. If you don’t provide clear instructions to the user, they cannot understand how to operate the interface. At best, your website will frustrate these people—at worst, you might prevent them from regaining control of their computer until they guess the correct command.

4. Robust

“Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.”

Assistive technologies (AT) are hardware and software devices that enable people with disabilities to use the internet more efficiently. A common example is screen-reading software, which converts text to human speech using text-to-speech (TTS) technology—and that’s just one example of this technology’s many use cases.

Native TTS can help your website, app, or product reach a broader audience.

Contact us to learn more
Black young man with headphones and a laptop

Content is robust if it uses accurate code and markup. For example, if your website correctly uses semantic HTML and WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications) for a complex JavaScript site, you’re offering a better experience for screen reader users. There’s also a good chance that your site will work well for people who use other types of AT—including technologies that aren’t widely available yet.

How to Apply WCAG to Websites and Mobile Apps

The best way to use WCAG is to reference the guidelines regularly when designing and developing your content. If you wait until your website is published to start thinking about accessibility, you’ll spend more time (and money) fixing issues. That said, there are simple steps you can take to improve accessibility for websites that are already up and running — and at least one major mistake to avoid.

A 3-Step Process for Improving Website Accessibility (and 1 Thing to Avoid)

When you start researching web accessibility, you’ll probably come across companies that offer multi-function accessibility plugins. These are called “accessibility overlays.” If providers of these overlays promise to fix all your accessibility issues at once, be wary.

Accessibility is best approached as a comprehensive philosophy of design, not as a “problem” that a single solution can fix. Even worse, some accessibility overlays can disrupt screen readers and other assistive devices. That makes things worse, not better.

Instead of looking for a one-size-fits-all solution, address individual accessibility flaws one at a time. Here’s a three-step process for organizing your digital accessibility initiative.

Step 1: Take inventory of your site.

Accessibility flaws are easier to spot when you have a detailed list of the pages, user interface features, and digital resources on your site. This inventory will help you organize your ongoing efforts at improving accessibility, too.

Step 2: Test your site for WCAG compliance.

Frequent testing is the best way to measure your level of compliance with WCAG. A mixture of automated and manual is most effective. See our chapter on Testing Content for WCAG Conformance for details.

Step 3: Add functionality that removes accessibility flaws.

Testing will reveal where your site isn’t as accessible as it could be. There are lots of ways to fix these issues (and lots of potential issues to fix). You might embed an optional text-to-speech (TTS) tool. You might include additional site functions, like text enlargement, page masks, or TTS with simultaneous highlighting. Or you might need to take a manual approach, writing clear alternate text descriptions for all images, for example.

As we mentioned earlier in this article, each WCAG success criterion is written as a simple pass-or-fail statement. Let’s take a look at several success criteria—and common mistakes that might cause your content to fail the requirements.

Schematic and text-rich image showing the WCAG Success Criteria definitions. These are discussed one-by-one in the text of this blog following this image.

WCAG 2.1 Success Criterion 1.1.1: Non-Text Content

“All non-text content that is presented to the user has a text alternative that serves the equivalent purpose.”

The very first WCAG criterion requires a text alternative for all non-text content, with limited exceptions. This is particularly important for images: Every image must contain alternative text (also called “alt text” or “image alt tags”) that describes its purpose and function.

Missing text alternatives are frequently cited in web accessibility lawsuits, including Robles v. Domino’s Pizza LLC, a landmark case that helped to establish that the ADA applies to online content.

To follow this criterion, you’ll simply need to include alternative text for images, graphs, animations, and other types of visual-first content.

WCAG 2.1 Success Criterion 1.4.3: Contrast (Minimum)

“The visual presentation of text and images of text has a contrast ratio of at least 4.5:1 […] Large-scale text and images of large-scale text have a contrast ratio of at least 3:1.”

The contrast ratio is the difference in luminance (or light) between the text and its background. Low-contrast text may be difficult for some users to read, especially for individuals with color-vision deficiency and other vision disabilities.

Color contrast issues are extremely common—but with some forethought, you can easily avoid this mistake. Web designers should test the contrast ratio of all color-pairs using free online tools such as the a11y® Color Contrast Accessibility Validator.

WCAG 2.1 Success Criterion 1.3.1: Info And Relationships

“Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.”

Programmatically determined means that the information is available to software. For instance, if you have a web form with required fields, users need to understand that the fields are required. If they can’t submit the form because they’re missing one of those fields, their software needs to be able to tell them why. You can communicate this information to visual-first users by outlining the field in red, but people who cannot perceive visual information would need another clue. One simple way to provide that info: Mark the required fields with an asterisk, then include “required fields marked with an asterisk” in the form instructions.

“The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.”

Simply put, people should be able to look at a hyperlink—or hear the anchor text with a screen reader—and determine how it functions. If your link text reads “click here” or “read more,” you’re not supplying users with enough information. Link text should be descriptive: Not “read more,” but “read more about X, Y, or Z.”For example, if we’re linking to an article about AI in education, the link text might simply read “AI in education.” That gives users enough information to decide whether to follow the link.

WCAG 2.1 Success Criterion 1.2.2: Captions (Prerecorded)

“Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such.”

This requirement generally refers to multimedia—videos, presentations, and other content that combines audio and video.

Captions allow people to understand your media, even if they cannot (or choose not to) hear the audio. By providing captions, you’ll reach a much wider audience: One Facebook study found that captioned video ads increase video view time by an average of 12%.

These are just a few examples of the nearly 80 success criteria found in WCAG version 2.1. (We’ll explain WCAG versions in the next section.) But regardless of which criterion you’re looking at, the best way to determine success remains the same: accessibility testing.

Testing Content for WCAG Conformance

If a website voluntarily follows all WCAG Level A and AA success criteria, it’s generally considered accessible for most people. To find out whether your content conforms, you’ll need to test it against the guidelines—frequently.

To find out whether your content conforms to WCAG, you’ll need to test it against the guidelines—frequently.

Each version of WCAG adds new success criteria, and the W3C recommends testing content against the latest official recommendations for optimal accessibility.

So which version of WCAG should you conform to? While that certainly depends on when you’re reading this, as we publish (in February 2023), the version currently in force is WCAG 2.1, with WCAG 2.2 expected for release later this year. Each version of WCAG 2 is backward-compatible. That means that WCAG 2.2 contains all of the success criteria from WCAG 2.1.

Meanwhile, WCAG 3.0 is in early draft stages as we publish, with an undetermined release date set “years” in the future. According to its authors, WCAG 3 will introduce new scoring mechanisms, so it will not be backward-compatible with WCAG 2.

Two Ways to Test WCAG Conformance

WCAG 2.1 contains a total of 78 success criteria, and WCAG 2.2 is expected to introduce 9 new success criteria. How can you test your content against dozens of requirements?

Most digital accessibility experts recommend using a combination of two techniques:

  • Automated audits use artificial intelligence (AI) to test for certain WCAG failures. AI testing is inexpensive and fast, but not as thorough as manual testing.
  • Manual testing is performed by trained accessibility experts. Ideally, manual tests should be handled by people who have disabilities or significant experience with screen-reading software and other assistive technologies (AT).

While automated testing is cheap, it’s not perfect: Some success criteria require human judgment. For example, an AI tool can tell you whether your images have alternative text—but it cannot judge whether your alt text accurately describes the image.

While automated testing is cheap, it’s not perfect: Some success criteria require human judgment.

By using both techniques, you can test your content thoroughly while keeping your budget intact. Below, we’ll provide a few additional tips for testing your content.

  • Don’t assign WCAG testing to a single person or team. This approach isn’t sustainable; if the person leaves your organization, you’ll need to start from square one.
  • Make sure everyone understands the goals of accessibility. Every member of your team can play a part: Designers must choose appropriate color combinations; developers must write clean, AT-friendly code; and content writers must use subheadings and lists (like this one) to keep content readable.
  • Test your products frequently. Start testing at the first stages of development.
  • Publish an accessibility statement detailing the steps you’ve taken and your long-term goals. Include contact information and listen to any feedback that you receive from your users.

It’s always a good idea to be transparent about your accessibility efforts. If you hire a third-party accessibility testing service for an audit, share those results freely. For example, here’s ReadSpeaker’s latest Accessibility Audit from consultancy ILUNION Accesibilidad S.A.

And another example: Here’s the latest Statement of Accessibility for ReadSpeaker’s webReader TTS solution.

If you plan to offer products or services to U.S. federal agencies, you’ll also need to post a Voluntary Product Accessibility Template, or VPAT®. This document demonstrates conformance with federal Section 508 Standards for accessibility. Curious what that looks like? Here’s the VPAT for webReader.

The First Step to Fixing an Accessibility Issue: Understanding Intent

As you read through WCAG and test your content, you might find dozens of issues that you’ll need to fix before publishing your website or other digital product.

However, in some cases, fixing an issue might introduce an entirely new accessibility barrier. For example, you might need to add alternative text to your images; if your descriptions aren’t accurate—or if they’re extremely long—you’re not actually improving accessibility.

WCAG provides guidance for addressing each success criterion, which you can find in the WCAG 2.1 Understanding documentation. When you thoughtfully approach each problem, you can understand the purpose of each requirement.

Before addressing an accessibility barrier, ask yourself a few quick questions:

  • Why is this a problem?
  • How does it affect users?
  • What’s the best way to fix the problem?
  • How will fixing the problem affect the rest of my content?

WCAG is most effective if you treat digital accessibility as a priority. Asking questions can help you understand the intent behind the requirements (and avoid remediating the same issues over and over again).

Why WCAG Is More Than a Simple Checklist

It’s true that following all WCAG Level A/AA success criteria can improve digital compliance. However, the goal of digital accessibility is to provide everyone with the best possible experience, not to check off boxes on a list of standards. To create truly accessible digital content, accessibility must be a guiding principle that influences every design decision you make. That’s a big commitment.

Why go above and beyond? For starters, accessibility benefits everyone—including people who don’t have disabilities or conditions that affect their browsing behavior. Again and again, we’ve seen accessibility-first technologies become standard features for all sorts of users.

Accessibility benefits everyone—including people who don’t have disabilities or conditions that affect their browsing behavior.

For example, high-contrast modes (“dark modes”) were originally designed to make text more readable for people with color vision deficiencies, but they quickly caught on with millions of users who prefer a darker aesthetic. Closed captions were developed for people with hearing disabilities, but many people—including 70% of Gen Z viewers—simply prefer to consume video content with subtitles. More generally, only 5% of college students in one survey used assistive technology due to disability, but 18% of students considered such tools “necessary.”

Text to speech (TTS) may be the best example of a digital accessibility improvement with profound implications for everyone. Early TTS systems were developed to bring written content to people with vision impairments, but it’s now an essential part of the technology landscape: If you’ve talked to Alexa, Siri, or another vocal assistant today, you’ve used TTS. Screen-reading software also uses TTS, and feedback from the disabilities community has helped providers create TTS voices with accurate, lifelike feedback.

WCAG-Compliant TTS in Action: ReadSpeaker and the Library of Congress

The Library of Congress’ public website, congress.gov, uses a ReadSpeaker TTS plug-in to audio-enable text at the user’s prompting. This tool itself complies with WCAG 2.1 AA standards—and, of course, TTS also helps the site as a whole comply with WCAG.

This optional TTS tool won’t interfere with screen readers. To use it, a site visitor simply needs to click the Listen button or a pull-down menu with additional options (text enlargement, page masks, mp3 downloads, etc.) This is one example of a TTS tool that provides additional functionality for readers who want it, without causing trouble for users of traditional assistive devices.

The partnership between the Library of Congress and ReadSpeaker illustrates the value of flexible TTS tools for improving WCAG compliance—and the accessibility such compliance demonstrates.

At ReadSpeaker, we’re committed to providing TTS technology for everyone. That means finding new opportunities to create engaging online experiences.

We also understand that digital accessibility doesn’t end with WCAG. When organizations treat accessibility as a core value and look for ways to expand their content, real users benefit—and so do businesses. People are more likely to support brands with strong values, and over time, accessibility has an enormous return on investment. If you’ve made a commitment to accessibility, TTS from ReadSpeaker can help your business take the next steps.

Want to find the ideal TTS solution for a more accessible website, app, or digital product?

Contact us today
A business woman smiles while holding a tablet in her hands
Related articles