Website Accessibility Compliance: WCAG 2.2, EAA, ADA and IS 5568

Website accessibility compliance means meeting several overlapping legal regimes at once, not just picking a WCAG checklist and moving on. In the United States, the operative risk is ADA Title III litigation; in the European Union, it is the European Accessibility Act (EAA); in Israel, it is Israeli Standard 5568 (IS 5568) under the Equal Rights for Persons with Disabilities Law. All three point back to the same technical foundation: the W3C's Web Content Accessibility Guidelines (WCAG), currently at version 2.2, evaluated at Level AA.

What Accessibility Compliance Actually Means

Every regime in this guide eventually asks the same question: does your site meet a named WCAG conformance level? WCAG, maintained by the World Wide Web Consortium (W3C), organizes requirements under four principles: content must be Perceivable, Operable, Understandable and Robust. Each requirement is a testable success criterion, rated Level A (minimum), AA (the level almost every law and standard references) or AAA (the most stringent).

WCAG 2.2 became a W3C Recommendation on October 5, 2023, and it is the current version most new regulations and standards either require directly or converge toward. Level AA is the practical and legal target worldwide. Level AAA includes success criteria the W3C itself does not recommend as a general policy for entire sites, because some content genuinely cannot satisfy them, so no major law requires full AAA conformance site-wide.

Treat "compliant" as shorthand for "meets WCAG 2.2 Level AA, tested and documented," not as a certificate you buy once. A site that passed an audit six months ago and shipped ten new features since is not compliant today; it is compliant as of its last test.

United States: ADA Title II, Title III and the Lawsuit Reality

The ADA splits into two relevant titles, and they work completely differently. Title II covers state and local government. A Department of Justice (DOJ) final rule published April 24, 2024 requires these entities' web content and mobile apps to meet WCAG 2.1 Level AA, one version behind the current WCAG 2.2.

The original compliance dates were April 24, 2026 for entities serving a population of 50,000 or more, and April 26, 2027 for smaller entities and special districts. On April 20, 2026, DOJ published an interim final rule extending both deadlines by one year, to April 26, 2027 and April 26, 2028 respectively. The WCAG 2.1 Level AA standard itself did not change, only the compliance timeline.

Title III covers "public accommodations," a category that includes most commercial websites and apps. DOJ's own guidance states plainly that the department "does not have a regulation setting out detailed standards" for private businesses, even though it has long taken the position that Title III applies to the websites of public accommodations. Businesses can currently choose how they make their sites accessible, and DOJ names WCAG and Section 508 only as helpful references, not mandatory ones.

That gap is exactly why Title III generates so much litigation. With no regulation to point to, plaintiffs, defendants and courts all reach for the same practical yardstick: WCAG 2.1 or 2.2 Level AA. Build to that standard and you remove the argument entirely, regardless of whether a specific rule technically requires it yet.

European Union: The European Accessibility Act

The European Accessibility Act (EAA) is Directive (EU) 2019/882. EU member states had to transpose it into national law by June 28, 2022, and its substantive accessibility requirements have applied since June 28, 2025. Unlike the ADA, the EAA is not a general website law; it applies to a defined list of products and services.

In-scope services include e-commerce, consumer banking, e-books, telephony and electronic communications, access to audiovisual media services, and passenger transport by air, bus, rail and water, along with related products such as computers, smartphones, ATMs, ticketing machines and digital television equipment. For most software companies, e-commerce and banking are the categories most likely to pull a website or app into scope. If you sell digital products or services in one of these categories to EU consumers, the EAA almost certainly applies to you regardless of where your company is headquartered.

The technical standard is EN 301 549, the harmonized European standard for ICT accessibility, which aligns its web content requirements with WCAG 2.1 Level AA. In-scope businesses must also publish accessibility information describing how their product or service meets the requirements. One exception worth knowing: microenterprises, fewer than 10 employees and no more than EUR 2 million in annual turnover, are exempt from the EAA's service requirements, though the exemption does not extend to a small subsidiary of a larger group.

Israel: The Equal Rights Law and IS 5568

Israel's accessibility framework starts with the Equal Rights for Persons with Disabilities Law, 5758-1998. Regulations issued in 2013 require accessibility adjustments for any service offered to the public, government or private, and they set Israeli Standard 5568 as the technical bar. IS 5568, published by the Standards Institution of Israel, requires Level AA conformance built on WCAG.

Unlike the EU framework, IS 5568 is not limited to a specific list of sectors. It applies to banks, insurers, telecoms, healthcare providers, e-commerce sites and any other private business serving the Israeli public, alongside government sites. The original phase-in window for existing websites to complete their adjustments closed years ago, so a non-compliant site serving Israeli users is not early to this requirement; it is already past due.

Enforcement runs through Israel's Commission for Equal Rights of Persons with Disabilities and through private civil claims: a person with a disability can sue over an inaccessible website as a civil wrong under the Equal Rights Law, without needing to prove a specific financial loss. Sites must also publish an accessibility statement describing the adjustments made and a contact channel for accessibility issues. For companies building bilingual Hebrew and English sites, accessibility and Hebrew SEO work overlap more than most teams expect: correct lang and dir attributes, real heading structure and readable link text serve screen readers and search crawlers at the same time.

US vs EU vs Israel at a Glance

The three regimes differ in who they cover and how they are enforced, but they converge on the same technical bar. Use this table to see where you likely have exposure before you plan a fix.

| Regime | Who must comply | Technical standard | Key date | How it is enforced | |---|---|---|---|---| | US, ADA Title II | State and local government bodies | WCAG 2.1 Level AA | Compliance due April 26, 2027 (population 50,000+) or April 26, 2028 (smaller entities), per DOJ's 2026 extension | DOJ enforcement and private lawsuits | | US, ADA Title III | Private "public accommodations," including most commercial sites | No mandated standard; WCAG 2.1 or 2.2 AA used as the practical benchmark | No fixed deadline; risk is ongoing | Private lawsuits under the ADA's private right of action | | EU, European Accessibility Act | Businesses offering in-scope products or services, such as e-commerce and banking | EN 301 549, aligned with WCAG 2.1 Level AA | Requirements have applied since June 28, 2025 | National market surveillance authorities in each member state | | Israel, Equal Rights Law and IS 5568 | Government bodies and private businesses serving the public | IS 5568, based on WCAG at Level AA | Adjustment window for existing sites closed years ago | Commission for Equal Rights of Persons with Disabilities, private civil suits |

Notice the pattern in the technical standard column: every regime that names one says the same thing, WCAG at Level AA. That overlap is what makes one compliance program more efficient than three separate ones.

What Is New in WCAG 2.2

WCAG 2.2 became a W3C Recommendation on October 5, 2023. It kept every WCAG 2.1 success criterion except one: 4.1.1 Parsing was removed as obsolete, since modern browsers and assistive technology handle malformed HTML robustly enough that the criterion no longer adds value. In its place, WCAG 2.2 added nine new success criteria, most aimed at cognitive disabilities, motor impairments and authentication flows.

| Success Criterion | Level | What It Requires | |---|---|---| | 2.4.11 Focus Not Obscured (Minimum) | AA | Keyboard focus indicator must not be completely hidden by sticky headers, cookie banners or chat widgets | | 2.4.12 Focus Not Obscured (Enhanced) | AAA | Stricter version: no part of the focused element may be hidden by other content | | 2.4.13 Focus Appearance | AAA | Focus indicators must meet a minimum size and contrast so they are clearly visible | | 2.5.7 Dragging Movements | AA | Any drag interaction needs a single-pointer alternative, such as buttons, not a drag-only control | | 2.5.8 Target Size (Minimum) | AA | Clickable targets must be at least 24 by 24 CSS pixels, with limited exceptions | | 3.2.6 Consistent Help | A | Help mechanisms such as chat, contact links or FAQ pages appear in the same relative order across pages | | 3.3.7 Redundant Entry | A | Users should not have to re-enter information they already supplied earlier in the same process | | 3.3.8 Accessible Authentication (Minimum) | AA | Logging in cannot require a cognitive function test, such as memorizing a puzzle, unless an alternative exists | | 3.3.9 Accessible Authentication (Enhanced) | AAA | Same rule as above, with no exceptions permitted |

Two of these criteria deserve attention from any product team shipping in 2026. Target Size affects every icon button and checkbox in your design system, and Accessible Authentication affects any login flow built around a puzzle-style CAPTCHA instead of a password manager or passkey friendly form.

Why Overlays and Widgets Do Not Deliver Compliance

An accessibility overlay is a script you drop into your site that adjusts the page at runtime: bigger text, higher contrast, a floating accessibility menu. Overlays are popular because they promise a fast, low-effort fix, and vendors often market them as a path to compliance. They are not.

An overlay can change how text looks, but it cannot rewrite broken HTML semantics, add alt text that actually describes an image's content, fix a keyboard trap inside a custom dropdown, or reorder a heading structure that skips from an h2 to an h5. Those are the barriers that block screen reader and keyboard users, and they live in your markup, not in a layer painted on top of it. Overlays can also conflict with assistive technology a visitor already has configured, effectively fighting their own screen reader.

None of the standards covered in this guide, WCAG itself, the ADA Title II rule, the EAA's EN 301 549, or IS 5568, treat an installed overlay as evidence of conformance. Each one expects testing against specific, testable success criteria in the actual code users receive. Fix accessibility the way you would fix a Core Web Vitals problem: in the codebase, not with a script that papers over the symptom. Our Core Web Vitals guide covers the same principle for performance: real fixes live in your code and your build, not in a plugin promising a shortcut.

Building an Accessibility Compliance Program: A Step-by-Step Checklist

A program beats a one-time audit, because new pages and features reopen old issues. Run these steps in order, then repeat the last three on every major release.

1. Map your exposure. List every market with paying customers, government contracts or app store listings, and match each one to the regimes above: ADA Title III risk in the US, the EAA if you sell e-commerce or banking services into the EU, IS 5568 if you serve Israeli users.
2. Pick one conformance target. Build to WCAG 2.2 Level AA. It satisfies the ADA's practical benchmark, the EAA's EN 301 549 baseline and IS 5568 at the same time, so you run one program instead of three.
3. Run an automated scan first. Tools such as axe or Lighthouse catch real issues quickly, including missing labels, poor contrast and empty links, but cannot judge whether alt text is meaningful, whether tab order matches visual order, or whether an error message makes sense.
4. Test with a keyboard and a screen reader. Walk your highest-value flows (signup, checkout, core product actions) using only a keyboard, then again with VoiceOver or NVDA. These flows expose the barriers automated scanners miss entirely.
5. Triage by severity, not by page. Fix anything that blocks a task completely first, such as an inability to submit a form or escape a modal, then serious barriers, then AAA-level polish. A prioritized backlog beats a flat list of hundreds of issues nobody will finish.
6. Fix at the component level. A focus-ring fix, form-field pattern or accordion component in your design system resolves the issue everywhere it is used in one pull request, instead of patching the same bug on forty pages.
7. Add accessibility checks to CI. Automated linting, such as eslint-plugin-jsx-a11y, plus axe-core assertions in your test suite catch regressions before they ship, the same way visual regression tests catch layout bugs.
8. Publish an accessibility statement. State your conformance target, known limitations and a contact channel for accessibility feedback. This is a legal requirement in Israel, expected practice under the EAA, and useful evidence of good faith in the US.
9. Train the people who create content. Editors, marketers and support teams add images, PDFs and videos every week; engineering cannot fix alt text or caption quality it never sees.
10. Retest on every major release. Accessibility drifts with every redesign and new feature. If a redesign or platform migration is already on your roadmap, fold the audit into it rather than running two separate projects; see our website migration SEO checklist for how to sequence a redesign without losing ground on either front.

Illustrative scenario: assume a 40-page marketing site plus a 15-screen customer portal, built on a mature Next.js codebase with an existing component library. Fixing at the component level rather than per page, a WCAG 2.2 Level AA audit typically takes 2 to 4 weeks, and remediation typically takes 6 to 10 weeks of engineering time. A site with no design system, or with dozens of one-off legacy pages, should expect both numbers to roughly double. These are typical market ranges for planning purposes, not a quote; actual scope depends heavily on your codebase and how many third-party widgets you embed.

How Agentixly Approaches Website Accessibility Compliance

Agentixly treats accessibility as an engineering discipline inside web development, not a bolt-on audit disconnected from your codebase. Our team includes veterans of Israel's elite technology units, and we apply the same disciplined, evidence-based approach to accessibility that we apply to security: test against a named standard, document the result, fix the root cause. A typical engagement moves through five phases.

1. Audit. Map applicable regimes based on your markets, then test against WCAG 2.2 Level AA with both automated scans and manual, assistive-technology testing. Deliverable: a severity-ranked backlog with effort estimates.
2. Remediate. Fix issues directly in your repository, prioritizing component-level and design-system fixes over one-off page patches, with every change reviewed as a normal pull request.
3. Verify. Retest fixed flows with keyboard and screen reader testing, and confirm the result against each relevant success criterion rather than declaring victory once an automated scan goes green.
4. Document. Draft an accessibility statement for you to publish, naming your conformance target and any known exceptions, matched to what Israel, the EU and US litigation practice each expect.
5. Sustain. Wire accessibility checks into CI and your design system so new features do not reintroduce fixed issues, and hand your team the patterns needed to keep building accessibly on its own.

What you get: a fixed, documented codebase you own outright, not a report that sits in a shared drive. When accessibility work is bundled with a broader rebuild, our custom web application development cost guide breaks down how that kind of budget typically splits across phases.

The Bottom Line

Website accessibility compliance is not one project with a finish line. It is an ongoing practice that happens to satisfy several legal frameworks at once, because WCAG 2.2 Level AA sits underneath all of them. Build it into your components, your CI pipeline and your content workflow, and the US, EU and Israeli questions mostly answer themselves.

This guide is general information, not legal advice; confirm your specific obligations with counsel who knows your markets and your product. If you want an engineering team that treats accessibility as part of the build rather than an afterthought, Agentixly's web development team can audit your current site or bake WCAG 2.2 Level AA into your next one. Get in touch and we will tell you honestly what your specific exposure looks like.