WCAG 2.1 AA Requirements: What Small Business Owners Need to Know

If you've been researching ADA website compliance, you've almost certainly encountered the acronym WCAG. It appears in legal documents, accessibility audits, compliance tools, and developer guides — and it can feel intimidating if you're not a technical person.

Here's the plain-English version: WCAG is the rulebook for web accessibility. Understanding it doesn't require a computer science degree. And knowing the key requirements will help you make smarter decisions about your website, your vendor choices, and your legal risk.

What Is WCAG?

WCAG stands for the Web Content Accessibility Guidelines. It's a set of technical standards developed and maintained by the World Wide Web Consortium (W3C) — the international body that sets standards for the web.

WCAG is organized into three levels of conformance:

• Level A — The minimum. Failing these criteria creates severe barriers for many users.
• Level AA — The standard. This is the level required for practical accessibility and legal compliance in the United States.
• Level AAA — The most stringent. Not required or expected for most websites.

When people talk about "WCAG compliance" for ADA purposes, they mean WCAG 2.1 Level AA. In 2024, the U.S. Department of Justice formally adopted WCAG 2.1 Level AA as the standard for ADA web accessibility, ending years of legal ambiguity.

The current version, WCAG 2.2, was published in 2023 and adds nine new criteria to 2.1. Courts and regulators are still predominantly referencing 2.1 AA, but meeting 2.2 AA is increasingly considered best practice.

The Four Principles: POUR

Everything in WCAG 2.1 is organized around four core principles. Together, they form the acronym POUR:

1. Perceivable

Users must be able to perceive all information and interface components. In other words: if your page has content, every user needs to be able to access it in some form.

For small businesses, this primarily means:

• Alt text on images — Screen readers need text descriptions to communicate visual content to blind users.
• Captions on videos — Deaf and hard-of-hearing users need text versions of audio content.
• Sufficient color contrast — Text must be readable against its background for users with low vision.
• Text isn't the only way information is conveyed — If you use color alone to indicate something ("required fields are shown in red"), users who are colorblind won't get that information.

The most commonly missed: Color contrast failures. Many small business websites use light gray text on white backgrounds or colored text that fails contrast requirements. Run a contrast check on your primary text colors.

2. Operable

Users must be able to operate the interface. Not everyone uses a mouse — many users with motor disabilities navigate entirely by keyboard, or use switch controls, eye-tracking software, or voice input.

For small businesses, this primarily means:

• Full keyboard accessibility — Every link, button, form field, and interactive element must be reachable and usable without a mouse.
• Visible focus indicators — When a keyboard user tabs to an element, there must be a visible indicator showing which element is selected. CSS that removes focus outlines ("outline: none") breaks this.
• No keyboard traps — If a user navigates into an element (like a modal dialog), they must be able to navigate out of it using the keyboard.
• No seizure-triggering content — Content that flashes more than three times per second can trigger seizures in some users. This also applies to flashing animations.
• Enough time — If your site uses timed sessions or auto-updating content, users need the ability to pause, extend, or disable the timing.

The most commonly missed: Removing focus styles. Developers often remove the default browser focus outline because it "looks bad." This is a serious accessibility failure that makes keyboard navigation nearly impossible to follow.

3. Understandable

Users must be able to understand the content and how the interface works. Accessibility isn't just about whether someone can physically access your content — it's also about whether they can comprehend it and complete tasks successfully.

For small businesses, this primarily means:

• Page language declared — Your HTML should specify the language of the page. Screen readers use this to apply the correct pronunciation rules.
• Consistent navigation — Navigation menus, headers, and footers should be consistent across pages so users can predict where things are.
• Descriptive labels and instructions — Form fields need real labels (not just placeholder text). Error messages need to explain what went wrong and how to fix it.
• Error prevention on important forms — For legal commitments, financial transactions, and data submissions, users should be able to review, correct, and confirm before finalizing.

The most commonly missed: Form label errors. Using placeholder text ("Enter your email address") instead of a proper label element is extremely common and is cited in a large percentage of ADA demand letters. When the placeholder disappears as soon as the user starts typing, they lose context — and screen readers often can't identify the field at all.

4. Robust

Content must be interpreted reliably by a wide range of current and future user agents, including assistive technologies.

In practical terms, this means your website's code needs to be clean and standards-compliant. Sloppy HTML — duplicate ID attributes, improperly nested elements, deprecated attributes — can cause unpredictable behavior with screen readers and other assistive technologies.

For small businesses, this primarily means:

• Valid HTML structure — Proper use of semantic elements (headings, lists, landmarks)
• Unique ID attributes — Duplicate IDs cause unpredictable behavior in assistive technology
• ARIA used correctly — ARIA attributes (used to add accessibility information to interactive elements) help when used correctly but cause serious problems when misused

The most commonly missed: Improper use of ARIA. Many developers add ARIA attributes to "fix" accessibility issues without understanding that ARIA has specific rules. ARIA used incorrectly can make a page less accessible than no ARIA at all. The rule of thumb: use native HTML elements before reaching for ARIA.

The 10 WCAG 2.1 AA Criteria That Matter Most for Small Businesses

You don't need to audit all 50 criteria from scratch. These ten cover the vast majority of issues found on typical small business websites:

• 1.1.1 Non-text Content — Alt text on all images (for screen reader users)
• 1.4.3 Contrast (Minimum) — 4.5:1 contrast ratio for text (for low vision users)
• 1.4.4 Resize Text — Text resizable to 200% without loss (for low vision users)
• 2.1.1 Keyboard — All functionality available by keyboard (for motor disability users)
• 2.4.3 Focus Order — Logical keyboard focus sequence (for keyboard users)
• 2.4.7 Focus Visible — Keyboard focus must be visible (for keyboard users)
• 3.1.1 Language of Page — HTML language declared (for screen reader users)
• 3.3.1 Error Identification — Form errors described in text (for all users)
• 3.3.2 Labels or Instructions — Form fields have visible labels (for all users, especially screen reader users)
• 4.1.1 Parsing — Valid, non-duplicate HTML (for assistive technology compatibility)

Does WCAG Apply to My Whole Website?

Yes — every publicly accessible page on your website should conform to WCAG 2.1 Level AA. This includes:

• Your homepage
• Product and service pages
• Contact forms and booking systems
• Checkout and payment pages
• Blog and content pages
• PDFs, downloadable documents, and linked files

The pages most likely to generate legal complaints are transactional pages — places where users are trying to complete a task and find they can't. A checkout page with inaccessible form fields is a more serious compliance gap than an inaccessible blog post, even though both technically violate WCAG.

How Much Does WCAG Compliance Cost?

This question has a wide range of honest answers:

For a simple small business website (under 20 pages, basic forms, no e-commerce): most developers can address the common WCAG 2.1 AA failures in 4 to 8 hours of work, which at typical developer rates is $400 to $1,200.

For a mid-complexity site (50+ pages, e-commerce, booking systems, custom JavaScript): a thorough remediation might take 20 to 40 hours, or $2,000 to $5,000.

For ongoing compliance (making sure new content and updates stay accessible): a modest ongoing process — including periodic scans and developer review — adds a few hours per month.

Compare this to the cost of an ADA lawsuit settlement: $5,000 to $75,000 in damages, plus $10,000 to $50,000 in plaintiff attorney fees. Proactive compliance costs a small fraction of reactive damage control.

How to Check Your Website Against WCAG 2.1

You have a few options, depending on how deep you want to go:

Automated scanning (fastest, free, good starting point):

Tools like CheckMyADA scan your website against WCAG 2.1 Level AA criteria and return a report of detected issues. Automated tools catch roughly 30–40% of potential issues — mainly the structural and code-level problems like missing alt text, contrast failures, and missing form labels.

Manual testing (thorough, requires expertise):

A human accessibility tester navigates your site using screen readers (NVDA, JAWS, VoiceOver) and keyboard-only navigation to identify issues automated tools miss — confusing user flows, context-dependent problems, and cognitive barriers.

For most small businesses: Start with an automated scan. It will identify your most critical and most common issues. Fix those. Then decide if the complexity of your site warrants a professional manual audit.

Scan your website for WCAG compliance issues — free →

A Note on "Compliance" Claims

Be skeptical of any tool that claims to make your website "WCAG compliant" or "ADA compliant" automatically. No automated tool — including CheckMyADA — can guarantee full compliance, because:

• Automated tools only detect 30–40% of WCAG criteria
• WCAG has criteria that require human judgment to evaluate
• "Compliance" is determined by a court or resolution agreement, not a software score

What a good tool can do is give you accurate, honest information about the detectable issues on your website and help you prioritize your remediation work. That's meaningful progress, and it reduces your risk — but it's not a compliance certificate.

The Bottom Line

WCAG 2.1 Level AA isn't an obscure technical standard for enterprise software teams. It's the rulebook that determines whether your website is usable for the 26% of Americans with disabilities — and whether you're exposed to legal action if it isn't.

The four POUR principles give you a framework for thinking about accessibility that goes beyond checklists. The ten high-priority criteria give you a starting point for action. And an automated scan gives you the specific evidence you need to have a productive conversation with your developer.

Start there. Understand where you stand. Then take it one step at a time.

Check your website for WCAG compliance issues at CheckMyADA — free →

---

Related reading: ADA Compliance for Small Business: Complete 2026 Guide | Free Website Accessibility Audit: What It Can (and Can't) Tell You

External resources: W3C: Introduction to WCAG 2.1 | DOJ Final Rule on Web Accessibility (2024)