Web Accessibility Checklist - WCAG 2.1 AA for SaaS Products
A checklist organized by the WCAG principles of perceivable, operable, understandable, and robust, with practical testing guidance for designers and developers.
Built for practical use
POUR framework
A checklist organized by the WCAG principles of perceivable, operable, understandable, and robust, with practical testing guidance for designers and developers.
WCAG checkpoints
A checklist organized by the WCAG principles of perceivable, operable, understandable, and robust, with practical testing guidance for designers and developers.
Testing guidance
A checklist organized by the WCAG principles of perceivable, operable, understandable, and robust, with practical testing guidance for designers and developers.
Team audit prompts
A checklist organized by the WCAG principles of perceivable, operable, understandable, and robust, with practical testing guidance for designers and developers.
How to Use This Checklist
For each criterion:
- Read the requirement (plain English)
- Test your product using the pass/fail test
- Mark the status: Pass / Partial / Fail / Not Applicable
- Document issues for remediation
Priority for fixing:
- Level A violations: Fix first (these are the bare minimum)
- Level AA violations: Fix second (this is your compliance baseline)
- Most legally-risky: Contrast (1.4.3), Keyboard (2.1.1), Alt Text (1.1.1), Forms (3.3.x)
Plan Your Accessibility Audit
Document your scope, blockers, and review cadence before turning the full guide into an actionable audit.
About WCAG 2.1 AA
The Web Content Accessibility Guidelines (WCAG) are the international technical standard for web accessibility, developed by the W3C (World Wide Web Consortium). WCAG 2.1 was published in June 2018. WCAG 2.2 (published October 2023) adds 9 more success criteria on top of 2.1.
Why WCAG 2.1 Level AA specifically:
- It's the legal standard referenced in most accessibility laws globally (ADA in the US, European Accessibility Act, Section 508, EN 301 549)
- It's the conformance level most organizations target — a balance of practicality and inclusivity
- It includes all of Level A (backward compatible)
- It's achievable for real-world websites and applications
Scope of this checklist: WCAG 2.1 AA includes 50 success criteria across 4 POUR principles:
- Perceivable (11 criteria)
- Operable (17 criteria)
- Understandable (12 criteria)
- Robust (2 criteria)
This checklist covers all 50 criteria with plain-English explanations, pass/fail tests, and SaaS-specific examples.
Who this is for: Designers, developers, product managers, and compliance leads ensuring their SaaS products are accessible.
PRINCIPLE 1: PERCEIVABLE (11 Success Criteria at AA)
Information and user interface components must be presentable to users in ways they can perceive.
Guideline 1.1 — Text Alternatives
1.1.1 Non-text Content (Level A) Every image, icon, button, and non-text element has a text alternative (alt text, aria-label, or equivalent).
Test: Inspect all images. Do they have meaningful alt attributes? Do icon-only buttons have aria-label?
Pass examples:
<img src="chart.png" alt="Revenue grew 40% from Q1 to Q2 2026"><button aria-label="Delete project"><svg>...</svg></button><img src="decorative-background.png" alt="">(empty alt for decorative images)
Common failures:
- Icon-only buttons with no accessible name
- Images with
alt="image"oralt="photo"(not descriptive) - Decorative images with descriptive alt text (should be empty)
Guideline 1.2 — Time-based Media
1.2.1 Audio-only and Video-only (Prerecorded) (Level A) Provide alternatives for audio-only content (transcript) and video-only content (description).
1.2.2 Captions (Prerecorded) (Level A) Captions are provided for all prerecorded video content with audio.
1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A) Audio description or full text alternative is provided for prerecorded video.
1.2.4 Captions (Live) (Level AA) Captions are provided for all live audio content in synchronized media.
1.2.5 Audio Description (Prerecorded) (Level AA) Audio description is provided for all prerecorded video content.
Test: Do all videos have captions? Do all audio files have transcripts? Do video files have audio descriptions where visual content isn't conveyed in audio?
SaaS relevance: Common for product demo videos, tutorial videos, webinars, onboarding videos.
Guideline 1.3 — Adaptable
1.3.1 Info and Relationships (Level A) Information, structure, and relationships conveyed visually can be programmatically determined.
Test: Headings use <h1>-<h6>. Lists use <ul> or <ol>. Tables use <th> with appropriate scope. Form labels are associated with inputs via <label for=""> or aria-labelledby.
Common failures:
- Using
<div>with CSS for headings instead of<h2> - Lists that look like lists visually but use
<br>instead of<ul> - Tables without header rows
1.3.2 Meaningful Sequence (Level A) When the sequence of content affects its meaning, a correct reading sequence can be programmatically determined.
Test: Disable CSS. Does the content still make sense in the order it appears in the DOM?
1.3.3 Sensory Characteristics (Level A) Instructions don't rely solely on sensory characteristics (shape, color, visual location, sound).
Pass: "Click the blue 'Submit' button at the bottom of the form" Fail: "Click the round button on the right" (relies only on shape/position)
1.3.4 Orientation (Level AA) Content isn't restricted to a single display orientation (portrait or landscape) unless essential.
Test: Rotate your device. Does content still work in both orientations?
1.3.5 Identify Input Purpose (Level AA) Input fields collecting user info have programmatically identifiable purpose (using autocomplete attributes).
Pass:
<input type="email" autocomplete="email">
<input type="tel" autocomplete="tel">
<input type="text" autocomplete="name">Why it matters: Enables browser autofill and assistive technology customization.
Guideline 1.4 — Distinguishable
1.4.1 Use of Color (Level A) Color is not the only visual means of conveying information, indicating an action, or prompting a response.
Fail: Form fields with errors shown only with red borders (color-only) Pass: Red border + error icon + error message below field
1.4.2 Audio Control (Level A) If audio plays automatically for more than 3 seconds, provide a mechanism to pause, stop, or control volume.
1.4.3 Contrast (Minimum) (Level AA) Text has a contrast ratio of at least:
- 4.5:1 for normal text (under 18px, or under 14px if bold)
- 3:1 for large text (18px or larger, or 14px+ if bold)
Test: Use WebAIM Contrast Checker (webaim.org/resources/contrastchecker) or Chrome DevTools Accessibility tab.
Common failures:
- Light gray text on white (#999 on #FFF = 2.8:1 — fails)
- Yellow buttons with white text (almost always fails)
- Placeholder text that's too light
1.4.4 Resize Text (Level AA) Text can be resized up to 200% without loss of content or functionality.
Test: Increase browser zoom to 200%. Does everything still work? Is text still readable? No horizontal scrolling for content?
1.4.5 Images of Text (Level AA) Use actual text instead of images of text (except for logos or essential decorations).
Why: Text in images can't be resized, translated, or read by screen readers.
1.4.10 Reflow (Level AA) Content can be presented at 320 CSS pixels wide without requiring horizontal scrolling (except for content that requires 2D layout, like maps or tables).
Test: Resize your browser to 320px wide. Does content reflow to fit without horizontal scrolling?
1.4.11 Non-text Contrast (Level AA) User interface components (buttons, form fields, focus indicators) and meaningful graphics have a contrast ratio of at least 3:1 against adjacent colors.
Test: Check contrast between button background and page background, form field borders and page background, focus indicators and their backgrounds.
1.4.12 Text Spacing (Level AA) No loss of content or functionality when users override text spacing:
- Line height: at least 1.5× font size
- Paragraph spacing: at least 2× font size
- Letter spacing: at least 0.12× font size
- Word spacing: at least 0.16× font size
1.4.13 Content on Hover or Focus (Level AA) Content that appears on hover or focus (tooltips, popovers):
- Can be dismissed without moving pointer/focus
- Is hoverable (user can move pointer onto the content)
- Remains visible until dismissed
PRINCIPLE 2: OPERABLE (17 Success Criteria at AA)
User interface components and navigation must be operable.
Guideline 2.1 — Keyboard Accessible
2.1.1 Keyboard (Level A) All functionality is available from a keyboard.
Test: Unplug your mouse. Can you reach and activate every button, link, form field, and interactive element using only Tab, Shift+Tab, Enter, Space, Escape, and Arrow keys?
Common failures:
- Custom dropdowns that only respond to mouse hover
- Modals that can't be closed with Escape
- Drag-and-drop with no keyboard alternative
2.1.2 No Keyboard Trap (Level A) Keyboard focus can be moved away from any component using only the keyboard.
Test: Tab into every component. Can you Tab out of it? Or is focus trapped?
2.1.4 Character Key Shortcuts (Level A) If single-character keyboard shortcuts exist, users can turn them off or remap them.
Guideline 2.2 — Enough Time
2.2.1 Timing Adjustable (Level A) If there's a time limit, users can turn off, adjust, or extend it (with exceptions for real-time events like auctions).
2.2.2 Pause, Stop, Hide (Level A) Automatic moving, blinking, scrolling, or auto-updating content can be paused, stopped, or hidden.
Guideline 2.3 — Seizures and Physical Reactions
2.3.1 Three Flashes or Below Threshold (Level A) Nothing flashes more than 3 times per second.
Relevant for: Animations, alerts, loading spinners, video content.
Guideline 2.4 — Navigable
2.4.1 Bypass Blocks (Level A) A "Skip to main content" link or equivalent mechanism is available to bypass repeated blocks of content.
2.4.2 Page Titled (Level A) Each web page has a descriptive title.
2.4.3 Focus Order (Level A) Focus moves in an order that preserves meaning and operability.
Test: Tab through the page. Does focus follow the visual reading order?
2.4.4 Link Purpose (In Context) (Level A) Link text makes the purpose clear, either alone or with the surrounding context.
Pass: "Read our onboarding guide" Fail: "Click here" or "Learn more" (ambiguous out of context)
2.4.5 Multiple Ways (Level AA) More than one way exists to locate a page (navigation, search, sitemap, etc.).
Exception: Pages that are part of a process (e.g., checkout flow).
2.4.6 Headings and Labels (Level AA) Headings and labels describe the topic or purpose.
Pass: <h2>Account Settings</h2> Fail: <h2>Section 3</h2>
2.4.7 Focus Visible (Level AA) A keyboard focus indicator is visible on every focusable element.
Common failure: CSS outline: none without providing an alternative focus style.
Guideline 2.5 — Input Modalities
2.5.1 Pointer Gestures (Level A) Functionality that uses multi-point or path-based gestures (like pinch-to-zoom) has a single-pointer alternative.
2.5.2 Pointer Cancellation (Level A) For single-pointer functions (click), users can abort or undo:
- No action on down-event (only on up-event), OR
- Users can move pointer away to abort
2.5.3 Label in Name (Level A) For components with visible labels, the accessible name matches the visible label.
Pass: Button visually says "Submit" — aria-label="Submit" or no aria-label (uses visible text) Fail: Button visually says "Submit" but aria-label="Send form" (name mismatch confuses voice control users)
2.5.4 Motion Actuation (Level A) Functionality triggered by device motion (shake to undo, tilt to scroll) can also be done via UI components.
PRINCIPLE 3: UNDERSTANDABLE (12 Success Criteria at AA)
Information and operation of the interface must be understandable.
Guideline 3.1 — Readable
3.1.1 Language of Page (Level A) The primary language of each page is programmatically identified.
Pass: <html lang="en">
3.1.2 Language of Parts (Level AA) Language of each passage or phrase is identified when it differs from the main page language.
Pass: <span lang="es">Bienvenido</span> within English content
Guideline 3.2 — Predictable
3.2.1 On Focus (Level A) Receiving focus doesn't cause a context change (page navigation, form submission, major UI change).
3.2.2 On Input (Level A) Changing the value of a form control (filling a field, selecting a dropdown option) doesn't cause an unexpected context change.
3.2.3 Consistent Navigation (Level AA) Navigation appears in the same relative order across pages.
3.2.4 Consistent Identification (Level AA) Components with the same functionality are labeled consistently.
Fail: Save button labeled "Save" on one page, "Update" on another, "Apply" on a third — all doing the same thing.
Guideline 3.3 — Input Assistance
3.3.1 Error Identification (Level A) Input errors are identified and described in text.
3.3.2 Labels or Instructions (Level A) Labels or instructions are provided for user input.
3.3.3 Error Suggestion (Level AA) If the error is known, suggest how to fix it.
Pass: "Email address must include an @ symbol" Fail: "Invalid email"
3.3.4 Error Prevention (Legal, Financial, Data) (Level AA) For pages that submit legal commitments, financial transactions, or modify data, at least one of the following:
- Submissions are reversible
- Data is checked for input errors with opportunity to correct
- A confirmation mechanism allows review and correction before finalizing
PRINCIPLE 4: ROBUST (2 Success Criteria at AA)
Content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies.
Guideline 4.1 — Compatible
4.1.1 Parsing (Level A) — REMOVED in WCAG 2.2 (Originally: Elements have complete start/end tags, are nested according to specs, don't contain duplicate attributes, and have unique IDs.)
Note: This success criterion has been removed in WCAG 2.2 but remains in WCAG 2.1.
4.1.2 Name, Role, Value (Level A) For all UI components, the name, role, value, and state are programmatically determinable.
Test: Use a screen reader (NVDA on Windows, VoiceOver on Mac). Does it correctly announce every interactive element?
Common pass: Using semantic HTML (<button>, <select>, <input>) Common fail: Custom components built from <div> without appropriate ARIA roles
4.1.3 Status Messages (Level AA) Status messages (success confirmations, error notifications, progress updates) can be programmatically determined without receiving focus.
Pass: Success toast with role="status" or aria-live="polite"
Testing Tools
Free automated tools
- axe DevTools (browser extension) — catches ~30-40% of accessibility issues
- WAVE (webaim.org/tools/wave) — free scanner with visual feedback
- Lighthouse (in Chrome DevTools) — accessibility score + specific issues
- Pa11y (command-line tool) — automated accessibility testing
Free assistive technology for testing
- NVDA (Windows) — free screen reader; most popular for testing
- VoiceOver (macOS / iOS) — built-in screen reader
- TalkBack (Android) — built-in screen reader
Paid tools
- Deque axe Pro — comprehensive testing
- Level Access — enterprise accessibility platform
- Siteimprove — continuous accessibility monitoring
Manual testing essentials
- Keyboard-only navigation (unplug your mouse)
- Screen reader testing (NVDA or VoiceOver)
- Zoom to 200% and check layout
- Disable CSS and check content order
- Test with high contrast mode enabled
Remediation Priority Matrix
Focus efforts in this order:
Priority 1 — Blocking (Fix immediately):
- Keyboard inaccessibility (2.1.1)
- Missing alt text on meaningful images (1.1.1)
- Color contrast failures on critical interactions (1.4.3)
- Missing form labels (3.3.2)
- Keyboard traps (2.1.2)
Priority 2 — Major (Fix within 30 days):
- Non-visible focus indicators (2.4.7)
- Error messages not associated with fields
- Headings that don't describe content (2.4.6)
- Color-only information conveyance (1.4.1)
- No skip links (2.4.1)
Priority 3 — Important (Fix within 90 days):
- Text that can't resize to 200% (1.4.4)
- Content reflow issues (1.4.10)
- Missing page titles (2.4.2)
- Inconsistent navigation (3.2.3)
Priority 4 — Polish (Ongoing):
- Audio/video captions
- Multiple navigation methods
- Enhanced ARIA implementations
WCAG 2.2 Additions (For Future-Proofing)
If you want to exceed AA and aim for WCAG 2.2 AA, add these 9 new criteria:
- 2.4.11 Focus Not Obscured (Minimum) — Focused element isn't fully hidden
- 2.4.12 Focus Not Obscured (Enhanced) — AAA level
- 2.4.13 Focus Appearance — AAA level
- 2.5.7 Dragging Movements — Drag actions have single-pointer alternatives
- 2.5.8 Target Size (Minimum) — Interactive targets at least 24×24 CSS pixels
- 3.2.6 Consistent Help — Help mechanisms in consistent locations
- 3.3.7 Redundant Entry — Don't require users to re-enter info in the same process
- 3.3.8 Accessible Authentication (Minimum) — No cognitive function tests
- 3.3.9 Accessible Authentication (Enhanced) — AAA level
Compliance Context
Which laws require WCAG 2.1 AA?
- ADA Title III (US): No specific WCAG version mandated, but courts typically reference WCAG 2.1 AA
- ADA Title II (US, April 2026): Requires WCAG 2.1 AA for state/local governments
- Section 508 (US, federal): References WCAG 2.0 AA (most agencies target 2.1 AA)
- European Accessibility Act (EAA, 2025): References EN 301 549, which maps closely to WCAG 2.1 AA
- AODA (Ontario, Canada): Requires WCAG 2.0 AA as of 2021
- Various other countries have similar laws referencing WCAG
What this means: WCAG 2.1 AA is the de facto global standard. Meeting it protects you legally and makes your product usable by ~15% of users who have disabilities.
Sources and References
- Web Content Accessibility Guidelines (WCAG) 2.1, W3C (www.w3.org/TR/WCAG21/)
- Web Content Accessibility Guidelines (WCAG) 2.2, W3C (www.w3.org/TR/WCAG22/)
- WebAIM (webaim.org) — accessibility resources and tools
- Deque University — accessibility training and documentation
- Accessible.org WCAG checklist
- Level Access WCAG 2.1 AA guide
Created by Desisle — SaaS UI/UX Design Agency desisle.com | hello@desisle.com Free to use and share with attribution.
For a professional WCAG 2.1 AA accessibility audit of your product, contact us at hello@desisle.com.
Keep Building With These Next
Color Contrast Checker & Remediation Guide
A quick reference for checking and fixing contrast issues, including WCAG ratios, tools, common failures, and a contrast-safe starter palette.
Open Contrast CheckerSaaS Dashboard Design Guidelines - Turning Data Dumps Into Decision Tools
A practical dashboard design guide covering information hierarchy, chart selection, filters, drill-downs, power-user disclosure, and data-state design.
Open Dashboard PlannerSaaS Meta Tags Cheat Sheet - Title Tags, Meta Descriptions & Schema for Every Page Type
A reference for writing page titles, meta descriptions, and schema recommendations across homepages, services, industries, blogs, case studies, pricing, and contact pages.
Open Meta Tag GeneratorNeed This Applied to Your Product? We'll Turn It Into Execution.
These resource pages are meant to be used hands-on. If you want the audit, plan, or framework translated into live product work, we can do that with your team.