WordPress ADA Compliance Guide 2026: Complete Website Accessibility Checklist

WordPress ADA compliance starts with a simple truth: your website can look sharp, load fast and still shut out real people. A visitor using a screen reader can hit a wall at an unlabeled button. Someone navigating by keyboard can get lost when the focus outline disappears. A person with low vision can leave because your light-gray text vanishes on a white background.

These accessibility barriers are more common than most site owners realize. In this guide we cover what WordPress ADA compliance really means, how WCAG fits in, what the law does and doesn’t say in 2026, and a practical checklist to find and fix problems.

One honest note first: no checklist, plugin or agency can promise your website is “lawsuit-proof.” What accessibility work can do is remove real barriers for real users and reduce legal risk. That is the goal of everything below.

What Is WordPress ADA Compliance?

In short: WordPress ADA compliance means making your WordPress website usable by people with disabilities, including visitors who rely on screen readers, keyboard navigation, captions, magnification or voice control. Most businesses measure this against the Web Content Accessibility Guidelines (WCAG).

The ADA (Americans with Disabilities Act) is a U.S. civil rights law that prohibits discrimination based on disability. It was written long before modern websites, so it has no technical web checklist. WCAG fills that gap. It is the technical yardstick most organizations, auditors and courts use to judge whether a website is accessible.

WCAG is built on four principles, often called POUR:

• Perceivable: Content can be perceived, with text alternatives for images, captions for video and enough color contrast.
• Operable: Menus, buttons, forms and controls work, including without a mouse.
• Understandable: Content and functionality are clear and predictable, with helpful error messages.
• Robust: Content works across browsers, devices and assistive technologies.

WCAG also has three conformance levels: A (the basics), AA (the level most laws and policies target) and AAA (the highest, not usually required across a whole site).

Why WordPress sites need attention: WordPress core has an active accessibility team, and its documentation states it targets WCAG 2.2 Level AA for development. But your site is more than core. It is your theme, page builder, plugins, popups, forms and content. Any of these can introduce barriers, even when core is solid.

Can I Get Sued If My Website Is Not ADA Compliant?

Short answer: It is possible. Accessibility barriers can create legal risk, but whether the ADA applies to a specific website or business depends on the facts, the applicable law and the jurisdiction. This is general information, not legal advice.

Government websites (ADA Title II). The DOJ’s 2024 rule requires state and local government websites and mobile apps to meet WCAG 2.1 Level AA. The original deadlines were April 2026 and April 2027. On April 20, 2026, the DOJ issued an Interim Final Rule moving them back one year. Public entities with a population of 50,000 or more now have until April 26, 2027, and smaller entities and special districts until April 26, 2028. The technical standard did not change, and existing nondiscrimination obligations still apply.

Private businesses (ADA Title III). The picture is less clear-cut. As of this writing, the DOJ has not adopted a specific technical web rule for private businesses, and courts have handled website accessibility claims differently. Even so, accessibility complaints, demand letters and lawsuits against businesses do happen, and WCAG is often the reference point.

In practice:

• Don’t assume you’re immune because you’re a small business.
• Don’t assume you’re automatically liable either. Facts and jurisdiction matter.
• Take any complaint or demand letter seriously and talk to a qualified attorney.
• A clean automated scan does not eliminate legal risk, because tools catch only some issues.
• Treat accessibility as a way to serve more customers, not only as a defensive move.

Barriers create legal risk, but the smarter reason to fix them is that they cost you visitors, leads and sales every day.

What Are the Requirements for an ADA Website Compliance Checklist?

In short: There is no single official “ADA checklist” for websites. Most checklists are built from WCAG success criteria, usually at Level AA. A solid one covers images, headings, links, keyboard access, focus, color, forms, media, menus, tables, documents and dynamic content.

Accessibility Area	What to Check
Images	Informative images have meaningful alt text; decorative images are marked decorative
Headings	Logical H1-H6 structure, not chosen for looks
Links	Descriptive link text (not “click here”)
Keyboard	Every function works without a mouse
Focus	Keyboard focus is clearly visible
Color	Text, buttons and form fields have adequate contrast
Forms	Visible labels, clear instructions, helpful error messages
Videos	Captions for prerecorded video
Audio	Transcripts where appropriate
PDFs	Downloadable documents are accessible too
Menus	Navigation works with a keyboard and on mobile
Buttons	Clear names and states (expanded, selected)
Tables	Proper header cells and structure
Content	Clear, readable language
Zoom	Content stays usable when enlarged
Mobile	Accessibility holds up on small screens
Screen readers	Important content is announced correctly
Dynamic content	Updates such as errors and confirmations are communicated

What Are the New WCAG Standards for 2026?

In short: WCAG 2.2 is the current W3C recommendation for WCAG 2. It was published in October 2023, so it isn’t brand new in 2026. It is simply the latest version and the one W3C recommends using.

• WCAG 2.0: The older foundation. Useful mainly as background.
• WCAG 2.1: Added mobile, low-vision and cognitive criteria. It is the standard in the DOJ’s Title II rule, so it still matters a lot.
• WCAG 2.2: Adds nine new success criteria to 2.1 and removes one obsolete criterion (4.1.1 Parsing). Meeting 2.2 AA generally also means meeting 2.1 AA.

What’s New in WCAG 2.2?

New Criterion	Level	Plain English
2.4.11 Focus Not Obscured (Minimum)	AA	A focused element can’t be completely hidden behind sticky headers or cookie banners
2.4.12 Focus Not Obscured (Enhanced)	AAA	No part of the focused element is hidden
2.4.13 Focus Appearance	AAA	Focus indicators must be large and contrasty enough to see
2.5.7 Dragging Movements	AA	Anything that needs dragging also needs a simple alternative
2.5.8 Target Size (Minimum)	AA	Clickable targets are at least 24×24 CSS pixels, or have enough spacing
3.2.6 Consistent Help	A	Help options (contact link, chat) appear in the same place across pages
3.3.7 Redundant Entry	A	Don’t make users re-enter information already provided in the same process
3.3.8 Accessible Authentication (Minimum)	AA	Logins shouldn’t depend on memory or puzzle-solving without an alternative
3.3.9 Accessible Authentication (Enhanced)	AAA	A stricter version of the above

A common mix-up: Status Messages (4.1.3) is not new in 2.2. It arrived in WCAG 2.1 at Level AA. It requires that updates like “Item added to cart” or “Form submitted” are announced to assistive technology without moving focus.

WCAG 2.1 vs WCAG 2.2 for WordPress Websites

Area	WCAG 2.1	WCAG 2.2
Levels A, AA, AAA	Yes	Yes
Keyboard accessibility	Covered	Covered
Color contrast	Covered	Covered
Mobile and reflow	Covered	Covered
Status messages (4.1.3)	Yes, AA	Yes, AA (unchanged)
Focus visibility	Focus Visible (AA)	Adds Focus Not Obscured (AA) and Focus Appearance (AAA)
Target size	Enhanced version only (AAA)	Adds Target Size Minimum (AA)
Authentication	Not addressed	Adds Accessible Authentication
Dragging	Not addressed	Adds Dragging Movements
Consistent Help / Redundant Entry	Not addressed	Added at Level A
4.1.1 Parsing	Included	Removed

Why this matters: the law that applies to your organization may reference one version, while current best practice is another. Government entities under Title II are held to WCAG 2.1 AA, while WordPress itself develops against 2.2 AA. For most site owners, building to WCAG 2.2 AA is the safest technical target because it covers 2.1 AA too. A qualified attorney can tell you which standard applies to you.

Is WordPress ADA Compliant?

Short answer: WordPress core aims for accessibility, but a WordPress website is not automatically ADA compliant. It depends on your theme, plugins, page builder, content and ongoing maintenance.

Think of WordPress as a solid foundation. A perfectly accessible core can still be paired with a theme with weak focus styles, a slider that traps keyboard users or a popup plugin that ignores screen readers.

The WordPress ADA Compliance Checklist for 2026

Work through this page by page, starting with your homepage, main service pages, contact page and any page with forms.

1. Add Proper Alt Text to Images

• Informative images (product photos, charts, team photos) need short, meaningful alt text.
• Decorative images (dividers, background flourishes) should be marked decorative so screen readers skip them. In WordPress that generally means an empty alt attribute.
• Avoid keyword stuffing. Alt text is for people first.
• Skip “image of” or “picture of.” Screen readers already announce it’s an image.
• Images containing text need that text in the alt text, or better, use real text.

Good: “Owner of a bakery handing a customer a box of cupcakes.” Poor: “cupcakes best bakery san diego cheap cupcakes order now.”

2. Use a Proper Heading Structure

• Use one clear H1 per page.
• Follow a logical hierarchy: H2 for main sections, H3 for subsections. Don’t skip levels.
• Never choose a heading level just for its size. Style text in your theme or builder instead.

Screen reader users often navigate by headings, so a broken outline is like a book with a scrambled table of contents.

3. Make Your Website Keyboard Accessible

Unplug your mouse and try to use your site. These keys should work:

• Tab / Shift + Tab: move forward and backward through links, buttons and fields.
• Enter: activate links and buttons.
• Space: toggle checkboxes and press buttons.
• Arrow keys: move within menus, tabs, sliders and radio groups where applicable.
• Escape: close popups, dropdowns and modals.

You should reach everything and never get stuck. A page where the keyboard gets trapped inside a widget is called a keyboard trap, and it is one of the most frustrating barriers there is.

4. Make Focus Indicators Visible

When you tab through a page, you should see exactly where you are. Many themes remove the focus outline for looks, which leaves keyboard users guessing. Keep a strong, high-contrast focus style, and make sure sticky headers, chat widgets and cookie banners don’t cover the focused element.

5. Check Color Contrast

Contrast is one of the most common failures on WordPress sites. At Level AA:

• Normal text: at least 4.5:1 against its background.
• Large text: at least 3:1.
• Buttons, icons, form field borders and focus indicators: generally at least 3:1 against neighboring colors.

Watch for light-gray placeholder text, text over photos or gradients, and brand-colored buttons with white text that look fine to you but fail the ratio.

6. Make Forms Accessible

Forms are where visitors become leads, so barriers here hurt most.

• Every field needs a visible, properly connected label. Placeholder text alone is not a label.
• Give clear instructions, including required fields and expected formats.
• Identify errors in text, say what went wrong and how to fix it. Don’t rely on red color alone.
• Make the whole form work with a keyboard.
• Announce success and error messages to assistive technology.
• Don’t force people to re-enter information they already gave.

7. Make Videos and Audio Accessible

• Add captions to prerecorded video.
• Provide transcripts for audio and, where appropriate, video.
• Don’t autoplay media with sound.
• Make sure player controls are labeled and work with a keyboard.

8. Check Your Navigation

Test with a keyboard and a screen reader: the main menu and dropdowns, search, breadcrumbs, footer links and the mobile “hamburger” menu. Add a skip link (“Skip to main content”) as one of the first focusable elements so keyboard users don’t have to tab through your whole menu on every page.

9. Check Popups and Modals

Popups are a common trouble spot on modern WordPress sites. A good one should:

• Be reachable and usable by keyboard.
• Move focus into the popup when it opens and return it when it closes.
• Have an obvious, labeled close button.
• Close with the Escape key.
• Announce itself to screen readers.
• Keep focus from wandering onto the hidden page behind it.

10. Make PDFs and Downloads Accessible

Accessibility doesn’t stop at your web pages. Price sheets, brochures, menus and forms offered as PDFs need real text (not scanned images), tagged headings and alt text. If a PDF is hard to fix, offer the same information as a regular web page.

11. Don’t Forget Mobile, Zoom and Reflow

• Content should stay usable when text is enlarged to 200%.
• Layouts should reflow on small screens without sideways scrolling.
• Tap targets should be large enough to press accurately (WCAG 2.2 sets a 24×24 CSS pixel minimum).

How to Check if Your WordPress Website Is ADA Compliant

W3C is clear that WCAG conformance involves both automated checks and human evaluation. Follow this workflow:

1. Run an automated scan to find common issues like missing alt text, low contrast and missing form labels.
2. Review results manually. Tools produce false positives and miss real problems.
3. Navigate with only a keyboard. Check tab order, focus visibility and traps.
4. Test with a screen reader and listen to how pages are announced.
5. Check mobile accessibility on real phones, with zoom and rotation.
6. Test your forms with errors and with valid data, using only a keyboard.
7. Check multimedia for captions, transcripts and controls.
8. Fix the issues, starting with the ones that block people entirely.
9. Retest to confirm fixes worked and didn’t create new problems.
10. Keep testing after updates. New themes, plugin updates and new content can bring barriers back.

A real-world example: a site can pass an automated scan and still have a mobile menu keyboard users can’t open. That is why the manual steps matter.

What Is the Best ADA Compliance Tool for a Website?

Short answer: There is no single best tool. Each type catches different problems, and none can certify legal compliance on its own.

Tool Type	Best For	Limitation
Automated scanner	Fast detection of common technical issues	Catches only a portion of issues
Browser accessibility audit	Checking individual pages while you build	Page-by-page, needs interpretation
Screen reader	Seeing the real experience of assistive-technology users	Takes practice to use well
Keyboard testing	Finding focus, navigation and trap problems	Manual and time-consuming
Manual accessibility audit	Deeper, expert evaluation against WCAG	Takes more time and expertise

The best “tool” is a combination: an automated scan for the easy wins, keyboard and screen-reader testing, and a human expert who can interpret the results.

Can an ADA Compliance Plugin Make WordPress Accessible?

Short answer: No. A plugin or widget can help, but it should never be treated as a guarantee of accessibility or legal compliance.

Accessibility issues live in many places: your theme, page builder, custom JavaScript, third-party plugins and your own content. One plugin can’t reliably rewrite all of that. Accessibility “overlays” that promise one-click compliance are especially risky. They can add a toolbar of options while leaving the underlying code barriers in place, and in some cases they interfere with the assistive technology people already use.

Some plugins are genuinely useful as helpers, such as tools that flag issues while you edit content or add skip links. Use them as part of a process, not a substitute for one. Since plugins also affect your site’s safety, our WordPress security services can help you keep your plugin stack lean and updated.

WordPress Themes, Plugins and Page Builders: What Should You Check?

Choose an Accessibility-Ready Theme

Look for themes tagged “accessibility-ready,” then verify the claims yourself. Check for semantic HTML, keyboard-friendly menus (including dropdowns), visible focus states, skip links, properly built forms and sufficient default contrast.

Audit Your Plugins

Plugins are a frequent source of barriers. Test anything interactive: popups and modals, sliders and carousels, contact and booking forms, calendars and event widgets, mega menus and JavaScript-heavy features.

Test Your Page Builder Output

Whether you build with Elementor, Gutenberg, Divi or another builder, don’t assume the output is automatically accessible. A builder gives you the tools, but how you use them (headings, contrast, spacing, labels) decides the result. If you use Elementor, our WordPress Elementor website design team builds with these checks in mind.

ADA vs WCAG: What’s the Difference?

ADA	WCAG
A U.S. civil rights law	A set of technical accessibility guidelines
A legal framework	A technical standard
Applies according to relevant ADA provisions	Provides testable success criteria
Legal questions depend on context and jurisdiction	Has conformance Levels A, AA and AAA

ADA Compliance vs WCAG Compliance

People use these terms interchangeably, but they aren’t the same:

• ADA is the law.
• WCAG is the technical guideline used to measure accessibility.
• Accessibility audit is the process of evaluating a site against those guidelines.
• Remediation is fixing the problems the audit finds.
• Conformance means satisfying the applicable WCAG success criteria at a given level.

“WCAG conformance” is something you can test. “ADA compliance” is a broader legal question that depends on your situation.

Common WordPress Accessibility Mistakes

• Missing or meaningless alt text
• Broken heading hierarchy
• Low-contrast text and buttons
• Keyboard traps in menus and popups
• Missing form labels (placeholder used instead)
• Popups that ignore keyboard and screen-reader users
• Vague links like “read more” and “click here”
• Auto-playing video or audio
• Videos without captions
• Removed or invisible focus outlines
• Inaccessible PDFs
• Relying only on automated scanners
• Assuming an accessibility plugin guarantees compliance

How to Fix ADA Accessibility Issues in WordPress

Use a simple loop: Audit, Identify, Prioritize, Fix, Test, Document, Monitor.

This rough ranking helps you prioritize (it’s a practical triage method, not a legal standard):

• Critical: Blocks access or interaction entirely, like a form that can’t be submitted by keyboard.
• High: Creates significant barriers, like very low contrast on main content.
• Medium: Reduces usability, like vague link text.
• Low: Improvements and best-practice tweaks.

Fix critical items first on your highest-value pages: homepage, contact page, checkout and lead forms. Then document what you fixed and publish an accessibility statement with a way for visitors to report problems.

How Often Should You Test Your WordPress Website?

Accessibility is not a one-time project. Test:

• Before launching a new site
• After a major redesign
• After changing your theme
• After installing or updating important plugins
• After adding new forms, popups or features
• After major WordPress updates
• On a regular schedule as part of ongoing care

That is why accessibility works best alongside a maintenance plan. Design, development, launch, updates and testing all connect. Our WordPress maintenance services keep updates, backups and monitoring in check, and reliable WordPress hosting keeps your site stable while you improve it. Accessible pages are also better structured for search engines, so this pairs well with our WordPress SEO packages.

How The Code Beast Can Help

Since 2011, The Code Beast has built, maintained and supported WordPress websites for over 2,400 clients. Our WordPress ADA compliance services follow the process in this guide:

• Manual audit: heading structure and contrast checks on key design elements
• Implementation: alt text, skip navigation, keyboard-only optimization, screen reader improvements and ARIA attributes
• Ongoing support: automated scans as new content is added, plus updates to your accessibility documentation

If your theme or plugins need custom fixes, our WordPress development team can handle the code side too.

Frequently Asked Questions

Conclusion

WordPress accessibility isn’t about ticking one box. It’s about building a site that works for everyone who visits and keeping it that way as it grows. Start with the checklist, test with real keyboards as well as tools, fix the barriers that block people first, and retest after every meaningful change. It’s good for usability, SEO and your brand’s reputation too.

For the technical details, the official W3C WCAG 2.2 specification is the best primary source.

Ready to find out where your site stands? Get a quote and let The Code Beast audit and fix your WordPress site.

Written by: Code Beast | Expertise: WordPress Development, Website Accessibility and SEO | Updated: September 2026