Guide

ADA Website Compliance Checklist for WordPress: WCAG 2.1 AA, With the Fix for Every Item

Most ADA checklists stop at "provide text alternatives for non-text content." That tells you the rule, not where the failing image is or which screen to open to fix it. This one names, for each item, the axe-core rule that catches it, the WCAG criterion behind it, and the place in WordPress where the fix goes. Sixteen items a scanner can check, then the ones only a person can.

Published by M.Lighthouse Agency. This page is not legal advice.

How to Use This Checklist

The ADA does not publish a technical checklist for private websites. What it has is the Department of Justice's web accessibility guidance, which lists the barriers that show up in enforcement, and the DOJ's 2024 rule for state and local governments, which requires WCAG 2.1 Level AA. Every honest ADA checklist is therefore a rendering of WCAG 2.1 AA, and so is this one. It is grouped the way WCAG is, by its four principles, and ordered inside each group by how often the item fails in the wild, using the WebAIM Million's February 2026 numbers.

Each item has three lines. Check is what to look for. Rule is the axe-core rule ID that catches it, so you can match it to a scan report from WCAGpatch or any other axe-based tool. Fix in WordPress is where the correction actually lives. Run a scan first, then work the list; the scan tells you which items apply to your site and on which pages. The free tier does that.

Perceivable: Can It Be Seen or Heard?

1. Text contrast is at least 4.5:1

Check: body text, links, and button labels against their backgrounds. Large text (24px, or 19px bold) needs 3:1. Fails on 83.9% of home pages. WCAG 1.4.3.
Rule: color-contrast.
Fix in WordPress: Appearance → Editor → Styles (block themes) or Appearance → Customize → Colors (classic themes). Change the palette color, not each block, or the fix will not hold on new pages.

2. Every meaningful image has alt text

Check: images that carry information have a text alternative; purely decorative ones have an empty alt="". Fails on 53.1% of home pages. WCAG 1.1.1.
Rule: image-alt, plus svg-img-alt, role-img-alt, input-image-alt, area-alt, object-alt for the less common cases.
Fix in WordPress: Media → Library → the image → "Alternative Text." That field feeds every block that uses the image. On Pro and up, WCAGpatch's AI fixer writes into this field.

3. Video has captions; audio has a transcript

Check: every <video> with speech has a captions track; every audio-only file has a transcript on the page. WCAG 1.2.1 and 1.2.2.
Rule: video-caption. axe flags the missing track; it cannot judge whether captions are accurate.
Fix in WordPress: Video block → "Text tracks" → upload a .vtt file. For embedded YouTube, captions live on YouTube, not in WordPress.

4. Links inside paragraphs are distinguishable without color

Check: a link in body text is underlined, or differs from the surrounding text by 3:1 and shows a non-color cue on hover or focus. WCAG 1.4.1.
Rule: link-in-text-block.
Fix in WordPress: Styles → Links (block themes) or the theme's link-underline setting. Re-enable underlines; most themes remove them for looks.

5. Content does not rely on blink or marquee

Check: no <blink> or <marquee> elements. Rare on modern themes, still present in old page-builder templates. WCAG 2.2.2.
Rule: blink, marquee.
Fix in WordPress: edit the block or template that contains it; replace with static text.

Operable: Can It Be Used Without a Mouse?

6. Every link has a name

Check: no link is an icon or image alone with no text and no accessible name. Fails on 46.3% of home pages; social icons and "read more" arrows are the usual culprits. WCAG 2.4.4 and 4.1.2.
Rule: link-name.
Fix in WordPress: Social Icons block → each icon's label; for image links, the image's alt text becomes the link name, so fill it in. In classic themes, the widget's "title" or "link text" field.

7. Every button has a name

Check: hamburger menus, search icons, cart icons, and carousel arrows announce something. Fails on 30.6% of home pages. WCAG 4.1.2.
Rule: button-name, input-button-name.
Fix in WordPress: Navigation block → "Overlay menu" label; Search block → button text or "label" toggle. Theme-rendered icons usually need an aria-label in the theme's header template, which is developer territory.

8. There is a way to skip repeated content

Check: a "skip to content" link is the first focusable element, or the page has proper landmarks a screen reader can jump between. WCAG 2.4.1.
Rule: bypass.
Fix in WordPress: most block themes ship a skip link; classic themes vary. If missing, it is one line in header.php pointing at the main content's id. Also confirm the page has one <main> landmark.

9. Frames have titles

Check: every <iframe> (maps, embedded forms, video) has a title attribute that says what it is. WCAG 4.1.2.
Rule: frame-title, frame-title-unique.
Fix in WordPress: for a Custom HTML block, add title="Store location map" to the tag. Embed blocks for YouTube and Vimeo set it automatically; third-party map and form plugins often do not.

10. Scrollable regions can be reached by keyboard

Check: any box with its own scrollbar (a code sample, a long table, a fixed-height testimonial list) can be focused and scrolled with the keyboard. WCAG 2.1.1.
Rule: scrollable-region-focusable.
Fix in WordPress: add tabindex="0" to the scrolling container in the block's Advanced → "Additional CSS class" (with a line of CSS) or in the Custom HTML block itself.

11. The page does not refresh or redirect on a timer

Check: no <meta http-equiv="refresh">. WCAG 2.2.1.
Rule: meta-refresh.
Fix in WordPress: usually left over from a redirect plugin or a "coming soon" template; remove the tag and use a proper 301 in the redirect plugin.

12. Audio does not autoplay

Check: no audio or video with sound starts on its own for more than three seconds without a control to stop it. WCAG 1.4.2.
Rule: no-autoplay-audio.
Fix in WordPress: Video block → uncheck "Autoplay," or keep autoplay and check "Muted."

Understandable: Does It Make Sense to Software?

13. Every form field has a label

Check: each input has a real <label> or an aria-label, not just a placeholder that disappears on typing. Fails on 51% of home pages, usually the newsletter box and the search field. WCAG 1.3.1 and 3.3.2.
Rule: label, select-name, form-field-multiple-labels, aria-input-field-name.
Fix in WordPress: in your form plugin (Contact Form 7, WPForms, Gravity Forms, Fluent Forms), each field has a Label setting; fill it, and if the design hides it, use the plugin's "hide label visually" option rather than deleting it.

14. The page declares its language

Check: the <html> tag has a valid lang attribute that matches the content. WCAG 3.1.1.
Rule: html-has-lang, html-lang-valid, valid-lang.
Fix in WordPress: Settings → General → Site Language. Themes that hard-code the <html> tag without language_attributes() break this; that is a theme bug.

15. Every page has a title

Check: the <title> is present and describes the page, not just the site. WCAG 2.4.2.
Rule: document-title.
Fix in WordPress: the page's title field; your SEO plugin's title template controls the format. An empty title usually means a theme without add_theme_support('title-tag').

Robust: Does the Markup Hold Up?

16. ARIA is valid and lists are real lists

Check: ARIA roles and attributes are spelled correctly, used on elements that allow them, and have the children they require; list markup contains only list items; no interactive control is nested inside another. Page builders and slider plugins are the usual source. WCAG 1.3.1 and 4.1.2.
Rule: aria-roles, aria-valid-attr, aria-valid-attr-value, aria-allowed-attr, aria-required-attr, aria-required-children, aria-required-parent, aria-hidden-focus, duplicate-id-aria, list, listitem, nested-interactive.
Fix in WordPress: identify the plugin that renders the flagged element (the scan report gives the selector), then update it, replace it, or raise it with the plugin's support. Block-editor core blocks pass these.

The Manual Checks No Scanner Can Do

The sixteen items above cover what axe-core can determine from the code. Across WCAG as a whole, roughly 30 to 40 percent of success criteria are machine-checkable, and the DOJ's guidance recommends pairing an automated checker with manual testing for exactly that reason. These are the checks that need a person, a keyboard, and a screen reader (VoiceOver on Mac and iPhone, NVDA free on Windows). Budget an hour for a small site.

  • Keyboard only. Unplug the mouse. Tab through the home page, a product or service page, the contact form, and checkout. Can you reach everything, see where you are at every step, and never get stuck? (WCAG 2.1.1, 2.1.2, 2.4.7)
  • Alt text quality. The scan confirms alt text exists. Read it. "IMG_4032.jpg" and "image" pass the scanner and fail the person.
  • Heading order. One <h1>, then <h2> for sections, <h3> inside them, no skipped levels. Themes that use headings for size rather than structure are the usual problem. (WCAG 1.3.1, 2.4.6)
  • Reading order. With styles off (or a screen reader running), does the content come in a sensible order? Multi-column builder layouts often read column by column in the wrong sequence. (WCAG 1.3.2)
  • Form errors. Submit the form empty. Are the errors announced, described in text, and placed next to the field? (WCAG 3.3.1, 3.3.3)
  • Zoom and reflow. At 400% browser zoom, does the page reflow to one column with no horizontal scroll? (WCAG 1.4.10)
  • Motion. Can carousels and background video be paused? Do they respect the operating system's reduced-motion setting? (WCAG 2.2.2)
  • Consistency. Is the navigation in the same place and order on every page, and do the same icons mean the same thing everywhere? (WCAG 3.2.3, 3.2.4)
  • PDFs and documents. Every linked PDF is part of the site. Tagged, with real text, with headings? Or a scan of a printout?

Write down what you find, with the date. Together with the scan history, that log is the record of good-faith effort described on the WCAG certification page, and the thing your lawyer will ask for first if a demand letter ever arrives.

Common Questions

Is there an official ADA website compliance checklist?

No. The ADA does not name a technical standard for private business websites. The DOJ's guidance lists common barriers and points to WCAG, and its 2024 rule for state and local governments requires WCAG 2.1 AA. So every checklist, including this one, is a rendering of WCAG 2.1 AA. This one adds the axe rule and the WordPress fix location for each item.

What is the difference between WCAG 2.1 AA and WCAG 2.2?

WCAG 2.2 adds nine success criteria on top of 2.1, mostly about focus visibility, dragging alternatives, target size, and authentication. Everything in 2.1 AA is still in 2.2 AA. Courts, demand letters, and the DOJ's 2024 rule cite 2.1 AA, so that is the level this checklist targets.

How much of this checklist can a scanner do for me?

The 16 automated items. Roughly 30 to 40 percent of WCAG success criteria can be checked by software; the rest, listed in the manual section, need a person with a keyboard and a screen reader. WCAGpatch's free tier runs the automated items on a WordPress site; the manual section is yours.

Which items on the checklist cause the most failures?

Per the WebAIM Million's February 2026 report: low-contrast text on 83.9 percent of home pages, missing alt text on 53.1 percent, missing form labels on 51 percent, empty links on 46.3 percent, and empty buttons on 30.6 percent. Those five are items 1, 2, 13, 6 and 7 here.

Do I need to edit theme code to fix these?

For most items, no. Alt text lives in the Media Library, labels in the form plugin, colors in the theme's global styles or Customizer, link text in the block editor, and the language attribute in Settings. Heading order and landmark problems sometimes trace to a theme template, and those are the items where a developer may be needed.

Once everything passes, is my site ADA compliant?

No tool or checklist can promise that, because compliance is a legal conclusion about how a court reads Title III. Passing the automated items and doing the manual checks means you have removed the barriers the DOJ lists and can show the work. That is what settlement discussions look for, and it is the honest limit of any checklist. Questions about a specific finding go to support.

Sources

  1. W3C, "How to Meet WCAG (Quick Reference)," WCAG 2.1. Success criterion numbers cited on each item.
  2. DOJ, "Guidance on Web Accessibility and the ADA". Common barriers; recommendation to pair automated and manual testing; the 2024 Title II rule's WCAG 2.1 AA requirement.
  3. WebAIM Million, February 2026. Failure percentages: contrast 83.9%, alt text 53.1%, form labels 51%, empty links 46.3%, empty buttons 30.6%. The ordering of items by those figures and the WordPress fix locations are ours.
  4. Deque, axe-core rule descriptions. Rule IDs are those tagged wcag2a and wcag2aa in axe-core 4.11.1, the version WCAGpatch ships.
  5. WCAGpatch product facts, checked 2026-09-07: the plugin runs axe-core with the wcag2a and wcag2aa tag set on Pro and Agency and the PHP-side checks on every tier; the 30 to 40 percent automated-coverage figure is the disclaimer in this site's footer.

Let the Scan Tell You Which Items Apply

The free tier runs the automated checks on your WordPress site and reports them by page and by rule ID, so you can match every finding to a line on this list.

Questions about a specific finding? Support is a human, and usually the same day.