“ADA compliant website” gets searched constantly, and it’s a slightly misleading phrase: there’s no official government certification or badge you can earn. The Americans with Disabilities Act doesn’t name a specific technical standard for websites. What’s actually happened is that the courts and the Department of Justice have, in practice, treated the Web Content Accessibility Guidelines (WCAG) as the reference standard when a website accessibility complaint gets litigated. So “ADA compliant” in practice means “meets WCAG,” almost always at the AA level.
This is a practical guide to what that actually involves on a WordPress site, not a legal opinion (I’m not a lawyer, and if you’re facing an active complaint or lawsuit, that’s a conversation for one). It’s the same checklist I build against on every custom WordPress project.
Why this matters beyond avoiding a lawsuit
Website accessibility lawsuits under the ADA have been rising for years, and healthcare, education, nonprofit, and financial services organizations are disproportionately targeted, both because they’re expected to be accessible and because they tend to serve populations more likely to rely on assistive technology. That’s real legal exposure and a real reason this guide exists.
But treating accessibility purely as legal risk-management undersells it. An estimated 1 in 4 adults in the US has some form of disability. A site that’s hard to navigate by keyboard, has poor color contrast, or confuses a screen reader is a site that’s actively turning away a meaningful share of its potential visitors and customers, lawsuit or not.
The standard: WCAG 2.2 AA
WCAG is organized around four principles, often abbreviated POUR: content should be Perceivable, Operable, Understandable, and Robust. Version 2.2 is the current release, and Level AA (out of A, AA, and AAA) is the level referenced in most legal settlements and most accessibility policies, including Section 508 for federal sites. AAA is a higher bar that’s genuinely difficult to hit across an entire site and isn’t the practical target for most businesses.
What actually needs to be true on the site
This is the real checklist, the same one I build against on every custom WordPress project:
- Semantic HTML and proper heading hierarchy. One H1 per page, headings that nest logically (H2 under H1, H3 under H2), and real HTML elements (
<button>,<nav>,<table>) instead of generic<div>s styled to look like them. This is the foundation everything else builds on, and it’s also what a screen reader relies on to let someone navigate by heading or landmark instead of reading the whole page top to bottom. - ARIA labels and roles where needed. ARIA fills gaps semantic HTML can’t, labeling an icon-only button, marking a live region that updates dynamically, describing a custom widget’s state. The important qualifier is “where needed”: overusing ARIA on elements that already have the right semantics can make things worse, not better.
- Keyboard navigation and focus management. Every interactive element, links, buttons, form fields, menus, modals, needs to be reachable and operable using only a keyboard, with a visible focus indicator at every step. This is the single most common failure point on page-builder sites, where custom-styled dropdowns and sliders frequently work with a mouse and nothing else.
- Color contrast compliance. WCAG AA requires a 4.5:1 contrast ratio for normal text and 3:1 for large text against its background. Light gray text on a white background, a common design trend, fails this constantly.
- Screen reader optimization. Beyond semantic HTML, this means things like skip-navigation links, meaningful link text (not a page full of “click here”), and form fields with properly associated labels rather than placeholder text standing in for a label.
- Alt text for all images. Descriptive alt text for images that convey information, and empty alt attributes (
alt="") for purely decorative images, so a screen reader skips them instead of announcing “image” for every icon on the page. - Accessible forms and interactive elements. Every form field programmatically associated with its label, clear error messaging that’s announced to assistive technology, and custom components (accordions, tabs, modals) built with the correct ARIA patterns for their type.
Why this is harder on page builders
Page builders generate their own markup, and it’s optimized for visual flexibility, not semantic correctness. A heading styled to look like an H2 is frequently a styled <div> or a <span> under the hood. Custom sliders, accordions, and dropdowns built with a builder’s own JavaScript often skip keyboard support entirely, because the builder was designed for drag-and-drop visual editing, not for building an accessibility tree. None of this is unfixable, but it means retrofitting accessibility onto an existing page-builder site is real, ongoing work rather than a settings toggle. A hand-coded site gives you control over the actual markup from the start, which is a large part of why accessibility and clean code tend to travel together.
How to check where your site actually stands
Before assuming your site is fine, or assuming it needs a full rebuild, run it through a few checks:
- Automated scan: WAVE (wave.webaim.org) or the axe DevTools browser extension will catch a meaningful chunk of issues, missing alt text, contrast failures, missing form labels, in minutes. They won’t catch everything; automated tools typically find 30-40% of WCAG issues, so a clean scan isn’t the same as a compliant site.
- Manual keyboard test: Unplug your mouse and try to use your own site. Can you reach every link, button, and form field with Tab? Is it always clear, visually, where focus currently is? Can you open and close a modal or dropdown menu without a mouse?
- Screen reader spot-check: macOS and Windows both ship with a built-in screen reader (VoiceOver and Narrator). Turn it on and try to navigate your homepage and one form. It’s uncomfortable the first time, and it’s the fastest way to understand what an automated report is actually describing.
The short version
“ADA compliant” means built to meet WCAG 2.2 AA, since that’s the standard courts and regulators reference in practice. It comes down to semantic markup, full keyboard operability, sufficient color contrast, and content that’s genuinely legible to assistive technology, not a plugin you install once. If you want a straight answer on where your current site stands, get in touch, or see how accessibility is built into every project on the custom WordPress development page.
