Quando un componente dell’interfaccia utente riceve il focus da tastiera, l’indicatore di focus deve soddisfare un rapporto di contrasto cromatico minimo di 3:1 rispetto ai colori adiacenti e coprire almeno il perimetro di un contorno solido di 2 pixel CSS attorno all’elemento focalizzato, o un’area equivalente dell’indicatore. Il criterio è una delle poche aggiunte WCAG che specifica una geometria misurabile piuttosto che un comportamento.

I focus ring predefiniti del browser che i designer hanno trascorso quindici anni a sovrascrivere per ragioni estetiche non soddisfano questa misura sulla maggioranza dei siti in produzione sottoposti ad audit. Gli stili di focus personalizzati tendono a usare contorni da 1 px o colori d’accento a basso contrasto che sembrano corretti negli strumenti di design ma ottengono un punteggio inferiore a 3:1 rispetto allo sfondo dell’elemento effettivamente focalizzato.

La cifra conta anche se il criterio è AAA: indica cosa accadrebbe se un futuro regolatore bloccasse WCAG 2.2 al livello AAA, o se un contratto di appalto elevasse questo singolo criterio.

Impostare un contorno di 2 pixel CSS a un colore che ottenga almeno 3:1 rispetto allo sfondo dell’elemento; verificare con uno strumento di controllo del contrasto piuttosto che a occhio. Dove il design system sovrascrive il focus del browser, esporre un token per lo stile di focus che i designer non possano abbassare accidentalmente sotto la soglia di contrasto.

Il target di puntamento di ogni input a puntatore deve essere di almeno 24 per 24 pixel CSS, tranne quando il target è inline in una frase, quando è dimensionato dall’agente utente, quando è disponibile un target equivalente, o quando la funzione del target è essenziale. Il criterio misura il target di tocco, non l’icona visibile.

Il criterio rileva un pattern UI specifico: barre degli strumenti con icone dense, in particolare in editor, dashboard e intestazioni di tabelle dati. La maggior parte delle librerie di pulsanti con icone predefinisce dimensioni dell’icona visiva da 16x16 o 20x20 pixel all’interno di un target leggermente più grande. Quando anche il target è inferiore a 24x24, il criterio fallisce — e i designer di barre degli strumenti comprimono regolarmente gli spazi per inserire più icone nello spazio orizzontale limitato.

Impostare un token di target minimo di 24 per 24 pixel CSS nel design system, applicato tramite padding piuttosto che le dimensioni dell’icona stessa. Dove le barre degli strumenti non riescono ad accomodare il limite, aggiungere spaziatura adeguata in modo che i target adiacenti non rientrino nell’esclusione di sovrapposizione del criterio. Fornire un equivalente a livello di impostazioni (un menu più ampio) per le superfici realmente limitate.

Il passaggio di autenticazione di un sito web o di un’app non può basarsi su un test di funzione cognitiva — risolvere un puzzle, trascrivere un’immagine distorta, riconoscere oggetti in una griglia — a meno che non sia fornito un metodo di autenticazione alternativo, sia disponibile un meccanismo assistivo o si applichi un’eccezione per il riconoscimento di oggetti. Memorizzare una password conta come test di funzione cognitiva, ecco perché i gestori di password sono esplicitamente accomodati.

La maggior parte dei CAPTCHA basati su immagini fallisce questo criterio palesemente. Lo stesso vale per le sfide «clicca i riquadri con i semafori», i test di trascrizione di testi distorte, e qualsiasi flusso che incolla un codice monouso in un campo ma disabilita l’interazione di incolla. Il pattern si concentra nei flussi di accesso, reimpostazione della password e creazione dell’account — esattamente i punti critici in cui essere bloccati fuori ha il costo più elevato.

I flussi di autenticazione sono anche l’area in cui l’effetto coercitivo del criterio è più netto, perché il fallimento non degrada l’esperienza — la termina.

Sostituire i CAPTCHA cognitivi con un’alternativa non cognitiva — attestazione basata su dispositivo, magic link, passkey o punteggio di rischio invisibile. Consentire il riempimento automatico dei gestori di password. Assicurarsi che il copia-incolla funzioni nei campi con codice monouso. Dove un CAPTCHA deve rimanere, fornire un’alternativa audio che non richieda essa stessa la trascrizione di un parlato distorto.

Quando un componente dell’interfaccia utente riceve il focus da tastiera, l’elemento focalizzato non deve essere completamente nascosto da contenuto creato dall’autore. L’occlusione parziale è consentita a questo livello (un’intestazione fissa che si sovrappone alla metà superiore di un campo focalizzato è ammessa); l’occlusione totale non lo è.

La collisione più comune è un’intestazione fissa — a volte un banner cookie o un widget di chat flottante — che si sovrappone al campo del modulo focalizzato quando un utente da tastiera vi fa tab. I siti in produzione che hanno aggiunto un’intestazione fissa a un modulo esistente durante il periodo di riprogettazione 2020–22 hanno regolarmente mancato il comportamento di focus-e-scorrimento perché il modulo originale era stato creato prima che gli elementi fissi esistessero.

Impostare scroll-margin-top (o scroll-padding-top sul contenitore di scorrimento) uguale all’altezza di qualsiasi overlay fisso. Verificare che la tabulazione attraverso un lungo modulo faccia scorrere l’elemento focalizzato completamente in vista sotto qualsiasi intestazione. Abbinare con stili focus-visible in modo che l’utente possa vedere dove si trova effettivamente il focus.

La funzionalità che utilizza un movimento di trascinamento deve essere anche operabile tramite un’azione a puntatore singolo — un tap, un clic o un equivalente che non richieda un movimento del puntatore sostenuto. Le interazioni drag-and-drop non sono vietate; semplicemente non possono essere l’unico percorso disponibile per la funzione.

Le UI di riordino delle liste e in stile kanban distribuiscono frequentemente un riordino solo tramite trascinamento. Lo stesso vale per i controlli slider implementati come cursori trascinabili senza un corrispondente spinbutton o input di testo, e per le UI di ritaglio delle immagini che richiedono un trascinamento per impostare i limiti. Il criterio li rileva ogni volta.

Per ogni interazione di trascinamento, distribuire un’alternativa equivalente tramite tap/clic — pulsanti «sposta su» e «sposta giù» accanto agli elementi di lista trascinabili, un input numerico accanto a uno slider, una modalità clic-per-impostare-i-limiti nel ritaglio. Dove l’alternativa è nascosta in un menu contestuale, assicurarsi che sia raggiungibile tramite tastiera.

All’interno dello stesso processo autenticato, non richiedere all’utente di inserire le stesse informazioni due volte — a meno che la reinserzione sia essenziale, che il valore precedente non sia più valido, o che le informazioni riguardino la sicurezza (un’eccezione canonica è la riscrittura della password durante la creazione dell’account). La precompilazione automatica o la selezione dai valori precedentemente inseriti soddisfano entrambe il criterio.

I flussi di checkout multi-step, i moduli di domanda multi-pagina e le domande di visto/permesso richiedono regolarmente gli stessi dati di indirizzo, nome o informazioni di contatto in due passaggi separati perché i passaggi sono stati costruiti da team diversi e mai riconciliati. I valori inseriti in precedenza dall’utente non sono mantenuti in una sessione condivisa tra i passaggi.

Mantenere i valori inseriti dall’utente tra i passaggi di un singolo processo; precompilare i campi corrispondenti nei passaggi successivi; o esporre un controllo «usa lo stesso indirizzo» con un clic. Il pattern di solito emerge durante la mappatura del processo piuttosto che durante l’audit front-end, quindi una revisione del flusso trasversale ai team è il passo pratico di rimedio.

Se viene fornito un meccanismo di aiuto — un link di contatto, un link all’assistenza, un widget di chat, un numero di telefono dell’assistenza, un link di auto-aiuto — deve apparire nella stessa posizione relativa nelle pagine in cui è fornito. Il criterio non richiede che l’aiuto sia presente; solo che, dove è presente, il suo posizionamento sia coerente.

Il criterio è semplice in linea di principio e rileva un insieme ristretto di siti che hanno un link «Contattaci» nell’intestazione in alcune pagine, nel footer in altre, e all’interno di un widget di chat flottante in un terzo gruppo di pagine — frequentemente il risultato di più sezioni del sito di proprietà di team diversi con template separati.

Verificare il posizionamento dei meccanismi di aiuto su tutti i template; scegliere un’unica posizione canonica (intestazione, footer persistente o widget flottante) e riconciliare le eccezioni. La correzione è raramente tecnica; è un passo di governance dei contenuti e dei template.

Il cugino AAA di 2.4.11: quando un componente dell’interfaccia utente riceve il focus da tastiera, l’elemento focalizzato non deve essere oscurato da contenuto creato dall’autore per nulla. L’occlusione parziale è vietata a questo livello — un’intestazione fissa che copre qualsiasi parte del campo focalizzato fallisce.

Le stesse collisioni con overlay fissi che causano i fallimenti di 2.4.11 persistono a 2.4.12. I siti che hanno adottato scroll-margin-top per soddisfare il criterio minimo tendono ancora a lasciare pochi pixel CSS di sovrapposizione su altezze di viewport limite. Al livello AAA, quella sovrapposizione è il fallimento.

Impostare scroll-margin-top in modo da superare confortevolmente l’altezza di ogni overlay creato dall’autore, inclusi quelli dinamici (banner cookie che compaiono alla prima visita, widget di chat che si espandono al passaggio del mouse). Aggiungere test di regressione espliciti per il comportamento di tab-nel-modulo alle dimensioni comuni di viewport.

Il cugino AAA di 3.3.8: l’autenticazione non può basarsi su un test di funzione cognitiva, punto. Le eccezioni per il riconoscimento di oggetti e contenuti personali che si applicano al livello AA non si applicano qui. I test di memoria, i test di trascrizione e le sfide di riconoscimento delle immagini falliscono tutti a questo livello.

Anche i siti che hanno sostituito i CAPTCHA tradizionali con sfide di riconoscimento degli oggetti (l’eccezione AA) falliscono 3.3.9. Il criterio è il segnale del gruppo di lavoro su dove dovrebbe andare l’autenticazione: lontano dalle sfide cognitive del tutto, verso l’attestazione del dispositivo o la verifica biometrica.

Adottare le passkey (WebAuthn) come meccanismo di autenticazione principale; trattare la combinazione password più passkey come uno stato di transizione piuttosto che una destinazione. Dove il riconoscimento delle immagini è stato mantenuto per la valutazione del rischio, eseguirlo lato server da segnali comportamentali piuttosto che come sfida rivolta all’utente.