Website accessibility (ADA and WCAG) for business owners

If your business serves the public, your website should meet WCAG 2.2 Level AA, the accessibility standard most US laws, settlements and policies point to. The ADA does not yet have a detailed web rule for private businesses, but accessibility lawsuits over websites are common, and the fixes also make the site easier for everyone to use. The reliable approach is to build accessibility into design, code and content, then test with real tools and real assistive technology. This is general information, not legal advice.

What the law says, in plain terms

There are a few pieces worth knowing.

• ADA Title III covers "places of public accommodation," which includes most businesses open to the public. It was written before the web existed, and there is no detailed federal technical rule for private business websites. Courts and the Department of Justice have generally treated websites as covered, especially where they connect to a physical location, and plaintiffs regularly file suits citing WCAG failures.
• ADA Title II covers state and local governments. In 2024 the DOJ issued a rule requiring their websites and apps to meet WCAG 2.1 Level AA. In April 2026 the DOJ pushed the compliance dates back by a year: larger public entities now have until April 2027, and smaller ones and special districts until April 2028. If you build for or contract with public entities, this applies to you indirectly.
• Section 508 requires federal agencies (and in practice many federal contractors) to make technology accessible, with standards aligned to WCAG.
• State laws such as California's Unruh Act add their own exposure.
• Outside the US, the European Accessibility Act began applying in June 2025 to many consumer-facing digital products and services sold in the EU, including ecommerce.

The common thread is WCAG. If you meet WCAG 2.1 or 2.2 Level AA, you are following the standard regulators and courts reference.

WCAG in one page

WCAG is organized around four principles. Content must be:

Each guideline has success criteria at three levels: A (minimum), AA (the usual target) and AAA (enhanced, rarely required site-wide).

What WCAG 2.2 added

WCAG 2.2 became a W3C Recommendation in October 2023 and builds on 2.1. Meeting 2.2 AA means you also meet 2.1 AA. The new criteria that matter most for business sites:

• Focus not obscured. When a user tabs to a link or button, sticky headers, cookie banners and chat widgets must not hide it.
• Target size (minimum). Clickable targets need to be big enough, or spaced far enough apart, to hit reliably.
• Dragging movements. Anything that requires dragging (sliders, sortable lists, maps) needs a single-pointer alternative.
• Consistent help. If you offer help (phone, chat, contact link) on multiple pages, keep it in the same place.
• Redundant entry. Don't make people re-type information they already gave in the same process.
• Accessible authentication. Logins should not depend on memorizing or transcribing things, such as puzzle CAPTCHAs, without an alternative. Allowing password managers and paste helps.

The problems we find most often

When we audit business websites, the same issues come up again and again:

1. Low color contrast, especially light gray text and text over images.
2. Missing or useless alt text, like file names or "image."
3. Forms without proper labels, or with errors shown only in red.
4. Keyboard dead ends: menus, modals and sliders that can't be used without a mouse.
5. Invisible focus states removed for aesthetic reasons.
6. Video without captions.
7. Headings used for styling, not structure, which breaks screen reader navigation.
8. Link text like "click here" that means nothing out of context.
9. Inaccessible PDFs for menus, forms and price sheets.
10. Third-party widgets (chat, booking, reviews) that the site owner doesn't control but still ships.

Most of these are design and content decisions, not exotic engineering.

Why overlays are not the answer

Accessibility overlays are scripts that add a toolbar or claim to "fix" a site automatically. We don't recommend them.

• They don't change the underlying code, so the real barriers remain.
• They can interfere with the assistive technology people already use.
• Many blind and disabled users and advocacy groups have spoken out against them.
• Sites using overlays have still been sued.
• The FTC has taken action against an overlay vendor over misleading claims that its tool made sites compliant.

An overlay can feel like a quick fix. It is not one. Budget for fixing the site.

How to make a site accessible in practice

On a new build

Accessibility is cheapest when it's part of the plan from the start.

• Design: check contrast in the design system, design visible focus states, size touch targets properly, and never rely on color alone.
• Development: use semantic HTML first (real buttons, real links, real headings), add ARIA only where needed, and test every component with a keyboard.
• Content: write meaningful alt text, descriptive link text and clear headings. Caption video. Prefer HTML pages over PDFs.
• Components: if you use a headless CMS with reusable blocks, make each block accessible once and every page inherits it. That is one of the quiet benefits of the approach we described in Contentful content models and reusable blocks.

On an existing site

1. Run automated scans (browser extensions and site crawlers) to catch the easy issues. Automated tools only find a portion of problems, so don't stop there.
2. Do a manual audit of key templates and user flows: home, service pages, forms, checkout, booking.
3. Test with assistive technology: a screen reader (VoiceOver, NVDA) and keyboard-only navigation.
4. Prioritize by impact: anything that blocks a task (forms, checkout, contact) comes first.
5. Fix templates, not pages. One template fix often resolves hundreds of pages.
6. Publish an accessibility statement with a way for people to report issues, and respond when they do.
7. Keep it up. New content, plugins and widgets can introduce new problems. Include checks in your care plan.

Platform notes

Accessibility also overlaps with performance and SEO. Clear headings, descriptive links, alt text and fast, stable pages help search engines and AI answer engines understand your content, a point we touched on in Core Web Vitals for small business and answer engine optimization. If you are redesigning, build accessibility into the project plan alongside the SEO checklist in how to redesign without losing SEO.

Industries where it matters most

Every public-facing business benefits, but some face more scrutiny or serve more users with disabilities: medical practices, senior services, restaurants, retail and ecommerce, finance and hospitality.

The short version

Target WCAG 2.2 Level AA. Skip overlays. Build accessibility into design, code and content, test with keyboards and screen readers, fix templates first, and keep checking as the site changes. Talk to counsel about legal exposure, and talk to your web team about the fixes.

Want an accessibility review of your site? See our UX and UI strategy services or contact us.