The Web Content Accessibility Guidelines (WCAG) 2.1 Level AA is the practical standard your small business website needs to meet to be considered accessible — about fifty specific success criteria covering how a site looks, behaves, and reads to people with disabilities. This is the plain-English checklist of what those criteria actually mean for an SMB website, in the order they tend to come up.

I'm David Campbell, founder of Nerd Stack. This guide is a practical companion to our ADA compliance overview — that piece covers the legal picture, this one covers the technical work. If you're worried about a demand letter, our guide to ADA website lawsuit risk covers exposure and response. The list below isn't every WCAG criterion — it's the AA items that come up first for ordinary business websites.

How to Use This Checklist

WCAG 2.1 organizes accessibility into four principles: Perceivable, Operable, Understandable, Robust ("POUR"). For an SMB site, the practical work clusters into six areas:

  1. Color and contrast
  2. Text alternatives (alt text, captions, transcripts)
  3. Keyboard navigation
  4. Semantic HTML and screen-reader experience
  5. Forms
  6. Motion and timing

Work through each one. Most accessibility problems are concentrated in a handful of the same offenders — fixing those gets you most of the way.

1. Color and Contrast

  • Text contrast ratio of at least 4.5:1 against its background for normal text (3:1 for large text). Most "elegant" light-gray text on white fails this badly.
  • Non-text contrast of at least 3:1 for UI components — buttons, form fields, focus indicators, icons that convey meaning.
  • Color isn't the only signal. An error state colored red but not labeled "error" excludes anyone who can't see red. Pair color with a label or icon.
  • Check every state. Default, hover, focus, active, disabled — each must meet contrast independently.

2. Text Alternatives

  • Alt text on meaningful images. Describe what the image conveys, not just what it shows. A product photo: "Black leather tote bag with brass hardware." A decorative flourish: empty alt (alt="") so screen readers skip it.
  • No alt text on purely decorative images. Empty alt is the correct value, not a missing attribute.
  • Captions and transcripts on prerecorded video. For live video, captions where feasible. Audio-only content needs a transcript.
  • Icons with no visible label need an accessible name (an aria-label or visually-hidden text).

3. Keyboard Navigation

  • Every interactive element is reachable by Tab, in a logical order. No keyboard traps — Tab should always escape a component.
  • Focus is visible. The browser default focus ring is fine; what isn't fine is suppressing it (outline: none) without a clear replacement.
  • Custom widgets behave like their HTML equivalents. A custom dropdown should respond to arrow keys; a custom checkbox to space; a custom button to Enter and space.
  • "Skip to main content" link at the top of each page, visible on focus, so keyboard users can bypass the navigation.

4. Semantic HTML and Screen Readers

  • One H1 per page, then ordered H2/H3. Headings are how screen-reader users navigate.
  • Use the right HTML element. A <button> for buttons, an <a> for links, <nav> / <main> / <footer> as landmarks. Don't reach for <div> with click handlers when a real element exists.
  • Page language declared with <html lang="en">. It's one line and screen readers need it to pick the right pronunciation.
  • ARIA only when HTML can't do it. The first rule of ARIA is don't use ARIA. Most "ARIA fixes" are someone reaching for ARIA when the correct HTML element would have solved the problem.

5. Forms

  • Every input has a real <label> linked by for/id. A placeholder is not a label.
  • Errors are announced clearly — not just colored red, but labeled and ideally announced to assistive tech (an aria-live region for dynamic errors).
  • Required fields are marked with the required attribute and indicated visually (an asterisk is fine if explained).
  • Sensible input types — type="email", type="tel", type="date" — so mobile keyboards adapt and validation is built in.

6. Motion and Timing

  • Auto-playing carousels and animations need a pause control. Auto-advancing slideshows are one of the most common AA violations on SMB sites.
  • Respect prefers-reduced-motion in CSS so users who set that system preference don't get aggressive animations.
  • Don't time out users mid-task on forms or carts without warning, and provide a way to extend the time.
  • Nothing flashes more than three times per second. Flashing content can trigger seizures — this one is non-negotiable.

How to Test What You've Built

Automated tools catch about 30–40% of accessibility issues. They're a starting point, not a finish line. The realistic testing stack:

  • axe DevTools (browser extension) — the best free automated checker.
  • WAVE (WebAIM) — a different, complementary perspective on the same automated checks.
  • Lighthouse (built into Chrome DevTools) — for a quick accessibility score alongside performance.
  • Keyboard-only navigation. Unplug your mouse. Tab through the site. If you can't complete the journey, neither can a keyboard user.
  • A real screen reader. VoiceOver is built into Mac; NVDA is free on Windows. Listen to your homepage for two minutes — you'll learn more than from any tool.

Platform-Specific Pitfalls

Some platforms have systemic accessibility problems baked into their default themes:

  • Shopify themes vary wildly — many popular themes ship with contrast and keyboard-navigation issues that require theme-level fixes, not theme settings. When we worked with a major Shopify e-commerce client on accessibility, the centerpiece of the work was overhauling the theme onto a properly accessible foundation, paired with visual accessibility work — the kind of platform-level engineering an overlay widget cannot do.
  • WordPress themes are similar: quality varies dramatically by theme, and page builders like Elementor and Divi can produce inaccessible markup unless used carefully.
  • SaaS site builders (Squarespace, Wix) ship reasonable defaults but limit how deeply you can fix what's broken. For accessibility-critical businesses, the platform itself can be the ceiling.

Frequently Asked Questions

What is WCAG 2.1 Level AA?

WCAG 2.1 Level AA is the Web Content Accessibility Guidelines 2.1 at the AA conformance level — the practical standard the DOJ, courts, and plaintiffs' counsel apply to commercial websites in the U.S. It's about fifty specific success criteria covering color, alternatives, keyboard navigation, semantics, forms, and motion.

How do I test my website for accessibility?

Start with axe DevTools and WAVE, which catch the most common automated issues. Then go beyond automation: navigate your site with just a keyboard, and listen to a page with a real screen reader (VoiceOver on Mac, NVDA on Windows). Automated tools catch roughly 30–40% of issues; the rest needs manual testing.

Do I need to fix every accessibility issue at once?

No — fix in order of impact. The most-violated criteria (color contrast, missing alt text, unlabeled form fields, missing keyboard navigation) cause the most disruption to disabled users and trigger the most lawsuits. Address those first; tighter compliance follows.

Will an accessibility overlay widget make my site WCAG compliant?

No. Overlay widgets — small JavaScript snippets that promise instant compliance — do not address the underlying HTML and CSS issues WCAG describes. They have been broadly discredited and have not protected businesses from lawsuits. Real compliance requires fixing the underlying site.

How much does WCAG compliance work cost?

It depends on the size of the site and how far the current build is from AA. For a typical SMB site, expect a focused accessibility remediation to run in the same range as a substantive redesign segment. Our pricing guide covers the broader picture.

Bottom Line

WCAG 2.1 AA is detailed but not mysterious — it's the same web craft a well-built site does anyway, with a layer of intentional accessibility on top. Most violations cluster in a handful of areas: contrast, alt text, keyboard navigation, form labels, and motion. Work through them in order, test with both tools and a real keyboard and screen reader, and don't trust an overlay widget to do work that the underlying site has to do.

If you'd like accessibility work built in from the start — or your existing site brought into AA territory — that's part of what we do at Nerd Stack. See our website redesign service or book a free call.

Sources: W3C Web Accessibility Initiative — WCAG Standards; ADA.gov — Fact Sheet on Web Rule (Title II).