Ho usato il Web per un giorno usando uno screen reader

Questo articolo fa parte di una serie in cui tento di utilizzare il Web con vari vincoli, rappresentando un determinato gruppo demografico di utenti. Spero di elevare il profilo delle difficoltà incontrate dalle persone reali, che sono evitabili se progettiamo e sviluppiamo in un modo che sia comprensivo ai loro bisogni. L'ultima volta, ho navigato sul Web per un giorno solo con la mia tastiera. Questa volta, sto evitando lo schermo e sto usando il Web con uno screen reader.

Che cos'è un lettore di schermo?

Uno screen reader è un'applicazione software che interpreta le cose sullo schermo (testo, immagini, collegamenti e così via) e le converte in un formato che le persone ipovedenti possono utilizzare e interagire con. Due terzi degli utenti di screen reader scelgono la voce come output dello screen reader e un terzo degli utenti di screen reader sceglie il braille.

Le utilità per la lettura dello schermo possono essere utilizzate con programmi come elaboratori di testi, client di posta elettronica e browser Web. Funzionano mappando i contenuti e l'interfaccia dell'applicazione su un albero di accessibilità che può quindi essere letto dallo screen reader. Alcuni screen reader devono mappare manualmente programmi specifici all'albero, mentre altri sono più generici e dovrebbero funzionare con la maggior parte dei programmi.

Su Windows, lo screen reader più popolare è JAWS, con quasi la metà del mercato complessivo degli screen reader. È un software commerciale, che costa circa mille dollari per l'edizione domestica. Un'alternativa open source per Windows è NVDA, che viene utilizzata da poco meno di un terzo di tutti gli utenti di screen reader sul desktop.

Esistono altre alternative, tra cui Microsoft Narrator , System Access , Window-Eyes e ZoomText (non un lettore a schermo intero, ma una lente di ingrandimento dello schermo con capacità di lettura); la somma combinata di questi equivale a circa il 6% dell'utilizzo dello screen reader. Su Linux, Orca è fornito in bundle per impostazione predefinita su un certo numero di distribuzioni.

Lo screen reader incluso in macOS, iOS e tvOS è VoiceOver . VoiceOver rappresenta l'11,7% degli utenti di screen reader desktop e sale al 69% degli utenti di screen reader sui dispositivi mobili. Gli altri principali lettori di schermo nello spazio mobile sono Talkback su Android (29,5%) e Voice Assistant su Samsung (5,2%), a sua volta basato su Talkback, ma con gesti aggiuntivi.

Ho un MacBook e un iPhone, quindi userò VoiceOver e Safari per questo articolo. Safari è il browser consigliato da utilizzare con VoiceOver, poiché entrambi sono gestiti da Apple e dovrebbero funzionare bene insieme. L'utilizzo di VoiceOver con un browser diverso può portare a comportamenti imprevisti.

Come abilitare e utilizzare lo screen reader

Le mie istruzioni sono per VoiceOver, ma dovrebbero esserci comandi equivalenti per il tuo screen reader preferito.

Voce fuori campo sul desktop

Se non hai mai usato uno screen reader prima, può essere un'esperienza scoraggiante. È un grande shock culturale andare a un'esperienza solo uditiva e non sapere come controllare l'assalto del rumore è snervante. Per questo motivo, la prima cosa che vorrai imparare è come disattivarlo.

La scorciatoia per disattivare VoiceOver è la stessa della scorciatoia per attivarlo: ⌘ + F5 ( ⌘ è anche noto come tasto Cmd ). Sui Mac più recenti con touch bar, la scorciatoia è tenere premuto il tasto comando e premere tre volte il pulsante Touch ID. VoiceOver parla troppo velocemente? Apri Utility VoiceOver, premi la scheda "Voce" e regola la velocità di conseguenza.

Una volta che hai imparato ad accenderlo e spegnerlo, dovrai imparare a usare il "tasto VoiceOver" (che in realtà è due tasti premuti contemporaneamente): Ctrl e ⌥ (quest'ultimo tasto è anche noto come "Opzione ” o il tasto Alt ). Usando il tasto VO in combinazione con altri tasti, puoi navigare sul web.

Ad esempio, puoi usare VO + A per leggere la pagina web dalla posizione corrente; in pratica, questo significa tenere premuto Ctrl + ⌥ + A . Ricordare a cosa corrisponde VO all'inizio è fonte di confusione, ma la notazione VO è per brevità e coerenza. È possibile configurare la chiave VO in modo che sia qualcos'altro, quindi ha senso avere una notazione standard che tutti possono seguire.

Puoi usare VO e i tasti freccia ( VO + → e VO + ← ) per scorrere ogni elemento nel DOM in sequenza. Quando ti imbatti in un collegamento, puoi utilizzare VO + Spazio per fare clic su di esso: utilizzerai questi tasti anche per interagire con gli elementi del modulo.

Huzzah! Ora sai abbastanza su VoiceOver per navigare sul Web.

Voce fuori campo sul cellulare

La scorciatoia da cellulare/tablet per attivare VoiceOver varia in base al dispositivo, ma generalmente è un "triplo clic" del pulsante Home (dopo aver abilitato la scorciatoia nelle impostazioni).

Puoi leggere tutto dalla posizione corrente con un comando Two-Finger Swipe Down e puoi selezionare ogni elemento nel DOM in sequenza con Swipe Right or Left .

Ora sai tanto su iOS VoiceOver quanto sul desktop!

Navigazione per tipo di contenuto

Pensa a come usi il web come utente vedente. Leggi attentamente ogni parola, in sequenza, dall'alto verso il basso? No. Gli esseri umani sono pigri in base alla progettazione e hanno imparato a "scansionare" le pagine alla ricerca di informazioni interessanti il ​​più velocemente possibile.

Gli utenti di screen reader hanno la stessa esigenza di efficienza, quindi la maggior parte navigherà la pagina in base al tipo di contenuto, ad esempio intestazioni, collegamenti o controlli dei moduli. Un modo per farlo è aprire il menu delle scorciatoie con VO + U , passare al tipo di contenuto desiderato con i tasti freccia ← e → , quindi navigare tra quegli elementi con i tasti ↑↓ .

Un altro modo per farlo è abilitare 'Quick Nav' (tenendo premuto ← insieme a → contemporaneamente). Con Quick Nav abilitato, puoi selezionare il tipo di contenuto tenendo la freccia ↑ accanto a ← o → . Su iOS, lo fai con un gesto Two-Finger Rotate .

Dopo aver selezionato il tipo di contenuto, puoi saltare ogni elemento del rotore con i tasti ↑↓ (o Swipe Up or Down su iOS). Se ti sembra molto da ricordare, vale la pena aggiungere questo utilissimo cheatsheet di VoiceOver ai segnalibri come riferimento.

Un terzo modo per navigare tra i tipi di contenuto consiste nell'usare i gesti del trackpad. Questo avvicina l'esperienza a come potresti usare VoiceOver su iOS su un iPad/iPhone, il che significa dover ricordare solo un set di comandi per lo screen reader!

Puoi esercitarti con la navigazione basata sui gesti e molte altre tecniche di VoiceOver nel programma di formazione integrato su OSX. Puoi accedervi tramite Preferenze di Sistema → Accessibilità → VoiceOver → Apri Formazione VoiceOver.

Dopo aver completato il tutorial, non vedevo l'ora di andare!

Caso di studio 1: YouTube

Ricerca su YouTube

Sono passato alla home page di YouTube nella barra degli strumenti di Safari, su cui VoiceOver mi ha detto di "entrare" nel contenuto web con Ctrl + ⌥ + Maiusc + ↓ . Mi abituerò presto a entrare nei contenuti Web, poiché lo stesso meccanismo si applica ai contenuti incorporati e ad alcuni controlli dei moduli.

Utilizzando Quick Nav, sono stato in grado di navigare tramite i controlli del modulo per saltare facilmente alla sezione di ricerca nella parte superiore della pagina.

Ho cercato alcuni contenuti di qualità:

E sono andato al pulsante di ricerca:

Tuttavia, quando ho attivato il pulsante con VO + Spazio , non è stato annunciato nulla.

Ho aperto gli occhi e la ricerca era avvenuta e la pagina si era popolata di risultati, ma non avevo modo di saperlo solo attraverso l'audio.

Perplesso, ho riprodotto le mie azioni con devtools aperto e ho tenuto d'occhio la scheda di rete.

Come sospettato, YouTube utilizza una tecnica di performance chiamata "rendering lato client", il che significa che JavaScript intercetta l'invio del modulo e visualizza i risultati della ricerca sul posto, per evitare di dover ridisegnare l'intera pagina. Se i risultati della ricerca fossero stati caricati in una nuova pagina come un normale collegamento, VoiceOver mi avrebbe annunciato la nuova pagina in cui navigare.

Ci sono interi articoli dedicati all'accessibilità per le applicazioni renderizzate dal client; in questo caso, consiglierei a YouTube di implementare una regione aria-live che annuncerebbe quando l'invio della ricerca ha esito positivo.

Suggerimento n. 1: utilizza le regioni aria-live per annunciare le modifiche lato client al DOM.

 <div role="region" aria-live="polite" class="off-screen"></div> <form> <label> <span class="off-screen">Search for a video</span> <input type="text" /> </label> <input type="submit" value="Search" /> </form> <script> document.getElementById('search-form').addEventListener('submit', function (e) { e.preventDefault(); ajaxSearchResults(); // not defined here, for brevity document.getElementById('search-status').textContent = 'Search submitted. Navigate to results below.'; // announce to screen reader }); </script>

Ora che avevo imbrogliato e sapevo che c'erano risultati di ricerca da guardare, ho chiuso gli occhi e sono passato al primo video dei risultati, passando alla modalità "intestazioni" di Quick Nav e quindi scorrendo i risultati da lì.

Riproduzione di video su YouTube

Non appena carichi una pagina video di YouTube, il video viene riprodotto automaticamente. Questo è qualcosa che apprezzo nell'uso quotidiano, ma è stata un'esperienza dolorosa quando è stata mescolata con VoiceOver che ne parlava. Non sono riuscito a trovare un modo per disabilitare la riproduzione automatica per i video successivi. Tutto quello che potevo davvero fare era caricare il mio prossimo video e premere rapidamente CTRL per interrompere gli annunci dello screen reader.

Suggerimento n. 2: fornisci sempre un modo per sopprimere la riproduzione automatica e ricorda la scelta dell'utente.

Il video stesso viene trattato come un "gruppo" in cui devi entrare per interagire. Potevo navigare in ciascuna delle opzioni nel lettore video, cosa di cui sono rimasto piacevolmente sorpreso: dubito che fosse così ai tempi di Flash!

Tuttavia, ho scoperto che alcuni dei controlli nel lettore non avevano etichetta, quindi "Modalità Cinema" veniva semplicemente letta come "pulsante".

Suggerimento n. 3: etichetta sempre i controlli del modulo.

Sebbene gli utenti di screen reader siano prevalentemente ciechi, circa il 20% è classificato come "ipovisione", quindi possono vedere parte della pagina. Pertanto, un utente di screen reader potrebbe comunque apprezzare la possibilità di attivare la "Modalità cinema".

Questi suggerimenti non sono elencati in ordine di importanza, ma se lo fossero, questo sarebbe il mio numero uno:

Suggerimento n. 4: gli utenti di screen reader dovrebbero avere la parità funzionale con gli utenti vedenti.

Trascurando di etichettare l'opzione "modalità cinema", escludiamo gli utenti di screen reader da una funzione che potrebbero altrimenti utilizzare.

Detto questo, ci sono casi in cui una funzionalità non sarà applicabile a uno screen reader, ad esempio un grafico a linee SVG dettagliato che potrebbe essere letto come un gobbledygook di numeri senza contesto. In casi come questi, possiamo applicare l'attributo speciale aria-hidden="true" all'elemento in modo che venga ignorato del tutto dagli screen reader. Tieni presente che dovremmo comunque fornire un testo alternativo o una tabella di dati fuori schermo come fallback.

Suggerimento n. 5: usa aria-hidden per nascondere il contenuto che non è applicabile agli utenti di screen reader.

Mi ci è voluto molto tempo per capire come regolare la posizione di riproduzione in modo da poter riavvolgere alcuni contenuti. Dopo aver "entrato" nel dispositivo di scorrimento ( VO + Maiusc + ↓ ), tieni premuto ⌥ + ↑↓ per regolare. Mi sembra poco intuitivo, ma ancora una volta non è la prima volta che Apple prende decisioni controverse sulle scorciatoie da tastiera.

Riproduzione automatica alla fine del video di YouTube

Alla fine del video sono stato automaticamente reindirizzato a un nuovo video, il che era fonte di confusione: non è avvenuto alcun annuncio.

Presto ho imparato a navigare verso i controlli di Autoplay e a disabilitarli:

Ciò non impedisce la riproduzione automatica di un video quando carico una pagina video, ma impedisce a tale pagina video di reindirizzare automaticamente al video successivo.

Caso di studio 2: BBC

Poiché le notizie sono qualcosa consumato passivamente piuttosto che cercando qualcosa di specifico, ho deciso di navigare in BBC News per titoli. Vale la pena notare che non è necessario utilizzare Quick Nav per questo: VoiceOver fornisce comandi di ricerca degli elementi che possono far risparmiare tempo all'utente esperto. In questo caso, potrei navigare nelle intestazioni con i tasti VO + ⌘ + H.

La prima intestazione era l'avviso sui cookie e la seconda intestazione era un <h2> intitolato "Link di accessibilità". Sotto quella seconda intestazione, il primo collegamento era un collegamento "Salta al contenuto" che mi ha permesso di saltare tutta l'altra navigazione.

I collegamenti "Salta al contenuto" sono molto utili e non solo per gli utenti di screen reader; vedi il mio precedente articolo “Ho usato il web per un giorno con solo una tastiera”.

Suggerimento n. 6: fornisci collegamenti "salta al contenuto" per gli utenti della tastiera e dello screen reader.

Navigare per titoli è stato un buon approccio: ogni notizia ha la sua intestazione, quindi ho potuto ascoltare il titolo prima di decidere se leggere di più su una determinata storia. E poiché l'intestazione stessa era racchiusa in un tag di ancoraggio, non dovevo nemmeno cambiare modalità di navigazione quando volevo fare clic; Potrei solo VO + Spazio per caricare la mia attuale scelta di articoli.

Mentre la scorciatoia per saltare al contenuto della home page si collegava bene a un ancoraggio #skip-to-content-link-target (che quindi leggeva il titolo della notizia principale), il collegamento per saltare la pagina dell'articolo era interrotto. Si collegava a un ID diverso ( #page ) che mi ha portato al group che circonda il contenuto dell'articolo, invece di leggere il titolo.

A questo punto, premo VO + A per farmi leggere l'intero articolo da VoiceOver.

Ha reagito abbastanza bene fino a quando non ha colpito l'incorporamento di Twitter, dove ha iniziato a diventare piuttosto dettagliato. Ad un certo punto, ha letto inutilmente "Link: 1068987739478130688".

Questo sembra essere dovuto a qualche markup leggermente incerto nella parte di incorporamento del video del tweet:

Sembra che VoiceOver non legga l'attributo alt dell'immagine nidificata e non ci sia altro testo all'interno dell'ancora, quindi VoiceOver fa la cosa più utile che sa: leggere una parte dell'URL stesso.

Altri lettori di schermo potrebbero funzionare correttamente con questo markup: il tuo chilometraggio potrebbe variare. Ma un'implementazione più sicura sarebbe l'anchor tag con aria-label , o del testo nascosto visivamente fuori dallo schermo, per trasportare il testo alternativo. Mentre siamo qui, probabilmente cambierei "Video incorporato" con qualcosa di un po' più utile, ad esempio "Video incorporato: fai clic per riprodurre").

I problemi di collegamento non erano laggiù:

Sotto il contenuto principale del tweet, c'è un pulsante "Mi piace" che funge anche da contatore "Mi piace". Visivamente ha senso, ma dal punto di vista dello screen reader non c'è contesto qui. Questa esperienza di lettura dello schermo è negativa per due motivi:

1. Non so cosa significhi "1.887".
2. Non so che facendo clic sul collegamento, mi piacerà il tweet.

Agli utenti di screen reader dovrebbe essere dato più contesto, ad esempio "1.887 utenti hanno apprezzato questo tweet. Clicca per mettere mi piace”. Ciò potrebbe essere ottenuto con un testo premuroso fuori schermo:

 <style> .off-screen { clip: rect(0 0 0 0); clip-path: inset(100%); height: 1px; overflow: hidden; position: absolute; white-space: nowrap; width: 1px; } </style> <a href="/tweets/123/like"> <span class="off-screen">1,887 users like this tweet. Click to like</span> <span aria-hidden="true">1,887</span> </a>

Suggerimento n. 7: assicurati che ogni link abbia senso se letto in isolamento.

Ho letto alcuni altri articoli sulla BBC, incluso un articolo in "forma lunga".

Leggere gli articoli più lunghi

Guarda lo screenshot seguente da un altro articolo della BBC in formato lungo: quante immagini diverse puoi vedere e quali dovrebbero essere i loro attributi alt ?

Per prima cosa, diamo un'occhiata all'immagine in primo piano del Lago Havasu al centro dell'immagine. Sotto c'è una didascalia: "Il lago Havasu è stato creato dopo il completamento della diga di Parker nel 1938, che ha trattenuto il fiume Colorado".

È consigliabile fornire un attributo alt anche se viene fornita una didascalia. Il testo alt dovrebbe descrivere l'immagine, mentre la didascalia dovrebbe fornire il contesto. In questo caso, l'attributo alt potrebbe essere qualcosa come "Vista aerea del Lago Havasu in una giornata di sole".

Nota che non dovremmo anteporre al nostro testo alt "Immagine:" o "Immagine di" o qualcosa del genere. I lettori di schermo forniscono già quel contesto annunciando la parola "immagine" prima del nostro testo alt . Inoltre, alt il testo alternativo breve (meno di 16 parole). Se è necessario un testo alt più lungo, ad esempio un'immagine contiene molto testo che deve essere copiato, esamina l' longdesc .

Suggerimento n. 8: scrivi testi alt descrittivi ma efficienti.

Semanticamente, l'esempio di screenshot dovrebbe essere contrassegnato con elementi <figure> e <figcaption> :

 <figure> <img src="/havasu.jpg" alt="Aerial view of Lake Havasu on a sunny day" /> <figcaption>Lake Havasu was created after the completion of the Parker Dam in 1938, which held back the Colorado River</figcaption> </figure>

Ora diamo un'occhiata all'immagine di sfondo in quello screenshot (quello che trasporta vari bicchieri e attrezzature). Come regola generale, le immagini di sfondo o di presentazione come queste dovrebbero avere un attributo alt vuoto ( alt="" ), in modo che a VoiceOver venga detto esplicitamente che non c'è testo alternativo e non tenti di leggerlo.

Nota che un alt="" vuoto NON equivale a non avere alcun attributo alt , il che è un grande no-no. Se manca un attributo alt , gli screen reader leggeranno invece i nomi dei file di immagine, che spesso non sono molto utili!

Suggerimento n. 9: non aver paura di utilizzare attributi alt vuoti per il contenuto di presentazione.

Caso di studio 3: Facebook

Andando su Facebook ora, e stavo avendo sintomi di astinenza da prima, quindi sono andato alla ricerca di altri Joker poco pratici.

Facebook fa un passo o due in più rispetto agli altri siti che ho provato finora, e invece di un collegamento "Salta al contenuto", abbiamo non meno di due menu a discesa che si collegano rispettivamente a pagine o sezioni di pagine.

Facebook definisce anche una serie di tasti come tasti di scelta rapida che possono essere utilizzati da qualsiasi punto della pagina:

Ho giocato con questi e funzionano abbastanza bene con VoiceOver, una volta che sai che sono lì. L'unico problema che vedo è che sono proprietari (non posso aspettarmi che queste stesse scorciatoie funzionino al di fuori di Facebook), ma è bello che Facebook si stia davvero impegnando qui.

Sebbene la mia prima impressione sull'accessibilità di Facebook sia stata buona, ho presto notato piccole stranezze che rendevano il sito più difficile da navigare.

Ad esempio, sono rimasto molto confuso quando ho provato a navigare in questa pagina tramite i titoli:

La prima intestazione della pagina è un'intestazione di livello 3, nascosta nella barra laterale. Questo è immediatamente seguito dal livello di intestazione SIX nella colonna del contenuto principale, che corrisponde a uno stato condiviso dalla Pagina.

Questo può essere visualizzato con il plug-in Web Developer per Chrome/Firefox.

Come regola generale, è una buona idea avere intestazioni sequenziali con una differenza non superiore a 1. Non è un problema se non lo fai, ma è sicuramente fonte di confusione arrivarci dal punto di vista dello screen reader e preoccuparsi di ' Ho saltato accidentalmente alcune informazioni importanti perché sei passato da un h1 a un h6 .

Suggerimento n. 10: convalida la struttura dell'intestazione.

Ora, sulla carne del sito web: i post. Facebook significa rimanere in contatto con le persone e vedere cosa stanno facendo. Ma viviamo in un mondo in cui il testo alt è un concetto sconosciuto alla maggior parte degli utenti, quindi come fa Facebook a tradurre quei selfie compiaciuti e le immagini di cani a un pubblico di lettori di schermo?

Facebook ha un generatore di testo alternativo automatico che utilizza la tecnologia di riconoscimento degli oggetti per analizzare cosa (o chi) c'è in una foto e generarne una descrizione testuale. Quindi, quanto bene funziona?

Il testo alt per questa immagine era "L'immagine può contenere: cielo, erba e spazio all'aperto." È molto lontano riconoscere la "Cattedrale di Cambridge al tramonto", ma è sicuramente un passo nella giusta direzione.

Sono rimasto incredibilmente colpito dall'accuratezza di alcune descrizioni. Un'altra immagine che ho provato è risultata come "L'immagine può contenere: 3 persone, inclusi John Smith, Jane Doe e Chris Ashton, persone sorridenti, in primo piano e al chiuso" — molto descrittiva e assolutamente giusta!

Ma mi infastidisce il fatto che i meme e le battute che diventano virali sui social media siano intrinsecamente inaccessibili; Facebook tratta quanto segue come "L'immagine può contenere: uccello e testo", che sebbene sia vero è molto lontano dalla vera rappresentazione!

Fortunatamente, gli utenti possono scrivere il proprio testo alt se lo desiderano.

Caso di studio 4: Amazon

Qualcosa che ho notato su Facebook, succede anche su Amazon. Il pulsante di ricerca viene visualizzato prima del campo di immissione della ricerca nel DOM. Questo nonostante il pulsante appaia visivamente dopo il campo di input.

È probabile che il tuo sito web sia visivamente in un ordine logico. E se qualcuno spostasse casualmente parti della tua pagina web, continuerebbe ad avere senso?

Probabilmente no. Questo è ciò che può accadere alla tua esperienza di screen reader se non sei disciplinato nel mantenere la tua struttura DOM sincronizzata con il tuo design visivo. A volte è più facile spostare il contenuto con CSS, ma di solito è meglio spostarlo nel DOM.

Suggerimento n. 11: fai in modo che l'ordine DOM corrisponda all'ordine visivo.

Il motivo per cui questi due siti di alto profilo scelgono di non adottare questa linea guida di best practice con la loro navigazione di ricerca mi lascia perplesso. Tuttavia, il pulsante e il testo di input non sono così distanti che il loro ordinamento causa un grosso problema di accessibilità.

Voci su Amazon

Ancora una volta, come Facebook, Amazon ha uno strano ordine delle intestazioni. Ho cercato tramite i titoli ed ero molto confuso dal fatto che il primo titolo nella pagina fosse un titolo di livello 5 nella sezione "Altri venditori su Amazon":

Ho pensato che questo dovesse essere un bug con lo screen reader, quindi ho scavato nel codice sorgente di Amazon per controllare:

L'h1 della pagina appare quasi 10.000 righe più in basso nel codice sorgente.

Non solo questo è povero dal punto di vista semantico e povero per l'accessibilità, ma è anche povero per la SEO. Una scarsa SEO significa meno conversioni (vendite), qualcosa su cui mi aspetto che Amazon sia molto in cima!

Suggerimento n. 12: Accessibilità e SEO sono due facce della stessa medaglia.

Molto di ciò che facciamo per migliorare l'esperienza dello screen reader migliorerà anche la SEO. Le intestazioni semanticamente valide e il testo alt dettagliato sono ottimi per i crawler dei motori di ricerca, il che dovrebbe significare che il tuo sito si posiziona più in alto nella ricerca, il che dovrebbe significare che attirerai un pubblico più ampio.

Se hai mai difficoltà a convincere il tuo manager aziendale che la creazione di siti accessibili è importante, prova un'angolazione diversa e sottolinea invece i vantaggi SEO.

Varie

È difficile condensare un giorno di navigazione ed esperienze in un unico articolo. Ecco alcuni punti salienti e luci basse che hanno fatto il taglio.

Noterai i siti lenti

Le utilità per la lettura dello schermo non possono analizzare la pagina e creare il proprio albero di accessibilità finché il DOM non è stato caricato. Gli utenti vedenti possono scansionare una pagina durante il caricamento, determinando rapidamente se ne vale la pena e premendo il pulsante Indietro in caso contrario. Gli utenti di screen reader non hanno altra scelta che attendere il caricamento del 100% della pagina.

È interessante notare che, sebbene la realizzazione di un sito Web performante avvantaggia tutti, è particolarmente vantaggiosa per gli utenti di screen reader.

Accetto cosa?

I controlli dei moduli come questo di NatWest possono dipendere fortemente dalla vicinanza spaziale per denotare relazioni. Nella terra degli screen reader, non c'è vicinanza spaziale - solo fratelli e genitori - e sono necessarie congetture per sapere a cosa stai spuntando "sì".

Avrei saputo cosa stavo acconsentendo se il disclaimer fosse stato parte dell'etichetta:

 <label> Important: We can only hold details of one trip at a time. <input type="checkbox" /> Tick to confirm you have read this. * </label>

Seguire il codice è un incubo

Ho provato a leggere un articolo tecnico sui CSS Tricks usando il mio screen reader, ma onestamente ho trovato l'esperienza totalmente impossibile da seguire. Non è colpa del sito Web CSS Tricks: penso che sia incredibilmente complesso spiegare idee tecniche ed esempi di codice in modo completamente uditivo. Quante volte hai provato a eseguire il debug con un partner e invece di spiegare l'esatta sintassi di cui hai bisogno, gli dai qualcosa da copiare e incollare o lo riempi tu stesso?

Guarda come puoi leggere facilmente questo esempio di codice dall'articolo:

Ma ecco la versione dello screen reader:

prima barra barra otteniamo l'altezza della finestra e la moltiplichiamo per uno [pausa] percento per ottenere un valore per un'unità vh lascia che vh sia uguale all'altezza interna della finestra stella [pausa] zero zero una barra barra quindi impostiamo il valore in [pausa ] vh proprietà personalizzata alla radice del documento documento documento elemento stile imposta proprietà [pausa] vh dollaro parentesi graffa sinistra vh parentesi graffa destra px

È totalmente illeggibile nel panorama sonoro. Tendiamo a non avere punteggiatura nei commenti e, in questo caso, una riga scorre senza interruzioni nella successiva nella terra dello screen reader. camelCase text viene letto come parole separate come se fossero state scritte in una frase. Periodi come window.innerHeight vengono ignorati e trattati come "altezza interna della finestra". L'unico "codice" letto sono le parentesi graffe alla fine.

Il codice è contrassegnato utilizzando elementi HTML standard <pre> e <code> , quindi non so come questo potrebbe essere migliorato per gli utenti di screen reader. Tutti coloro che perseverano con la programmazione hanno la mia totale ammirazione.

In caso contrario, l'unico difetto che ho riscontrato è stato che il logo del sito aveva un collegamento alla home page, ma nessun testo alt , quindi tutto ciò che ho sentito è stato "link: slash". È solo nella mia qualità di sviluppatore web che so se hai un link con un attributo href="/" ti porta alla home page del sito web, quindi ho capito a cosa serviva il link, ma "link: CSS Tricks homepage” sarebbe stato meglio!

VoiceOver su iOS è più complicato di OSX

Usare VoiceOver sul mio telefono è stata un'esperienza!

Mi sono dato la sfida di navigare nell'app di Twitter e scrivere un Tweet, a schermo spento e utilizzando la tastiera del cellulare. È stato più difficile del previsto e ho commesso diversi errori di ortografia.

Se fossi un normale utente di screen reader, penso che dovrei unirmi al 41% degli utenti di screen reader mobili che utilizzano una tastiera esterna e investono in una tastiera Bluetooth. Clara Van Gerven è giunta alla stessa conclusione quando ha utilizzato uno screen reader per quaranta giorni nel 2015.

È stato fantastico attivare la modalità Tenda schermo con un triplo tocco usando tre dita. Questo ha spento lo schermo ma ha mantenuto il telefono sbloccato, così ho potuto continuare a navigare nel mio telefono senza che nessuno guardasse. Questa funzione è essenziale per gli utenti non vedenti che potrebbero altrimenti fornire inconsapevolmente le proprie password alla persona che sorveglia alle loro spalle, ma ha anche il vantaggio di essere ottimo per risparmiare la batteria.

Sommario

Questa è stata un'esperienza interessante e stimolante, e l'articolo più difficile della serie da scrivere finora.

Sono rimasto sbalordito dalle piccole cose che sono ovvie quando ti fermi a pensarci. Ad esempio, quando si utilizza uno screen reader, è quasi impossibile ascoltare la musica contemporaneamente alla navigazione sul Web! Anche mantenere il contesto della pagina può essere difficile, soprattutto se vieni interrotto da una telefonata o qualcosa del genere; quando torni allo screen reader hai quasi perso il tuo posto.

Il mio più grande risultato è che c'è un grande shock culturale nell'andare a vivere un'esperienza solo audio. È un modo completamente diverso di navigare sul Web e, poiché esiste un tale contrasto, è difficile persino sapere cosa costituisca un'esperienza di screen reader "buona" o "cattiva". Può essere piuttosto travolgente e non sorprende che molti sviluppatori evitino di testarli.

Ma non dovremmo evitare di farlo solo perché è difficile. Come ha detto Charlie Owen nel suo intervento, caro sviluppatore, il Web non parla di te : questo. È. Il tuo. Lavoro . Whilst it's fun to build beautiful, responsive web applications with all the latest cutting-edge technologies, we can't just pick and choose what we want to do and neglect other areas. We are the ones at the coal face. We are the only people in the organization capable of providing a good experience for these users. What we choose to prioritize working on today might mean the difference between a person being able to use our site, and them not being able to.

Let us do our jobs responsibly, and let's make life a little easier for ourselves, with my last tip of the article:

Tip #13: Test on a screen reader, little and often.

I've tested on screen readers before, yet I was very ropey trying to remember my way around, which made the day more difficult than it needed to be. I'd have been much more comfortable using a screen reader for the day if I had been regularly using one beforehand, even for just a few minutes per week.

Test a little, test often, and ideally, test on more than one screen reader. Every screen reader is different and will read content out in different ways. Not every screen reader will read “23/10/18” as a date; some will read out “two three slash one zero slash one eight.” Get to know the difference between application bugs and screen reader quirks, by exposing yourself to both.

Did you enjoy this article? This was the third one in a series; read how I Used The Web For A Day With JavaScript Turned Off and how I Used The Web For A Day With Just A Keyboard.