Complete WCAG Accessibility Compliance Cheat Sheet: Making Digital Content Accessible to All

Introduction: Understanding Web Accessibility and WCAG

Web accessibility ensures digital content and services are usable by everyone, including people with disabilities. The Web Content Accessibility Guidelines (WCAG) are internationally recognized standards developed by the World Wide Web Consortium (W3C) that provide a framework for making web content more accessible. WCAG compliance is not only a legal requirement in many jurisdictions but also expands your audience reach, improves user experience for everyone, and demonstrates corporate social responsibility. The current version, WCAG 2.1, builds on WCAG 2.0 and includes additional success criteria, while WCAG 2.2 adds several new requirements.

WCAG Core Principles (POUR)

WCAG is organized around four core principles, commonly referred to as POUR:

Conformance Levels

WCAG defines three levels of conformance:

Key WCAG Success Criteria by Principle

Perceivable

1.1 Text Alternatives

• 1.1.1 Non-text Content (A): Provide text alternatives for all non-text content
  • Add alt text to images (<img alt="Description">)
  • Provide transcripts for audio
  • Include descriptions for videos
  • Label form controls with descriptive text

1.2 Time-based Media

• 1.2.1 Audio/Video Only (A): Provide alternatives for pre-recorded audio/video
• 1.2.2 Captions (A): Provide captions for all pre-recorded audio
• 1.2.3 Audio Description or Media Alternative (A): Provide audio description or transcript
• 1.2.4 Captions (Live) (AA): Provide captions for live audio
• 1.2.5 Audio Description (AA): Provide audio descriptions for pre-recorded video

1.3 Adaptable

• 1.3.1 Info and Relationships (A): Information, structure, and relationships can be programmatically determined
  • Use proper HTML semantic elements (<header>, <nav>, <main>, <footer>, etc.)
  • Implement proper heading hierarchy (<h1> through <h6>)
  • Use HTML tables for tabular data, with proper headers
  • Associate form labels with inputs
• 1.3.2 Meaningful Sequence (A): Present content in a meaningful sequence
• 1.3.3 Sensory Characteristics (A): Instructions don’t rely solely on sensory characteristics
• 1.3.4 Orientation (AA, 2.1): Content not restricted to specific orientation
• 1.3.5 Identify Input Purpose (AA, 2.1): Identify purpose of form inputs
• 1.3.6 Identify Purpose (AAA, 2.1): Identify purpose of UI components, icons, and regions

1.4 Distinguishable

• 1.4.1 Use of Color (A): Color is not the only visual means of conveying information
• 1.4.2 Audio Control (A): Provide mechanism to stop, pause, or control audio volume
• 1.4.3 Contrast (Minimum) (AA): Text has contrast ratio of at least 4.5:1 (3:1 for large text)
• 1.4.4 Resize Text (AA): Text can be resized up to 200% without loss of content or function
• 1.4.5 Images of Text (AA): Use actual text rather than images of text
• 1.4.10 Reflow (AA, 2.1): Content reflows to fit viewport without scrolling in two dimensions at 400% zoom
• 1.4.11 Non-text Contrast (AA, 2.1): UI components and graphical objects have contrast ratio of at least 3:1
• 1.4.12 Text Spacing (AA, 2.1): No loss of content when adjusting text spacing
• 1.4.13 Content on Hover or Focus (AA, 2.1): Additional content that appears on hover/focus is dismissible, hoverable, and persistent

Operable

2.1 Keyboard Accessible

• 2.1.1 Keyboard (A): All functionality available from keyboard
• 2.1.2 No Keyboard Trap (A): Keyboard focus is not trapped
• 2.1.4 Character Key Shortcuts (A, 2.1): Shortcuts can be turned off, remapped, or active only on focus
• 2.1.6 Concurrent Input Mechanisms (AAA, 2.2): Allow multiple input methods beyond keyboard-only

2.2 Enough Time

• 2.2.1 Timing Adjustable (A): Users can adjust, extend, or disable time limits
• 2.2.2 Pause, Stop, Hide (A): Provide controls for moving, blinking, scrolling, or auto-updating content
• 2.2.6 Timeouts (AAA, 2.2): Users are warned about timeouts that could cause data loss

2.3 Seizures and Physical Reactions

• 2.3.1 Three Flashes or Below Threshold (A): No content flashes more than three times per second
• 2.3.3 Animation from Interactions (AAA, 2.1): Motion animation triggered by interaction can be disabled

2.4 Navigable

• 2.4.1 Bypass Blocks (A): Provide a way to bypass repeated blocks of content
  • Use skip links (<a href="#main">Skip to main content</a>)
  • Implement proper heading structure
  • Use ARIA landmarks
• 2.4.2 Page Titled (A): Provide descriptive page titles
• 2.4.3 Focus Order (A): Focus order preserves meaning and operability
• 2.4.4 Link Purpose (In Context) (A): Purpose of link can be determined from link text or context
• 2.4.5 Multiple Ways (AA): Multiple ways to locate a webpage (site search, sitemap, etc.)
• 2.4.6 Headings and Labels (AA): Descriptive headings and labels
• 2.4.7 Focus Visible (AA): Keyboard focus indicator is visible
• 2.4.11 Focus Appearance (AA, 2.2): Focus indicator area is at least as large as 2px border and has contrast of at least 3:1

2.5 Input Modalities (WCAG 2.1)

• 2.5.1 Pointer Gestures (A): Functionality using multipoint or path-based gestures can be operated with single pointer
• 2.5.2 Pointer Cancellation (A): No down-event to trigger actions; users can abort or undo actions
• 2.5.3 Label in Name (A): Visible text labels match their programmatic name
• 2.5.4 Motion Actuation (A): Functionality operated by device or user motion can also be operated by UI components
• 2.5.5 Target Size (AAA): Size of target for pointer inputs is at least 44×44 pixels
• 2.5.6 Concurrent Input Mechanisms (AAA): Content doesn’t restrict use of input modalities
• 2.5.7 Dragging Movements (AA, 2.2): Functions that require dragging have alternative single-pointer operation
• 2.5.8 Target Size (Minimum) (AA, 2.2): Size of target for pointer inputs is at least 24×24 pixels

Understandable

3.1 Readable

• 3.1.1 Language of Page (A): Human language of page can be programmatically determined
  • Use the lang attribute on the HTML element (<html lang="en">)
• 3.1.2 Language of Parts (AA): Human language of passages can be programmatically determined
  • Use the lang attribute on elements containing content in a different language

3.2 Predictable

• 3.2.1 On Focus (A): Focus doesn’t trigger unexpected changes
• 3.2.2 On Input (A): Input doesn’t trigger unexpected changes without warning
• 3.2.3 Consistent Navigation (AA): Navigation mechanisms are consistent
• 3.2.4 Consistent Identification (AA): Components with same functionality are identified consistently
• 3.2.5 Change on Request (AAA): Changes in context only happen with user request
• 3.2.6 Consistent Help (A, 2.2): Help mechanisms appear in same relative order as repeated components

3.3 Input Assistance

• 3.3.1 Error Identification (A): Errors are identified and described to users
• 3.3.2 Labels or Instructions (A): Labels or instructions are provided for user input
• 3.3.3 Error Suggestion (AA): Suggestions for correction are provided
• 3.3.4 Error Prevention (Legal, Financial, Data) (AA): Submissions can be checked, confirmed, or reversed
• 3.3.7 Redundant Entry (A, 2.2): Information previously entered is either auto-populated or available for selection
• 3.3.8 Accessible Authentication (AA, 2.2): Authentication without cognitive function tests unless alternatives provided

Robust

4.1 Compatible

• 4.1.1 Parsing (A): Use valid, well-formed markup
• 4.1.2 Name, Role, Value (A): For all UI components, name and role can be programmatically determined
• 4.1.3 Status Messages (AA, 2.1): Status messages can be programmatically determined

Technical Implementation Guide

Semantic HTML Implementation

ARIA Implementation Guide

Use ARIA (Accessible Rich Internet Applications) attributes when HTML semantics alone aren’t sufficient:

ARIA Landmark Roles

Key ARIA Attributes

Keyboard Navigation Implementation

Testing and Validation

Accessibility Testing Process

1. Automated Testing

   • Run automated tools
   • Fix identified issues
   • Understand limitations (catch ~30% of issues)

2. Manual Testing

   • Keyboard navigation testing
   • Screen reader testing
   • Color contrast validation
   • Content structure review
   • Zoom/magnification testing

3. User Testing

   • Testing with users with disabilities
   • Collect feedback and observations
   • Identify real-world issues

Automated Testing Tools

Manual Testing Checklist

• [ ] Keyboard Navigation
  • [ ] Navigate entire site using Tab, Shift+Tab, Enter, Space, arrow keys
  • [ ] Ensure focus indicator is visible
  • [ ] Verify all interactive elements are operable
  • [ ] Check for keyboard traps
• [ ] Screen Reader Testing
  • [ ] Test with at least one screen reader (NVDA, JAWS, VoiceOver)
  • [ ] Check that all content is announced correctly
  • [ ] Verify page title is announced
  • [ ] Ensure heading structure is logical
  • [ ] Test form inputs and error messages
• [ ] Visual Inspection
  • [ ] Check text resizing (200%)
  • [ ] Test responsive design at multiple viewports
  • [ ] Verify color contrast meets guidelines
  • [ ] Check information is not conveyed by color alone
  • [ ] Test with high contrast mode
• [ ] Content Structure
  • [ ] Validate heading hierarchy
  • [ ] Check for proper use of lists
  • [ ] Ensure table structure is correct
  • [ ] Verify form labels are associated with inputs
• [ ] Interactive Elements
  • [ ] Test custom widgets (dropdowns, tabs, modals)
  • [ ] Verify error handling and messaging
  • [ ] Check timeout warnings
  • [ ] Test with enlarged text and zooming

Common Accessibility Issues & Solutions

Best Practices & Tips

Development Best Practices

• Progressive Enhancement: Build core functionality with HTML first
• Semantic HTML: Use appropriate elements for their intended purpose
• Test Early and Often: Include accessibility in your development workflow
• Automated Testing: Integrate accessibility testing in CI/CD
• Use Native Elements: When possible, use native HTML elements rather than custom widgets
• Avoid Overriding Browser Defaults: Be cautious when overriding keyboard behaviors
• Consider Reading Order: Ensure source order matches visual presentation
• Minimize Assumptions: Don’t assume specific input methods or abilities
• Document Accessibility Features: Include accessibility information in documentation

Design Best Practices

• Include Accessibility from Start: Incorporate accessibility in design phase
• Provide Sufficient Contrast: Text and UI components should have adequate contrast
• Don’t Rely on Color Alone: Use additional indicators (icons, patterns, text)
• Design with Flexibility: Allow for text resizing and zooming
• Consider Different Viewports: Design responsively for various screen sizes
• Create Clear Hierarchy: Use visual hierarchy that matches document structure
• Consistent UI Patterns: Maintain consistency in navigation and interactions
• Accessible Forms: Design clear labels, error states, and feedback mechanisms
• Sufficient Touch Targets: Make interactive elements large enough (at least 44×44px recommended)
• Reduce Cognitive Load: Keep interfaces simple and predictable

Content Best Practices

• Use Plain Language: Write clearly and concisely
• Structure Content Logically: Use headings, lists, and paragraphs appropriately
• Descriptive Links: Make link text meaningful out of context
• Provide Transcripts and Captions: For audio and video content
• Explain Complex Content: Provide explanations for complex ideas or data
• Use Tables Appropriately: Only for tabular data, with proper structure
• Consider Reading Level: Aim for lower secondary education level when possible
• Avoid Directional Instructions: Don’t rely on spatial location (“click the button on the right”)
• Include Glossaries: For technical or specialized terminology
• Consistent Terminology: Use the same terms for the same concepts

Legal Considerations

Major Accessibility Laws and Standards

Compliance Planning

1. Assess Current Status: Conduct accessibility audit
2. Create Remediation Plan: Prioritize critical issues
3. Implement Fixes: Address issues according to plan
4. Document Progress: Create accessibility statement
5. Ongoing Monitoring: Regular testing and maintenance
6. Staff Training: Train team on accessibility practices
7. User Feedback: Create process for accessibility feedback
8. Legal Review: Consider legal implications of non-compliance

Resources for Further Learning

Official Documentation

• WCAG 2.1 Guidelines
• WCAG 2.2 Guidelines
• WAI-ARIA Authoring Practices
• WebAIM Resources
• MDN Accessibility Guide

Tools and Testing Resources

• WAVE Web Accessibility Evaluation Tool
• axe Accessibility Testing Tools
• Colour Contrast Analyser
• Accessibility Insights
• Screen Reader User Survey

Learning Platforms and Courses

• W3C Introduction to Web Accessibility
• Deque University
• Google Web Accessibility Course
• Level Access Accessibility Training
• A11Y Project

Community Resources

• WebAIM Mailing List
• A11Y Slack Community
• Accessibility Developers Guide
• Inclusive Design Principles
• Web Accessibility Tutorials