ADA Website Compliance: What WCAG 2.1 AA Means

For business owners in the United States, discussions about ADA website compliance often lead to the same phrase: WCAG 2.1 AA. It appears in audit reports, development proposals, and accessibility claims. But what does it actually tell you about whether a customer can use your website?

WCAG provides a structured way to identify accessibility barriers. Rather than treating accessibility as a vague promise to make a site easier to use, it defines testable requirements. Understanding that structure helps you commission better audits, ask more useful questions, and distinguish meaningful improvements from reassuring labels.

WCAG 2.1 AA and ADA website compliance

WCAG stands for Web Content Accessibility Guidelines. In WCAG 2.1 AA, “2.1” identifies the version, while “AA” identifies the conformance level. The guidelines organize accessibility around four principles: content must be perceivable, operable, understandable, and robust.

The relevant law is the Americans with Disabilities Act, commonly called the ADA. The U.S. Department of Justice, Civil Rights Division is the federal enforcement authority. Its 2024 rule under ADA Title II codifies WCAG 2.1 AA for state and local government web content.

That government context matters: it should not be presented as a rule written for every private business website. For businesses, the supplied legal context is primarily private litigation: lawsuits and demand letters from plaintiffs’ firms, typically referencing WCAG, with defendants bearing injunctive relief and attorneys’ fees.

This helps explain why WCAG is a practical reference point in accessibility discussions. It gives businesses, developers, and evaluators a shared technical framework. A technical evaluation is not a guarantee of a legal outcome, however, and an accessibility report should not imply otherwise.

Perceivable: can customers access the information?

Perceivable means that information cannot depend entirely on a particular way of seeing or hearing. Customers need access to the meaning of your content, even when they use a different sensory route.

Consider a product page. A photograph may communicate the product’s appearance to a sighted customer, but someone using a screen reader needs an appropriate text alternative. That alternative should convey the image’s purpose in context, rather than merely say “image” or repeat a filename.

Other everyday examples include:

• Form errors: explain the problem in text rather than marking an input red without an explanation.
• Text contrast: make text distinguishable from its background, including secondary information and instructions.
• Video: provide captions for spoken content and meaningful sounds where required.
• Page layout: allow customers to enlarge text and read content without losing essential information or functionality.

The useful question is not simply whether something is visible on your own screen. It is whether the same information remains available when someone cannot perceive it that way.

Operable: can customers use every control?

Operable means that people can navigate and interact with the site. A checkout button that works with a mouse but cannot be reached with a keyboard presents a barrier, however clear its wording may be.

Try moving through a key page using the keyboard. Can you reach links, menus, filters, form fields, and buttons? Can you tell which element currently has focus? Does the sequence make sense?

Interactive features deserve particular attention. When a dialog opens, keyboard focus should move appropriately into it. Users need a way to close it, and focus should return to a sensible place afterward. A menu must not trap someone who cannot use a mouse.

Time limits also matter. A customer who needs longer to read or enter information should not encounter avoidable barriers from a session that expires without a usable way to respond. The goal is a complete, workable journey—not merely a homepage whose links can be selected.

Understandable: does the site make sense?

Understandable content and interactions help customers predict what will happen and recover when something goes wrong. This principle reaches beyond choosing simpler words.

Imagine a booking form with an unlabeled field and an error message saying only “Invalid.” A customer may not know what information belongs there, which format is accepted, or how to continue. A clear label, relevant instructions, and a specific error message make the task more understandable.

Navigation and controls should also behave consistently. A help link should not unexpectedly become a purchase action on another page. Selecting a field should not trigger an unexpected change that leaves someone unsure where they are.

For important transactions, review how customers check and correct their entries. Clear confirmation and correction steps can help prevent mistakes as well as make the experience more accessible.

Robust: does the meaning reach assistive technology?

Robust content can be interpreted reliably by browsers and assistive technologies. Visual appearance alone does not establish this: a control can look like a button without being communicated as one.

A properly implemented button exposes its name and role. An expandable menu also needs to communicate its state, so a screen reader user can discover whether it is open or closed.

This is why underlying structure matters. Headings should represent the page’s organization, form labels should be associated with their inputs, and changes such as a successful cart update should be available to assistive technology when appropriate.

Using native HTML controls where suitable often provides a stronger starting point than recreating familiar controls from generic elements. Custom interactions still need careful implementation and testing.

What does level AA cover?

WCAG groups its testable requirements, called success criteria, into levels A, AA, and AAA. A target of AA includes the applicable requirements at both A and AA. It does not mean meeting only the AA requirements, and it is not an average score.

At this level, evaluation covers concerns such as text alternatives, keyboard access, contrast, resizing and reflow, labels, errors, and compatibility with assistive technology. These are interconnected: a form may have clear labels but still fail customers if its error feedback is inaccessible.

Some criteria apply only when the relevant content or functionality exists. Video requirements, for example, need to be evaluated in the context of the video you provide. An evaluator should explain applicability, rather than treating every page as an identical checklist.

Meeting a defined standard also does not mean every person will find every interaction effortless. Usability feedback can reveal friction worth addressing beyond the specific barriers recorded in an audit.

What to expect from a WCAG 2.1 AA audit

A useful website accessibility audit connects requirements to reproducible problems and practical fixes. Before commissioning one, agree on its scope: pages, templates, user journeys, interactive states, and any third-party components included.

Ask whether the work includes:

• Automated checks for issues that tools can detect reliably.
• Manual evaluation of keyboard behavior, focus, content meaning, and assistive technology interactions.
• Actionable findings identifying the affected element, the barrier, and the relevant success criterion.
• Retesting to check whether fixes resolve the reported problems.

A homepage scan is a starting point, not evidence about an entire purchase or booking journey. Likewise, a clean automated result cannot establish that all interactions are accessible.

Professional audit services such as geta11y can help identify issues, but the report’s scope and testing methods matter more than a broad assurance. Use WCAG 2.1 AA as a working framework: investigate barriers, fix their causes, verify the changes, and include accessibility checks when your website evolves.