ADA Website Compliance: How to Get There

ADA website compliance is one of the most searched and most confused topics in web work. Some vendors say a script will make you compliant overnight. Others say nothing is required. Neither is accurate. This post explains what the Department of Justice has said, which technical standard to aim for, and a practical plan to get your site there and keep it there.

This is general information, not legal advice. If you have received a demand letter or are unsure of your obligations, talk to an attorney who handles ADA matters.

What the ADA says about websites

Businesses open to the public (Title III). The Department of Justice's web accessibility guidance, published in March 2022, says the ADA's requirements apply to all the goods, services, privileges and activities offered by public accommodations, including those offered on the web. It also says DOJ does not have a regulation setting out detailed technical standards for these businesses, and that businesses have flexibility in how they comply with the ADA's general requirements of nondiscrimination and effective communication. The guidance notes that it has no legally binding effect on its own.

State and local governments (Title II). In 2024 DOJ issued a rule requiring state and local government websites and mobile apps to meet WCAG 2.1 Level AA. DOJ's fact sheet says an interim final rule published in April 2026 extended the compliance dates to April 26, 2027 for public entities with a population of 50,000 or more, and April 26, 2028 for smaller entities and special district governments. This rule covers state and local governments only. It still shows which standard DOJ chose when it did set one.

Why WCAG is the benchmark for ADA website compliance

The Web Content Accessibility Guidelines, published by the W3C, are the standard DOJ points to in its guidance and adopted in its Title II rule. WCAG is organized around four principles (perceivable, operable, understandable, robust) and three conformance levels (A, AA, AAA). Level AA is the usual target.

The current version is WCAG 2.2, published as a W3C Recommendation in October 2023. It keeps the 2.1 success criteria (except 4.1.1 Parsing, which was removed as obsolete) and adds new ones, such as minimum target sizes of 24 by 24 CSS pixels and making sure focused elements are not hidden behind sticky headers or banners. Building to 2.2 AA puts you at or above the level DOJ chose for governments.

The common barriers DOJ lists

DOJ's guidance lists the problems it sees most often. They are a good first audit:

• Poor color contrast. WCAG AA asks for a ratio of at least 4.5:1 for normal text and 3:1 for large text.
• Using color alone to convey information, such as red fields for errors with no text.
• Missing text alternatives on images, including linked images and icons.
• No captions on videos.
• Inaccessible forms: fields without labels, errors that are not announced, CAPTCHAs with no alternative.
• Mouse-only navigation: menus, sliders and pop-ups that cannot be used with a keyboard.

What overlays and automated scans cannot do

DOJ's guidance says automated checkers and overlays can be helpful tools but need to be used carefully, and that a "clean" report does not necessarily mean everything is accessible.

The FTC has acted on this. In April 2025 it finalized an order requiring accessiBe, an overlay vendor, to pay $1 million over allegations that it misrepresented its tool's ability to make any website WCAG compliant. The order bars the company from claiming its automated products can make websites WCAG compliant unless it has evidence.

The practical takeaway: a script added to your site does not replace fixing the site. A simple rule for vendor claims: if a product promises compliance without anyone changing your templates or content, ask for the evidence behind the claim and for a manual test of your own booking or checkout flow. Automated scans are useful for catching contrast, missing labels and missing alt text quickly. Keyboard use, screen reader behavior, logical reading order and whether alt text actually describes the image need a person.

A step-by-step plan

1. Inventory your key journeys. List the tasks people come to do: book an appointment, request a quote, apply for a job, pay an invoice, read your services. Prioritize those pages.
2. Run an automated scan across the site to catch the easy, repeatable issues.
3. Test the key journeys by hand. Keyboard only, then a screen reader (VoiceOver on Mac and iPhone, NVDA on Windows), then zoomed to 200% on desktop and on a phone.
4. Fix at the template level. Most problems live in shared components: the header, the menu, the form styles, the footer. Fixing a template fixes every page that uses it.
5. Fix content. Alt text, heading order, link text that makes sense out of context, captions on videos, accessible PDFs or HTML alternatives.
6. Check third-party tools. Booking widgets, chat, payment forms and embedded maps. Ask vendors for their accessibility conformance documentation.
7. Add a way to report problems. DOJ's guidance notes that giving the public a way to report accessibility problems helps owners fix them. An accessibility page with an email and phone number is a simple start.
8. Build it into your process. New pages and campaigns get checked before launch, and the whole site gets reviewed on a schedule. Our website redesign checklist and maintenance plan guide show where it fits.

A ten-minute version of step 3 that any owner can run today: put the mouse aside and press Tab from the top of your home page. You should always be able to see where the focus is, reach the menu, open and close it, get to your contact or booking form, fill it in, submit it and read any error message. Wherever you get stuck, a keyboard user gets stuck too. Write down each place and hand the list to whoever maintains the site.

Industry notes

• Healthcare and home care: intake forms, patient portals and appointment booking are the highest priority; they are how people get care.
• CPA and tax firms: client upload portals and e-signature tools are often third-party; check them.
• Restaurants: menus posted only as images or PDFs are a frequent barrier. Publish menus as text.
• E-commerce: product filters, variant pickers and checkout are where keyboard and screen reader users get stuck.
• Interactive and 3D sites: our interactive product demo checklist covers the WCAG criteria animated and interactive content most often misses.

How Pinn.Media builds accessible sites

We build to WCAG 2.2 AA from the start, test key journeys with a keyboard and screen readers before launch, and fix accessibility at the component level so it holds up as the site grows. Our stack page shows the tools we build with. If you want an honest assessment of where your site stands and a plan to close the gaps, book a discovery call.