WCAG Compliance Checklist for Web Developers
WCAG 2.1 Level AA is the conformance level required by the ADA, the European Accessibility Act, Section 508, and most other accessibility laws. It includes all Level A criteria plus additional requirements that address the most common barriers disabled users encounter. This checklist organizes those criteria into practical testing categories rather than WCAG's own numbering system, because developers testing a site work through it by feature area, not by specification clause number.
Check Images and Non-Text Content
Every informational image must have an alt attribute with text that describes the image's content and purpose. The alt text should convey what the image communicates to a sighted user, not just describe what the image looks like. A photo of a team at a conference might need alt="Marketing team presenting Q3 results at SaaS Connect 2026" rather than alt="group of people." Product images should describe the product. Charts should summarize the data trend. Icons used as buttons need alt text that describes the action, not the icon shape.
Decorative images that add no informational value, such as background patterns, visual separators, or purely aesthetic photos, should have an empty alt attribute (alt=""). This tells screen readers to skip the image entirely rather than announcing the filename. Never omit the alt attribute entirely; a missing alt attribute causes screen readers to read the image's URL or filename, which is worse than no description.
Complex images like charts, infographics, and diagrams need extended descriptions beyond what fits in an alt attribute. Provide a text summary in the alt attribute and a full description in adjacent text, a linked long description, or an aria-describedby reference to a hidden text block. Data tables are usually a better format than chart images for conveying quantitative information accessibly.
Background images set via CSS are invisible to screen readers. If a CSS background image conveys information (like a hero banner with text baked into the image), that information must also exist as real HTML text positioned over or near the image. WCAG criterion: 1.1.1 Non-text Content (Level A).
Test Color and Contrast
Normal-size text (below 18pt or 14pt bold) must have a contrast ratio of at least 4.5:1 against its background. Large text (18pt and above, or 14pt bold and above) must meet a 3:1 ratio. Use a contrast checker like the one built into Chrome DevTools, the WebAIM Contrast Checker, or the axe-core contrast rules to measure ratios. Common failures include light gray text on white backgrounds, white text on light-colored hero images, and placeholder text in form fields with insufficient contrast.
User interface components and graphical objects that convey information must meet a 3:1 contrast ratio against adjacent colors. This applies to form field borders, icon buttons, chart segments, and focus indicators. A text input with a light gray border on a white background that relies solely on the border to indicate where the field is fails this criterion. WCAG criterion: 1.4.11 Non-text Contrast (Level AA).
Color must not be the only means of conveying information. Error messages should not rely solely on red text; add an error icon, bold text, or a text prefix like "Error:" alongside the color change. Links within body text should be distinguishable from surrounding text by more than just color; underlines, bold weight, or other visual treatment must differentiate them. Charts should use patterns, labels, or other non-color indicators alongside color coding. WCAG criterion: 1.4.1 Use of Color (Level A).
Text should be resizable up to 200% without loss of content or functionality. Test by zooming your browser to 200% and verifying that all text remains readable, no content is clipped or hidden behind other elements, and all interactive functions still work. CSS that uses fixed pixel heights on text containers is the most common cause of content overflow at higher zoom levels. WCAG criterion: 1.4.4 Resize Text (Level AA).
Validate Keyboard Accessibility
Every interactive element must be reachable and operable using only the keyboard. Tab through the page and verify that focus reaches every link, button, form control, dropdown, modal trigger, and custom widget. Elements that respond to mouse clicks but cannot receive keyboard focus are accessibility failures. Native HTML elements like button, a, input, and select are keyboard-accessible by default. Custom elements built with div or span need tabindex="0" to be focusable and JavaScript key event handlers to be operable.
Focus must be visible on every element that receives it. The default browser focus outline is sufficient if not overridden. If your CSS removes outlines (outline: none), you must provide an alternative focus indicator with at least 3:1 contrast against surrounding content. Custom focus styles using box-shadow, border, background color change, or outline with custom styling all work. The focus indicator must be visible in all color themes, including dark mode if your site supports it. WCAG criterion: 2.4.7 Focus Visible (Level AA).
Tab order must follow a logical reading sequence. For left-to-right languages, focus should generally move left-to-right, top-to-bottom through the page, matching the visual layout. Avoid positive tabindex values (tabindex="1", tabindex="2"), which create a custom tab order that almost always produces a confusing sequence. Instead, ensure the DOM order matches the visual order and use CSS for visual positioning. WCAG criterion: 2.4.3 Focus Order (Level A).
No keyboard trap should exist anywhere on the page. A keyboard trap occurs when focus enters a component and cannot leave using standard keyboard interactions (Tab, Shift+Tab, Escape). Modal dialogs are the most common source of keyboard traps: focus should be contained within the modal while it is open (preventing users from tabbing behind it), but pressing Escape or activating the close button must release focus back to the trigger element. Embedded content like iframes, video players, and third-party widgets should also be tested for keyboard traps. WCAG criterion: 2.1.2 No Keyboard Trap (Level A).
Audit Forms and Error Handling
Every form control needs a programmatically associated label. The most reliable method is a label element with a for attribute matching the input's id. For cases where a visible label is impractical (like a search input with a search button next to it), use aria-label on the input. For complex labeling situations where multiple elements contribute to the label, use aria-labelledby. Placeholder text is not a substitute for a label because it disappears when the user starts typing, leaving them with no indication of what the field expects. WCAG criterion: 1.3.1 Info and Relationships (Level A).
Required fields must be indicated both visually and programmatically. Add the required attribute or aria-required="true" to required inputs so screen readers announce them as required. Visual indicators like asterisks are fine but must be accompanied by a text explanation (such as "* Required field") and the programmatic attribute. WCAG criterion: 3.3.2 Labels or Instructions (Level A).
Error messages must identify the specific field with the error and describe how to fix it. "Please correct the errors below" is insufficient. "Email address must include an @ symbol" is effective. Error messages should be programmatically associated with their fields using aria-describedby or aria-errormessage so screen readers announce the error when the user focuses the field. When errors are detected, either move focus to the first error or to an error summary at the top of the form. WCAG criteria: 3.3.1 Error Identification (Level A), 3.3.3 Error Suggestion (Level AA).
Form fields that collect user information should use appropriate autocomplete attributes. Name fields should have autocomplete="name", email fields autocomplete="email", phone fields autocomplete="tel", and address fields the corresponding autocomplete values for street-address, postal-code, and country. Autocomplete helps all users fill forms faster and specifically helps users with cognitive and motor disabilities by reducing the amount of typing required. WCAG criterion: 1.3.5 Identify Input Purpose (Level AA).
Review Page Structure and Semantics
Every page needs a unique, descriptive title in the title element. Page titles are the first thing screen readers announce when a page loads, and they appear in browser tabs, bookmarks, and search results. A title like "Products" is ambiguous across tabs. "Running Shoes for Women | SportStore" provides context about both the page content and the site. WCAG criterion: 2.4.2 Page Titled (Level A).
Headings must follow a logical hierarchy without skipping levels. Start with a single h1 that describes the page's primary content, then use h2 for major sections, h3 for subsections within h2 blocks, and so on. Never skip from h1 to h3 or from h2 to h4. Screen reader users navigate by heading level to scan page structure, and skipped levels create confusion about content organization. Do not choose heading levels based on visual size; use CSS to style headings if the default sizes do not match your design. WCAG criterion: 1.3.1 Info and Relationships (Level A).
Landmark roles must divide the page into navigable regions. Use the header element (or role="banner") for the site header, nav (or role="navigation") for navigation blocks, main (or role="main") for the primary content area, and footer (or role="contentinfo") for the site footer. Screen reader users jump between landmarks to navigate quickly, bypassing repetitive header and navigation content. If a page has multiple nav elements, label each one with aria-label to distinguish them (aria-label="Main navigation" versus aria-label="Footer navigation"). WCAG criterion: 1.3.1 Info and Relationships (Level A).
The HTML element must have a lang attribute specifying the page's primary language (lang="en" for English, lang="fr" for French). Content in a different language than the page's primary language should be wrapped in an element with the appropriate lang attribute so screen readers switch pronunciation rules. A French quote within an English page should be wrapped in span lang="fr" or a similar element. WCAG criteria: 3.1.1 Language of Page (Level A), 3.1.2 Language of Parts (Level AA).
Lists should use proper list markup (ul, ol, li) rather than paragraphs with bullet characters or line breaks. Tables presenting data should use th for header cells with scope attributes indicating whether they are column or row headers. Definition lists, blockquotes, and other semantic elements should be used where appropriate rather than styled divs that look like the correct element but lack its semantic meaning.
Test Dynamic Content and ARIA
Live regions must announce dynamic content changes to screen readers. When content updates without a page reload, such as a notification appearing, a search results count updating, or a chat message arriving, the containing element needs an appropriate aria-live attribute. Use aria-live="polite" for non-urgent updates that should be announced when the screen reader finishes its current task. Use aria-live="assertive" for urgent messages like error alerts that need immediate attention. The role="status" shorthand creates a polite live region, and role="alert" creates an assertive one.
Modal dialogs require careful focus management. When a modal opens, focus must move to the modal (typically to the first focusable element or the modal's heading). While the modal is open, keyboard focus must be trapped within the modal so Tab and Shift+Tab cycle through the modal's controls without escaping to the background page. The background content should be hidden from screen readers using aria-hidden="true" on the main content wrapper or inert on content behind the modal. When the modal closes, focus must return to the element that triggered it.
Custom widgets built with ARIA must use the correct roles, states, and properties as defined in the WAI-ARIA Authoring Practices Guide. A custom dropdown should use role="combobox" or role="listbox" with appropriate aria-expanded, aria-selected, and aria-activedescendant attributes. A tab interface needs role="tablist" on the container, role="tab" on each tab, and role="tabpanel" on each panel, with aria-selected tracking the active tab and aria-controls linking tabs to their panels. Incorrect ARIA is worse than no ARIA because it provides misleading information to screen readers.
Content that moves, blinks, or auto-updates must be controllable by the user. Carousels should have pause controls. Auto-refreshing content should allow the user to pause or extend the update interval. No content should flash more than three times per second, as this can trigger seizures in people with photosensitive epilepsy. WCAG criteria: 2.2.2 Pause, Stop, Hide (Level A), 2.3.1 Three Flashes or Below Threshold (Level A).
Using This Checklist Effectively
Run through this checklist on a representative sample of pages rather than trying to audit every page individually. Test the homepage, one or two key landing pages, the login and registration flows, a product or content page, the checkout or primary conversion flow, and any pages with complex interactive components. Issues found on sample pages typically recur across the site because they stem from shared templates, components, and CSS.
Combine this manual checklist with automated scanning. Run axe-core or Lighthouse accessibility audits first to catch the machine-detectable violations, then use this checklist to cover the issues automation misses. Track findings in a spreadsheet or issue tracker with the WCAG criterion number, severity, page URL, element description, and recommended fix for each issue.
Prioritize fixes by user impact. Issues that prevent task completion (keyboard traps, missing form labels, broken modal focus management) are more urgent than issues that cause inconvenience (suboptimal alt text, minor contrast failures in non-essential decorative elements). A remediation plan that fixes the highest-impact issues first delivers the greatest accessibility improvement per hour of development effort.
A thorough WCAG compliance audit requires testing images, color contrast, keyboard access, forms, page structure, and dynamic content. Automated tools handle roughly a third of these checks; the rest require manual evaluation using this checklist alongside real screen reader and keyboard testing.