Il report di audit dice che il 2.1.1 fallisce su ogni elemento. Come capire se è vero.

Qualcuno ti manda un audit di accessibilità. Sotto 2.1.1 Tastiera, ogni elemento della pagina porta lo stesso verdetto: nessuna alternativa all'uso del solo mouse. Tu stacchi il mouse, attraversi la pagina con il Tab e funziona tutto — il focus si sposta, l'anello si vede, Invio attiva quello che deve.

Uno dei due sbaglia. Capire quale non è una questione di opinioni, e la risposta è più interessante di «il fornitore gonfia il report».

Primo: il 2.1.1 non significa quello che il report probabilmente dà per scontato

Il criterio dice:

Tutte le funzionalità del contenuto sono utilizzabili tramite un'interfaccia da tastiera senza che siano richieste tempistiche specifiche per i singoli tasti, tranne quando la funzionalità sottostante richiede un input che dipende dal percorso del movimento dell'utente e non solo dai punti iniziale e finale.

Livello A. Nota cosa manca: qualsiasi menzione di un tasto specifico.

Il documento Understanding è esplicito:

i pulsanti che hanno il focus possono generalmente essere attivati sia con Invio sia con la barra spaziatrice. Se un controllo pulsante personalizzato in un'applicazione web reagisce invece solo a Invio (o perfino a un tasto o a una combinazione completamente personalizzati), questo soddisfa comunque i requisiti di questo criterio di successo.

Quindi «Invio non ha fatto niente, dunque 2.1.1» non è un rilievo. E nemmeno «questo controllo vuole un tasto che non ho indovinato». La domanda che pone il 2.1.1 è se la funzione si possa eseguire da tastiera, non se si possa eseguire nel modo che ti aspettavi.

Vale in entrambe le direzioni. Elimina una classe di falsi positivi, ma significa anche che un controllo può superare il 2.1.1 pur essendo di fatto inutilizzabile, perché nessuno indovina il tasto. È un problema vero, ma appartiene ad altri criteri e alla semplice usabilità, non a questo.

Secondo: tre cose che finiscono sotto 2.1.1 e sono criteri diversi

Conta, perché se il report mette tutto sotto un numero solo, quello è già un segnale su come è stato prodotto.

Restare intrappolati è 2.1.2 Nessun impedimento all'uso della tastiera (A). Entri con il Tab e non riesci a uscire. Criterio diverso.

Vedere dove sei è 2.4.7 Focus visibile (AA). Quell'anello spesso che hai osservato è prova per il 2.4.7. Non è prova né a favore né contro il 2.1.1 — una pagina può avere un indicatore di focus perfetto su ogni controllo e fallire comunque il 2.1.1, e può superare il 2.1.1 senza alcun focus visibile.

Il focus nascosto dietro un'intestazione fissa è 2.4.11 Focus non oscurato (minimo) (AA), nuovo nelle WCAG 2.2. Nemmeno questo è 2.1.1.

Se il tuo test è consistito in «ho premuto Tab, vedevo il focus e Invio funzionava», hai raccolto buone prove sul 2.4.7 e prove solo parziali sul 2.1.1.

Che aspetto ha un rilievo 2.1.1 vero

Un fallimento di questo criterio deve nominare una funzione che non si può eseguire. Non un elemento che esiste. Quindi un rilievo utilizzabile contiene:

• l'elemento, e cosa stavi cercando di farci
• i passi per riprodurre
• risultato atteso contro risultato ottenuto
• browser, sistema operativo, e quale tecnologia assistiva a quale versione

Non è un'asticella alta. È quello che il tester ha annotato mentre provava, perché è servito a lui per sapere che falliva. Qualsiasi audit che valga i suoi soldi ce l'ha già.

Se ogni elemento porta un verdetto identico, quello non è un risultato: è un modello. Una lista di controllo compilata una volta e ricopiata lungo la colonna ha esattamente questo aspetto. E anche un report in cui «non testato» è stato esportato come «fallito».

Torna da loro e chiedi i passi di riproduzione per due o tre voci segnalate. È una richiesta di fatto, che possono soddisfare oppure no, e chiude la discussione senza che nessuno debba dibattere sulla formulazione di un criterio.

Ma non concludere che il tuo test abbia assolto la pagina

Qui chi ha ragione sul report finisce spesso per avere torto sul proprio sito.

Staccare il mouse e premere Tab è un test vero, e non vede la maggior parte dei fallimenti che negli audit saltano fuori davvero:

• Contenuto che compare solo al passaggio del puntatore. Il tuo puntatore non c'è più, quindi non lo vedi mai, e nemmeno chi usa la tastiera. (Collegato: 1.4.13 Contenuto al passaggio del mouse o al focus, AA.)
• Tutto ciò che richiede un trascinamento. Cursori, elenchi riordinabili, spostamento delle mappe. Le WCAG 2.2 hanno aggiunto 2.5.7 Movimenti di trascinamento (AA) proprio perché continuava a succedere.
• Widget compositi in cui il Tab raggiunge il componente ma le frecce dentro non sono mai state collegate. Una listbox o un set di schede personalizzati in cui entri e non navighi.
• Finestre modali che si aprono benissimo e non si chiudono senza puntatore. È 2.1.2, ed è il difetto grave da tastiera più comune che mi capita di vedere.
• Tutto ciò che sta sotto un impedimento all'uso della tastiera, che non raggiungerai mai, e la cui assenza dai tuoi appunti sembra un successo.

Il motivo per cui potete aver ragione entrambi

Ecco la spiegazione che di solito si applica, e che quasi nessuno verifica: la sola tastiera e la tastiera con uno screen reader acceso sono due test diversi.

NVDA e JAWS in modalità browse intercettano i tasti prima che arrivino alla pagina. Un elemento raggiungibile con il Tab a screen reader spento può essere irraggiungibile in modalità browse, e occasionalmente il contrario. Un tester che usa NVDA e uno sviluppatore che non usa niente osservano davvero comportamenti diversi sulla stessa pagina.

Quindi se il fornitore ha provato con la tecnologia assistiva accesa e tu con quella spenta, nessuno dei due sta mentendo e nessuno dei due ha il quadro completo. È anche il motivo per cui la riga sull'ambiente in un rilievo non è burocrazia: senza, il rilievo non si può né riprodurre né smentire.

Cosa fare, in ordine

1. Chiedi i passi di riproduzione per due o tre voci segnalate.
2. Prova proprio quelle con NVDA acceso, in modalità browse, su Windows. Firefox o Chrome, quello che hanno indicato loro.
3. Se si riproducono, hai imparato qualcosa di vero sul tuo sito.
4. Se non si riproducono e il fornitore non sa produrre i passi, hai motivo per respingere la colonna — e per chiedere cos'altro nel report sia stato generato allo stesso modo.

Uno scanner automatico, il mio compreso, non te lo risolve. L'operabilità da tastiera non è rilevabile in modo affidabile da una macchina: uno strumento può segnalare un tabindex positivo, un elemento nascosto alle tecnologie assistive ma ancora focalizzabile, o un controllo senza nome accessibile, e sono cose che vale la pena avere. Se una persona riesca davvero a completare il tuo checkout senza mouse resta una domanda che richiede una persona.

La riserva

Sto descrivendo come valutare un report, non ti sto dicendo che il tuo sito passa. Se l'audit ha ragione, il fatto che sia scritto male non lo rende sbagliato: lo rende scritto male. Chiedi i passi, e poi prendi sul serio quello che torna indietro.

Fonti: Understanding SC 2.1.1 Keyboard · WebAIM: Keyboard Accessibility