Why You Need a WCAG 2.1 Checklist for Developers

The Web Content Accessibility Guidelines (WCAG) 2.1 specification is long, technical, and honestly overwhelming if you just need to ship an accessible website. Most developers do not have time to read 100+ pages of W3C documentation before writing their next pull request.

That is exactly why we created this WCAG 2.1 checklist for developers. It distills every AA-level success criterion into clear, actionable items organized by the four core principles: Perceivable, Operable, Understandable, and Robust (often called POUR). Bookmark this page, share it with your team, and use it as a quality assurance reference every time you build or update a site.

This checklist targets WCAG 2.1 Level AA, which is the conformance level required by most accessibility laws worldwide, including the European Accessibility Act (EAA), ADA case law in the United States, and Section 508 requirements.

How This Checklist Is Organized

WCAG 2.1 is built on four principles. Every success criterion falls under one of them:

1. Perceivable – Users must be able to perceive the content (it cannot be invisible to all their senses).
2. Operable – Users must be able to operate the interface (it cannot require interactions a user cannot perform).
3. Understandable – Users must be able to understand the information and how the interface works.
4. Robust – Content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies.

Below, each section maps directly to these principles and lists every Level A and Level AA success criterion you need to satisfy.

Principle 1: Perceivable

Content and UI components must be presented in ways users can perceive regardless of ability.

1.1 Text Alternatives

Criterion	Level	What to Do
1.1.1 Non-text Content	A	Provide alt text for every meaningful image. Use alt="" for decorative images. Ensure form inputs have associated labels. Provide text alternatives for icons, charts, and CAPTCHA.

1.2 Time-Based Media

Criterion	Level	What to Do
1.2.1 Audio-only and Video-only	A	Provide a transcript for audio-only content. Provide a text or audio description for video-only content.
1.2.2 Captions (Prerecorded)	A	Add synchronized captions to all prerecorded video with audio.
1.2.3 Audio Description or Media Alternative	A	Provide an audio description or a full text alternative for prerecorded video.
1.2.4 Captions (Live)	AA	Provide real-time captions for live audio in video streams.
1.2.5 Audio Description (Prerecorded)	AA	Provide audio description for all prerecorded video content.

1.3 Adaptable

Criterion	Level	What to Do
1.3.1 Info and Relationships	A	Use semantic HTML: headings (h1–h6), lists (ul, ol), tables with th, label for inputs, and landmark roles (nav, main, aside, footer).
1.3.2 Meaningful Sequence	A	Ensure the DOM order matches the visual reading order. Do not rely solely on CSS to reorder content.
1.3.3 Sensory Characteristics	A	Do not use shape, size, visual location, or sound alone to convey instructions (e.g., “click the round button on the left”).
1.3.4 Orientation	AA	Do not restrict the display to a single orientation (portrait or landscape) unless it is essential.
1.3.5 Identify Input Purpose	AA	Use the autocomplete attribute on form fields that collect personal data (name, email, address, etc.).

1.4 Distinguishable

Criterion	Level	What to Do
1.4.1 Use of Color	A	Never use color as the only means of conveying information (e.g., red text for errors). Add icons, text labels, or patterns.
1.4.2 Audio Control	A	If audio plays automatically for more than 3 seconds, provide a way to pause, stop, or control its volume independently.
1.4.3 Contrast (Minimum)	AA	Text must have a contrast ratio of at least 4.5:1 against its background. Large text (18pt+ or 14pt+ bold) needs at least 3:1.
1.4.4 Resize Text	AA	Text must be resizable up to 200% without loss of content or functionality. Use relative units (rem, em, %).
1.4.5 Images of Text	AA	Use real text instead of images of text, except for logos or essential visual presentations.
1.4.10 Reflow	AA	Content must reflow at 320 CSS pixels width (equivalent to 400% zoom) without requiring two-dimensional scrolling. Build responsive layouts.
1.4.11 Non-text Contrast	AA	UI components (buttons, inputs, focus indicators) and meaningful graphics must have at least a 3:1 contrast ratio against adjacent colors.
1.4.12 Text Spacing	AA	No loss of content or functionality when users override: line height to 1.5x font size, paragraph spacing to 2x font size, letter spacing to 0.12x font size, and word spacing to 0.16x font size.
1.4.13 Content on Hover or Focus	AA	If content appears on hover or focus (tooltips, dropdowns), it must be: dismissible (e.g., Esc key), hoverable (user can move pointer over it), and persistent (stays visible until dismissed).

Principle 2: Operable

UI components and navigation must be operable by all users.

2.1 Keyboard Accessible

Criterion	Level	What to Do
2.1.1 Keyboard	A	All functionality must be operable via keyboard. Use native HTML controls when possible. If you build custom widgets, add proper keyboard event handlers.
2.1.2 No Keyboard Trap	A	Users must be able to navigate away from any component using the keyboard. Pay special attention to modals, media players, and embedded iframes.
2.1.4 Character Key Shortcuts	A	If you implement single-character keyboard shortcuts, allow users to turn them off, remap them, or make them active only on focus.

2.2 Enough Time

Criterion	Level	What to Do
2.2.1 Timing Adjustable	A	If a time limit exists, let users turn it off, adjust it, or extend it (at least 10 times). Session timeouts must warn users and give them a chance to extend.
2.2.2 Pause, Stop, Hide	A	Provide controls to pause, stop, or hide any moving, blinking, scrolling, or auto-updating content that starts automatically and lasts more than 5 seconds.

2.3 Seizures and Physical Reactions

Criterion	Level	What to Do
2.3.1 Three Flashes or Below Threshold	A	No content flashes more than 3 times per second, unless the flash is below the general flash and red flash thresholds.

2.4 Navigable

Criterion	Level	What to Do
2.4.1 Bypass Blocks	A	Provide a “Skip to main content” link. Use landmark regions (main, nav, aside).
2.4.2 Page Titled	A	Every page must have a descriptive, unique <title>.
2.4.3 Focus Order	A	Focus order must be logical and follow the visual reading sequence. Avoid positive tabindex values.
2.4.4 Link Purpose (In Context)	A	The purpose of each link can be determined from the link text alone or from the link text plus its surrounding context. Avoid “click here” and “read more” without context.
2.4.5 Multiple Ways	AA	Provide at least two ways to locate a page (e.g., navigation menu + site search, or navigation + sitemap).
2.4.6 Headings and Labels	AA	Headings and labels must describe the topic or purpose of their content.
2.4.7 Focus Visible	AA	Keyboard focus indicator must be visible at all times. Never use outline: none without providing an alternative focus style.

2.5 Input Modalities

Criterion	Level	What to Do
2.5.1 Pointer Gestures	A	If functionality uses multipoint or path-based gestures (pinch, swipe), provide a single-pointer alternative (button tap or click).
2.5.2 Pointer Cancellation	A	Actions fire on the up-event (mouseup/touchend), not on the down-event. Allow users to abort or undo actions.
2.5.3 Label in Name	A	The accessible name of a component must contain the visible text label. For example, if a button shows “Search”, its aria-label should not be “Find items”.
2.5.4 Motion Actuation	A	If functionality is triggered by device motion (shake, tilt), provide a UI alternative and allow users to disable motion activation.

Principle 3: Understandable

Information and operation of the UI must be understandable.

3.1 Readable

Criterion	Level	What to Do
3.1.1 Language of Page	A	Set the lang attribute on the <html> element (e.g., lang="en").
3.1.2 Language of Parts	AA	Identify any content in a different language with the lang attribute on the containing element.

3.2 Predictable

Criterion	Level	What to Do
3.2.1 On Focus	A	Receiving focus on a component must not automatically trigger a change of context (e.g., submitting a form or opening a new window).
3.2.2 On Input	A	Changing a form control value must not cause an unexpected context change unless the user is informed beforehand.
3.2.3 Consistent Navigation	AA	Navigation menus that appear on multiple pages must be presented in the same relative order.
3.2.4 Consistent Identification	AA	Components that perform the same function must be identified consistently across the site (same icons, labels, and alt text).

3.3 Input Assistance

Criterion	Level	What to Do
3.3.1 Error Identification	A	If an input error is detected, identify the error in text and describe it to the user. Do not rely on color alone.
3.3.2 Labels or Instructions	A	Provide labels or instructions when user input is required. Include format hints (e.g., “Date: DD/MM/YYYY”).
3.3.3 Error Suggestion	AA	When an error is detected and suggestions are known, provide them to the user (e.g., “Did you mean [email protected]?”).
3.3.4 Error Prevention (Legal, Financial, Data)	AA	For pages that cause legal or financial commitments or modify user data, make submissions reversible, verifiable, or confirmable.

Principle 4: Robust

Content must be robust enough that it can be reliably interpreted by assistive technologies.

4.1 Compatible

Criterion	Level	What to Do
4.1.1 Parsing (Obsolete in WCAG 2.2 but still in 2.1)	A	Ensure valid HTML: no duplicate IDs, properly nested elements, complete start and end tags. Use an HTML validator.
4.1.2 Name, Role, Value	A	All UI components must have an accessible name and role. Custom widgets must use ARIA attributes correctly. States (expanded, selected, checked) must be programmatically set.
4.1.3 Status Messages	AA	Status messages (success alerts, form errors, loading indicators) must be communicated to assistive technologies without receiving focus. Use role="alert", role="status", or aria-live regions.

Quick-Reference Developer Checklist

Here is a condensed checklist you can copy into your project management tool or print out for code reviews:

• Images: Every <img> has appropriate alt text (or alt="" if decorative).
• Headings: Heading hierarchy is logical (no skipping levels).
• Color contrast: Text meets 4.5:1 (normal) or 3:1 (large) ratios. UI components meet 3:1.
• Keyboard: All interactive elements are reachable and operable via keyboard.
• Focus indicator: A visible focus ring exists on every focusable element.
• Skip link: A “Skip to main content” link is present.
• Forms: Every input has a visible <label>. Error messages are descriptive and appear in text.
• Autocomplete: Personal data fields use the correct autocomplete attribute values.
• Language: lang attribute is set on <html> and on any content in a different language.
• Responsive: Content reflows at 320px width without horizontal scrolling.
• Text spacing: No content is clipped when text spacing is overridden.
• Motion: Animations can be disabled (respect prefers-reduced-motion).
• Video/Audio: Captions and transcripts are provided.
• ARIA: Used only when native HTML is insufficient. Roles, states, and properties are correct.
• Status messages: Use aria-live regions for dynamic content updates.
• Valid HTML: No duplicate IDs, proper nesting, valid markup.
• Link text: Links are descriptive. No generic “click here” links without context.
• Orientation: Site works in both portrait and landscape.
• Timeouts: Users can extend or disable session time limits.
• Touch targets: Pointer actions fire on the up-event, and single-pointer alternatives exist for complex gestures.

Tools to Help You Test WCAG 2.1 Compliance

Automated tools catch roughly 30-40% of accessibility issues. You still need manual testing and real assistive technology testing. Here are the tools we recommend combining:

• axe DevTools (browser extension) for automated scanning during development.
• WAVE by WebAIM for a visual overview of issues on any page.
• Lighthouse (built into Chrome) for a quick accessibility audit score.
• Colour Contrast Analyser (CCA) for checking contrast ratios of any on-screen color combination.
• NVDA (Windows) or VoiceOver (macOS/iOS) for real screen reader testing.
• Keyboard-only navigation using Tab, Shift+Tab, Enter, Space, and Arrow keys.

Pro tip: Integrate axe-core into your CI/CD pipeline so accessibility regressions are caught before they reach production.

Common WCAG 2.1 Mistakes Developers Make

After auditing hundreds of websites, we see the same problems over and over. Avoid these pitfalls:

1. Removing the focus outline with outline: none and not replacing it with a custom focus style.
2. Using div and span for interactive elements instead of native <button> or <a> tags.
3. Missing or incorrect ARIA attributes on custom components, which confuses screen readers more than having no ARIA at all.
4. Placeholder text as the only label for form fields. Placeholders disappear on input and are not reliable labels.
5. Auto-playing video or audio without user controls to pause or stop it.
6. Color-only error indicators such as turning an input border red without adding an error message in text.
7. Fixed-width layouts that break at higher zoom levels or on narrow viewports.
8. Missing page titles or using the same generic title on every page.

WCAG 2.1 vs. WCAG 2.2: Should You Target 2.2 Instead?

WCAG 2.2 was published in October 2023 and adds nine new success criteria on top of WCAG 2.1. If you are starting a new project in 2026, targeting WCAG 2.2 AA is a smart choice since it is now the latest W3C Recommendation.

However, many legal requirements and organizational policies still reference WCAG 2.1 AA specifically. The good news is that WCAG 2.2 is backwards compatible. Meeting 2.2 AA means you automatically meet 2.1 AA as well.

If your current goal is WCAG 2.1 AA, use the checklist above. When you are ready to go further, the additional 2.2 criteria (like Focus Not Obscured, Dragging Movements, and Accessible Authentication) are natural next steps.

Download and Print Options

Want a portable version of this WCAG 2.1 checklist for developers? You can:

• Bookmark this page for quick reference during code reviews.
• Print this page using your browser’s print function (Ctrl+P / Cmd+P). It prints cleanly.
• Copy the quick-reference checklist into your project’s README, Jira template, or pull request template.

Need help making your website or application WCAG 2.1 AA compliant? Contact Box Software and our development team will audit your site and provide a prioritized remediation plan.

Frequently Asked Questions

What is WCAG 2.1 Level AA?

WCAG 2.1 Level AA is the middle conformance level of the Web Content Accessibility Guidelines version 2.1. It includes all Level A (minimum) criteria plus additional requirements around color contrast, text resizing, navigation, and more. Level AA is the standard most commonly referenced in accessibility laws and regulations worldwide.

How many success criteria are in WCAG 2.1 AA?

WCAG 2.1 contains 78 success criteria in total. At the AA level (which includes Level A), you need to satisfy 50 success criteria. The remaining 28 are Level AAA, which is recommended but not typically required for legal compliance.

Is WCAG 2.1 still relevant in 2026?

Yes. While WCAG 2.2 is the latest version, many contracts, legal standards, and organizational policies still reference WCAG 2.1. Additionally, WCAG 2.2 is a superset of 2.1, so meeting 2.1 AA is a solid foundation even if you later upgrade to 2.2.

Can automated tools fully test WCAG 2.1 compliance?

No. Automated accessibility testing tools can detect approximately 30-40% of WCAG issues. Things like logical reading order, meaningful alt text quality, keyboard trap scenarios, and context-dependent link purposes require manual human testing and screen reader verification.

What is the difference between WCAG 2.1 A, AA, and AAA?

Level A is the minimum level of accessibility. Level AA addresses the most common barriers and is the legal standard in most jurisdictions. Level AAA is the highest level and provides the best user experience for people with disabilities, but it is not always achievable for all types of content.

How do I add a skip navigation link?

Add a visually hidden link as the first focusable element on the page that becomes visible on focus. It should link to the id of your <main> element. Example:

<a href="#main-content" class="skip-link">Skip to main content</a>
...
<main id="main-content">...</main>

Style the .skip-link class so it is positioned off-screen by default and slides into view when it receives keyboard focus.

Does my single-page application (SPA) need to meet WCAG 2.1?

Yes. SPAs face unique accessibility challenges, including managing focus on route changes, announcing dynamic content updates with ARIA live regions, and ensuring the document title updates on navigation. All WCAG 2.1 criteria still apply regardless of your technology stack.