A small business owner emailed me last month. Her site had been live for four years. Quiet, useful, low-traffic. Then a demand letter arrived alleging her site violated the ADA and offering a "settlement amount" to make it go away. She wanted to know if it was a scam, and what she should actually do about her site.

It wasn't a scam. The letter was real, and there are firms that send hundreds of these a month. Welcome to web accessibility in 2026.

What just happened

April 24, 2026 was originally the Title II compliance deadline. That rule applies to state and local government entities — public universities, city websites, libraries, courts. Days before it hit, the DOJ issued an Interim Final Rule extending the deadline to April 26, 2027 for entities with 50,000+ population, and to April 26, 2028 for smaller ones. If you're not running a public entity, the rule doesn't directly apply to you anyway.

But the broader environment did shift. WCAG 2.2 is now treated as the working baseline by procurement teams, by larger clients writing RFPs, and by most plaintiffs' attorneys assessing exposure. The European Accessibility Act came into force last June and reaches into e-commerce, banking apps, and a long list of digital products. And the federal accessibility lawsuit count keeps climbing — over 5,000 web-related ADA cases were filed in 2025 alone, and the 2026 trend line points up.

The headline most people miss: 95.9% of the world's top one million homepages have detected WCAG failures, with low-contrast text on 79.1% of pages and missing alt text on 55.5%. The number went up from last year, not down. There is a lot of room to be the exception.

What WCAG 2.2 actually wants

If you've never read the spec, here's the honest version. WCAG 2.2 is mostly a list of things any thoughtful designer should already be doing.

Text needs enough contrast against its background. Forms need labels. Images need alt text — descriptive when the image carries information, empty when it's decorative. Pages need to work without a mouse. Focus indicators need to be visible when someone tabs through. Error messages need to explain what went wrong, not just light up red. Touch targets need to be big enough to actually hit.

There are 86 success criteria across three levels (A, AA, AAA). The realistic target for most businesses is AA conformance. AAA is aspirational, often impractical for marketing sites, and rarely required.

The single most common failure, by a wide margin, is low-contrast text — it averages 29.6 instances per affected page. The second is missing alt text. Both are unglamorous and both are fixable in an afternoon if someone actually pays attention.

What overlays don't do

You may have seen the widgets — the little blue accessibility icon that floats in the corner and pops open a panel offering "high contrast mode" and "screen reader optimization."

These are accessibility overlays. They are sold as a one-line solution. They are not a solution.

Courts in multiple jurisdictions have explicitly stopped treating overlay installation as evidence of compliance. Plaintiffs frequently sue sites that have them installed. Screen reader users — the people overlays claim to help — overwhelmingly report that overlays make their experience worse, not better. The National Federation of the Blind has formally opposed them. The Disability Rights Bar has built an entire practice around suing sites that deploy them.

If you have one installed, take it off. It is paying a subscription fee for legal liability.

Where to actually start

If you have a marketing site or a small web app and you have never thought about accessibility before, here's the order I'd run a first pass in:

Color contrast. Run your site through a contrast checker. Fix anywhere body text is below 4.5:1 against its background, and large text below 3:1. This usually means tweaking your gray-on-white text color. It's a one-evening fix and it removes the single largest category of failures.

Alt text. Every image that conveys information needs descriptive alt text. Logos, product photos, charts. Decorative flourishes get alt="" so screen readers skip them. The bar is "would a person reading the page out loud mention this?"

Form labels. Every input needs a real <label> associated with it, not a placeholder pretending to be one. Placeholders disappear when the user starts typing and don't get read consistently by assistive tech.

Keyboard navigation. Tab through your own site. Can you reach every link and button? Can you see where the focus is? Can you submit forms without touching a mouse? If not, that's the next thing to fix.

Focus styles. If your designer "removed the ugly blue outline" on focus, put something back — a custom outline, a background change, anything visible. People who navigate by keyboard need to see where they are.

That's not all of WCAG 2.2, but it's the 80% of complaints we see in the wild. After that, you're into the long tail: ARIA roles only when native HTML doesn't cut it, captions on video, motion preferences, error recovery patterns, and so on. Worth doing, but not where to start.

What this costs

Honest answer: it depends on how your site was built. Sites built on solid HTML with a sensible design system can usually be brought to AA conformance in a few days of focused work. Sites built on a mess of WordPress page builders, custom JavaScript widgets, and 11 nested div soup take longer because the underlying structure is fighting you.

The cheapest path is to bake accessibility into the design system from the start. Buttons that ship with proper focus states. Forms that ship with proper labels. Color tokens that pass contrast by default. Then accessibility stops being a project and starts being a property — something the site has, not something you remember to do later.

The most expensive path is to ignore it until a demand letter shows up, then panic-pay a settlement and rush a remediation contract while your team also fields support tickets and ships features. I have watched that math go badly several times now.

A note on AI tooling

Every accessibility platform on the market in 2026 is selling some version of "AI scans your site and finds the issues." Some of these tools are genuinely useful. They flag low-hanging issues quickly and at scale.

What they don't do is tell you whether your form actually makes sense to a screen reader user, whether your error messages are helpful, or whether your keyboard flow gets people to the thing they came for. That still takes a human running through the site with a screen reader on, or at minimum a developer who knows what they're listening for.

Use the tools. Don't trust them as a complete picture. The shift this year isn't AI replacing accessibility work — it's AI making the boring parts faster so the careful parts get more attention.

We design and build sites with accessibility baked into the system, not bolted on at the end. If your site is heading into a redesign, an audit, or a quiet moment between projects, that's the moment to make this part of the foundation. We're happy to walk through what your site needs and what's worth doing in what order.