If you run a website, app, or self-service terminal that serves the Italian market, the Stanca Act framework is now your direct concern, not just a public-sector rule. Law 4/2004, known as Legge Stanca after the minister who introduced it, originally bound public administrations and public-interest bodies. The European Accessibility Act (EAA) changed the picture by pulling private companies into the same orbit.
This guide explains how the Stanca Act, the AgID technical guidelines, and the EAA fit together in Italy: who is in scope, the WCAG 2.2 and EN 301 549 baseline you must hit, and exactly what your accessibility statement has to say.
From Legge Stanca to the EAA: what actually changed
The original 2004 Stanca Act was a public-sector instrument. It obliged the Italian state, regions, municipalities, and bodies providing public-interest services to make their digital tools accessible. Private companies were largely untouched unless they were contracting with government.
The European Accessibility Act, Directive (EU) 2019/882, changed that. Italy transposed it through Legislative Decree 82/2022, which amended the Stanca Act framework and extended accessibility duties to private economic operators. The obligations apply from 28 June 2025, the same EU-wide start date used in every member state. So the law you knew as a public-sector rule is now the chassis Italy uses to enforce private-sector accessibility.
If you also operate in other EU markets, the same directive surfaces under different national names. Germany uses the Barrierefreiheitsstärkungsgesetz (BFSG), France relies on the RGAA, and Italy uses the Stanca Act with AgID guidelines. The technical target is deliberately identical, which is the point of harmonisation. See our European Accessibility Act overview for the cross-border view.
Who is in scope in Italy
The EAA, and therefore the Stanca Act plus Decree 82/2022 regime, covers a defined list of products and services. If your business offers any of the following to Italian consumers, you are almost certainly in scope:
- E-commerce: online stores and the full purchase journey, including checkout and account creation
- Consumer banking and payment services, plus banking self-service terminals
- E-books, e-readers, and the related software and hardware
- Electronic communications services and their supporting consumer equipment
- Access services for audiovisual media (the menus and apps, not the programmes themselves)
- Passenger transport services: ticketing, check-in, real-time travel information, and the related machines
- Self-service terminals such as ATMs, ticketing kiosks, and check-in machines
Microenterprises that provide services (fewer than 10 employees and under EUR 2 million annual turnover) are generally exempt from the service obligations. That carve-out is narrow: it does not blanket-cover product manufacturers, and it does not relieve you of the older Stanca Act duties if you supply the public sector. Verify your status against the actual thresholds rather than assuming.
The technical baseline: WCAG 2.2 and EN 301 549
The AgID guidelines do not invent a separate Italian checklist. They point to the harmonised European standard EN 301 549, which in turn adopts the WCAG 2.2 Level A and AA success criteria as its web baseline. Meet WCAG 2.2 AA and you have satisfied the technical heart of both the Stanca Act and the EAA. Our WCAG overview and EN 301 549 guide break down how the two documents map onto each other.
WCAG 2.2 added several criteria that catch real-world failures, and these are now part of the baseline:
- 2.4.11 Focus Not Obscured (Minimum, AA): a sticky header or cookie banner must not hide the element a keyboard user just focused
- 2.5.7 Dragging Movements (AA): anything done by dragging (a slider, a map, reordering) needs a single-pointer alternative
- 2.5.8 Target Size (Minimum, AA): interactive targets must be at least 24 by 24 CSS pixels unless an exception applies
- 3.2.6 Consistent Help (A) and 3.3.7 Redundant Entry (A): help stays in a consistent place, and you don't force users to re-enter data they already gave
- 3.3.8 Accessible Authentication (Minimum, AA): no cognitive test such as transcribing a code can be the only way to log in
Note that WCAG 2.2 removed the old 4.1.1 Parsing criterion, so legacy 'valid HTML' findings no longer count against you. The criteria businesses still fail most often are the long-standing ones: text contrast of 4.5:1 for normal text and 3:1 for large text and user-interface components, 1.4.4 Resize Text, 1.4.10 Reflow so content works at 320 CSS pixels wide without horizontal scrolling, 1.4.12 Text Spacing, 2.4.7 Focus Visible, and 4.1.3 Status Messages for dynamic updates. Time-based media still needs the 1.2.x captions and audio descriptions.
You can check a page against several of these in seconds with AccessScan's free tools: run a full scan, or drill into a single problem area with the contrast, alt-text, and heading checkers.
The accessibility statement (dichiarazione di accessibilità)
Both the Stanca Act tradition and the EAA require a published accessibility statement, and Italy takes it seriously. For public bodies, AgID prescribes a model format generated through its own platform. Private operators under the EAA must publish equivalent information, either as a standalone statement or woven into their general terms and conditions.
A defensible statement should include:
- The conformance level you claim (for the web baseline this is WCAG 2.2 AA via EN 301 549)
- A specific, honest list of content that is not yet accessible, with the reason for each gap
- An accessible feedback mechanism so a user can report a barrier and reach a human
- A reference to the enforcement and complaints route, which in Italy runs through AgID
- The date the statement was prepared or last reviewed
Vague claims like 'this site is fully accessible' are worse than useless: an inaccurate statement is itself a compliance problem and a gift to any complainant. AccessScan's statement generator produces a draft tied to your actual scan results rather than boilerplate.
A practical compliance path
Treat conformance as a programme, not a one-time fix. A realistic sequence for an Italian business:
- Confirm scope: are you offering an in-scope product or service, and do the microenterprise thresholds apply to you?
- Audit against WCAG 2.2 AA, combining automated scanning with manual keyboard and screen-reader testing, since tools catch only part of the picture
- Prioritise the criteria that block tasks outright: checkout, login, forms, and navigation
- Remediate, then publish an accurate accessibility statement with a working feedback channel
- Re-test on a schedule and after major releases, because a single redesign can reintroduce barriers
Work through the accessibility checklist to scope the effort, and start with a free scan of your site to see where you stand against the Stanca Act and EAA baseline today.