Questo modulo è incentrato sull'uso delle tecnologie per la disabilità per i test di accessibilità. Una persona con disabilità può utilizzare l'AT per aumentare, mantenere o migliorare le capacità di eseguire un'attività.
Nello spazio digitale, i test di verifica possono essere:
- No/Low-tech: bastoncini per testa/bocca, lenti di ingrandimento portatili, dispositivi con pulsanti grandi
- High-tech: dispositivi ad attivazione vocale, dispositivi per il tracciamento degli occhi, tastiere/mopi adattivi
- Hardware: pulsanti di opzione, tastiere ergonomiche, dispositivo braille con aggiornamento automatico
- Software: programmi di sintesi vocale, sottotitoli in tempo reale, screen reader
Ti consigliamo di utilizzare più tipi di testi AT nel flusso di lavoro di test complessivo.
Nozioni di base sul test degli screen reader
In questo modulo ci concentriamo su uno degli screen reader digitali più popolari, ovvero gli screen reader. Uno screen reader è un software che legge il codice sottostante di un sito web o di un'app e converte queste informazioni in output vocale o braille per l'utente.
Gli screen reader sono essenziali per le persone cieche e sordocieche, ma potrebbero anche essere utili per le persone ipovedenti, disturbi della lettura o disabilità intellettive.
Compatibilità del browser
Sono disponibili diverse opzioni per lo screen reader. Gli screen reader più popolari oggi sono JAWS, NVDA e VoiceOver per computer desktop e VoiceOver e TalkBack per i dispositivi mobili.
A seconda del sistema operativo (OS), del browser preferito e del dispositivo utilizzato, uno screen reader può risaltare come l'opzione migliore. La maggior parte degli screen reader è realizzata con hardware e browser web specifici. Quando utilizzi uno screen reader con un browser per cui non è stato calibrato, potresti riscontrare più "bug" o comportamenti imprevisti. Gli screen reader funzionano meglio se utilizzati nelle seguenti combinazioni.
Comandi dello screen reader
Una volta configurato il software dello screen reader per il tuo computer o dispositivo mobile, consulta la relativa documentazione (link nella tabella precedente) ed esegui alcuni comandi essenziali dello screen reader per acquisire familiarità con la tecnologia. Se hai già utilizzato uno screen reader, valuta la possibilità di provarne uno nuovo.
Quando utilizzi uno screen reader per i test di accessibilità, l'obiettivo è rilevare problemi nel codice che interferiscono con l'utilizzo del sito web o dell'app, non emulare l'esperienza di un utente di screen reader. Di conseguenza, puoi fare molto con alcune conoscenze di base, alcuni comandi dello screen reader e un po' di pratica.
Se hai bisogno di comprendere ulteriormente l'esperienza utente delle persone che utilizzano screen reader e altri AT, puoi coinvolgere molte organizzazioni e persone per ottenere queste preziose informazioni. Ricorda che utilizzare un AT per testare il codice in base a un insieme di regole e chiedere agli utenti informazioni sulla loro esperienza spesso produce risultati diversi. Entrambi sono aspetti importanti per creare prodotti completamente inclusivi.
Comandi principali per screen reader per computer
Comandi principali per screen reader per dispositivi mobili
Demo di test dello screen reader
Per testare la nostra demo, abbiamo utilizzato Safari su un laptop con sistema operativo MacOS per acquisire l'audio. Puoi seguire questi passaggi utilizzando qualsiasi screen reader, ma il modo in cui riscontri alcuni errori potrebbe essere diverso da quello descritto in questo modulo.
Passaggio 1
Consulta la versione aggiornata di CodePen, a cui sono stati applicati tutti gli aggiornamenti automatici e manuali dell'accessibilità.
Visualizzalo in modalità di debug per procedere con i test successivi. Questo è importante, in quanto rimuove <iframe> che circonda la pagina web demo, il che potrebbe interferire con alcuni strumenti di test. Scopri di più sulla modalità di debug di CodePen.
Passaggio 2
Attiva lo screen reader che preferisci e vai alla pagina demo. Prima di concentrarti su problemi specifici, prova a spostarti attraverso l'intera pagina dall'alto verso il basso.
Abbiamo registrato lo screen reader per ogni problema, prima e dopo l'applicazione delle correzioni alla demo. Ti consigliamo di eseguire la demo con il tuo screen reader.
Problema 1: struttura dei contenuti
Le intestazioni e i punti di riferimento sono uno dei modi principali per navigare utilizzando gli screen reader. Se non sono presenti, un utente di screen reader deve leggere l'intera pagina per comprendere il contesto. Questa procedura può richiedere molto tempo e causare frustrazione. Se provi a navigare per uno dei due elementi nella demo, scoprirai subito che non esistono.
- Esempio di punto di riferimento:
<div class="main">...</div> - Esempio di intestazione:
<p class="h1">Join the Club</p>
Se hai aggiornato tutto correttamente, non dovrebbero verificarsi modifiche all'aspetto, ma l'esperienza con lo screen reader sarà notevolmente migliorata.
Risolviamo il problema.
Alcuni elementi inaccessibili non possono essere osservati semplicemente guardando il sito. Potresti ricordare l'importanza dei livelli di intestazioni e dell'HTML semantico del modulo Struttura dei contenuti. Un contenuto può sembrare un titolo, ma in realtà è racchiuso in un <div> stilizzato.
Per risolvere il problema relativo alle intestazioni e ai punti di riferimento, devi prima identificare ogni elemento che deve essere sottoposto a markup come tale e aggiornare il relativo codice HTML. Assicurati di aggiornare anche il CSS correlato.
Esempio di punto di riferimento: <main>...</main>
Esempio di intestazione: <h1>Join the Club</h1>
Se hai aggiornato tutto correttamente, non dovrebbero verificarsi modifiche all'aspetto, ma l'esperienza con lo screen reader sarà notevolmente migliorata.
Problema 2: contesto del link
È importante fornire contenuti agli utenti di screen reader in merito allo scopo di un link e se il link li reindirizza a una nuova posizione al di fuori del sito web o dell'app.
Nella nostra demo, abbiamo corretto la maggior parte dei link quando abbiamo aggiornato il testo alternativo attivo dell'immagine, ma sono disponibili alcuni link aggiuntivi sulle varie malattie rare che potrebbero trarre vantaggio da un contesto aggiuntivo, soprattutto perché reindirizzano a una nuova posizione.
<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease">
Maple syrup urine disease (MSUD)
</a>
Per risolvere il problema relativo agli utenti di screen reader, aggiorniamo il codice per aggiungere ulteriori informazioni, senza influire sull'elemento visivo. In alternativa, per aiutare ancora più persone, come quelle con disturbi della lettura e disturbi cognitivi, potremmo scegliere di aggiungere altro testo visivo.
Per aggiungere ulteriori informazioni sui link, possiamo prendere in considerazione molti schemi diversi. Sulla base del nostro semplice ambiente che supporta una sola lingua, l'etichetta ARIA è un'opzione semplice in questa situazione. Potresti notare che l'etichetta ARIA sostituisce il testo originale del link, quindi assicurati di includere questa informazione nell'aggiornamento.
<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease"
aria-label="Learn more about Maple syrup urine disease on the Rare Diseases website.">
Maple syrup urine disease (MSUD)
</a>
Problema 3: immagine decorativa
Nel nostro modulo di test automatico, Lighthouse non è riuscito a rilevare l'immagine SVG in linea che funge da immagine iniziale di schermata nella nostra pagina demo, ma lo screen reader la trova e la annuncia come "immagine" senza ulteriori informazioni. Questo vale anche senza aggiungere esplicitamente l'attributo role="img" al file SVG.
<div class="section-right">
<svg>...</svg>
</div>
Per risolvere il problema, dobbiamo innanzitutto decidere se l'immagine è informativa o decorativa. In base a questa decisione, dobbiamo aggiungere il testo alternativo appropriato all'immagine (immagine informativa) o nascondere l'immagine agli utenti di screen reader (immagine decorativa).
Abbiamo ponderato i pro e i contro di come classificare al meglio l'immagine e abbiamo deciso che era decorativa, il che significa che vogliamo aggiungere o modificare il codice per nascondere l'immagine. Un metodo rapido consiste nell'aggiungere un role="presentation" direttamente all'immagine SVG. In questo modo viene inviato allo screen reader un segnale per saltare sopra questa immagine e non elencarla nel gruppo di immagini.
<div class="section-right">
<svg role="presentation">...</svg>
</div>
Problema 4: decorazione di punti elenco
Forse avrai notato che lo screen reader legge l'immagine punto elenco del CSS sotto la sezione Malattie rare. Sebbene non sia il tipo tradizionale di immagine descritto nel modulo Immagini, l'immagine deve comunque essere modificata poiché interrompe il flusso dei contenuti e potrebbe distrarre o confondere l'utente di uno screen reader.
<p class="bullet">...</p>
Proprio come nell'esempio dell'immagine decorativa discusso in precedenza, puoi aggiungere un role="presentation" al codice HTML con la classe bullet per nasconderlo allo screen reader. Analogamente, potrebbe funzionare un role="none". Assicurati solo di non utilizzare aria-hidden: true, altrimenti nasconderai tutte le informazioni del paragrafo agli utenti di screen reader.
<p class="bullet" role="none">...</p>
Problema 5: campo modulo
Nel modulo Moduli abbiamo appreso che tutti i campi dei moduli devono avere anche un'etichetta visiva e programmatica. Questa etichetta deve rimanere sempre visibile.
Nella nostra demo, manca un'etichetta visiva e programmatica nel campo dell'email di iscrizione alla newsletter. È presente un elemento segnaposto di testo, che però non sostituisce l'etichetta poiché non è visivamente persistente e non è completamente compatibile con tutti gli screen reader.
<form>
<div class="form-group">
<input type="email" placeholder="Enter your e-mail address" required>
<button type="submit">Subscribe</button>
</div>
</form>
Per risolvere il problema, sostituisci il segnaposto di testo con un elemento etichetta simile. L'elemento etichetta è connesso in modo programmatico al campo del modulo e lo spostamento è stato aggiunto tramite JavaScript per mantenere visibile l'etichetta anche quando i contenuti sono stati aggiunti al campo.
<form>
<div class="form-group">
<input type="email" required id="youremail" name="youremail" type="text">
<label for="youremail">Enter your e-mail address</label>
<button type="submit" aria-label="Subscribe to our newsletter">Subscribe</button>
</div>
</form>
Conclusione
Complimenti! Hai completato tutti i test per questa demo. Puoi dare un'occhiata a tutte queste modifiche nel codepen aggiornato per questa demo.
Ora, puoi utilizzare ciò che hai imparato per esaminare l'accessibilità dei tuoi siti web e delle tue app.
L'obiettivo di tutti questi test di accessibilità è risolvere quanti più possibili problemi che un utente potrebbe riscontrare. Tuttavia, questo non significa che il tuo sito web o la tua app saranno perfettamente accessibili una volta che avrai finito. Per ottenere risultati migliori, progetta il tuo sito web o la tua app rendendoli accessibili durante l'intero processo e incorporando questi test negli altri test pre-lancio.
Verifica la tua comprensione
Verifica le tue conoscenze dei test di accessibilità automatici
Qual è lo screen reader migliore da utilizzare per testare l'accessibilità?
A cosa servono i test con le tecnologie per la disabilità?