What is the European Accessibility Act and what changes in the code?

The European Accessibility Act (EAA) is Directive (EU) 2019/882, which imposes accessibility requirements on a closed list of consumer-facing products and services: e-commerce, banking services, e-books, electronic ticketing, self-service terminals. Italy transposed it through Legislative Decree 82/2022, which sets 28 June 2025 as the date from which the requirements apply to products and services placed on the market by private operators, with a dedicated exemption for microenterprises on the requirements concerning services. Unlike compliance regimes born as a downstream constraint, this one aims straight at the code and the interface, with the same by-design logic as the Cyber Resilience Act: it asks that a person with a visual, motor or cognitive disability can complete a purchase or a booking with the same autonomy as anyone else. It is the EU law that turns accessibility of these products and services into a condition for selling in the Union, like CE marking for electrical safety.

See also: Accessibility overlay · JavaScript widget sold as automatic compliance: it edits the DOM at runtime but never fixes the underlying markup.

What actually changes in the code

The reference technical standard is EN 301 549, developed by ETSI, CEN and CENELEC under a Commission mandate. On September 2, 2026 ETSI published version 4.1.1, the revision built for the EAA: meeting it counts in law as automatic proof of conformity only once its reference appears in the Official Journal of the EU. The previous version, 3.2.1, fully incorporates WCAG 2.1 level AA in its web chapter, then extends it to documents, native apps and interactive software that WCAG alone does not cover. In development practice this means working on a concrete set of requirements: correct HTML semantics instead of generic divs and spans, minimum color contrast between text and background, a working tab order and a visible focus indicator for keyboard navigation, ARIA attributes only where native markup falls short, and forms with associated labels and errors announced to screen readers. None of these points is new: they are the same WCAG criteria many agencies treated as optional. The difference is that now a market surveillance authority can check and sanction them, and an enterprise client can require them as a binding tender criterion.

An enterprise example

A recurring case is a consumer e-commerce store that discovers the problem late: the checkout flow works perfectly with a mouse, but a keyboard user gets stuck on a dropdown with no visible focus, or a screen reader cannot parse a payment form with no labels. Fixing it after release means touching components already in production, with regression tests across every page of the funnel; fixing it during the design system's construction means writing accessible components (buttons, forms, modals) once and reusing them everywhere. It is the classic retrofit cost versus the cost of building it right from the start, the same logic as secure by design applied to accessibility: some vendors offer accessibility overlays or scripts that promise automatic compliance without touching the code, but a serious audit does not settle for that shortcut.

Why it matters for decision makers

The EAA is not something to hand off to the legal department once a year: it has to be verified with a technical audit (manual, not just automated, because scanners miss many keyboard-navigation and reading-order problems), then fixed by correcting the existing code, and finally kept in check with continuous testing at every release, since a new feature can break the compliance already reached. Anyone commissioning a site or an app today should ask for EN 301 549 conformity in the brief, the document listing the project's requirements, not discover it at the end of the project when fixing it costs more. The showcase site of an SME that sells to other businesses falls outside the EAA, but anyone supplying software to a bank or a consumer e-commerce store will be asked for conformity in the contract; and service contracts signed before 28 June 2025 remain valid until they expire, at the latest in 2030.

This entry is informational and does not constitute legal advice: for verifying the applicable scope, exemptions and penalties under Legislative Decree 82/2022, involve your legal counsel or an accessibility compliance specialist.