Quasi ogni programma di accessibilità che sottoponiamo ad audit riporta lo stesso dato: il novanta e rotti percento dei developer frontend dichiara di «testare con uno screen reader». Si chiede loro di dimostrarlo, e la dimostrazione è di solito la stessa: tre tasti — accendere, fare tab nella pagina, spegnere. Non è testare. È spuntare una casella.

Il motivo per cui accade è strutturale, non pigrizia. Uno screen reader non è uno strumento che si impara come si impara un nuovo linter. È un modello di interazione diverso, con il proprio stato modale, la propria grammatica di scorciatoie e una serie di convenzioni che hanno senso solo dopo averlo usato per diverse ore di lavoro reale. Finché non si supera quella soglia, lo strumento non dice quasi nulla — e, peggio, dice cose sbagliate, perché gli annunci che si sentono dipendono dalla modalità del lettore, dall’albero di accessibilità del browser e dallo strato IME della piattaforma in modi che non sono evidenti dall’esterno.

Per i nostri scopi, la fluidità è il punto in cui si è in grado di prendere in mano la tastiera di un collega, ricevere da lui un componente rotto e riprodurre il bug con lo screen reader attivo — senza guardare lo schermo, senza consultare un foglio di riferimento e senza peggiorare gli annunci rispetto a come sarebbero nell’uso reale. La familiarità è il punto in cui si è sentito uno screen reader. Il divario tra le due è di circa trenta-trentacinque ore di pratica deliberata.

Il mercato dispone di tre screen reader rilevanti per il lavoro web su desktop: NVDA su Windows, VoiceOver su macOS e iOS, e JAWS su Windows. Ognuno ha una base di utenti abbastanza ampia da rendere la sua esclusione una vera scommessa, e ognuno annuncia lo stesso markup in modo leggermente diverso. Un developer fluente sa usarne almeno due.

La raccomandazione, dopo aver osservato decine di developer superare la soglia, è inequivocabile: iniziare con NVDA su Windows e VoiceOver su macOS. Entrambi sono gratuiti. Entrambi sono preinstallati (VoiceOver) o installabili in meno di cinque minuti (NVDA). Entrambi sono usati da un numero sufficiente di utenti reali — NVDA detiene circa il 65% della quota di mercato degli screen reader su Windows nel più recente sondaggio WebAIM, VoiceOver domina il mobile e una quota significativa di macOS — che ciò che si impara si traduce immediatamente in bug per cui si può rilasciare una correzione. JAWS è il terzo strumento, non il primo, anche se rimane lo screen reader con la base di installazione enterprise più ampia. Tre ragioni.

Le tre ragioni per rimandare JAWS sono pedagogiche, non politiche. In primo luogo, JAWS e NVDA condividono un modello mentale — la modalità browse contro la modalità focus su Windows, lo stesso prefisso di comando basato su Insert, lo stesso buffer virtuale — quindi una volta che si sa usare NVDA, il novanta percento dei comandi JAWS di cui si ha davvero bisogno è a portata di un glossario. In secondo luogo, JAWS ha accumulato decenni di inferenza «intelligente»: cerca di correggere il markup difettoso prima che l’utente lo ascolti, il che significa che un bug che JAWS maschera arriverà comunque agli utenti NVDA. Il comportamento deliberatamente conservativo di NVDA lo rende il lettore di riferimento migliore quando si cerca di capire cosa è rotto. In terzo luogo, la frizione della licenza di JAWS — l’attivazione, la modalità di prova di quaranta minuti che sollecita a ogni riavvio — è una tassa sull’apprendimento che non è necessario pagare finché non si è abbastanza sicuri da valerne la spesa.

VoiceOver si abbina a NVDA piuttosto che competere con esso perché i due lettori rappresentano i due modelli di interazione dominanti. NVDA (e JAWS) utilizzano il modello «PC cursor»: un buffer virtuale che presenta la pagina come un documento lineare e un focus separato che segue l’ordine di tabulazione. VoiceOver utilizza un singolo cursore VoiceOver sovrapposto al focus, navigato dal rotor e dai tasti VO+freccia. Un developer fluente in un solo modello scriverà codice che viene annunciato bene nel suo lettore e male nell’altro. Imparare entrambi contemporaneamente è l’unico modo affidabile per percepire la differenza.

Il programma della prima settimana ha una sola regola: spegnere il monitor. Non oscurato, non ridotto a icona, non «chiuderò gli occhi» — fisicamente spento, o coperto con un pezzo di cartone se il display è l’unico nella stanza. Lo scopo è eliminare la possibilità di barare. L’istinto di un developer vedente, nel momento in cui uno screen reader dice qualcosa di confuso, è di dare un’occhiata allo schermo e risolvere visivamente l’ambiguità. Quell’istinto è la singola ragione principale per cui «ho testato con uno screen reader» non intercetta bug reali.

Si prevedano tre sessioni di circa novanta minuti ciascuna nella prima settimana, con almeno un giorno tra una sessione e l’altra affinché la memoria muscolare abbia il tempo di consolidarsi. Ogni sessione ha un compito. La prima costruisce la grammatica di base dei comandi. La seconda impone un’interazione reale. La terza testa la ritenzione sotto una piccola dose di pressione.

Le settimane dalla seconda alla quarta di pratica dovrebbero totalizzare circa venti ore di lavoro — due sessioni di novanta minuti a settimana, più un po’ di utilizzo incidentale durante la giornata lavorativa. L’obiettivo in questo periodo è interiorizzare le due cose che confondono i nuovi utenti degli screen reader più di qualsiasi altra: la distinzione tra modalità browse e modalità focus, e la differenza tra ciò che il rotor vede e ciò che vede l’ordine di tabulazione.

La confusione più comune nella seconda settimana è il momento in cui un developer preme un tasto freccia in NVDA, si aspetta che il buffer virtuale si sposti, e invece sente la combobox in focus aprire il suo elenco di opzioni. È la modalità browse che passa alla modalità focus automaticamente perché il focus è atterrato su un elemento che NVDA classifica come widget di tipo «application». I nuovi developer vivono questo come un malfunzionamento del lettore. Non lo è — è il lettore che fa esattamente ciò che la specifica richiede. Una volta che lo si è sentito dieci o quindici volte si smette di sorprendersi; fino ad allora, ci si aspetti di essere sorpresi circa ogni altra sessione.

Il pattern della terza settimana sono i form. Si costruisce una pagina di test privata con otto o dieci controlli: un input di testo obbligatorio con un errore inline, un date picker, una selezione multipla, una checkbox personalizzata con stile, un pulsante disabilitato che diventa abilitato, un toggle «mostra password», un campo numero di telefono con selettore del prefisso internazionale e un pulsante di invio che attiva un riepilogo di validazione lato server. Monitor spento, si naviga attraverso di esso cinque volte — prima con NVDA in modalità browse, poi NVDA in modalità focus, poi NVDA di nuovo con l’impostazione di annuncio verboso attivata (Insert+Z, più avanti nella sezione cinque), poi VoiceOver con il rotor, poi VoiceOver senza il rotor. Lo stesso form suonerà diverso cinque volte. Questa è la fluidità vissuta dall’interno: rendersi conto che lo stesso markup racconta cinque storie diverse, ed essere in grado di prevedere in anticipo quale andrà in scena.

La quarta settimana è dedicata alla navigazione. Si prende un sito reale e complesso — un portale di documentazione, una dashboard aziendale, una pagina di categoria e-commerce — e si cerca di trovare una specifica informazione usando solo le scorciatoie dello screen reader. Si usa H per saltare alle intestazioni. Si usa D (NVDA) o VO+U poi «Punti di riferimento» (VoiceOver) per saltare i landmark. Si usano da 1 a 6 per saltare a un particolare livello di intestazione. Entro la fine della quarta settimana, le scorciatoie di navigazione dovrebbero essere riflessi condizionati piuttosto che scelte consapevoli, così come già lo sono tab e shift-tab.

Una volta che i comandi in modalità utente sono riflessi automatici, il passo successivo è accedere alle superfici rivolte agli sviluppatori di ciascun lettore. Sono le modalità e le scorciatoie che i manuali nascondono — in parte perché sono pensate per i developer, in parte perché sono abbastanza rumorose da non essere desiderabili per un utente quotidiano. Tre meritano di essere conosciute immediatamente.

Due ulteriori abitudini faranno risparmiare più tempo di qualsiasi singola scorciatoia. Prima: lasciare lo speech viewer di NVDA fisso su un secondo monitor (o in un angolo dell’unico monitor) durante lo sviluppo. Il log verbatim di ogni annuncio è per il lavoro con gli screen reader quello che la console degli strumenti di sviluppo è per JavaScript: la differenza tra indovinare e sapere. Seconda: imparare a leggere l’albero di accessibilità negli strumenti di sviluppo del browser — il pannello Accessibility di Chrome, l’Accessibility Inspector di Firefox, la scheda Audit di Safari. Il lettore annuncia il contenuto dell’albero di accessibilità, non quello del DOM, e i due divergono abbastanza spesso da rendere impossibile il debug di live region, ARIA o shadow DOM senza leggere l’albero direttamente.

Una confusione da segnalare ora, perché consuma ore nelle settimane due e tre: la modalità lettura contro la modalità focus non coincide con l’asse «la pagina è interattiva» contro «la pagina è un documento». NVDA passa in modalità focus automaticamente quando il focus atterra su un controllo con role=“application”, su un contenteditable, o su certi widget personalizzati che il lettore classifica euristicamente come interattivi — indipendentemente dal fatto che la pagina sia principalmente statica. Al contrario, un’applicazione a pagina singola ricca di interattività il cui elemento radice è un landmark main e i cui widget sono pulsanti nativi ben marcati rimarrà in modalità browse per quasi tutta la sessione di un utente. La modalità è una proprietà dell’elemento in focus, non una proprietà della pagina.

I numeri seguenti provengono da un monitoraggio informale di circa ottanta developer — ingegneri frontend, responsabili QA, specialisti di accessibilità in formazione — nell’arco di tre anni di workshop aziendali e tutoraggio individuale. Non sono uno studio di ricerca. Sono sufficientemente affidabili per pianificare. Due premesse: pratica deliberata (monitor spento, compiti reali, non «ho lasciato NVDA in esecuzione in background mentre programmavo»), e un abbinamento fisso di lettori (NVDA su Windows e VoiceOver su macOS).

La «semi-fluidità» è la destinazione realistica per la maggior parte dei developer vedenti ed è, in termini pratici, tutto ciò che occorre per contribuire in modo efficace a un prodotto accessibile. La vera fluidità — il livello a cui si potrebbe plausibilmente sostituire un utente quotidiano di screen reader durante una revisione di usabilità — corrisponde a circa centocinquanta ore e un anno di pratica incidentale, e la maggior parte dei developer in attività non ne ha bisogno. L’obiettivo è la semi-fluidità: si programmano le quaranta ore e si accetta che tutto ciò che va oltre arriva dal fare il lavoro quotidiano con un lettore attivo e dalla disponibilità a rallentare.

Un ultimo benchmark per impostare le aspettative onestamente: i developer che si bloccano, secondo la nostra esperienza, si bloccano tra le dieci e le venti ore. La causa è quasi sempre la stessa — smettono di spegnere il monitor. Si convincono di essere ormai «abbastanza bravi» da testare con il monitor acceso, lo screen reader in esecuzione in background e la conferma visiva disponibile ogni volta che l’audio è ambiguo. Non lo sono. Le sedici ore tra «utile» e «a proprio agio» richiedono il monitor spento perché è in quel tratto che gli annunci del lettore diventano informazioni anziché rumore. Senza quella pressione, il cervello torna alla vista e la voce del lettore sfuma in sottofondo. Se ci si accorge di rallentare, la causa è quasi sempre il monitor.

Il motivo per cui «testare con uno screen reader» produce risultati così deboli nel settore non è che lo strumento sia difficile da imparare — quaranta ore non sono davvero molte — ma che l’apprendimento è scomodo in un modo specifico. Spegnere il monitor fa sentire un developer vedente inetto in un modo insolito nella nostra professione. Siamo abituati a essere quelli che risolvono i problemi; lo screen reader ci rende, per qualche ora di fila, nuovamente principianti. Questo disagio, e non le scorciatoie, è il vero ostacolo.

Il percorso per superarlo è quello descritto sopra: NVDA e VoiceOver, tre sessioni nella prima settimana con il monitor spento, form e modalità nelle settimane da due a quattro, scorciatoie in modalità developer non appena quelle in modalità utente sono riflessi automatici, quaranta ore in totale prima di poter essere incaricati di una seria verifica pre-rilascio. Nulla di tutto ciò è inedito. Il lavoro che il settore non ha fatto è trattarlo come lavoro — pianificare le ore, difenderle da altri impegni, accettare che le prime dieci di quelle ore sembreranno inutili finché all’improvviso non lo saranno più.

Se si sviluppa un frontend, la versione di sé che si trova dall’altra parte di quelle quaranta ore è un ingegnere sostanzialmente migliore di quello che ha iniziato, in modi che si manifesteranno non solo nel lavoro sull’accessibilità ma nella comprensione dell’ordine di focus, del miglioramento progressivo, di ciò che il browser fa davvero sotto il cofano. Lo screen reader è la lezione di sistemi distribuiti più economica disponibile a chiunque scriva per il web. Il prezzo è il monitor spento e qualche weekend.