Come rendere accessibile il tuo sito web: guida introduttiva WCAG 2.2

Per rendere accessibile un sito web, costruiscilo in modo che le persone possano usarlo con la tastiera, uno screen reader, lo zoom o un dispositivo a interruttore oltre che con il mouse: usa elementi HTML reali per pulsanti, link, intestazioni ed etichette dei moduli, dai alle immagini testi alternativi significativi, mantieni alto il contrasto del testo e rendi visibile il focus. Lo standard da raggiungere è WCAG 2.2 Livello AA. I controlli automatici individuano una parte del problema; un test di dieci minuti con la tastiera e uno screen reader ne individua gran parte del resto.

Cosa significa "accessibile" in pratica

L'accessibilità riguarda le persone: chi è cieco e usa uno screen reader, chi ha un tremore e naviga con la tastiera, chi ha una vista ridotta e ingrandisce al 200%, chi legge alla luce del sole, chi ha un braccio temporaneamente rotto. Una buona accessibilità tende a rendere il sito migliore per tutti: struttura più chiara, testo leggibile, moduli che spiegano i loro errori.

Lo standard di riferimento sono le Web Content Accessibility Guidelines (WCAG) del W3C. Ad oggi (settembre 2026), la versione attuale è WCAG 2.2 (pubblicata nell'ottobre 2023, aggiornata nel dicembre 2024); WCAG 3 è una bozza iniziale. WCAG è organizzato intorno a quattro principi — i contenuti devono essere percepibili, utilizzabili, comprensibili e robusti — e ha tre livelli di conformità:

Livello	Cosa significa	Chi lo punta
A	Il minimo; senza di esso alcune persone non possono usare affatto il sito	Tutti
AA	Il traguardo comune; copre contrasto, focus, ridimensionamento, gestione degli errori	La maggior parte delle organizzazioni e molte leggi
AAA	Il più rigoroso; non raggiungibile per tutti i contenuti	Servizi e pubblici specifici

Alcune leggi in diversi paesi fanno riferimento a WCAG — per esempio lo European Accessibility Act, che si applica a molti servizi digitali rivolti ai consumatori nell'UE dal giugno 2025. Quali regole si applicano a te dipende da dove operi e da cosa vendi; se non sei sicuro, chiedi a un consulente. Questa guida copre il lavoro pratico.

Opzioni: come arrivarci

Approccio	Adatto a	Compromesso
Costruirlo fin dall'inizio	Siti e app nuovi	Il minor sforzo complessivo; va deciso in anticipo
Verificare e correggere	Siti esistenti	Trova problemi reali; richiede un passaggio mirato per pagina
Audit professionale	Settori regolamentati, siti grandi, enti pubblici	Approfondito e documentato; ha un costo
Widget sovrapposto	Non consigliato	Non può correggere il codice sottostante

Per la maggior parte dei piccoli siti bastano i primi due: chiedi all'AI di costruire in modo accessibile fin dall'inizio, poi verifica prima del lancio.

Le correzioni più importanti

Usa gli elementi HTML giusti

La maggior parte dell'accessibilità arriva gratis con un HTML corretto. Un <button> è focalizzabile, funziona con Invio e Spazio, e viene annunciato come pulsante. Un <div> con un gestore di clic non ha nessuna di queste caratteristiche. Il codice generato dall'AI a volte usa div stilizzati per tutto; chiedi elementi semantici:

<button> per le azioni, <a href> per la navigazione
Un solo <h1> per pagina, poi <h2>, <h3> in ordine — gli utenti di screen reader saltano tra le intestazioni
Punti di riferimento: <header>, <nav>, <main>, <footer>
Un <label> collegato a ogni campo del modulo
La lingua della pagina in <html lang="it">

Usa gli attributi ARIA solo quando nessun elemento nativo è adatto — per un insieme di schede personalizzato o una combobox, per esempio. Un ARIA sbagliato è peggio di nessun ARIA.

Accesso da tastiera e focus visibile

Tutto ciò che puoi fare con il mouse deve funzionare solo con la tastiera (WCAG 2.1.1). Premi Tab nella pagina: ogni link, pulsante e campo deve essere raggiungibile in un ordine logico, e devi sempre vedere dov'è il focus (2.4.7 Focus visibile). WCAG 2.2 ha aggiunto che l'elemento a fuoco non deve essere completamente nascosto da intestazioni fisse o banner dei cookie (2.4.11, Livello AA).

Errori comuni: menu che si aprono solo al passaggio del mouse, finestre modali che non trattengono il focus o non si chiudono con Esc, e outline: none nel CSS senza nulla che lo sostituisca.

Alternative testuali

Ogni immagine significativa ha bisogno di un testo alternativo che descriva ciò che mostra nel contesto («Lo chef impiatta il menu degustazione», non «immagine1.jpg»). Le immagini decorative ricevono un alt="" vuoto, così gli screen reader le saltano. I pulsanti con solo icona hanno bisogno di un nome accessibile («Chiudi», «Cerca»). I video richiedono sottotitoli; l'audio richiede una trascrizione.

Colore e contrasto

WCAG 2.2 AA richiede un rapporto di contrasto di almeno 4,5:1 per il testo normale e 3:1 per il testo grande (1.4.3), e 3:1 per le parti dell'interfaccia come i bordi dei campi di input e le icone significative (1.4.11). Il testo segnaposto grigio chiaro e i pulsanti pallidi sono i fallimenti più comuni. Inoltre, non usare mai solo il colore per trasmettere un significato — un bordo rosso su un campo non valido richiede anche un messaggio di errore.

Ridimensionamento e reflow

Il testo deve restare utilizzabile quando lo ingrandisci al 200% (1.4.4), e il contenuto deve funzionare su una larghezza di 320 pixel CSS senza scorrimento orizzontale (1.4.10). Un layout responsive gestisce la maggior parte di questo.

Dimensioni dei bersagli, moduli ed errori

Dimensione dei bersagli: WCAG 2.2 AA richiede bersagli puntatore di almeno 24 per 24 pixel CSS, o spazio sufficiente intorno a quelli più piccoli (2.5.8). Più grandi sono, meglio è sui telefoni.
Moduli: etichette visibili (non solo segnaposto), istruzioni chiare e messaggi di errore che dicano cosa non va e come correggerlo, accanto al campo.
Login: non far risolvere enigmi o ricopiare un codice senza un'alternativa; consenti i gestori di password e l'incolla (3.3.8 Autenticazione accessibile).

Prompt che funzionano

Costruisci questo sito in modo che rispetti WCAG 2.2 Livello AA: punti di riferimento semantici HTML, un h1 per pagina con intestazioni in ordine, veri elementi button e link, etichette su ogni campo del modulo, stili di focus visibili, contrasto del testo di almeno 4,5:1, testi alternativi sulle immagini significative e alt="" su quelle decorative, e html lang impostato.

Verifica l'accessibilità delle pagine /signup e /checkout. Controlla l'uso solo da tastiera, l'ordine del focus, il focus visibile, le etichette, i messaggi di errore, il contrasto e i nomi per gli screen reader dei pulsanti con icona. Elenca ogni problema con il criterio WCAG, poi correggili senza cambiare il design visivo più del necessario.

Il menu mobile non si può usare con la tastiera. Trasformalo in un pulsante con aria-expanded, sposta il focus dentro il menu quando si apre, chiudilo con Esc e riporta il focus sul pulsante.

Passo dopo passo

Esegui un controllo automatico. La sezione Accessibilità di Lighthouse negli strumenti per sviluppatori di Chrome, oppure l'estensione del browser axe, sulle pagine principali. Correggi tutto ciò che segnala.
Stacca il mouse. Premi Tab su ogni pagina e completa ogni attività chiave — registrazione, ricerca, checkout. Annota tutto ciò che non raggiungi, su cui non vedi il focus o da cui non riesci a uscire.
Ingrandisci al 200% e restringi la finestra alla larghezza del telefono. Nulla deve essere tagliato o richiedere scorrimento orizzontale.
Prova uno screen reader per dieci minuti: VoiceOver su Mac e iPhone, TalkBack su Android, o NVDA su Windows (gratuito). Ascolta intestazioni, link e campi del modulo. Un «pulsante» senza nome, o un «link, clicca qui», significa lavoro da fare.
Controlla il contrasto di testi, pulsanti e campi con uno strumento di verifica del contrasto.
Correggi, poi ripeti gli stessi compiti.
Pubblica una dichiarazione di accessibilità che indichi quale standard punti e come segnalare i problemi — e rispondi a quelle segnalazioni.

Errori comuni

Affidarsi a un widget sovrapposto invece di correggere il codice.
Rimuovere i contorni di focus perché sembrano disordinati, senza una sostituzione.
Testo segnaposto come unica etichetta. Scompare quando qualcuno inizia a scrivere ed è spesso di contrasto basso.
Link "clicca qui" e "Leggi di più". Fuori dal contesto, gli utenti di screen reader sentono un elenco di link identici.
Testi alternativi farciti di parole chiave. Il testo alternativo serve alle persone; descrivi l'immagine.
Testare una sola volta. Ogni nuova funzione può rompere l'accesso da tastiera. Aggiungi un passaggio con la tastiera al tuo test pre-lancio.

Checklist di accessibilità

Controllo automatico (Lighthouse o axe) senza segnalazioni sulle pagine principali
Ogni compito può essere completato solo con la tastiera
Focus sempre visibile e mai nascosto da elementi fissi
Intestazioni, punti di riferimento, pulsanti e link semantici; lang impostato
Testi alternativi significativi; immagini decorative con alt=""; sottotitoli sui video
Contrasto del testo ≥ 4,5:1 (testo grande ≥ 3:1); parti dell'interfaccia ≥ 3:1
Funziona con zoom al 200% e larghezza di 320 px
Ogni campo del modulo ha un'etichetta visibile e messaggi di errore chiari
Dichiarazione di accessibilità con un modo per segnalare problemi

Per i concetti alla base di tutto questo, leggi cos'è l'accessibilità web. Il design accessibile e il buon design si sovrappongono molto; come progettare un'app dall'aspetto curato con l'AI copre il lato visivo.

Accessibilità su Mythex

Mythex costruisce secondo lo standard che chiedi, quindi inserisci "WCAG 2.2 AA" nel primo prompt e nei successivi. Puoi usare la cornice a dimensione telefono di Preview per controllare i piccoli schermi (Preview e Codice), ma i test di tastiera, zoom e screen reader funzionano meglio sull'URL pubblicato o su un'anteprima aperta in una scheda propria. Chiedi all'agente di verificare una pagina, correggere ciò che trova, poi testa tu stesso le correzioni — una verifica automatica è un inizio, non una conferma definitiva.

Domande

Qual è lo standard di accessibilità attuale per i siti web?

Ad oggi (settembre 2026), lo standard W3C attuale è WCAG 2.2, pubblicato per la prima volta nell'ottobre 2023. La maggior parte delle organizzazioni e molte leggi puntano al Livello AA. WCAG 3 è ancora una bozza iniziale.

Un widget di accessibilità sovrapposto può rendere il mio sito conforme?

Non affidarti a uno solo. I sovrapposti aggiungono una barra degli strumenti sopra la pagina, ma non possono correggere etichette mancanti, accesso da tastiera non funzionante o una struttura debole nel codice sottostante. Rendere accessibile il sito stesso è ciò che lo rende utilizzabile.

I controlli automatici trovano tutti i problemi?

No. Strumenti come Lighthouse e axe individuano cose come testi alternativi mancanti, contrasto basso e campi senza etichetta, ma molti problemi — un ordine di focus confuso, testi dei link privi di senso, testi alternativi presenti ma sbagliati — richiedono una persona che verifichi con la tastiera e uno screen reader.

Quale rapporto di contrasto richiede WCAG?

WCAG 2.2 Livello AA richiede almeno 4,5:1 per il testo normale e 3:1 per il testo grande, e 3:1 per i componenti dell'interfaccia come i bordi dei campi di input e le icone che trasmettono un significato.