Product

Accessibility in 2026: The EAA, WCAG 2.2 and US Legal Exposure

Abstract cover art for the article: Accessibility in 2026: The EAA, WCAG 2.2 and US Legal Exposure

Accessibility is now a condition of selling software to consumers in the European Union and a steady source of lawsuits in the United States. The European Accessibility Act has applied since 28 June 2025. In the US, private businesses have no federal web regulation but face thousands of federal suits a year, while state and local governments have a hard WCAG 2.1 AA deadline. The cheapest place to meet all of it is your design system, before you have two hundred screens to fix. Retrofitting later works, but you pay for every screen twice.

This is a practical overview for founders and product leaders. It is not legal advice. Scope questions under the EAA and the ADA turn on facts about your business, so confirm them with counsel in the markets you sell into.

The European Accessibility Act in plain terms

The EAA is Directive (EU) 2019/882. As a directive, it works through national laws in each member state, and those laws have applied since 28 June 2025. Penalties are also set nationally. The directive only requires them to be “effective, proportionate and dissuasive” and to take into account how serious the failure is and how many people it affects.

Who is in scope

Article 2 lists what is covered. Products include consumer computers and operating systems, payment terminals, ATMs, ticketing and check-in machines, smartphones, TV equipment and e-readers. Services include electronic communications, access to audiovisual media, passenger transport websites, apps and e-tickets, consumer banking, e-books and e-commerce.

For most startups, e-commerce is the category to check first. The directive defines it as services provided at a distance, through websites and mobile apps, “at the individual request of a consumer with a view to concluding a consumer contract.” A direct-to-consumer brand with a checkout is plainly in. A consumer subscription app that sells plans in the app is very likely in. A B2B platform sold to companies on enterprise contracts is a harder call, because the service obligations apply to services “provided to consumers,” and the directive defines a consumer as a person acting outside their trade or profession.

Some content is carved out. Pre-recorded video and audio and office documents published before 28 June 2025 are exempt. So are genuine archives that are no longer updated, and third-party content you neither fund, develop nor control. Service contracts signed before that date can run until they expire, but for no more than five years.

The microenterprise exemption is narrower than it sounds

Microenterprises that provide services are exempt from the accessibility requirements. The directive defines a microenterprise as one with fewer than 10 employees and annual turnover or balance sheet total of no more than EUR 2 million. The exemption covers services only. Microenterprises that make or sell in-scope products still have to comply, with lighter paperwork.

Two cautions. First, the directive says businesses must “genuinely fulfil” the definition in the Commission’s SME Recommendation 2003/361/EC. Under that Recommendation, headcount and financials can be combined with those of partner and linked companies, such as a parent group. Certain venture capital and angel holdings are treated more leniently, but the details matter. Second, the exemption expires the moment you grow past it. A seed-stage team of eight may be exempt today. After a Series A hiring plan it is not, and the product it already shipped is what has to comply.

If you are not based in the EU

The directive defines a service provider as anyone “who provides a service on the Union market or makes offers to provide such a service to consumers in the Union.” Unlike the definition of an importer, that wording does not require you to be established in the EU. If you sell an in-scope service to EU consumers from San Francisco or Tel Aviv, read the directive as applying to you. Service providers also have to publish information on how the service meets the requirements, usually in their general terms and conditions, as set out in Annex V.

Article 14 offers a narrow escape valve for requirements that would fundamentally alter the service or impose a disproportionate burden. You must document that assessment and keep it for five years. It is meant for genuine edge cases, and an inaccessible checkout is not one.

WCAG 2.2, EN 301 549 and which version to target

The EAA sets functional requirements. The technical detail comes from EN 301 549, the European standard for ICT accessibility. Meeting a harmonized standard gives you a presumption of conformity. According to AccessibleEU, the Commission’s accessibility resource center, EN 301 549 v4.1.1 was published in September 2026 and adopts WCAG 2.2 in place of WCAG 2.1. It is not yet the legal reference. Until the Commission cites it in the Official Journal, the reference remains v3.2.1 from 2021, which is based on WCAG 2.1 AA.

Design to WCAG 2.2 Level AA. It was first published as a W3C Recommendation on 5 October 2023 and builds on 2.1: it adds new criteria and removes only one, 4.1.1 Parsing, as obsolete. Targeting 2.1 today means redoing work once v4.1.1 is cited.

WCAG 2.2 added nine success criteria, six of them at Level A or AA. Most of them are design decisions. Focus Not Obscured says a focused element must not be entirely hidden by author-created content such as a sticky header or cookie bar. Dragging Movements requires a single-pointer alternative to any drag interaction. Target Size (Minimum) sets 24 by 24 CSS pixels as the floor for pointer targets, with exceptions for spacing and inline links. Accessible Authentication (Minimum) says no step in a login can require a cognitive test, such as remembering a password or solving a puzzle, unless there is an alternative or a mechanism that helps. W3C’s guidance on that criterion says blocking paste or password managers fails it unless you offer an alternative. Consistent Help and Redundant Entry round out the six.

The US: two different regimes

Private businesses: Title III and the lawsuit numbers

For private companies, the risk is litigation under Title III of the ADA. There is still no federal regulation that sets a technical standard for business websites. The Department of Justice’s 2022 guidance says businesses open to the public must make their websites accessible and have flexibility in how they do it. It points to WCAG and the Section 508 standards as helpful references.

The most-cited count with a published method comes from the law firm Seyfarth Shaw, which searches Courthouse News Service data by keyword and reviews the results by hand. Its 2025 figures show 3,117 website accessibility suits filed in federal court, up 27% from 2024. They made up 36% of the 8,667 federal ADA Title III cases filed that year, compared with 28% the year before. New York, Florida and Illinois led. The count covers federal courts only, and the authors note that a keyword search can miss cases, so treat it as a floor. Geography follows case law. The authors point out that New York federal judges have been more receptive to suits against online-only businesses, while appeals courts in California have held that online-only businesses are not covered by the ADA. Where you operate changes your exposure, which is one more question for counsel.

Public entities: the DOJ’s Title II rule

In April 2024 the DOJ adopted a Title II rule that makes WCAG 2.1 Level AA the technical standard for the websites and mobile apps of state and local governments, including their agencies, special purpose districts and commuter authorities. It does not apply to private businesses under Title III. On 20 April 2026 an interim final rule pushed the compliance dates back one year: to 26 April 2027 for entities serving a population of 50,000 or more, and to 26 April 2028 for smaller entities and special district governments.

If you sell to cities, counties, public universities or transit agencies, their obligation becomes a line in your procurement questionnaire.

Overlays do not solve this

Vendors will pitch a script that promises compliance in one line of code. In April 2025 the Federal Trade Commission finalized an order requiring accessiBe to pay $1 million over claims that its accessWidget product could make any website WCAG-compliant. The order bars the company from making such claims without evidence. An overlay cannot make a custom date picker usable with a keyboard. That problem lives in your components.

What to build into the design system on day one

The WebAIM Million 2026 audit of the top one million home pages found detectable WCAG failures on 95.9% of them, an average of 56.1 errors per page. Six failure types made up 96% of all detected errors: low-contrast text (83.9% of pages), missing image alt text (53.1%), missing form labels (51%), empty links (46.3%), empty buttons (30.6%) and missing document language (13.5%). Nearly all of these are token and component decisions, which is why the system is the place to fix them.

Decision Day one, in the system Cost of retrofitting
Color tokens Every text and background pair checked for 4.5:1 (3:1 for large text and UI components) before it becomes a token Brand palette changes, marketing sign-off, every screen re-checked
Focus styles A visible focus ring that is part of the brand, and sticky elements that never cover it Hunting down every element with outline removed
Target size Icon buttons and controls that meet 24 by 24 CSS pixels in the component spec Layout reflow across dense tables and toolbars
Form fields A field component that cannot render without a programmatic label and error text Auditing every form, including ones marketing built
Interactive components Native elements first; menus, dialogs and comboboxes built and keyboard-tested once Rewriting custom widgets that only work with a mouse
Authentication Paste and password managers allowed; no puzzle CAPTCHA without an alternative Reworking a flow that security and growth both own

Be careful with ARIA. The same WebAIM report found that pages with more ARIA attributes had more detected errors, and 22% of ARIA menus introduced barriers because the required markup and keyboard behavior were missing. Use native buttons, links and inputs unless you have a reason not to, and test the exceptions with a screen reader.

Put contrast checks in the token pipeline and keyboard checks in each component’s definition of done. Run automated tests in CI, but remember WebAIM’s caveat that the absence of detected errors does not mean a page is accessible. Plan a manual audit before major launches.

What can wait, and when this advice does not apply

A third-party audit and a formal conformance report can wait for real traction, though if you are in EAA scope the Annex V information is already due. The token and component decisions above should not wait, because they are cheap now and expensive later.

The legal urgency is lower in a few cases. A pure B2B tool sold only to businesses, with no consumer transactions and no EU consumer users, may sit outside the EAA’s service scope. A team that genuinely qualifies as a microenterprise providing services is exempt for now. With no US public-sector customers, the Title II deadlines are not yours. None of that removes Title III risk for a consumer-facing US product. Larger customers can also ask for a conformance report during procurement, so being out of legal scope does not always mean being out of commercial scope.

A concrete next step

Pick the three flows that make you money, usually signup, checkout and the main dashboard. Complete each one using only a keyboard, then again with a screen reader such as VoiceOver or NVDA, and zoomed to 200%. Note every place you get stuck. Then run your color tokens through a contrast checker and list every pair below 4.5:1. That list and your stuck points are your first design-system backlog. Fix them at the component level and the next hundred screens inherit the fix.

Sources