WCAG 2.1 AA Accessibility Checklist: Complete Implementation Guide

WCAG 2.1 Level AA compliance requires addressing 50 testable criteria across four categories: perceivable (content is visible and understandable), operable (users can navigate with keyboard and assistive technology), understandable (clear language and predictable interaction patterns), and robust (compatible with all browsers and assistive technology). This checklist breaks down every requirement you need to audit and document.

WCAG 2.1 AA has become the de facto standard for enterprise accessibility. Government procurement requires it. Courts use it as the standard for ADA compliance. Enterprise B2B buyers request attestation. If you're building platforms at scale, WCAG 2.1 AA isn't optional—it's the entry requirement for serious business.

The standard covers 50 criteria, each with specific testing procedures. Many are straightforward (images need alt text). Some require deeper technical understanding (color contrast math, semantic HTML patterns, ARIA state management). This checklist walks through every requirement organized by the four foundational principles: Perceivable, Operable, Understandable, and Robust (POUR).

Bemeir's accessibility remediation process uses this exact checklist. We've applied it to eCommerce platforms handling millions of users, B2B software serving enterprise teams, and government-adjacent applications requiring ADA compliance. The outcomes are consistent: systematic application of this checklist eliminates 95 percent of accessibility barriers.

Perceivable: Users Can See and Understand Content

Content must be presented so users can perceive it, regardless of sensory capability. This means providing alternative representations of visual and audio information.

Text Alternatives for Non-Text Content (1.1.1)

• All images have descriptive alt text. Alt text describes the image purpose, not just "image" or "photo"
• Decorative images have empty alt attributes (alt="") so screen readers skip them
• Background images don't convey essential information, or equivalent text is provided adjacent to the image
• Icons without text labels have aria-labels or nearby text describing their purpose
• Complex diagrams and charts have text descriptions or links to detailed explanations
• Maps and visualizations have text alternatives explaining key data
• Graphs and charts include data tables or detailed text summaries
• Infographics don't rely solely on image—key information is available as text

Audio and Video (1.2.1 – 1.2.5)

• Pre-recorded video has captions for all speech and sound effects essential to understanding
• Pre-recorded audio has transcripts available
• Live video has real-time captions (CART or automated)
• Audio descriptions are provided for important visual information in video
• Controls for audio/video players are keyboard accessible and labeled

Adaptable Content (1.3.1 – 1.3.6)

• Content uses semantic HTML (proper heading hierarchy, lists marked as lists, tables marked as tables)
• Heading order is logical and sequential (no skipping h2 to h4)
• Reading order in markup matches visual order on screen
• Data tables have row and column headers marked with th elements
• Table headers are associated with data cells programmatically
• Form labels are associated with input fields (label with for attribute or fieldset)
• Instructions don't rely on visual characteristics alone (e.g., "click the red button" also uses text label)
• Relationships and sequences in content are conveyed through markup, not visual formatting

Distinguishable: Foreground Separates from Background (1.4.1 – 1.4.11)

• Text color contrast is at least 4.5:1 against background for normal text
• Large text (18pt or larger) has contrast of at least 3:1
• UI components and borders have at least 3:1 contrast against adjacent colors
• No information is conveyed using color alone (use icons, patterns, or text)
• Text can be resized to 200 percent without loss of functionality or readability
• Avoid blocks of all-caps text (use standard capitalization)
• Audio tracks don't auto-play or provide controls to mute
• Images of text are avoided unless essential (actual text preferred)
• No hashed or scrambled text presented as images

Operable: Users Can Navigate and Control Interfaces

Your interface must be navigable via keyboard and compatible with assistive technology. Users must have sufficient time to interact.

Keyboard Accessibility (2.1.1 – 2.1.4)

• All functionality is accessible via keyboard (no mouse-only interactions)
• Tab order is logical and follows visual flow (left to right, top to bottom)
• Focus is visible (outline, background color, or clear indicator when tabbing)
• No keyboard traps—users can tab away from any element without getting stuck
• Keyboard shortcuts don't interfere with browser or assistive technology shortcuts
• Single-key shortcuts can be disabled or require modifier keys (to avoid accidental activation)

Enough Time (2.2.1 – 2.2.6)

• Auto-playing content can be paused, stopped, or muted (visible controls)
• Moving, blinking, or scrolling content that lasts more than 5 seconds can be paused
• Time limits on user interactions can be extended (login sessions, form timeouts)
• Notifications about upcoming time limits are provided when possible
• Users can disable animations and transitions (no forced motion)
• No content flashes more than three times per second (seizure risk)

Navigable (2.3.1 – 2.4.8)

• No sequences designed to cause seizures (flashing at frequencies that trigger photosensitive epilepsy)
• Pages have a clear title that describes the page purpose
• Links have descriptive text ("Learn more" is bad; "Learn more about our accessibility process" is good)
• Link purpose is obvious from link text alone or from context
• Multiple ways exist to find pages (navigation, site map, search, internal links)
• Breadcrumbs or equivalent navigation path is provided
• Focus indicators are always visible and clear
• Section headings are used to organize content
• Forms use fieldsets and legends to group related fields
• Purpose of input fields is obvious from labels

Input Modalities (2.5.1 – 2.5.7)

• Touch targets are at least 44×44 CSS pixels in size
• Motion-based controls have keyboard alternatives (don't require shaking or tilting device)
• Gestures that work have single-pointer alternatives (don't require multi-touch)
• Functionality that depends on device orientation works in both portrait and landscape
• Draggable elements have keyboard alternatives
• Target size and spacing accommodate users with motor impairments

Understandable: Users Can Understand Content and Predict Interaction

Information must be presented in language users understand. Interaction patterns must be predictable and consistent.

Readable (3.1.1 – 3.1.5)

• Page language is specified in HTML (lang attribute on html element)
• Language changes are marked (lang attribute on elements with different language)
• Text is written in clear, plain language appropriate for your audience
• Abbreviations and acronyms are defined on first use or in a glossary
• Complex words have definitions or explanations
• Text doesn't require reading level above middle school to understand basic content
• Unusual pronunciations are explained for screen reader users

Predictable (3.2.1 – 3.2.5)

• Navigation elements appear in consistent locations across pages
• Interactive components behave consistently (buttons always look like buttons)
• Unexpected changes don't occur without user action (no automatic redirects or modal dialogs)
• Submitting forms doesn't unexpectedly change context (navigate to error page without warning)
• On-focus events don't cause major layout changes (focus on form field doesn't scroll or shift layout)
• Auto-submit doesn't occur without explicit user action
• User receives warning before deletion or other destructive action

Input Assistance (3.3.1 – 3.3.8)

• Error messages are provided when required fields are empty or invalid input is submitted
• Error messages identify the specific field with the problem
• Suggestions for correcting errors are provided (e.g., "Password must be 8+ characters")
• Required fields are identified before submission (in label or legend)
• Form validation occurs before submission or immediately after
• Submit buttons are clearly labeled with the action they perform
• Sensitive transactions (payments, account deletion) require confirmation
• Legal and financial agreements provide an undo option within reasonable timeframe

Robust: Content Works Across Browsers and Assistive Technology

Content must be robust enough to work with current and future assistive technologies.

Compatible (4.1.1 – 4.1.3)

• HTML is valid (proper opening and closing tags, no duplicate attributes)
• Element IDs are unique (no duplicate IDs on page)
• Role, state, and property attributes are used correctly (ARIA roles are valid)
• ARIA attributes don't conflict with native HTML (don't use role="button" on actual buttons)
• Custom components implement full keyboard support and screen reader compatibility
• Complex interactions expose state changes to assistive technology (ARIA live regions)
• Errors are communicated to screen reader users immediately
• Status messages are announced without taking focus (ARIA live="polite")
• Multi-step processes clearly indicate current step and progress
• Session timeouts are announced with opportunity to extend

Testing by Component Type

Different components require specific accessibility checks. Here's how to test the highest-impact patterns in eCommerce and B2B platforms.

Forms

• Every input has a label associated programmatically (label with for attribute)
• Form grouping uses fieldset and legend for related inputs
• Required fields are marked in HTML and visually
• Error messages are associated with the problematic field (aria-describedby)
• Date inputs accept multiple formats (MM/DD/YYYY and without separators)
• Autocomplete works with screen readers and password managers
• CAPTCHA has alternatives (question-based verification, audio CAPTCHA)

Navigation and Menus

• Primary navigation is keyboard accessible
• Submenu items are keyboard accessible and don't open on hover alone
• Mobile menu button is clearly labeled and keyboard accessible
• Mobile menu can be closed by pressing Escape key
• Navigation landmark is marked with nav element or role="navigation"
• Skip links exist to jump over repetitive content (skip to main content)

Data Tables

• Table has a caption or title describing its contents
• Row and column headers are marked with th elements
• Table headers are associated with data cells (scope attribute or id/headers)
• Table structure is not created with divs—use actual table elements
• Complex multi-level headers use scope="colgroup" or scope="rowgroup"

Images and Icons

• All meaningful images have alt text describing content or function
• Alt text is concise (under 125 characters in most cases)
• Decorative images have empty alt (alt="")
• Icon-only buttons have aria-label or adjacent visible text
• Complex images (charts, diagrams) have detailed text alternatives
• SVG icons have proper aria-hidden or aria-label treatment

Modals and Dialogs

• Modal backdrop is present (prevents interaction with background content)
• Focus moves into modal when it opens
• Modal can be closed by Escape key or close button
• Focus returns to triggering element when modal closes
• Modal is announced as dialog with aria-modal="true"
• Modal title is marked with aria-labelledby

Dynamic Content and Updates

• Content updates are announced to screen readers (ARIA live regions)
• Live regions use appropriate politeness level (polite or assertive)
• Loading states are communicated (spinner with aria-label or status message)
• AJAX requests load new content with focus management or announcement
• Infinite scroll doesn't prevent access to footer or alternative pagination
• Asynchronous search results are announced and focusable

Validation and Testing Workflow

Use this workflow to validate WCAG compliance systematically.

Automated Scanning

• Run axe, WAVE, or Lighthouse accessibility audit on every page type
• Configure tools to scan for common WCAG failures
• Generate report identifying issues by severity
• Address critical and major issues before minor issues

Manual Testing

• Navigate entire site using only keyboard (Tab, Arrow Keys, Enter, Escape)
• Test forms using keyboard alone
• Test with screen reader (NVDA on Windows, JAWS for enterprise, VoiceOver on Mac)
• Test with color blindness simulator to verify contrast passes
• Test with zoom enabled (200 percent) to verify layout remains functional
• Test on multiple browsers (Chrome, Firefox, Safari, Edge)

User Testing

• Include participants with disabilities in user research
• Test with actual assistive technology users
• Document real-world friction that automated testing misses
• Record specific feedback on screen reader compatibility

Building Remediation Roadmap

If you're starting from scratch, prioritize in this order:

Phase 1: Keyboard Navigation and Focus
Keyboard accessibility unblocks other improvements. Users with any motor impairment depend on it.

Phase 2: Semantic HTML and Heading Structure
Proper markup enables screen readers to navigate. It also forces better code organization.

Phase 3: Color Contrast and Text Alternatives
Quick wins with high visibility impact across user base.

Phase 4: Form Labels and Input Assistance
Conversion directly improves when forms are accessible.

Phase 5: Complex Components and ARIA
Custom components, modals, and dynamic content require more specialized expertise.

Phase 6: Advanced Patterns
Live regions, drag-and-drop alternatives, gesture handling for mobile applications.