Web Accessibility in 2026: A Compliance Guide

Web accessibility stopped being optional. The European Accessibility Act has been enforced since June 28, 2025, and it reaches any business that sells products or services to EU customers, regardless of where that business is based. In the United States, the Department of Justice's ADA Title II rule requires public bodies to meet WCAG 2.1 Level AA by April 2026, and private-sector lawsuits keep climbing every year.

For a company shipping a website or app, that means a real deadline and real financial exposure. EAA penalties can reach 5% of annual turnover for large companies, and a single ADA complaint can cost tens of thousands to settle before you have fixed anything.

The good news: the standard everyone points to, WCAG 2.1 AA, is well-defined and achievable. The bad news is that the most heavily marketed shortcut, the accessibility overlay widget, does not get you there and can make your legal position worse. This guide covers what the law actually requires, why the quick fix backfires, and how we build accessibility into a site from the start instead of bolting it on at the end.

What the law actually requires

Three names come up constantly, and they fit together cleanly. WCAG 2.1 Level AA is the technical standard. The EAA and the ADA are the laws that, in practice, point back to it. In Europe, meeting WCAG 2.1 AA satisfies the digital requirements of the harmonized EN 301 549 standard, which is how you demonstrate EAA conformance.

WCAG is organized around four principles, known as POUR: content must be Perceivable, Operable, Understandable, and Robust. In concrete terms that means text alternatives for images, sufficient color contrast, full keyboard operability, visible focus states, labeled form fields, and markup that screen readers can parse. Level AA, not AAA, is the bar nearly every regulation references. Note the EAA exempts the smallest businesses, those under 10 employees and under two million euros in turnover, but that carve-out is narrower than most founders assume.

Why accessibility overlays make it worse

Overlay widgets promise compliance from a single line of JavaScript. They do not deliver it. Automated tooling can only detect and address roughly 30% of accessibility issues, and an overlay that rewrites the page after load often arrives after the screen reader has already processed it, sometimes breaking the experience for the exact users it claims to help.

The legal record is blunt. In 2024, a quarter of all digital accessibility lawsuits specifically cited overlays as the problem, and settlements routinely require their removal. Courts have repeatedly declined to accept an installed widget as evidence of compliance. In April 2025 the FTC fined a leading overlay vendor one million dollars for marketing claims it found were not supported by competent and reliable evidence. Paying for an overlay can leave you both non-compliant and out of pocket.

Build accessibility in: a developer's checklist

Accessibility is mostly the result of writing the front end correctly, not a separate project. Start with semantic HTML: real button and a elements, headings in order, landmarks like nav and main. Most keyboard and screen-reader support comes free when the markup is right.

From there, the high-impact items are consistent:

• Keyboard: every interactive element is reachable and operable by keyboard alone, with a visible focus indicator and no traps.
• Contrast: body text meets a 4.5:1 ratio, large text 3:1.
• Images and media: meaningful images have descriptive alt text, decorative ones have empty alt, video has captions.
• Forms: every input has a programmatically associated label, and errors are announced, not just shown in red.
• ARIA, sparingly: reach for native elements first; add ARIA only to fill genuine gaps, because incorrect ARIA is worse than none.

Done at build time, this adds little cost. Retrofitted later, it becomes an expensive audit-and-rework cycle.

Test with real tools and real people

Automated checkers like axe, Lighthouse, and WAVE are a fast first pass, and you can wire them into CI so regressions fail the build. But remember they catch only a fraction of issues, so do not stop there.

Manual testing is where the real defects surface. Unplug the mouse and navigate the whole site by keyboard. Run it through a screen reader such as VoiceOver or NVDA. Where stakes are high, test with people who actually rely on assistive technology, because lived experience finds problems no scanner will.

What compliance is worth

The framing that helps clients is not the fine, it is the upside. Accessible sites reach the roughly one in six people living with a disability, render more reliably across devices and assistive tech, and tend to rank better because clean semantic markup is exactly what crawlers prefer. The same work that satisfies the EAA and the ADA also makes the product better for everyone. Treat it as engineering quality with a legal deadline attached, and it stops feeling like a tax.