WCAG 2.1 AA Explained: What It Actually Means for Your Website

WCAG sounds like an acronym from a government document nobody reads. But if you run a website for a nonprofit, church, HOA, or government agency, it's the standard that determines whether people with disabilities can actually use what you've built.

WCAG stands for Web Content Accessibility Guidelines. The "2.1" is the version. "AA" is the conformance level (there are three: A, AA, and AAA, with AA being the most commonly required). It's published by the World Wide Web Consortium (W3C), the same organization that sets standards for HTML and CSS.

Here's what it actually requires, in language that doesn't read like a legal brief.

The Four Principles

Everything in WCAG is organized around four principles. Your website must be perceivable, operable, understandable, and robust. If you remember those four words, you understand the entire framework.

Perceivable: Can people see, hear, or otherwise access your content?

This means every image has a text description (alt text) so screen readers can convey what the image shows. Every video has captions so deaf users can follow along. Text has enough contrast against its background to be readable by people with low vision. The minimum ratio is 4.5:1 for normal text and 3:1 for larger text. Content doesn't rely on color alone to communicate meaning. A form field outlined in red with the word "Required" next to it works. A form field that only turns red with no other indication does not.

Operable: Can people navigate and interact with your site?

Every interactive element (links, buttons, form fields, menus) must be reachable and usable with a keyboard. No mouse required. Users must be able to see where their keyboard focus is at all times. That means a visible outline or highlight on the currently focused element. No content should flash more than three times per second (seizure risk). Users need enough time to read and interact with content. Timers and auto-advancing slideshows need to be pausable.

Understandable: Can people figure out what's going on?

The language of the page is declared in the code (so screen readers know what language to use). Navigation is consistent from page to page. Form inputs have visible labels. Error messages tell people what went wrong and how to fix it. "Invalid input" is not helpful. "Please enter a valid email address" is.

Robust: Does your site work with assistive technology?

Your HTML needs to be clean and valid. ARIA attributes (the code that tells screen readers what elements do) need to be used correctly. Your site needs to work with screen readers, voice navigation software, and other assistive tools today and as those tools evolve.

What "Level AA" Specifically Requires

WCAG has three levels. Level A is the minimum (the most basic requirements). Level AAA is the most strict (and is rarely required in full). Level AA is the middle ground, and it's what most laws, regulations, and best practices point to.

Level AA includes everything in Level A, plus additional requirements around contrast ratios (the 4.5:1 minimum mentioned above), text resizing (content must be readable when zoomed to 200%), multiple ways to navigate (search, sitemap, or breadcrumbs in addition to the main menu), focus visibility (keyboard users can always see where they are), and consistent identification (the same icon or element means the same thing across all pages).

In total, WCAG 2.1 Level AA has 50 success criteria. That sounds like a lot, but many of them overlap or are addressed by writing clean, well-structured code in the first place.

What This Looks Like on a Real Website

Here are common scenarios where WCAG 2.1 AA matters.

Your contact form. Every field needs a visible label (not just placeholder text that disappears when someone starts typing). Required fields need to be marked. Error messages need to appear next to the field that has the problem, not just at the top of the page. And the entire form needs to be completable using only a keyboard.

Your navigation menu. It needs to open and close with keyboard controls, not just mouse clicks. Dropdown items need to be reachable by tabbing. When a dropdown closes, focus needs to return to the parent menu item, not jump to the top of the page.

Your images. Informational images (photos of your team, your building, your events) need descriptive alt text. "Volunteer Sarah reading to children at the after-school program" is helpful. "Image" or "IMG_4532.jpg" is not. Decorative images (background patterns, design flourishes) should have empty alt text so screen readers skip them entirely.

Your PDF documents. If you link to PDFs (meeting minutes, bylaws, annual reports), those PDFs need to be accessible too. That means tagged structure, reading order, alt text on images within the PDF, and a declared language. Most PDFs created by scanning paper documents are completely inaccessible.

Your videos. Any video on your site needs synchronized captions. Auto-generated captions from YouTube are a starting point, but they need to be reviewed for accuracy, especially for names, specialized terms, and speaker identification in multi-person content.

Who Needs to Meet This Standard

The short answer: almost everyone building a professional website.

Government websites are now explicitly required to meet WCAG 2.1 AA under the ADA Title II final rule, with deadlines in 2026 and 2027.

Nonprofits receiving federal funding may be required to comply under Section 508, which references WCAG standards.

Churches and HOAs aren't legally mandated in most cases, but accessibility is a matter of serving your entire community. A church that says "everyone is welcome" but has a website that a blind person can't navigate is contradicting its own message.

Any organization that wants to avoid risk. ADA web accessibility lawsuits have been increasing year over year, with thousands filed annually. Even if you're not legally required to comply, WCAG 2.1 AA is the standard courts reference when evaluating whether a website is accessible.

Common Failures (and How to Check)

The most common WCAG failures found across websites are low color contrast on text, missing alt text on images, empty links or buttons (they exist in the code but have no accessible name), missing form labels, and empty headings.

You can check for many of these yourself in under 10 minutes. Install the free axe DevTools browser extension. Open any page on your site. Click the axe icon. It will scan the page and list every detectable accessibility issue with an explanation of what's wrong and how to fix it.

For a deeper check, try tabbing through your entire page using only your keyboard. Can you reach everything? Can you see where your focus is? Can you complete your forms? If you get stuck or can't see where you are on the page, keyboard users are having the same experience.

The Overlay Question

You may have seen companies selling accessibility overlay widgets: a small icon you add to your site that claims to make it accessible with one line of code.

These do not achieve WCAG compliance. They can't fix structural code issues. They sometimes create new barriers for screen reader users. They've been named in multiple ADA lawsuits. And the National Federation of the Blind has publicly opposed their use.

Real accessibility comes from building it into the code, the content, and the design. There are no shortcuts.

Getting Started

You don't need to fix everything at once. Start with three things: run the axe DevTools scan on your homepage and fix what it finds, tab through your most important page with only your keyboard and note where you get stuck, and check your color contrast on any text that isn't black on white.

Those three checks will surface the biggest issues. Everything else can follow from there.