For years, web accessibility was treated as a nice-to-have. Since June 28, 2025, it is a legal requirement for a wide range of digital products and services sold to consumers in the EU under the European Accessibility Act. At the same time, the state of the web is poor: in 2026, automated tests found accessibility failures on 95.9% of the top one million home pages. This guide explains who the EAA applies to, what WCAG 2.2 changed, which problems are most common and how to make an existing React or Next.js product accessible without a rewrite.

The European Accessibility Act in brief

The European Accessibility Act, Directive (EU) 2019/882, harmonizes accessibility requirements for products and services across the EU. Member states had to transpose it into national law, and the requirements apply from June 28, 2025 (European Commission: European Accessibility Act).

Covered products and services include computers and operating systems, smartphones, ATMs and ticketing machines, e-books, banking services, passenger transport services and e-commerce. In practice, an online store, a banking app or a booking site serving EU consumers is in scope.

Key points for software companies:

  • Microenterprises providing services are exempt — companies with fewer than 10 employees and annual turnover or balance sheet of no more than €2 million.
  • It applies to B2C. Purely internal tools and B2B systems are generally outside the EAA, although public sector websites have separate rules under the Web Accessibility Directive.
  • Non-EU companies are covered when they sell to EU consumers.
  • The technical benchmark is the harmonized standard EN 301 549, which incorporates WCAG success criteria at level AA. Building to WCAG 2.2 AA is the practical target.

Enforcement is national, through market surveillance authorities, with penalties set by each member state.

WCAG 2.2: what's new

WCAG 2.2 became a W3C Recommendation on October 5, 2023 and adds nine success criteria; the obsolete 4.1.1 Parsing was removed (W3C: What's new in WCAG 2.2; WCAG 2.2). The ones at levels A and AA that most products must meet:

Criterion Level What it requires
2.4.11 Focus Not Obscured (Minimum) AA A focused element is not completely hidden by sticky headers, cookie banners or chat widgets
2.5.7 Dragging Movements AA Anything done by dragging also works with a single click or tap
2.5.8 Target Size (Minimum) AA Interactive targets are at least 24×24 CSS pixels or have enough spacing
3.2.6 Consistent Help A Help links or contact options appear in the same place across pages
3.3.7 Redundant Entry A Users don't have to re-enter information already provided in the same process
3.3.8 Accessible Authentication (Minimum) AA Login doesn't require a cognitive test such as remembering or transcribing, unless an alternative exists; allow password managers and paste

The most common failures

The WebAIM Million 2026 analysis of one million home pages found WCAG failures on 95.9% of them, with an average of 56.1 errors per page (WebAIM Million). Six problems account for about 96% of detected errors and have topped the list for seven years:

  1. Low-contrast text — 83.9% of pages
  2. Missing alternative text for images — 53.1%
  3. Missing form input labels — 51%
  4. Empty links — 46.3%
  5. Empty buttons — 30.6%
  6. Missing document language — 13.5%

The good news: these are cheap to fix and easy to test automatically.

Fixing accessibility in React and Next.js

Semantics first

Use native elements: <button> for actions, <a href> for navigation, <label> for inputs, headings in order. A <div onClick> is invisible to keyboard and screen reader users unless you rebuild everything a button already does.

// Bad: icon-only button with no accessible name, not keyboard-focusable
<div className="icon" onClick={openCart}><CartIcon /></div>

// Good: native button with an accessible name
<button type="button" onClick={openCart} aria-label="Open cart, 3 items">
  <CartIcon aria-hidden="true" />
</button>

Forms

Every input needs a visible label linked with htmlFor, errors described in text and announced, and required fields marked. Don't rely on placeholder text as the label. Support autocomplete attributes so browsers and password managers can fill fields — this also helps with 3.3.7 and 3.3.8.

Keyboard and focus

  • Every interactive element must be reachable and operable with the keyboard, in a logical order.
  • Never remove focus outlines without a visible replacement.
  • Dialogs trap focus while open and return it when closed; libraries such as Radix UI handle this correctly out of the box.
  • Account for sticky headers and banners so focused elements are not obscured (2.4.11), for example with scroll-padding-top.

Images, color and motion

  • Meaningful images get descriptive alt; decorative ones get alt="".
  • Text contrast at least 4.5:1, large text 3:1. Check your design tokens once instead of every page.
  • Respect prefers-reduced-motion for animations.

Language and structure

Set lang on the <html> element and on passages in another language. For multilingual sites, make sure each localized page declares its own language — this helps screen readers and search engines alike, as discussed in Technical SEO for Next.js.

Testing: automated plus manual

Automated tools catch roughly the failure types listed above, not everything. Use both:

  • Automated: axe-core in unit or end-to-end tests, Lighthouse accessibility audits in CI, linting with eslint-plugin-jsx-a11y.
  • Manual: keyboard-only walkthrough of key flows (search, product page, cart, checkout, login), screen reader checks with NVDA or VoiceOver, zoom to 200% and 400%.
  • With users: include people with disabilities in usability testing for critical flows.
// Playwright + axe: fail the build on serious violations in checkout
import AxeBuilder from "@axe-core/playwright"

test("checkout has no serious a11y violations", async ({ page }) => {
  await page.goto("/checkout")
  const results = await new AxeBuilder({ page }).withTags(["wcag2a", "wcag2aa", "wcag22aa"]).analyze()
  expect(results.violations.filter((v) => ["serious", "critical"].includes(v.impact!))).toEqual([])
})

A practical remediation plan

  1. Scope: list consumer-facing flows covered by the EAA and the countries you serve.
  2. Audit: automated scan of all templates plus manual testing of the top five user journeys.
  3. Fix the design system first: color tokens, focus styles, button and form components. One fix propagates everywhere.
  4. Fix templates and flows in order of traffic and revenue.
  5. Publish an accessibility statement describing conformance, known limitations and a contact for feedback.
  6. Prevent regressions: automated checks in CI and accessibility in the definition of done.

Accessibility work often improves performance and conversion too: lighter, semantic markup helps Core Web Vitals, see Core Web Vitals in 2026. If your product also includes AI features for EU users, the AI Act adds its own transparency duties, covered in EU AI Act for software companies.

What to put in an accessibility statement

An accessibility statement is expected under the EAA and builds trust with users. Keep it short and honest:

  • Scope: which websites and apps it covers.
  • Standard and status: for example, "partially conforms to WCAG 2.2 level AA".
  • Known limitations: what is not yet accessible, why, and when you plan to fix it.
  • Alternatives: how users can get the same service another way, such as by phone or email.
  • Feedback contact: an email or form, with an expected response time.
  • Date of the last review.

FAQ

Does the EAA apply to our B2B SaaS? Generally no, if it is sold only to businesses. Consumer-facing parts, such as a checkout used by consumers, may be in scope. Check with counsel.

Is WCAG 2.1 enough or do we need 2.2? EN 301 549 currently references WCAG 2.1 AA, but WCAG 2.2 is backward compatible and the current W3C standard. Targeting 2.2 AA future-proofs the work.

Can an accessibility overlay widget make us compliant? No. Overlays don't fix underlying code problems and often interfere with assistive technologies.

How long does remediation take? For a typical store, fixing the design system and main flows takes four to eight weeks; continuous testing keeps it compliant.

Who enforces the EAA in practice? National market surveillance authorities in each member state. Many also accept complaints from users and consumer organizations, so an inaccessible checkout can trigger an investigation.

Do PDFs and documents count? Yes, documents that are part of the service — invoices, contracts, booking confirmations — should be accessible too.

Sources

  1. European Union. Directive (EU) 2019/882 — European Accessibility Act.
  2. European Commission. European Accessibility Act.
  3. W3C. Web Content Accessibility Guidelines (WCAG) 2.2 and What's new in WCAG 2.2.
  4. WebAIM (2026). The WebAIM Million.