The Essential WCAG 2.1 AA Compliance Checklist for Web Developers

The Web Content Accessibility Guidelines (WCAG) 2.1 Level AA is the global benchmark we all work to. It’s the standard. The U.S. Department of Justice (DOJ) demands it, federal courts enforce it under Title III of the Americans with Disabilities Act (ADA), federal procurement requires it via Section 508, and the European Accessibility Act (EAA) keeps it on the books...

Getting your web app to meet WCAG 2.1 AA means you have to pay attention to HTML semantics, design tokens, responsive layouts, and how interactive keyboard states behave!

Below is an engineering checklist organized across the four core principles of accessible design: Perceivable, Operable, Understandable, and Robust (POUR).

---

1. Perceivable – Make Sure Everyone Can Get the Info

You’ve got to present stuff in a way that all of your visitors can actually notice it; if it’s invisible to a sense, it’s basically missing.

1.1.1 Non-Text Content (Level A)

• Rule: Every informative image, diagram, and icon needs an alt attribute that tells its main point.
• Implementation:
  • Informative images: <img src="chart.png" alt="Quarterly revenue growth showing a 22% increase in Q4" />
  • Decorative graphics: give them an empty alt="" or add aria-hidden="true" so screen readers just skip them.
  • Complex charts: pair the picture with a data table or a short text summary.

1.3.1 Info and Relationships (Level A)

• Rule: The way you structure info and visual relationships has to be readable by assistive tech.
• Implementation:
  • Use real HTML headings (<h1>-<h6>) in the right order; don’t jump levels just because you like the look.
  • Use native list tags (<ul>, <ol>, <dl>) for any grouped items.
  • Lay out the page with semantic landmarks (<header>, <nav>, <main>, <aside>, <footer>).

1.4.3 Contrast Minimum (Level AA)

• Rule: Text needs enough contrast against its background.
• Benchmarks:
  • Standard Text (under 18 pt or under 14 pt bold): at least 4.5:1 contrast.
  • Large Text (18 pt+ or 14 pt bold+): at least 3:1 contrast.
  • Interactive Controls & Borders: form borders and active UI icons also need 3:1 or higher.

1.4.10 Reflow (Level AA)

• Rule: Your content has to reflow cleanly down to a width of 320 CSS pixels without forcing users into horizontal scrolling.
• Implementation:
  • Build with responsive CSS (flexbox, grid, clamp()) and steer clear of fixed-pixel widths on containers.

That’s it. Pretty simple, right?

2. Operable: User Interface Components Must Be Operable

You know what really bugs me? Here’s the core idea. Users have to actually use the interface. If navigation or interactions depend on actions a person can't perform, you’ve got a problem. The interface needs to work for everyone, including those who can’t click.

2.1.1 Keyboard Accessible (Level A)

• Rule: All functionality must be operable via a standard keyboard interface without requiring specific timings for individual keystrokes.
• Implementation:
  • Buttons, links, dropdowns, tab panels, and modal dialogs must respond to Tab, Shift+Tab, Enter, and Space.
  • Never replace native <button> or <a> tags with generic <div onClick="..."> without adding keyboard listeners and ARIA roles.

2.1.2 No Keyboard Trap (Level A)

• Rule: If keyboard focus can be moved to a component, focus must be able to leave that component using standard keystrokes.
• Implementation: In modal dialogs, make sure pressing Escape dismisses the overlay and immediately restores focus to the triggering element.

2.4.1 Bypass Blocks / Skip Links (Level A)

• Rule: A mechanism must be available to bypass blocks of content that are repeated on multiple web pages.
• Implementation: Include a hidden "Skip to main content" link as the first focusable child of the <body> element.

2.4.7 Focus Visible (Level AA)

• Rule: Any keyboard-operable interface must display an unambiguous, high-contrast visual focus indicator.

• Implementation: Never declare outline: none without providing a high-visibility replacement using :focus-visible:

  :focus-visible {
    outline: 2px solid var(--primary-color, #2563eb);
    outline-offset: 2px;
  }
  

3. Understandable: Keeping It Predictable

In plain English, people need to get the content and figure out how to use the interface without guessing.

3.1.1 Language of Page (Level A)

• Rule: Each web page's default human language has to be programmatically determinable.
• Implementation: Always set the valid language attribute on the root HTML tag, like <html lang="en">.

3.3.1 Error Identification & 3.3.2 Labels (Level A)

• Rule: Form fields need explicit labels, and validation errors must be clearly identified and described in text.
• Implementation:
  • Always link inputs to labels with matching attributes, so use <label for="user-email"> and <input id="user-email">.
  • If validation fails, associate error copy using aria-describedby="error-msg-id" and flag aria-invalid="true".
  • Never rely solely on color, like a red border, to communicate an error state.

---

4. Robust: Make Your Content Play Nice With Assistive Tech

Honestly, your pages need to be solid enough that every assistive gadget out there – screen readers, voice browsers, braille displays – can get the right info without guessing, and that’s what “robust” really means.

4.1.2 Name, Role, Value (Level A)

• Rule: Every UI component has to expose its accessible name, role, and current state in code.
• Implementation:
  • If you build a custom button or modal, give it a proper WAI-ARIA role like role="dialog" or role="combobox".
  • Make sure dynamic states are visible too, for example aria-expanded="true" or aria-checked="false".

4.1.3 Status Messages (Level AA)

• Rule: Live alerts and toast messages must reach assistive tech without stealing focus.
• Implementation: Wrap those notifications in an element with aria-live="polite" so screen readers announce them after they finish what they’re reading.

That's it. Pretty simple, right?

Getting Automation into Your Workflow

Manual testing alone won't scale if your product team is moving fast. You need to catch problems before they ship. That means adding automated scanning to your build process.

Tools like axe-core are the standard way to do this. Funny enough, they flag a bunch of common issues right there in the pipeline. But here's the thing: automation isn't magic. Deque estimates these tests find about 57% of issues by volume.

So keep a short manual check in the mix.

The truth is, you can't just rely on the bot. Pair it with regular keyboard reviews. That's how you get durable, defensible compliance. It's a two-part job. Accessibility Shield handles the continuous WCAG 2.1 AA audits for you, running them on your domain for just $1/month ($12/year)!

---

Want to see where your site stands? Run a free accessibility scan, then publish a hosted accessibility statement so visitors know how to reach you.