WCAG 2.1 Level AA in Plain Language
The Web Content Accessibility Guidelines version 2.1 were published by the World Wide Web Consortium in 2018. They build on the 2008 WCAG 2.0 standard and add new criteria addressing mobile accessibility, low vision, and cognitive disabilities.
The guidelines define three conformance levels. Level A is the floor — the minimum requirements without which a page is essentially unusable for some people with disabilities. Level AA adds requirements that address the most common barriers. Level AAA is the ceiling, intended for specialized contexts and not expected of general commercial websites.
When the Department of Justice refers to WCAG in its 2022 web accessibility guidance, it points to Level AA as the relevant benchmark. This is also the level referenced in most demand letters and court cases involving private websites.
The Four Principles (POUR)
Every WCAG criterion belongs to one of four principles. Understanding the principles helps make sense of individual requirements:
Perceivable
Information and interface components must be presentable to users in ways they can perceive. This covers text alternatives for images, captions for video, and not relying solely on color to convey meaning.
Operable
Interface components and navigation must be operable. Users must be able to navigate entirely by keyboard. Content must not flash in ways that could trigger seizures. Users must have enough time to read and use content.
Understandable
Information and operation must be understandable. This includes identifying the language of a page, making navigation consistent, and helping users avoid and correct errors in forms.
Robust
Content must be robust enough to be interpreted by a wide variety of user agents, including current and future assistive technologies. Proper HTML structure is the foundation of this principle.
Key Level AA Criteria for Small Business Websites
WCAG 2.1 contains 78 success criteria across all levels. At Level AA, the criteria most relevant to typical small business websites include:
- 1.1.1 Non-text Content (A): All images that convey information need text alternatives. Decorative images need empty alt attributes.
- 1.3.1 Info and Relationships (A): Structure conveyed visually — like headings and lists — must also be conveyed through proper HTML markup.
- 1.4.3 Contrast (Minimum) (AA): Text must have a contrast ratio of at least 4.5:1 against its background. Large text (18pt or 14pt bold) requires 3:1.
- 1.4.4 Resize Text (AA): Text must be resizable up to 200% without loss of content or functionality.
- 2.1.1 Keyboard (A): All functionality must be operable via keyboard without requiring specific timing for keystrokes.
- 2.4.3 Focus Order (A): When navigating sequentially, focus must move in a logical order that preserves meaning.
- 3.3.1 Error Identification (A): When a form error is detected, the item in error must be identified and described in text.
WCAG 2.2 was published in October 2023 and adds nine new success criteria. Courts and the DOJ have not yet widely adopted it as the reference standard, but it's worth understanding as the landscape evolves.
Running a Free Accessibility Audit
A free automated audit is a reasonable first step. It won't catch everything, but it will surface the most obvious technical issues and give you a structured list to work from.
Step-by-Step: Using WAVE
- Go to wave.webaim.org or install the WAVE browser extension from the Chrome or Firefox extension store.
- Navigate to any page on your website.
- Click the WAVE extension icon. The tool will overlay icons on your page — red for errors, orange for contrast errors, yellow for alerts, green for structural elements.
- Click any icon to see what it means and where in the page code the issue originates.
- Use the Details panel on the left to see a full list of all issues found on the page.
- Repeat for each key page: homepage, contact page, any page with a form, and any page with images or video.
What Automated Tools Can and Cannot Catch
Automated tools are reliable for detecting missing alt text, missing form labels, insufficient color contrast, missing page language declarations, and empty heading elements. These are the issues most tools flag.
They cannot reliably evaluate whether alt text is meaningful (only that it exists), whether the reading order makes logical sense, whether a form's error messages are helpful, or whether a site is navigable by keyboard in practice. Those require manual testing.
Basic Keyboard Testing
Open your website. Put your mouse aside. Use the Tab key to move through the page. Every link, button, and form field should receive visible focus in a logical order. Press Enter to activate links and buttons. Press Space to activate buttons and checkboxes. If you reach a point where focus disappears or becomes trapped, that's a keyboard accessibility failure.
Screen reader testing is the most accurate way to understand what a user with visual impairment experiences. NVDA is free for Windows. VoiceOver is built into macOS and iOS. Learning to use either for even 15 minutes reveals issues no automated tool will catch.
Common Violations and How to Fix Them Without a Developer
Missing or Poor Alt Text
What it is: Screen readers announce images by reading their alt attribute. An image with no alt attribute causes the screen reader to announce the filename — often something like "IMG_4829.jpg" — which conveys nothing. An image with alt="" is treated as decorative and skipped.
How to fix it in most CMS platforms: In WordPress, click on any image in the Media Library and find the "Alternative Text" field. Write a concise description of what the image shows and why it's relevant. In Squarespace, click an image block and look for the Image Settings panel. In Wix, right-click an image and select "Settings" to find the alt text field.
What good alt text looks like: "Storefront of Green Valley Hardware on Main Street, Atlanta" is better than "hardware store" or "image." Describe what's actually in the image, not just its category.
Insufficient Color Contrast
What it is: WCAG 1.4.3 requires that normal-sized text have a contrast ratio of at least 4.5:1 against its background. Light gray text (#999) on white (#fff) has a ratio of roughly 2.85:1 — a common failure. Users with low vision, color blindness, or those viewing screens in bright light are affected.
How to check it: Use the WebAIM Contrast Checker at webaim.org/resources/contrastchecker. Enter your text color and background color as hex codes. The tool tells you whether you pass at AA and AAA levels.
How to fix it: In most website builders, you can change text and background colors through the design or style settings without touching code. Darken text colors or lighten/darken backgrounds until the ratio reaches 4.5:1. Avoid using color alone to convey meaning — a red error message should also have an icon or text label.
Unlabeled Form Fields
What it is: Every form input needs a visible label that is programmatically associated with it. Placeholder text — the gray text inside an empty field — is not a label. It disappears when the user starts typing, leaving people with memory or cognitive disabilities without a reminder of what the field requires.
How to fix it: In WordPress form plugins like Gravity Forms, WPForms, or Contact Form 7, each field has a label setting — make sure it's visible and not hidden. In Squarespace's form block, labels are shown by default. Don't override this to hide them for visual reasons. If your theme hides labels, look for a "show labels" toggle in the form settings.
Video Without Captions
What it is: WCAG 1.2.2 requires captions for all prerecorded video with audio. This applies to promotional videos, product demos, and any other video content on your site.
How to fix it: YouTube's auto-generated captions are a starting point but often contain errors — especially with proper nouns, technical terms, and accented speech. Edit the auto-captions in YouTube Studio before publishing. For videos hosted elsewhere, most platforms support uploading a .vtt or .srt caption file. Several free tools, including YouTube's own editor and the open-source Subtitle Edit, can help create or clean up captions.
Non-Descriptive Link Text
What it is: Screen reader users often navigate by pulling up a list of all links on a page. Links labeled "click here," "read more," or "learn more" are meaningless out of context. WCAG 2.4.4 requires that link purpose be determinable from the link text alone or from its surrounding context.
How to fix it: Change "click here" to something like "Download our accessibility checklist" or "Read our guide to color contrast." In your CMS, this is usually as simple as editing the hyperlinked text. No code required.
Legal Risks: What Court Cases Show
The Statutory Basis
Title III of the Americans with Disabilities Act prohibits discrimination on the basis of disability in places of public accommodation. The statute was enacted in 1990, before the commercial internet existed. Whether websites are "places of public accommodation" under Title III has been litigated in federal courts for over a decade.
Notable Cases in Public Record
Robles v. Domino's Pizza (9th Cir. 2019): The Ninth Circuit ruled that the ADA applies to Domino's website and mobile app because they have a sufficient nexus to the company's physical restaurant locations. The court noted that WCAG could serve as a technical standard for compliance. The Supreme Court declined to hear the case in 2019.
Gil v. Winn-Dixie (11th Cir. 2021): The Eleventh Circuit ruled in favor of Winn-Dixie, finding that the website was not a place of public accommodation under Title III because it was not a physical location. This created a circuit split with the Ninth Circuit's position.
Acheson Hotels, LLC v. Laufer (Supreme Court 2023): The Supreme Court addressed standing questions in ADA cases involving "tester" plaintiffs — individuals who visit websites to look for ADA violations without necessarily intending to use the services. The Court's ruling on standing has implications for who can bring ADA website cases.
The Demand Letter Pattern
Many small business owners first encounter this issue not through a lawsuit but through a demand letter. These letters are typically sent by plaintiffs' attorneys and allege specific accessibility barriers on a website. They request either remediation or a settlement payment.
Receiving a demand letter is not the same as being sued. How to respond appropriately is a question for an attorney. What's useful to understand from an informational standpoint is that demand letters tend to cite specific WCAG criteria and specific pages — suggesting the sender has conducted at least a basic automated audit of the site.
The DOJ issued guidance in March 2022 stating that web accessibility is required under the ADA and that WCAG 2.1 Level AA is an appropriate technical standard. This guidance does not carry the force of a formal regulation but signals the federal government's interpretive position.
Accessibility Overlay Widgets: A Balanced View
Accessibility overlay widgets are third-party JavaScript tools that insert a floating button on a website. When clicked, the button opens a panel with options like larger text, high contrast mode, or simplified layout. The marketing for these products often claims they bring a site into ADA compliance automatically.
What Overlays Can Reasonably Do
User-preference controls — font size, contrast, animation reduction — are genuinely useful for some users. Providing these controls is a reasonable accommodation and some users do find them helpful. Overlays that focus on giving users interface preferences rather than claiming to fix underlying code are more defensible.
What Overlays Cannot Do
An overlay cannot reliably generate accurate alt text for images. It cannot fix broken keyboard navigation — if a custom dropdown menu traps keyboard focus, an overlay cannot resolve that without changing the underlying code. It cannot correct the heading structure of a page or fix form labels that were never programmatically associated with their inputs.
Documented Problems with Overlays
The Overlay Fact Sheet, signed by hundreds of accessibility practitioners and disability advocates, documents specific cases where overlay tools interfered with assistive technology. Screen readers like JAWS and NVDA can conflict with overlay JavaScript in ways that make the page harder to use — not easier. Several disabled users have publicly described being blocked from accessing sites that use overlays.
The Legal Defense Question
Courts have not accepted the presence of an overlay as a defense against ADA claims. In documented cases, plaintiffs have successfully argued that an overlay did not remove the barriers they encountered. Installing an overlay does not, based on available case records, substitute for addressing underlying accessibility issues.
A Reasonable Approach
If you're considering an overlay, understand it as a potential supplement to accessibility work — not a replacement for it. User preference controls can be a thoughtful addition to a site that is otherwise working toward genuine accessibility. They are not a shortcut around that work.
The Overlay Fact Sheet at overlayfactsheet.com is a publicly available resource signed by accessibility practitioners, researchers, and disabled users. It documents specific cases where overlays have caused harm and explains the technical reasons why automated fixes have inherent limits.
The most durable accessibility improvements are made at the source — in the HTML, CSS, and content of the page itself. These fixes don't conflict with assistive technology because they work with it rather than trying to override it.