Accessibility & ADA Compliance
ADA Compliance Website Checklist (2026): WCAG 2.2 AA in Plain Language
A plain-language ADA checklist for 2026: the WCAG 2.2 AA items editors control, the ones built into the code, current deadlines, and free testing tools.
What an ADA compliant website is
An ADA compliant website is one that people with disabilities can use: it works with a screen reader, can be operated entirely from a keyboard, has readable contrast, and gives every image, form field and video a text equivalent. The ADA itself does not list web requirements; courts, the Department of Justice and HHS all measure compliance against the Web Content Accessibility Guidelines (WCAG) at Level AA. This checklist turns WCAG 2.2 AA into plain-language items you can check page by page, first the things content editors control, then the things that have to be built into the site itself. It was last reviewed in September 2026 and reflects the current standard and the current deadlines.
Skip to
Is ADA compliance mandatory for websites?
For most businesses, yes in practice. The ADA does not mention websites, but courts have treated the websites of businesses open to the public as places of public accommodation under Title III since the mid-2010s, and plaintiffs’ firms filed more than 5,000 digital accessibility lawsuits in 2025. In those cases the standard applied is WCAG 2.0 or 2.1 at Level AA.
For two groups the requirement is written down. State and local governments are covered by the 2024 ADA Title II rule, which requires WCAG 2.1 AA; on April 20, 2026 the Department of Justice extended the deadlines to April 26, 2027 for entities serving 50,000 or more people and April 26, 2028 for smaller entities. Healthcare organizations that receive federal funding are covered by the HHS Section 504 rule, with deadlines of May 11, 2027 (15 or more employees) and May 10, 2028 (smaller). Both require Level AA, not AAA; the idea that government sites need AAA is a common myth.
The practical answer for any organization is the same: build and maintain to WCAG 2.1 AA at minimum, and to 2.2 AA if you are starting now. Our ADA compliance services page covers the legal picture in more detail.
How to make a website ADA compliant
There are five steps, and the order matters.
- Pick the target: WCAG 2.2 Level AA. It includes everything in 2.1 AA, which is what the regulations cite, plus nine newer criteria that mostly affect mobile use and forms.
- Audit what you have. Run an automated scanner on every template (not every page; templates are where the code lives), then test by hand with a keyboard and a screen reader. Automated tools catch the mechanical failures and miss most of the rest. Our guide to website accessibility audits explains what a proper audit includes and costs, and ten checks you can do in 30 minutes is the fast version.
- Fix the code first. Heading structure, form labels, focus states, keyboard operability and component markup are theme-level problems. If the site was built on a page builder or a template that was never accessible, a rebuild is often faster and cheaper than remediation. This is the work our ADA compliance services do.
- Then fix the content. Alt text, captions, link wording, contrast on images with text overlays, PDFs. This is ongoing, and it is what the checklist below is for.
- Keep it that way. Every new page, plugin and editor can break compliance. Add the checklist to your publishing process, re-scan quarterly, and publish an accessibility statement that says what standard you follow and how to report a problem.
Do not rely on an accessibility overlay or widget. They do not fix code, they often interfere with assistive technology, and sites using them have been sued anyway.
ADA compliance website checklist for content editors
These are the items that break compliance most often after launch, because they are in the hands of whoever adds content. Check them on every new page and post.
Alt text
Give every meaningful image concise, descriptive alt text that says what the image conveys, not "image of." Purely decorative images get an empty alt attribute (alt="") so screen readers skip them. (WCAG 1.1.1)
Heading order
One H1 per page, then H2s for sections and H3s nested under H2s. Never skip levels and never pick a heading for its size. Screen reader users navigate by headings, so the outline has to make sense on its own. (1.3.1, 2.4.6)
Link text
Link text should say where the link goes: "download the 2026 price list," not "click here" or "read more." Links must be distinguishable from surrounding text by more than color: underline them, or use a 3:1 contrast difference plus a hover or focus cue. (1.4.1, 2.4.4)
Text contrast
Normal text needs a contrast ratio of at least 4.5:1 against its background; large text (18pt, or 14pt bold) needs 3:1. Text placed over photos is the usual failure. Check it with a contrast tool before publishing. (1.4.3)
Non-text contrast
Icons, form field borders, chart lines and other visual elements people need to understand or operate the page must have at least 3:1 contrast against what is next to them. (1.4.11)
Images of text
Do not put text in images unless it is a logo or purely decorative. If you must, the full text goes in the alt attribute. Real text can be resized, reflowed, translated and read aloud; a picture of text cannot. (1.4.5)
Form labels
Every field needs a visible label that is programmatically tied to it. Placeholder text is not a label: it disappears when the user starts typing and most screen readers ignore it. Mark required fields in text, not with color alone. (1.3.1, 3.3.2)
Emphasis markup
Use <strong> for bold and <em> for italics, not <b>, <i> or CSS styling. Pasting from Word or Google Docs often inserts the wrong tags, so check the code view after pasting. Assistive technology reads semantic tags; it cannot read styling.
Video and audio
Recorded video needs accurate captions (auto-captions must be corrected), and audio-only content needs a transcript. Video with essential visual information also needs an audio description or a text alternative. Never autoplay with sound. (1.2.1 to 1.2.5, 1.4.2)
No sensory-only instructions
Avoid instructions that depend on sight or position: "click the green button," "see the image on the right," "fill out the form below." Refer to things by name instead. (1.3.3)
Tables and PDFs
Use real tables with header cells for data, never for layout. PDFs you publish must be tagged, have a reading order and real text (not scans), or the content should be published as a web page instead. Both are frequent lawsuit targets.
Page title and language
Every page needs a unique, descriptive title, and the page language is set in the HTML (lang="en"). Content in another language needs its own lang attribute so screen readers pronounce it correctly. (2.4.2, 3.1.1, 3.1.2)
ADA compliant website requirements: the code-level WCAG 2.2 AA checklist
These are the requirements that live in the site’s code and design rather than in day-to-day content: the 29 criteria that most often decide whether a site passes, grouped by WCAG’s four principles. (WCAG 2.2 has 55 Level A and AA criteria in all; our complete WCAG 2.2 checklist explains every one.) If your site fails several of these, the theme or page builder is usually the cause, and remediation means changing how the site is built.
Perceivable
- Structure is in the markup. Headings, lists, tables, landmarks and form relationships are expressed in HTML, not just visually with CSS. (1.3.1)
- Reading order makes sense when styles are removed or content is read aloud. (1.3.2)
- Orientation is not locked to portrait or landscape. (1.3.4)
- Input fields declare their purpose with autocomplete attributes (name, email, tel, street-address) so browsers and assistive tech can fill them. (1.3.5)
- Text resizes to 200 percent without loss of content or function. Use relative units, not fixed pixels, for type. (1.4.4)
- Content reflows at 320 pixels wide with no horizontal scrolling. This is the mobile requirement. (1.4.10)
- Text spacing can be overridden (line height 1.5, paragraph spacing 2x, letter and word spacing) without breaking the layout. Avoid fixed heights on text containers. (1.4.12)
- Content on hover or focus (tooltips, menus) can be dismissed, hovered and stays visible until dismissed. (1.4.13)
Operable
- Everything works with a keyboard alone: menus, modals, sliders, accordions, custom dropdowns, video controls. (2.1.1)
- No keyboard traps. Focus can always move away from any component using the keyboard. (2.1.2)
- A skip link lets keyboard users jump past the header and navigation to the main content. (2.4.1)
- Focus order follows the visual order and focus is always visible. Never set outline: none without providing a replacement focus style. (2.4.3, 2.4.7)
- Focus is not obscured by sticky headers, cookie banners or chat widgets. New in WCAG 2.2. (2.4.11)
- More than one way to reach each page: navigation plus search, a sitemap, breadcrumbs or footer links. (2.4.5)
- Time limits can be turned off, adjusted or extended, and anything that moves, scrolls or auto-updates can be paused. (2.2.1, 2.2.2)
- Nothing flashes more than three times a second. (2.3.1)
- Multi-point and path-based gestures have a single-pointer alternative, and actions fire on release, not on press, so a mis-tap can be cancelled. (2.5.1, 2.5.2)
- Anything done by dragging can also be done without dragging. New in 2.2. (2.5.7)
- Touch targets are at least 24 by 24 CSS pixels, or have enough spacing around them. New in 2.2. (2.5.8)
- Visible labels match accessible names, so voice-control users can say what they see. (2.5.3)
Understandable
- Navigation and components are consistent across pages: same order, same names, same behavior. (3.2.3, 3.2.4)
- Help is in the same place on every page where it is offered (contact link, chat, phone number). New in 2.2. (3.2.6)
- Nothing changes context unexpectedly when a field gets focus or a value changes; no auto-submitting forms. (3.2.1, 3.2.2)
- Errors are identified in text, the field is named, and a fix is suggested where possible. Color or an icon alone is not enough. (3.3.1, 3.3.3)
- Legal, financial and data-changing submissions can be reviewed, corrected or reversed. (3.3.4)
- Users are not asked to re-enter information they already provided in the same process. New in 2.2. (3.3.7)
- Logging in does not require a cognitive test such as remembering a password without paste support or solving a puzzle; allow password managers, passkeys or email links. New in 2.2. (3.3.8)
Robust
- Every custom component exposes its name, role and state to assistive technology, using native HTML elements first and ARIA only where HTML cannot do the job. (4.1.2)
- Status messages are announced (form saved, item added to cart, search results updated) without moving focus. (4.1.3)
Common WCAG compliance mistakes
- Building headings with CSS classes instead of heading tags.
- Inserting meaningful images with CSS backgrounds or :before and :after, where they have no alt text.
- Using color alone to show links, errors or required fields.
- Removing the focus outline for aesthetics.
- Custom dropdowns, accordions and carousels built from divs with no keyboard support or ARIA.
- Modals that trap focus, cannot be closed with Escape, or are shorter than their content with no scroll.
- Fixed heights on paragraphs and containers that clip text when it is enlarged.
- Carousels and videos that autoplay with no pause control.
- Installing an accessibility overlay and calling it done.
Frequently asked questions
What level of WCAG do I need for ADA compliance?
Level AA. The ADA Title II rule, the HHS Section 504 rule and the settlements in Title III lawsuits all reference WCAG 2.1 at Level AA. Building to WCAG 2.2 AA satisfies 2.1 AA and covers the newer mobile and form criteria. Level AAA is not required of anyone, including government sites. WCAG 3.0 is still a working draft and does not change any of this; our WCAG 3.0 explainer covers where it stands.
Can I check ADA compliance myself?
Partly. Free scanners such as WAVE and axe will find contrast problems, missing alt text, unlabeled fields and heading errors in minutes. What they cannot judge is whether the site actually works: whether a screen reader user can complete your contact form, whether every menu opens from the keyboard, whether the focus order makes sense. For that, test with a keyboard only and with VoiceOver (Mac and iPhone) or NVDA (Windows, free), or have an audit done. Our ten quick checks and screen reader testing guide walk through the hands-on part.
Does an accessibility overlay make my site compliant?
No. Overlays change how the page is displayed for some visitors, but they do not repair headings, labels, focus management or custom components in the code, and they often conflict with the assistive technology people already use. Businesses running overlays continue to be sued, and the FTC has fined one vendor for its compliance claims; the details are in do accessibility overlays work? Compliance comes from how the site is built and maintained.
How much does it cost to make a website ADA compliant?
It depends on how the site was built. Content fixes (alt text, captions, link text, PDFs) are inexpensive and can be done in-house with this checklist. Code fixes on a well-built custom site are usually a modest engagement. A site built on a page builder or a template that was never accessible often cannot be patched into conformance, and a rebuild that has accessibility designed in from the start is the cheaper path over any reasonable horizon. Our website cost guide covers what a custom build includes, and the accessibility audit guide covers what an audit costs.
Do I need an accessibility statement?
It is not required by the ADA for private businesses, but it is expected by the Title II and Section 504 rules, and it helps everyone. State the standard you follow (WCAG 2.2 AA), known limitations, and how to report a barrier. A published statement with a working contact route is also the first thing a plaintiff’s firm checks. How to write a website accessibility statement includes a template.
Tools for checking ADA compliance
Start with these three, then test by hand with a keyboard and a screen reader. Automated tools catch the mechanical failures; they cannot tell you whether the site is usable.
WAVE (Web Accessibility Evaluation Tool)
Enter a URL and WebAIM's scanner marks up the page with errors, alerts and structure. Free, and the fastest way to see missing alt text, unlabeled fields and contrast failures.
axe DevTools
Deque's browser extension runs inside Chrome or Firefox DevTools and reports each failure by WCAG success criterion, which is the format an audit or a lawyer expects. The free tier covers automated checks.
WebAIM Contrast Checker
Paste two colors and get the ratio against the 4.5:1 and 3:1 thresholds for text, large text and UI components. Use it on every brand color pairing before it reaches a page.
Want to know where your site stands?
We audit sites against WCAG 2.2 AA and tell you which failures are content, which are code, and whether the site can be fixed or should be rebuilt. Straight answer, no obligation.