Checklist di accessibilità web per piccole imprese ed e-commerce

Si immagini una cliente che usa uno screen reader. Trova le sneaker che cercava, sceglie il numero e preme quello che crede sia il pulsante del carrello. Lo screen reader dice “pulsante”. Nient'altro. Sulla pagina ce ne sono tre così e nessuno ha un nome, quindi se ne va, e il negozio non saprà mai perché.

La maggior parte dei problemi di accessibilità sui siti delle piccole imprese è così: invisibile per chi gestisce il sito, un vicolo cieco per il cliente. Questa checklist è pensata per chi gestisce un sito su Shopify, WooCommerce, PrestaShop, Wix o Squarespace senza uno sviluppatore in squadra.

Il sito di una piccola impresa deve essere accessibile?

Se vende a consumatori nell'UE, probabilmente sì. L'European Accessibility Act (si apre in una nuova scheda) copre i servizi di commercio elettronico dal 28 giugno 2025. L'esenzione principale riguarda le microimprese che forniscono servizi: meno di 10 addetti e un fatturato annuo o un totale di bilancio non superiore a 2 milioni di euro.

Commercio elettronico qui significa vendere a distanza, tramite un sito o un'app, “su richiesta individuale di un consumatore al fine di concludere un contratto di consumo” (articolo 3, punto 30). Un negozio online o un motore di prenotazione rientrano in questa definizione. L'esenzione riguarda solo i servizi: vendere prodotti interessati, come i lettori di e-book, fa comunque scattare le regole sui prodotti (articolo 4, paragrafo 5). Né aiuta avere sede fuori dall'UE: un negozio svizzero o britannico che vende a clienti in Italia rientra nell'ambito per quei clienti (articolo 3, punto 4). La nostra guida all'European Accessibility Act illustra leggi nazionali e sanzioni, compreso il D.Lgs. 82/2022.

Nel Regno Unito l'Equality Act 2010 (si apre in una nuova scheda) impone accomodamenti ragionevoli per le persone con disabilità, ma non fissa uno standard tecnico per i siti web. Negli Stati Uniti le indicazioni del marzo 2022 (si apre in una nuova scheda) del Dipartimento di Giustizia affermano che le imprese aperte al pubblico devono rendere accessibile ciò che offrono online, e che standard come le WCAG “forniscono indicazioni utili”. Qualunque cosa dica la legge, un cliente che non riesce a completare il checkout non compra.

Quali sono i problemi di accessibilità più comuni sui siti web?

Sei errori dominano. Nel WebAIM Million 2026 (si apre in una nuova scheda), una scansione automatica delle home page del primo milione di siti svolta a febbraio 2026, il 95,9% delle pagine presentava errori WCAG rilevati, con una media di 56,1 errori per pagina. Il testo a basso contrasto era il problema più frequente, presente sull'83,9% delle home page.

Le WCAG, le Linee guida per l'accessibilità dei contenuti web, sono lo standard alla base di queste verifiche; la maggior parte delle leggi rimanda al loro livello AA, e la nostra guida alle WCAG 2.2 spiega l'ultima versione. Inoltre, diversi controlli qui sotto riguardano aspetti che nessuno scanner è in grado di valutare.

Tutti riescono a leggere i testi e a capire le immagini?

Si comincia da qui, perché sono correzioni economiche e per lo più si fanno direttamente nell'editor del sito. Il testo deve avere un contrasto sufficiente, le immagini che portano informazioni devono avere un testo alternativo e nulla deve basarsi solo sul colore. Circa 1 uomo su 12 e 1 donna su 200 hanno un'alterazione della visione dei colori, secondo Colour Blind Awareness (si apre in una nuova scheda).

• Contrasto. Il testo normale richiede un rapporto di contrasto di almeno 4,5:1 (si apre in una nuova scheda) rispetto allo sfondo, il testo grande almeno 3:1. I colori vanno provati con uno strumento gratuito, compreso il testo sopra le foto dei banner. La nostra guida al contrasto dei colori mostra correzioni che rispettano il brand.
• Testo alternativo dei prodotti. Descrivere ciò che serve sapere a chi compra: “Maglione di lana blu navy a collo alto a coste, vista frontale” è meglio di “immagine prodotto 1”. Si parte dai dieci prodotti più venduti.
• Immagini decorative. Un motivo decorativo di sfondo deve avere un testo alternativo vuoto, così gli screen reader lo saltano. Alcune piattaforme riempiono un campo alt vuoto con il nome del file: meglio controllare.
• Solo colore. Un “Esaurito” indicato solo da un campione di colore ingrigito, o un campo obbligatorio segnato solo in rosso, non arriva a tutti. Si può guardare la pagina con il filtro in scala di grigi dello smartphone e aggiungere una parola o un'icona ovunque il significato sparisca.
• Zoom. Con lo zoom del browser al 200%, il testo deve ingrandirsi senza sovrapporsi né essere tagliato, e il menu deve continuare a funzionare.
• Lingua della pagina. Qualsiasi strumento gratuito segnala una dichiarazione di lingua mancante. È un'impostazione del tema o una riga da cambiare nel template.

Il sito si può usare con la tastiera?

Molte persone navigano senza mouse: chi usa uno screen reader, chi ha un tremore o una mobilità ridotta delle mani, e chiunque si sia appena ritrovato con il trackpad fuori uso. Basta mettere da parte il mouse e premere Tab. Si deve poter raggiungere ogni link, pulsante e campo dei moduli in un ordine sensato, vedere sempre dove ci si trova e non restare mai bloccati.

• Focus visibile. Un contorno deve indicare l'elemento attivo, e un header fisso o una bolla della chat non devono coprirlo (criterio 2.4.11 Focus non nascosto delle WCAG 2.2). Molti temi tolgono il contorno per estetica; uno sviluppatore può ripristinarlo.
• Nessuna trappola. Aprire da tastiera il menu, il selettore della taglia, i pop-up e la galleria di immagini, scegliere qualcosa, poi provare a uscire. Il tasto Esc deve chiudere i pop-up.
• Nomi per le icone. Ogni link o pulsante a forma di icona ha bisogno di un nome che lo screen reader possa annunciare, come “Carrello, 2 articoli”. “Clicca qui” va sostituito con parole che dicano dove porta il link.
• Link per saltare al contenuto e titoli. La prima pressione di Tab dovrebbe mostrare un link “Vai al contenuto”. Nel sondaggio 2024 di WebAIM tra gli utenti di screen reader (si apre in una nuova scheda), il 71,6% degli intervistati ha detto di esplorare una pagina lunga prima di tutto attraverso i titoli: servono veri livelli di titolo, non testo in grassetto.
• Obiettivi da toccare. Le WCAG 2.2 chiedono obiettivi di almeno 24 per 24 pixel CSS, o abbastanza spazio intorno (criterio di successo 2.5.8 (si apre in una nuova scheda)).

Tutti riescono a completare moduli, carrello e checkout?

Il checkout è il punto in cui i problemi di accessibilità costano denaro in modo diretto, quindi va testato dall'inizio alla fine, compreso ciò che succede quando qualcosa va storto. Ogni campo ha bisogno di un'etichetta visibile, gli errori devono spiegare il problema a parole e l'accesso non deve dipendere da test di memoria o rompicapi. Contano anche le pagine del fornitore dei pagamenti.

• Etichette, non segnaposto. Il testo segnaposto (placeholder) sparisce appena si digita ed è spesso troppo chiaro per essere letto. Ogni campo ha bisogno di un'etichetta che resti visibile.
• Messaggi di errore. Inviare il modulo vuoto. Ogni errore deve essere scritto per esteso (“Inserire il CAP, per esempio 00184”), stare accanto al proprio campo ed essere annunciato, non limitarsi a colorare di rosso un bordo.
• Non chiedere due volte. Offrire “L'indirizzo di fatturazione è lo stesso” invece di far ridigitare l'indirizzo di consegna. Le WCAG 2.2 ne hanno fatto un requisito di livello A, il 3.3.7 Inserimento ridondante.
• Login. Lasciare che si possano incollare password e codici monouso e usare i password manager. Impedire di incollare viola il criterio di autenticazione accessibile (si apre in una nuova scheda) delle WCAG 2.2, a meno che non si offra un altro modo per accedere.
• CAPTCHA. Nel sondaggio 2024 di WebAIM, gli utenti di screen reader hanno indicato il CAPTCHA come l'elemento più problematico del web. Se serve una protezione dai bot, meglio evitare i rompicapi visivi e offrire sempre un'alternativa non visiva.
• Limiti di tempo. Se un carrello o una prenotazione scadono, avvisare e permettere di prolungare.

Se alcune parti del checkout appartengono alla piattaforma o al fornitore dei pagamenti, vanno testate comunque: i problemi si segnalano e si elencano come problemi noti.

E i banner dei cookie, i pop-up e i widget di chat?

Per i clienti, gli script di terze parti fanno parte del sito. Un banner dei cookie che non si chiude da tastiera blocca ogni pagina, e un pop-up della newsletter che si prende il focus a metà checkout può far perdere una vendita. Ogni script aggiunto va testato, e prima di installarne uno nuovo conviene chiedere al fornitore come gestisce l'accessibilità.

• Banner dei cookie. Si raggiungono “Accetta” e “Rifiuta” con Tab, si leggono con lo zoom al 200% e poi si riprende da dove si era rimasti?
• Pop-up. Il focus deve entrare nel pop-up, restarci fino alla chiusura e poi tornare indietro. Il tasto Esc deve chiuderlo.
• Widget di chat. Il pulsante ha bisogno di un nome, la finestra deve aprirsi e chiudersi da tastiera e sullo smartphone non deve coprire “Paga ora”.
• Caroselli. Tutto ciò che si muove da solo per più di cinque secondi deve poter essere messo in pausa, fermato o nascosto (WCAG 2.2 (si apre in una nuova scheda), criterio di successo 2.2.2).
• Contenuti incorporati. Widget di recensioni, mappe e strumenti di prenotazione stanno anch'essi sulla pagina. Gli errori vanno segnalati al fornitore.

Video, PDF e menu funzionano per tutti?

I video hanno bisogno di sottotitoli, l'audio di una trascrizione, e le informazioni importanti non devono stare solo in un PDF o in un'immagine. Un ristorante con il menu in PDF scansionato, o un negozio con la guida alle taglie in foto, esclude chi usa uno screen reader e chiunque abbia bisogno di ingrandire sullo smartphone.

• Sottotitoli e trascrizioni. I sottotitoli automatici vanno corretti prima della pubblicazione. I podcast hanno bisogno di una versione testuale.
• Testo in immagine. Menu, listini, guide alle taglie e orari vanno messi su una normale pagina web. Se serve un PDF, va esportato con titoli e tag dal programma di videoscrittura invece di scansionare una stampa.
• File meno recenti. L'EAA non chiede di correggere i documenti d'ufficio o i contenuti audio e video preregistrati pubblicati prima del 28 giugno 2025, né gli archivi che non si aggiornano più (articolo 2, paragrafo 4). I file nuovi rientrano nell'ambito.

Cosa si può correggere da soli, e quando servono uno sviluppatore o un audit?

La maggior parte dei problemi di contenuto si corregge da soli nel CMS: testi alternativi, titoli, testo dei link, colori, sottotitoli e molte etichette dei moduli. I problemi a livello di tema, come stili del focus mancanti, trappole per la tastiera e menu a tendina personalizzati, richiedono uno sviluppatore. Un audit ha più senso quando le basi sono sistemate, o prima di mettere online un restyling.

Che ruolo ha un widget come il nostro? Un pannello lato visitatore come SiteAccessible permette di aumentare il contrasto, ingrandire il testo o attivare una guida di lettura. Questo aiuta alcuni visitatori, ma non spunta nessuna voce di questa checklist: un pulsante senza nome resta senza nome e una trappola per la tastiera resta una trappola. Prima si sistema il sito, poi il widget si aggiunge come extra.

Come documentare il lavoro fatto?

Basta un registro semplice di cosa si è testato, quando, cosa si è corretto e cosa non funziona ancora, da cui pubblicare una sintesi onesta in una dichiarazione di accessibilità. Se si rientra nell'EAA, bisogna anche pubblicare informazioni su come il servizio soddisfa i requisiti di accessibilità, di solito nelle condizioni generali o in un documento equivalente.

Questo secondo obbligo deriva dall'allegato V della direttiva; il formato lo stabilisce la legge nazionale. La nostra guida alla dichiarazione di accessibilità contiene un modello da adattare. Poi si tratta di mantenere il ritmo:

1. Applicare la checklist alle tre pagine chiave e fare uno screenshot di ogni errore.
2. Correggere da soli, entro la settimana, gli elementi di contenuto.
3. Affidare a uno sviluppatore i punti su tema e checkout, partendo dai più gravi.
4. Ritestare ogni correzione con la tastiera oltre che con lo strumento di verifica.
5. Pubblicare o aggiornare la dichiarazione, con la data.
6. Ripetere ogni volta che si aggiunge un'app, si cambia tema o si lancia una nuova landing page.