Joe O'Leary
01Projects02Blog03About04Contact

Accessibility

WCAG 2.1 AA Accessibility Checklist

April 12, 2026

8 min read

Most accessibility audits I've seen follow the same pattern: someone runs an automated tool, flags a handful of color contrast issues, and calls it done. That's not accessibility. That's checkbox theater.


Real WCAG 2.1 AA compliance is about designing for the full range of human ability — low vision, motor impairment, cognitive differences, screen reader users. It's one of the most under-invested areas in product design, and also one of the highest-leverage places a senior designer can add value.


After ten years building financial products, healthcare platforms, and consumer apps, here's the checklist I actually use.


1. Perceivable


Users must be able to perceive all content. Nothing should be invisible to their senses.


**Color Contrast**

  • Body text: minimum 4.5:1 contrast ratio against background
  • Large text (18px bold or 24px regular): minimum 3:1
  • UI components (buttons, inputs, focus indicators): minimum 3:1
  • Never use color alone to convey information

    • **Images and Media**

  • Every meaningful image has descriptive alt text
  • Decorative images use alt="" (empty, not missing)
  • Complex images (charts, diagrams) have extended descriptions
  • Videos have captions; audio has transcripts

    • **Text and Sizing**

  • Text can be resized up to 200% without loss of content or functionality
  • No text is baked into images (unless it's a logo)
  • Line height is at least 1.5x font size; paragraph spacing at least 2x font size

    • 2. Operable


    Users must be able to operate the interface — keyboard, voice, switch access, whatever they use.


    **Keyboard Navigation**

  • Every interactive element is reachable by Tab key
  • Focus order follows logical reading order
  • No keyboard traps (user can always Tab out)
  • Skip navigation link at the top of every page

    • **Focus Indicators**

  • Every focused element has a visible focus ring
  • Focus ring meets 3:1 contrast against adjacent colors
  • Never use outline: none without a replacement style
  • Focus indicators are at least 2px thick

    • **Timing**

  • No content auto-advances without warning
  • Users can pause, stop, or hide any moving content
  • Session timeouts give at least 20 seconds warning with option to extend

    • **Touch and Pointer**

  • Touch targets are at least 44x44px (I use 48px minimum)
  • Sufficient spacing between adjacent targets
  • No functionality requires complex gestures without a simpler alternative

    • 3. Understandable


    Interfaces need to make sense. Predictability and error prevention matter enormously.


    **Language and Reading Level**

  • Page language is declared in the HTML lang attribute
  • Unusual words or jargon are defined or explained
  • Abbreviations are expanded on first use

    • **Predictable Behavior**

  • Navigation is consistent across pages
  • Components behave the same way in the same contexts
  • No unexpected context changes on focus or input

    • **Error Handling**

  • Errors are identified in text, not just color
  • Error messages describe what went wrong and how to fix it
  • For important submissions (payments, account changes), users can review before confirming
  • Auto-complete is enabled on standard form fields (name, email, address)

    • **Forms**

  • Every input has a visible, persistent label (not just placeholder text)
  • Labels are programmatically associated via for/id or aria-labelledby
  • Required fields are marked — both visually and programmatically
  • Instructions appear before the field, not after

    • 4. Robust


    Content must work reliably across different browsers, devices, and assistive technologies.


    **Semantic HTML**

  • Use native elements where possible: button, nav, main, header, footer, article
  • Headings follow logical hierarchy: one h1, h2s for sections, h3s for subsections
  • Lists use ul/ol/li, not divs styled to look like lists
  • Tables use th, caption, and scope attributes

    • **ARIA When Necessary**

  • ARIA roles supplement — never replace — semantic HTML
  • aria-label and aria-labelledby are used on elements with no visible text
  • aria-live regions announce dynamic content changes
  • aria-expanded, aria-selected, aria-checked reflect current component state

    • **Interactive Components**

  • Custom components (dropdowns, modals, tabs) implement full keyboard patterns
  • Modal dialogs trap focus while open and return focus on close
  • Comboboxes follow ARIA Authoring Practices patterns

    • 5. Common Patterns Worth Getting Right


    **Images of Text**: If you're rendering text as an SVG or image for visual reasons, provide a text alternative. Exception: logos.


    **Link Text**: "Click here" and "read more" are meaningless out of context. Describe where the link goes. "Read the WCAG 2.1 guidelines" is correct. "Click here" is not.


    **Icon Buttons**: A button that's just an icon needs aria-label. A magnifying glass icon button should have aria-label="Search", not nothing.


    **Placeholder Text**: Placeholder disappears on input. It's not a label. Use both a visible label and placeholder if needed.


    **Disabled States**: Disabled elements are typically excluded from the accessibility tree. If users need to understand why something is disabled, consider using aria-disabled instead, which keeps the element in focus order.


    **Motion**: Respect prefers-reduced-motion. Any animation should pause or simplify when that media query is true.


    6. Testing Stack


    Automated tools catch about 30% of issues. The rest requires human judgment.


  • **axe DevTools** — Browser extension, catches the mechanical stuff
  • **NVDA + Chrome** (Windows) or **VoiceOver + Safari** (Mac/iOS) — Real screen reader testing
  • **Color Contrast Analyzer** — Desktop tool for spot-checking
  • **Keyboard-only navigation** — Unplug the mouse and try to complete core tasks
  • **200% zoom** — Resize the browser and check for overflow or broken layouts

    • The Honest Take


    Accessibility isn't a sprint at the end of a project. It's a design constraint that shapes decisions from the start — color palette, type scale, interaction patterns, component architecture.


    When I'm starting a new project, I establish contrast ratios before I pick brand colors. I define focus styles before I write component CSS. That's the only way to make it stick.


    The spec is dense. But in practice, 80% of issues come from five things: missing alt text, poor color contrast, unlabeled form inputs, no keyboard focus styles, and inaccessible custom components.


    Get those right and you're most of the way there.

    Back to Blog