L'accessibilità non è una fase finale. È una qualità del prodotto che va progettata dall'inizio e verificata durante lo sviluppo. WCAG 2.2 rafforza criteri importanti su focus, target, drag e autenticazione, ma la maggior parte dei problemi nasce ancora da HTML sbagliato e interazioni non testate da tastiera.
Una checklist non sostituisce una valutazione completa, ma aiuta a non perdere i fondamentali. Per molti siti, sistemare semantica, form, focus e contrasto elimina già una grande parte degli ostacoli.
Aggiornamento luglio 2026
WCAG 2.2 resta la raccomandazione stabile da usare come riferimento per siti e applicazioni web. WCAG 3.0 è ancora una direzione futura, non una base di conformità. Per progetti pubblici, enterprise o europei, l'obiettivo pratico resta almeno WCAG 2.2 AA, con attenzione specifica a focus, target, autenticazione e input.
La best practice 2026 è integrare accessibilità nel design system: token di contrasto verificati, stati focus progettati, componenti testati da tastiera e pattern documentati per modali, menu, tab, accordion, toast e form. Gli audit automatici sono utili, ma non sostituiscono navigazione da tastiera, screen reader sui flussi principali e test su mobile.
Un criterio operativo semplice: ogni componente interattivo deve avere nome accessibile, ruolo corretto, stato percepibile, focus visibile e comportamento coerente con tastiera.
Cosa cambia con WCAG 2.2
WCAG 2.2 aggiunge criteri che rendono più esplicite alcune esigenze pratiche:
- focus non nascosto da header sticky o overlay;
- focus visibile con aspetto riconoscibile;
- alternative ai movimenti di drag;
- target interattivi con dimensioni minime;
- autenticazione senza richiedere solo memoria o puzzle cognitivi;
- riduzione della richiesta di reinserire dati già forniti.
Questi criteri sono utili perché parlano di problemi quotidiani: bottoni troppo piccoli, focus coperto, slider impossibili da usare senza mouse, login complicati.
Semantica prima di tutto
Molti bug di accessibilità iniziano con il tag sbagliato. Se un elemento naviga, usa un link. Se esegue un'azione, usa un button. Evita div cliccabili quando esiste un elemento HTML nativo.
Controlla:
- un solo
h1principale per pagina; - ordine logico degli heading;
- landmark come
header,main,nav,footer; - testi link comprensibili;
- icone con label accessibile;
- immagini decorative con
alt=""; - immagini informative con alt descrittivo.
Il browser offre già molta accessibilità gratis. Il problema nasce quando la si rimuove con markup improprio.
Form accessibili
Ogni campo deve avere una label associata. Placeholder e label non sono equivalenti: il placeholder sparisce durante la compilazione e spesso ha contrasto debole.
Gli errori devono essere chiari, vicini al campo e annunciabili dagli screen reader. Per gruppi di radio e checkbox, usa fieldset e legend. Per dati personali, valuta autocomplete corretto: migliora usabilità e accessibilità.
Un form accessibile non dice solo "errore". Dice cosa è sbagliato e come correggerlo.
Tastiera e focus
Naviga ogni pagina con Tab, Shift+Tab, Invio, Spazio ed Esc. Se non riesci a completare un flusso senza mouse, c'è un problema.
Il focus deve essere visibile, non nascosto e in ordine logico. Attenzione a modali, menu mobile, carousel e componenti custom: sono i punti in cui la tastiera si rompe più spesso, soprattutto quando le microinterazioni sono pensate solo per mouse e hover.
Gli skip link sono semplici e utili, soprattutto su pagine con navigazioni lunghe. Non devono essere decorativi: devono funzionare.
Contrasto e colore
Il contrasto non riguarda solo testo nero su sfondo bianco. Riguarda bottoni, placeholder, bordi input, stati focus, errori e grafici.
Non affidare informazioni solo al colore. Un campo in errore non dovrebbe essere solo rosso: deve avere testo, icona o messaggio. Una dashboard non dovrebbe distinguere stati critici solo con verde e rosso.
Audit automatico e test manuale
Strumenti come axe e Lighthouse trovano molti problemi, ma non tutto. Possono segnalare mancanza di label o contrasto insufficiente. Non possono sempre capire se il testo è chiaro, se l'ordine di focus ha senso o se il flusso è comprensibile.
Un audit minimo, utile anche dentro un progetto di UI/UX design, dovrebbe includere:
- scansione automatica;
- navigazione tastiera;
- test con screen reader almeno sui flussi principali;
- verifica responsive;
- controllo modali e menu;
- test form con errori reali.
Fonte utile
Conclusione
L'accessibilità è buona ingegneria frontend. Migliora usabilità, robustezza e qualità del codice. WCAG 2.2 rende più visibili problemi che gli utenti incontrano ogni giorno: focus, target, input e autenticazione. Partire da HTML corretto resta la scelta più efficace, e rende più robusti anche i test E2E basati su ruoli e label.