Questo modulo è incentrato sull'utilizzo delle tecnologie per la disabilità per i test sull'accessibilità. Una persona con disabilità può utilizzare AT per aumentare, mantenere o migliorare le capacità di svolgere un'attività.
Nell'ambito digitale, i valori AT possono essere:
- No/Low-tech: bastoncini per la testa/bocca, lenti d'ingrandimento portatili, dispositivi con pulsanti grandi
- High-tech: dispositivi ad attivazione vocale, dispositivi di tracciamento oculare, tastiere/mopi adattivi
- Hardware: passa da un pulsante all'altro, tastiere ergonomiche, dispositivo braille con aggiornamento automatico
- Software: programmi di sintesi vocale, sottotitoli in tempo reale, screen reader
Ti invitiamo a utilizzare più tipi di AT nel flusso di lavoro complessivo di test.
Nozioni di base sui test degli screen reader
In questo modulo ci concentriamo su uno dei più diffusi, gli screen reader, uno degli AT digitali. Uno screen reader è un software che legge il codice sottostante di un sito web o di un'app. Quindi converte queste informazioni in output vocale o braille per l'utente.
Gli screen reader sono essenziali per le persone cieche e sordocieche, ma possono anche aiutare le persone ipovedenti, disturbi della lettura o disabilità cognitive.
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, nonché VoiceOver e TalkBack per i dispositivi mobili.
A seconda del sistema operativo (OS), del browser preferito e del dispositivo che utilizzi, uno screen reader potrebbe distinguersi come l'opzione migliore. La maggior parte degli screen reader viene sviluppata tenendo in considerazione hardware e browser web specifici. Quando utilizzi uno screen reader con un browser per il quale non è stato calibrato, potresti riscontrare più "bug" o inaspettati. Gli screen reader funzionano meglio se utilizzati nelle seguenti combinazioni.
Comandi dello screen reader
Dopo aver configurato correttamente il software dello screen reader per il computer o il dispositivo mobile, è necessario consultare la documentazione dello screen reader (link nella tabella precedente) ed eseguire alcuni comandi essenziali dello screen reader per acquisire familiarità con la tecnologia. Se hai già utilizzato uno screen reader, prova a 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 tuo sito web o della tua app, non di 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' (o molto) 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 singoli individui per ottenere queste preziose informazioni. Ricorda che usare un AT per testare il codice sulla base di 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 usato Safari su un laptop con MacOS e l'acquisizione dell'audio. Puoi seguire questi passaggi utilizzando qualsiasi screen reader, ma il modo in cui riscontri alcuni errori potrebbe essere diverso da come è descritto in questo modulo.
Passaggio 1
Visita il CodePen aggiornato, che abbiano applicato tutti gli aggiornamenti automatici e manuali dell'accessibilità.
Visualizzala in modalità di debug per procedere con
i prossimi test. Questo è importante, poiché rimuove il parametro <iframe> che circonda il componente
pagina web demo, che potrebbe interferire con alcuni strumenti di test. Scopri di più su
Modalità di debug di CodePen.
Passaggio 2
Attiva lo screen reader che preferisci e vai alla pagina demo. Puoi valutare la possibilità di navigare nell'intera pagina dall'alto verso il basso prima di concentrarti su problemi specifici.
Abbiamo registrato il nostro screen reader per ogni problema, prima e dopo l'applicazione delle correzioni alla demo. Ti invitiamo a esaminare la demo con il tuo screen reader.
Problema 1: struttura dei contenuti
Intestazioni e punti di riferimento sono uno dei principali modi in cui gli utenti navigano utilizzando gli screen reader. Se non sono presenti, l'utente di uno screen reader deve leggere l'intera pagina per comprendere il contesto. Ciò può richiedere molto tempo e causare frustrazione. Se provi a esplorare uno dei due elementi della demo, scoprirai rapidamente 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 esserci modifiche visive, ma l'esperienza con lo screen reader sarà notevolmente migliorata.
Risolviamo il problema.
Alcuni elementi inaccessibili non possono essere osservati semplicemente guardando il sito. Forse ricordi l'importanza dei livelli di intestazione e dell'HTML semantico indicato nel modulo Struttura dei contenuti. Un determinato contenuto potrebbe sembrare un titolo, ma in realtà è inserito in un elemento <div> stilizzato.
Per risolvere il problema relativo a intestazioni e punti di riferimento, devi prima identificare ogni elemento per cui eseguire il markup come tale e aggiornare il relativo 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 esserci modifiche visive, ma l'esperienza con lo screen reader sarà notevolmente migliorata.
Problema 2: contesto dei link
È importante fornire contenuti agli utenti di screen reader sullo 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 durante l'aggiornamento del testo alternativo dell'immagine attiva. Tuttavia, sono presenti 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 per gli utenti di screen reader, aggiorniamo il codice per aggiungere ulteriori informazioni, senza influire sull'elemento visivo. In alternativa, per aiutare ancora più persone, ad esempio chi soffre di disturbi della lettura e disturbi cognitivi, potremmo scegliere di aggiungere un ulteriore testo visivo.
Esistono diversi pattern che possiamo prendere in considerazione per aggiungere ulteriori informazioni sui link. In base al nostro ambiente semplice che supporta una sola lingua, un'etichetta ARIA è un'opzione molto 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'SVG incorporato che funge da immagine iniziale principale nella nostra pagina demo, ma lo screen reader lo trova e lo annuncia come "immagine" senza ulteriori informazioni. Questo è vero, anche senza aggiungere esplicitamente l'attributo role="img" al file SVG.
<div class="section-right">
<svg>...</svg>
</div>
Per risolvere il problema, devi prima decidere se l'immagine è informativa o decorativa. In base a questa decisione, dobbiamo aggiungere il testo alternativo all'immagine appropriata (immagine informativa) o nascondere l'immagine agli utenti di screen reader (immagine decorativa).
Abbiamo valutato 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 role="presentation" direttamente all'immagine SVG. In questo modo viene inviato un segnale allo screen reader per saltare l'immagine e non elencarla nel gruppo di immagini.
<div class="section-right">
<svg role="presentation">...</svg>
</div>
Problema 4: decorazione dei punti elenco
Avrai notato che lo screen reader legge l'immagine punto elenco CSS sotto nelle sezioni sulle malattie rare. Sebbene non sia il tipo tradizionale di immagini discusso nel modulo Immagini, l'immagine deve essere comunque modificata mentre interrompe. il flusso dei contenuti e ciò potrebbe distrarre o confondere l'utente di uno screen reader.
<p class="bullet">...</p>
Proprio come per l'esempio di immagine decorativa discusso in precedenza, puoi aggiungere role="presentation" al codice HTML con la classe bullet per nasconderlo dallo screen reader. Analogamente, può andare bene 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 del modulo
Nel modulo Moduli, abbiamo imparato che tutti i moduli devono avere anche un'etichetta visiva e programmatica. Questa etichetta deve rimanere sempre visibili.
Nella nostra demo mancano le etichette visive e programmatiche nel campo dell'email di iscrizione alla newsletter. È presente un elemento segnaposto di testo che però non sostituisce l'etichetta in quanto non è visivamente permanente 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. Questo elemento dell'etichetta è collegato in modo programmatico al campo del modulo e il movimento è stato aggiunto con JavaScript per mantenere l'etichetta visibile anche quando vengono aggiunti contenuti 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 usare ciò che hai imparato per verificare l'accessibilità dei tuoi siti web e app.
L'obiettivo di tutti questi test sull'accessibilità è affrontare il maggior numero possibile problemi che un utente potrebbe incontrare. Tuttavia, questo non significa che il tuo sito web o la tua app saranno perfettamente accessibili quando hai finito. Riuscirai a ottenere i migliori risultati progettando il tuo sito web o la tua app tenendo sotto controllo l'accessibilità durante l'intero processo e a incorporare questi test insieme agli altri test pre-lancio.
Verifica le tue conoscenze
Verifica le tue conoscenze dei test automatici di accessibilità
Qual è lo screen reader migliore da usare per testare l'accessibilità?
A cosa serve eseguire test con le tecnologie per la disabilità?