TLDR
WCAG 2.1 AA has 50 success criteria. In practice, the same 8-10 failures appear on most SMB client sites. This checklist covers the high-frequency issues: what they are, how to identify them, and how to fix them. Agencies that build these checks into their standard workflow catch most issues before launch.
- WCAG 2.1 AA
- Web Content Accessibility Guidelines version 2.1 at conformance level AA. AA is the middle tier (above A, below AAA) and is the standard referenced in most legal and policy frameworks. Conformance means meeting all Level A and Level AA success criteria.
DEFINITION
- Success criterion
- An individual testable requirement within WCAG. WCAG 2.1 includes 78 success criteria at levels A, AA, and AAA. Level A has 30 criteria, Level AA adds 20 more (for 50 total that define AA conformance).
DEFINITION
- Focus indicator
- The visible outline or highlight that shows which element currently has keyboard focus. Users who navigate with a keyboard (including many users with motor disabilities) rely on the focus indicator to orient themselves on the page. WCAG 2.4.7 requires that the focus indicator be visible.
DEFINITION
- Accessible name
- The text that assistive technology (screen readers, voice control) uses to identify an interactive element. For buttons, the accessible name comes from the button text. For images, from alt text. For form inputs, from associated labels. Missing accessible names are among the most frequent WCAG failures.
DEFINITION
WCAG 2.1 has 50 success criteria at the AA conformance level. Reading all 50 and cross-referencing them against a client site during every project is not a realistic workflow. The practical approach is knowing which criteria cause the most failures on the types of sites you build, building those checks into your standard process, and using automated scanning to catch structural failures consistently.
This checklist is organized by failure frequency on SMB agency client sites. The top items appear on the majority of sites that have not been built with accessibility in mind. The bottom items appear less frequently but are important enough to check explicitly.
1. Color Contrast (WCAG 1.4.3)
Requirement: Normal text — 4.5:1 contrast ratio against background. Large text (18pt or 14pt bold and above) — 3:1 ratio.
What fails: Brand colors applied to text that were chosen for aesthetics without contrast testing. Light gray text on white backgrounds. Colored text on colored backgrounds in hero sections. Placeholder text in form fields.
How to check: Automated scanners catch most contrast failures. The WebAIM Contrast Checker or Chrome DevTools accessibility panel can verify specific combinations.
How to fix: Darken text or lighten backgrounds until the ratio meets the threshold. For brand colors that fail, find the closest compliant variant. This is a design decision — involve the designer, not just the developer.
2. Image Alternative Text (WCAG 1.1.1)
Requirement: Informative images have alt text that describes the content or function. Decorative images have empty alt attributes (alt="").
What fails: Images with no alt attribute at all. Alt text that says “image” or contains the filename. CMS users adding images without filling in alt fields. SVG icons without accessible names.
How to check: Automated scanners catch missing alt attributes. Human review is needed to evaluate whether present alt text is accurate and descriptive.
How to fix: Add alt text to informative images. Add alt="" to decorative images (this tells screen readers to skip the image). For icon buttons with no text, add aria-label to the button element.
3. Form Labels (WCAG 1.3.1, 4.1.2)
Requirement: Every form input has a programmatically associated label. The association must be in the code (via for/id attributes or aria-labelledby), not just visually near the input.
What fails: Placeholder text used as a substitute for visible labels. Labels that are visually near inputs but not programmatically associated. Contact forms built in page builders without label configuration.
How to check: Automated scanners catch missing label associations. Also test by tabbing into each input and listening to what a screen reader announces.
How to fix: Add <label for="inputId"> elements. If the design requires no visible label, use aria-label or aria-labelledby on the input. Do not rely on placeholder text alone — it disappears on focus and does not satisfy WCAG.
4. Keyboard Navigation (WCAG 2.1.1)
Requirement: All functionality available via mouse must also be accessible via keyboard. Users must be able to navigate to and activate all interactive elements using Tab, Shift+Tab, Enter, Space, and arrow keys.
What fails: Custom dropdown menus or megamenus that only respond to hover. Modal dialogs that trap keyboard focus or don’t close on Escape. Video players with controls that can’t receive keyboard focus. Carousels where next/previous controls are images without keyboard handling.
How to check: Close the mouse, open the site, and tab through every interactive element. If you can’t reach it or activate it with a keyboard, it fails.
How to fix: Add tabindex="0" to custom interactive elements that need keyboard focus. Add keyboard event listeners (Enter/Space for buttons, arrow keys for menus). Use standard HTML elements where possible — <button>, <a>, <select> are keyboard-accessible by default.
5. Focus Indicator Visibility (WCAG 2.4.7)
Requirement: The keyboard focus indicator — the visible outline showing which element is focused — must be visible at all times during keyboard navigation.
What fails: CSS that removes focus outlines (outline: none or outline: 0) without providing an alternative. Focus indicator styles that have insufficient contrast against the element’s background.
How to check: Keyboard-navigate the site and confirm the focus indicator is always visible. Check in multiple browsers (focus indicator styles differ by browser).
How to fix: Remove CSS rules that suppress focus outlines without replacement. Add custom focus styles (outline: 2px solid with sufficient contrast) that match the design system.
6. Skip Navigation (WCAG 2.4.1)
Requirement: A mechanism to bypass repeated blocks of content (navigation, header) and jump directly to the main content.
What fails: No skip link present. Skip link present but hidden from keyboard users (invisible and never visible on focus). Skip link present but linking to an element that can’t receive focus.
How to check: Press Tab once after loading the page. The first focusable element should be a “Skip to main content” link or equivalent.
How to fix: Add a visually hidden skip link that becomes visible on focus, linking to a <main> element or a #main-content anchor. Test that tabbing to the link and pressing Enter actually moves focus to the main content.
7. Page Title (WCAG 2.4.2)
Requirement: Each page has a descriptive title that identifies the page’s topic. Titles should be unique across the site.
What fails: All pages using the site name as the title with no page-specific information. CMS pages with auto-generated titles that include IDs or slugs. Template pages where the title variable is empty.
How to check: Automated scanners check for missing titles. Human review confirms uniqueness and descriptiveness.
How to fix: Configure CMS templates to include page-specific content in title tags. Use the pattern “Page Name | Site Name” consistently.
8. HTML Language Attribute (WCAG 3.1.1)
Requirement: The <html> element has a lang attribute that identifies the primary language of the page.
What fails: HTML templates without the lang attribute. Multi-language sites where the lang attribute is not updated per language. CMS themes that omit the lang attribute.
How to check: Automated scanners catch missing lang attributes. Inspect the <html> element in DevTools.
How to fix: Add lang="en" (or the appropriate language code) to the <html> element in page templates. For multi-language sites, dynamically set the lang attribute based on the active language.
Automating These Checks
Build automated scanning into your development workflow to catch items 1, 2, 3, 7, and 8 without manual effort on every project. Items 4, 5, and 6 require quick manual verification that takes 10-15 minutes per site.
A consistent process: automated scan at launch milestone, manual keyboard test for navigation and focus, final scan confirmation before client delivery.
Q&A
What is the WCAG 2.1 AA checklist for agency client sites?
The highest-priority WCAG 2.1 AA checks for typical agency client sites: (1) Color contrast — 4.5:1 ratio for normal text, 3:1 for large text (1.4.3). (2) Alt text on images — descriptive for informative images, empty alt for decorative (1.1.1). (3) Form labels — every input has an associated label (1.3.1, 4.1.2). (4) Keyboard navigation — all functionality accessible without a mouse (2.1.1). (5) Focus visible — keyboard focus indicator visible at all times (2.4.7). (6) Skip navigation — link to skip repetitive navigation (2.4.1). (7) Page titles — unique, descriptive title tags on every page (2.4.2). (8) Language attribute — HTML lang attribute present (3.1.1).
Q&A
How should agencies document WCAG compliance for clients?
Document with a before-and-after audit report: automated scan before remediation showing issues by WCAG criterion, remediation confirmation scan showing issues resolved, and any outstanding items with remediation timeline. A WCAG conformance statement (declaring WCAG 2.1 AA conformance, the date evaluated, and known exceptions) is appropriate for clients who need formal documentation.
Want to learn more?
Frequently asked