ADA Compliance for WordPress Sites: A Practical Guide for 2026
What the ADA means for WordPress websites in 2026: who is covered, current federal deadlines, why WCAG 2.2 AA is the target, and how to get your site there.
ADA compliance for a WordPress site means people with disabilities can use it: they can read your content, navigate with a keyboard or screen reader, and complete forms and purchases. The law itself does not name a technical standard for private business websites, so in practice “compliant” means meeting the Web Content Accessibility Guidelines at Level AA. This guide explains who the ADA covers, the current federal deadlines, and how we bring WordPress sites up to that standard.
This article is general information, not legal advice; talk to a lawyer about your specific situation.
What the ADA says about websites
The Americans with Disabilities Act became law in 1990, before most businesses had a website. It does not mention websites. Two parts of the law matter for the web:
- Title II covers state and local governments, such as cities, counties, public schools, public universities and transit agencies.
- Title III covers “public accommodations,” which are businesses open to the public, such as stores, restaurants, hotels, clinics, banks and many online businesses.
The U.S. Department of Justice (DOJ) enforces both. Its guidance on web accessibility and the ADA says the ADA’s requirements apply to the goods and services businesses offer on the web. The same guidance says DOJ does not have a regulation setting out detailed standards for business websites, and that businesses have flexibility in how they comply. It points to the Web Content Accessibility Guidelines (WCAG) as helpful technical guidance.
Title II: state and local governments have a firm rule
In April 2024, DOJ published a final rule for state and local government web content and mobile apps. It names WCAG 2.1 Level AA as the technical standard.
On April 20, 2026, DOJ published an interim final rule in the Federal Register that pushed the compliance dates back by about a year. The technical standard did not change.
| Public entity | Original date | Current compliance date |
|---|---|---|
| Population of 50,000 or more | April 24, 2026 | April 26, 2027 |
| Population under 50,000, and special district governments | April 26, 2027 | April 26, 2028 |
If you build or maintain websites for a city, school district or public agency, those dates apply to them. Contractors and vendors are part of the picture too, because the rule covers content a public entity provides “through contractual, licensing, or other arrangements.”
Title III: businesses have no technical rule, but still have obligations
There is still no DOJ regulation that sets a technical web standard for private businesses. That does not mean businesses are off the hook. DOJ’s position is that the ADA covers online services, and private lawsuits and demand letters about inaccessible websites are common in the US. Without a specific rule, courts and settlements usually measure websites against WCAG 2.1 or 2.2 Level AA.
So for a business, the practical question is not “Which regulation applies?” It is “Can a blind customer, a keyboard user or someone with low vision actually use our site?” WCAG gives you a testable way to answer that.
Other federal rules you may run into
If your organization receives funding from the Department of Health and Human Services (HHS), such as many hospitals and clinics, Section 504 of the Rehabilitation Act also applies. HHS adopted WCAG 2.1 Level AA in its 2024 rule. In May 2026, HHS extended its compliance dates to May 11, 2027 for recipients with 15 or more employees, and May 10, 2028 for those with fewer than 15.
Rules and dates can change. Check ADA.gov and the relevant agency before you plan around a deadline.
Why we target WCAG 2.2 Level AA
WCAG is published by the World Wide Web Consortium (W3C). It has three levels: A (minimum), AA (the usual legal and contract target) and AAA (enhanced, not expected for whole sites).
The federal rules above reference WCAG 2.1. We still audit against WCAG 2.2 Level AA, for three reasons:
- It covers 2.1. The W3C states that content conforming to WCAG 2.2 also conforms to WCAG 2.1 and 2.0. You meet the older target and the newer one with one piece of work.
- It is the current standard. WCAG 2.2 became a W3C Recommendation on October 5, 2023, with an updated version in December 2024.
- WordPress itself uses it. The WordPress accessibility coding standards expect code in WordPress core, WordPress.org sites and official plugins to conform to WCAG 2.2 at Level AA.
We cover what changed in our guide to WCAG 2.2 changes for WordPress.
Where WordPress sites usually fail
WordPress core is in good shape. The admin screens and default themes get regular accessibility review. Most problems come from what gets added on top.
Themes and page builders
A theme controls headings, menus, color contrast, focus styles and page landmarks. Many commercial themes and page builders output layouts that look fine but make little sense to a screen reader. Common issues we find:
- Focus outlines removed with CSS, so keyboard users cannot see where they are.
- Dropdown menus that only open on mouse hover.
- Headings chosen for their size, not their meaning, so the outline jumps from H2 to H5.
- Sliders and carousels that move on their own and cannot be paused.
- Light gray text that fails the 4.5:1 contrast ratio WCAG requires for normal text.
A theme marked “accessibility-ready” in the WordPress.org directory has passed a review, but the Theme Review Team notes that the tag does not mean the theme meets WCAG Level AA. It is a good starting point, not proof.
Forms
Forms are where accessibility turns into lost leads and sales. Missing labels, error messages that are only shown in red, CAPTCHAs that require solving a puzzle, and multi-step forms that lose data are all common. Contact forms, checkout pages and login screens deserve the most attention.
Content
Editors add most accessibility problems over time without knowing it: images with no alternative text or with “image123.jpg” as the description, link text like “click here,” videos without captions, and scanned PDF files that a screen reader cannot read. Fixing a theme once does not fix the content your team publishes next month.
Plugins and third-party widgets
Chat widgets, cookie banners, booking tools and embedded maps often trap keyboard focus or cover content. You may not control their code, but you choose whether to keep them.
How to get a WordPress site to ADA compliance
There is no shortcut. The process that works is the same one we use for any measurable problem: find out where you stand, fix the highest-impact issues first, and keep measuring so things do not slide back.
1. Audit the site
Start with an audit against WCAG 2.2 Level AA. A real audit combines automated scanning with manual testing: keyboard-only navigation, screen reader checks, zoom and reflow, and a close look at forms. Automated tools alone miss a lot. The W3C says plainly that tools cannot check all accessibility aspects automatically. Our step-by-step guide on how to audit WordPress accessibility walks through the process.
2. Prioritize by impact
Not every issue is equal. A checkout button that keyboard users cannot reach blocks a purchase. A slightly low-contrast footer link is a problem, but a smaller one. We rank issues by how badly they block users and how many templates they affect. A theme-level fix can clear hundreds of page-level errors at once.
3. Fix at the source
Fix problems in the theme, the child theme, the form setup or the content, not with a layer on top. This is why we advise against overlay widgets. In 2025 the Federal Trade Commission ordered an overlay vendor to pay $1 million over claims that its product could make any website WCAG compliant. We explain the full story in why accessibility overlays do not make you compliant.
Sometimes the audit shows the theme or page builder is so far off that fixing it costs more than replacing it. That is a real decision with real tradeoffs, and we cover how to make it in refactor or rebuild a legacy WordPress site.
4. Train your editors
Give the people who publish content a short checklist: write useful alt text, use headings in order, write descriptive link text, caption videos, and avoid text in images. Ten minutes of training prevents months of new errors.
5. Publish an accessibility statement
An accessibility statement explains what standard you aim for, what you know is not yet fixed, and how people can report a problem or get help. It shows good faith and gives users a direct way to reach you instead of leaving the site. The W3C has a free accessibility statement generator.
6. Keep testing
Accessibility is not a one-time project. Plugin updates, new landing pages and redesigns all bring new issues. We add automated accessibility checks to the same test runs we use for updates, so a regression shows up before it goes live. If your site already has a staging workflow, this fits right into it; see our guide to safe WordPress updates with staging and tests.
Accessibility is measurable, so measure it
We treat accessibility the same way we treat WordPress technical debt: as a number you can track. The number of WCAG 2.2 failures per template, split by severity, tells you where you are today and whether you are improving. A site that can show its blocking issues going down to zero, with records of each fix, is in a much stronger position than one with a widget and no data.
That number also helps with budgeting. Once issues are grouped by template and component, you can see that fixing the header, the main menu and the form styles clears most of the problems, and plan the rest over time.
Common myths about ADA compliance
| Myth | Reality |
|---|---|
| “Small businesses are exempt.” | Title III applies to businesses open to the public regardless of size. Some ADA rules scale with size, but there is no general website exemption for small businesses. |
| “We passed an automated scan, so we’re compliant.” | Automated tools catch only part of the WCAG criteria. Keyboard, screen reader and form testing are still needed. |
| “An accessibility plugin fixes it.” | Plugins and overlays cannot repair your theme’s code or your content. |
| “There’s an official ADA certification.” | No government agency certifies websites. You can document an audit and your fixes. |
| “Once it’s fixed, we’re done.” | New content and updates bring new issues. Ongoing checks are part of the job. |
Get help making your WordPress site accessible
If you want to know where your site stands, our ADA compliance service starts with a WCAG 2.2 Level AA audit, fixes issues in your theme, forms and content, and sets up ongoing checks so the site stays accessible. If you only need the findings, an accessibility audit gives you a prioritized report your own team can work from. Contact us to tell us about your site.
Frequently asked questions
- Does the ADA apply to private business websites?
- The Department of Justice has long said the ADA covers the goods and services businesses offer online, but it has not issued a regulation with a technical standard for private business websites. Most businesses use WCAG 2.1 or 2.2 Level AA as their target.
- What is the deadline for state and local government websites?
- Under the Title II rule as extended in April 2026, governments serving 50,000 or more people must comply by April 26, 2027. Smaller governments and special districts must comply by April 26, 2028.
- Is there an ADA compliance certificate for websites?
- No. There is no official government certification for ADA website compliance. What you can have is an audit report against WCAG, a record of fixes, and an accessibility statement that explains your commitment and how to report problems.
- Can a WordPress plugin make my site ADA compliant?
- No single plugin can. Plugins can help with specific tasks, but most accessibility problems live in your theme, page builder output, forms and content, and they need to be fixed there.