WCAG 2.2 per designer: focus, target e autenticazione accessibile
WCAG 2.2 riguarda il lavoro del designer prima ancora che inizi lo sviluppo. Focus da tastiera, dimensione dei target, alternative al trascinamento e autenticazione accessibile dipendono da stati, spazi, componenti e percorsi che devono essere previsti nel progetto grafico.
La versione 2.2 estende le precedenti WCAG e il W3C ne raccomanda l’adozione come obiettivo di conformità. Per un team di design, il passo utile non è trasformare ogni criterio in una nota tecnica: è incorporare requisiti verificabili nel design system, nei prototipi e nelle revisioni.
WCAG 2.2: progettare il focus, non aggiungerlo dopo
Chi usa la tastiera deve sapere quale elemento riceverà l’azione successiva. Il focus visibile non può essere un dettaglio lasciato allo stile predefinito del browser senza verificarne contrasto, forma e coerenza.
Il criterio 2.4.11, Focus Not Obscured (Minimum), richiede al livello AA che il componente con focus non sia completamente nascosto da contenuti creati dall’autore. Header fissi, banner cookie, chat e pannelli sticky possono coprire il punto di interazione durante la navigazione.
Nel file di design conviene mostrare almeno:
- stato predefinito, hover e focus;
- ordine di navigazione nei flussi principali;
- comportamento con header, modali e componenti fissi;
- ritorno del focus quando un dialogo viene chiuso.
Target da 24 CSS pixel: misura e spaziatura
Il criterio 2.5.8, Target Size (Minimum), stabilisce al livello AA un riferimento di 24 × 24 CSS pixel, con eccezioni definite anche in base alla spaziatura e alla presenza di un controllo equivalente. Non significa che ogni icona debba apparire grande 24 pixel: conta l’area attivabile.
Per il designer la soluzione più robusta è spesso aumentare padding e distanza tra controlli. Icone di chiusura, frecce di carosello, menu compatti e azioni nelle tabelle meritano un controllo specifico. Su mobile va testata la densità reale, non soltanto la tavola del mockup.
Trascinamento con un’alternativa semplice
WCAG 2.2 richiede che una funzione basata sul trascinamento possa essere eseguita anche con un singolo puntatore senza trascinare, salvo i casi in cui il movimento sia essenziale o dipenda dall’user agent. Il motivo è concreto: il drag richiede precisione e può essere difficile con tremori, trackball, puntatori adattati o controllo oculare.
Un ordinamento drag-and-drop può quindi offrire pulsanti “sposta su” e “sposta giù”; uno slider può accettare un tap sulla traccia o un valore numerico; una mappa di configurazione può prevedere una selezione seguita dal comando di destinazione. L’alternativa deve realizzare la stessa funzione, non essere una spiegazione testuale.
Autenticazione accessibile e memoria
Il criterio 3.3.8, Accessible Authentication (Minimum), limita l’obbligo di superare test di funzione cognitiva, come ricordare una password o risolvere un puzzle, quando non è disponibile un’alternativa o un meccanismo di supporto. Password manager, copia e incolla e autenticazione basata su dispositivi possono ridurre la barriera.
Nel progetto del login occorre evitare di bloccare il paste, rendere chiaro il recupero dell’account, mantenere etichette persistenti e spiegare gli errori senza affidarsi al solo colore. Se viene usato un CAPTCHA, bisogna valutare alternative coerenti con il percorso.
Checklist WCAG 2.2 per il file di design
| Area | Domanda di revisione |
|---|---|
| Focus | Ogni componente interattivo ha uno stato visibile e non coperto? |
| Target | L’area attivabile e la spaziatura riducono tocchi involontari? |
| Drag | La stessa azione è disponibile con click o tap senza trascinamento? |
| Login | Il flusso supporta password manager, paste e recupero? |
| Errori | Messaggio, posizione e correzione sono espliciti? |
| Responsive | Zoom, reflow e componenti fissi sono stati prototipati? |
Questi controlli possono diventare proprietà o varianti dei componenti. Un pulsante, per esempio, non è completo se il design system mostra solo stato normale e hover.
Dal prototipo alla verifica
Un prototipo visuale non dimostra da solo la conformità: ordine del focus, semantica, tecnologie assistive e comportamento reale richiedono sviluppo e test. Il designer deve però consegnare intenzioni non ambigue e partecipare alla verifica, soprattutto nei flussi ad alta densità.
La stessa disciplina migliora anche la gerarchia visiva delle dashboard: target più chiari, focus riconoscibile e messaggi persistenti riducono errori per un pubblico più ampio.
La revisione dovrebbe combinare test automatici, navigazione da tastiera, zoom, dispositivi mobili e prove con utenti. Le WCAG forniscono criteri testabili, ma non coprono ogni possibile esigenza.
Fonti e riferimenti
- W3C, Web Content Accessibility Guidelines 2.2
- W3C, Understanding Focus Not Obscured
- W3C, Understanding Target Size (Minimum)
- W3C, Understanding Dragging Movements
Il design system descrive davvero gli stati accessibili dei componenti?
Possiamo integrare WCAG 2.2, UX e verifica nel processo di design.