Il 28 giugno 2025 ha segnato l’entrata in vigore dell’European Accessibility Act (direttiva UE 2019/882) per la maggior parte dei prodotti e servizi e-commerce venduti a consumatori europei. Un anno dopo, il quadro sul campo è chiaro: la maggior parte dei negozi PrestaShop che operano in Italia non è conforme — e la maggior parte dei merchant lo ignora ancora.
Il tema non è solo etico. È ormai un rischio giuridico, commerciale (perdita di gare pubbliche, B2B sensibili) e reputazionale. Questo articolo fa il punto sul quadro legale reale, sulle sanzioni effettivamente applicate da un anno, e sulla roadmap tecnica per mettere un negozio PrestaShop 8 o 9 in conformità senza rifare il tema.
Il quadro legale che si applica a un negozio PrestaShop nel 2026
L’EAA è stato recepito in diritto italiano dal D.Lgs. 82/2022. Il perimetro è ampio: ogni servizio e-commerce destinato a consumatori europei è interessato — sito web, app mobile, processo di acquisto, comunicazione post-vendita.
Due esenzioni strutturali:
- Le microimprese ai sensi europei (meno di 10 dipendenti E fatturato o bilancio inferiore a 2 M€) sono esentate per i loro servizi. Attenzione: la soglia si valuta a livello di gruppo.
- I contenuti di terze parti non controllati (commenti utente grezzi, ad esempio) non rientrano nel perimetro, ma il merchant resta responsabile della struttura di accoglienza di questi contenuti.
La norma tecnica di riferimento in Italia è la EN 301 549 v3.2.1 (che si allinea su WCAG 2.1 livello AA). In pratica, la norma internazionale che guida il lavoro quotidiano è WCAG 2.2, pubblicata nell’ottobre 2023, che aggiunge nove criteri di successo — in particolare il focus visibile (2.4.11), i target di puntamento sufficientemente grandi (2.5.8) e la persistenza degli elementi di aiuto (3.2.6). Un negozio conforme WCAG 2.2 AA è conforme alla EN 301 549.
Le sanzioni effettivamente applicate da un anno
Il controllo è ripartito tra AGID (volet contenuti digitali) e AGCM (volet consumatori). In un anno, il quadro è il seguente:
- Fase pedagogica maggioritaria: i primi controlli 2025 hanno soprattutto portato a diffide e impegni correttivi. Poche ammende ferme.
- Inasprimento a partire dal Q1 2026: diverse sanzioni amministrative sono state notificate, scaglionate da 5.000 € a 75.000 € secondo la dimensione dell’operatore e la gravità (assenza totale di dichiarazione di accessibilità in particolare).
- Il tetto legale è alto: fino al 5% del fatturato per le inadempienze gravi e reiterate.
- Rischio indiretto probabilmente superiore: esclusione da gare pubbliche, rifiuto di referenziamento da parte di centrali di acquisto B2B, segnalazioni clienti sui comparatori.
L’obbligo visibile più sistematicamente controllato è la dichiarazione di accessibilità, che deve essere pubblicata sul sito, datata, e indicare il livello di conformità raggiunto (totalmente / parzialmente / non conforme) nonché uno schema pluriennale di adeguamento. Un negozio senza questa pagina viene individuato immediatamente.
L’audit sul campo: cosa zoppica davvero su PrestaShop
Sulla base degli audit che conduciamo su temi Classic, Hummingbird, Warehouse e temi custom, le non conformità ricorrenti si concentrano su sei famiglie:
1. Contrasto insufficiente (criterio WCAG 1.4.3 / 1.4.11)
Il grigio chiaro su fondo bianco usato per i prezzi barrati, le diciture “IVA inclusa”, o le icone di rassicurazione manca quasi sistematicamente il rapporto 4.5:1 (testo normale) o 3:1 (testo grande e interfacce). Una passata di audit con Lighthouse o axe-core restituisce in genere 15-40 difetti di contrasto su una scheda prodotto standard.
2. Navigazione da tastiera rotta
Il menu dropdown in alto, i filtri della facet a sinistra, il selettore di quantità custom, il popup newsletter — tutti questi componenti sono frequentemente inaccessibili da tastiera (Tab + Invio + Spazio). Il focus visibile sparisce nella metà dei temi premium. È un criterio bloccante.
3. Form di checkout non etichettato correttamente
Campo senza attributo label associato, indicazione di errore solo a colori (rosso), nessun attributo aria-describedby per i vincoli (“8 caratteri minimo”), riepilogo inaccessibile allo screen reader. Il checkout one-page nativo di PrestaShop 8 ha fatto progressi ma resta da completare, soprattutto appena viene aggiunto un modulo di pagamento o un selettore di indirizzo di terze parti.
4. Immagini senza testo alternativo strutturato
Il buon vecchio problema: tutti i visual prodotto hanno un attributo alt vuoto o ripetuto (nome del prodotto copia-incollato). La logica corretta: alt vuoto per i visual puramente decorativi (alt=””), alt descrittivo e differenziato per le viste secondarie (“vista posteriore”, “dettaglio cucitura”). PrestaShop non lo fa automaticamente, spetta al merchant inserirlo all’import catalogo.
5. Video e carosello automatici
Carosello home che scorre da solo senza pulsante pausa, video prodotto in autoplay: violazione diretta del criterio 2.2.2 (Pausa, arresto, occultamento). E tecnicamente, per un visitatore con un disturbo vestibolare, lo scorrimento automatico può scatenare un malessere.
6. Captcha bloccante e popup intrusivi
reCAPTCHA v2 “spunta la casella” senza alternativa per utenti di screen reader, popup newsletter senza trappola di focus, modale cookie impossibile da chiudere da tastiera. Tre classici che ogni audit rileva in pochi minuti.
Roadmap di adeguamento — senza rifare il tema
Buona notizia: la maggior parte dei negozi può raggiungere una conformità sostanziale WCAG 2.2 AA in 4-8 settimane di lavoro mirato, senza refactoring completo. Ecco la sequenza che funziona:
Settimana 1 — Audit quantificato
Lanciare un audit automatizzato (axe DevTools, WAVE, Lighthouse) su 10 pagine rappresentative: home, categoria, scheda prodotto, carrello, step di spedizione, step di pagamento, conferma, blog, contatti, dichiarazione legale. Affiancare un test manuale solo tastiera + un test screen reader (NVDA gratuito su Windows, VoiceOver su Mac). Estrarre una matrice “criterio / pagina / severità” con punteggi.
Settimane 2-3 — Correzioni di superficie ad alto impatto
- Ripresa della palette colori per raggiungere i rapporti di contrasto — spesso una variabile CSS da regolare, al massimo due o tre.
- Aggiunta di un focus visibile globale e leggibile (outline 2 pixel con un colore contrastato).
- Ripresa delle label alt sul catalogo: regola automatizzabile via uno script SQL o un modulo dedicato.
- Rimozione degli autoplay e aggiunta di un controllo di pausa sul carosello.
Settimane 4-5 — Componenti critici
- Refactoring del menu principale con gestione tastiera completa (Tab, Invio, Esc, frecce).
- Etichettatura ARIA corretta dei filtri facet, del selettore di quantità, delle notifiche carrello.
- Ripresa dei form: label associate, indicazioni di errore in testo E colore, focus sul primo campo in errore.
Settimane 6-7 — Conformità editoriale e dichiarazione
- Audit delle pagine CMS e degli articoli del blog (struttura dei titoli, alt delle immagini).
- Redazione e pubblicazione della dichiarazione di accessibilità conforme al modello ufficiale AGID (stato di conformità, deroghe giustificate, feedback utente, ricorso).
- Schema pluriennale di adeguamento pubblicato nella stessa pagina.
Settimana 8 — Test utente e documentazione
Un test con un utente reale in situazione di disabilità (deficit visivo o motorio) resta l’unico modo per validare di non aver mancato un criterio sottile. È anche un argomento in caso di controllo: dimostrare un percorso di miglioramento continuo.
La trappola dei moduli di terze parti
L’angolo cieco maggiore: i moduli di terze parti aggiungono in permanenza elementi non auditati. Un popup wishlist, un modulo di cross-sell con carosello, un widget di recensioni di terze parti — ogni aggiunta può rompere la conformità acquisita. La regola sana: auditare ogni nuovo modulo con axe-core prima del deploy, ed esigere dallo sviluppatore una dichiarazione di compatibilità WCAG 2.2 AA.
Lato DataFirefly, l’insieme dei moduli recenti (carrello laterale, avvisi, ricerca live, page builder) è testato con axe-core e screen reader prima della pubblicazione, e la dichiarazione di conformità tecnica è fornita su richiesta per i merchant sotto controllo dell’autorità.
Conclusione: il rischio non è più teorico
L’argomento “nessuno controlla” non è più sostenibile un anno dopo l’entrata in vigore dell’EAA. Le sanzioni iniziano ad arrivare, la dichiarazione di accessibilità è diventata il minimo visibile, e la pressione B2B si intensifica (centrali di acquisto, gare pubbliche, grandi committenti esigono ormai impegni WCAG nei loro contratti).
L’angolo strategico corretto per un merchant PrestaShop non è fare il minimo cosmetico, ma usare l’adeguamento come un audit UX generale: la maggior parte delle correzioni di accessibilità migliora anche la conversione (leggibilità, contrasto, navigazione tastiera apprezzata dai power-user, struttura semantica migliore per la SEO e l’AEO). Un investimento di 4-8 settimane che serve a più obiettivi.
