Test di tecnologie per la disabilità

Questo modulo è incentrato sull'utilizzo di tecnologie per la disabilità (TA) per i test di accessibilità. Una persona con disabilità può utilizzare le tecnologie assistive per aumentare, mantenere o migliorare le capacità di svolgere un'attività.

Nel mondo digitale, le tecnologie assistive possono essere:

• Tecnologia assente o di base: bacchette per la testa e la bocca, ingranditori portatili, dispositivi con pulsanti grandi
• Tecnologia avanzata: dispositivi ad attivazione vocale, dispositivi di tracciamento oculare, tastiere e mouse adattivi
• Hardware: pulsanti di commutazione, 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 AT nel tuo flusso di lavoro di test complessivo.

Nozioni di base sui test con screen reader

In questo modulo ci concentriamo su una delle tecnologie assistive digitali più diffuse: gli screen reader. 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 sordo-cieche, ma possono essere utili anche per le persone con problemi di vista, disturbi della lettura e disabilità cognitive.

Compatibilità del browser

Sono disponibili diverse opzioni di screen reader. Gli screen reader più diffusi sono JAWS, NVDA e VoiceOver per computer e VoiceOver e Talkback per 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 sono progettati per hardware e browser web specifici. Quando utilizzi un lettore di schermo 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 correttamente il software di screen reader per il computer o il dispositivo mobile, consulta la documentazione dello screen reader (collegata nella tabella precedente) ed esegui alcuni comandi essenziali dello screen reader per familiarizzare con la tecnologia. Se hai già utilizzato uno screen reader, ti consigliamo di provarne uno nuovo.

Quando utilizzi uno screen reader per i test di accessibilità, il tuo obiettivo è rilevare problemi nel codice che interferiscono con l'utilizzo del tuo sito web o della tua app, non emulare l'esperienza di un utente di screen reader. Pertanto, con un po' di conoscenze di base, alcuni comandi dello screen reader e un po' (o molto) di pratica, puoi fare molto.

Se vuoi comprendere meglio l'esperienza utente delle persone che utilizzano screen reader e altre tecnologie assistive, puoi collaborare con molte organizzazioni e privati per ottenere queste preziose informazioni. Ricorda che l'utilizzo di 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 gli screen reader per computer

Comandi principali per gli screen reader mobile

Demo di test dello screen reader

Per testare la demo, abbiamo utilizzato Safari su un laptop con macOS e abbiamo acquisito l'audio. Puoi seguire questi passaggi utilizzando qualsiasi screen reader, ma il modo in cui potresti riscontrare alcuni errori potrebbe essere diverso da quello descritto in questo modulo.

Passaggio 1

Visita la CodePen aggiornata, a cui sono stati applicati tutti gli aggiornamenti di accessibilità automatici e manuali.

Visualizzalo in modalità di debug per procedere con i test successivi. Questo è importante perché rimuove il <iframe> che circonda la pagina web demo, 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. Ti consigliamo di scorrere l'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 provare la demo con il tuo screen reader.

Problema 1: struttura dei contenuti

Titoli e punti di riferimento sono uno dei modi principali in cui le persone navigano utilizzando gli screen reader. Se questi elementi non sono presenti, l'utente di screen reader deve leggere l'intera pagina per comprendere il contesto. L'operazione può richiedere molto tempo e causare frustrazione.

Se provi a navigare in base a uno dei due elementi nella 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. Potresti ricordare l'importanza dei livelli di intestazione e dell'HTML semantico dal modulo Struttura dei contenuti. Un contenuto potrebbe sembrare un'intestazione, 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 contrassegnato come tale e aggiornare l'HTML correlato. 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 del link

È importante fornire agli utenti di screen reader informazioni 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 quando abbiamo aggiornato il testo alternativo dell'immagine attiva, ma ci sono 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>

Risolviamo il problema.

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 un numero ancora maggiore di persone, come quelle con disturbi cognitivi e di lettura, potremmo scegliere di aggiungere un testo visivo aggiuntivo.

Esistono molti pattern diversi che possiamo prendere in considerazione per aggiungere informazioni aggiuntive sui link. In base al nostro ambiente che supporta una sola lingua, un'etichetta ARIA è un'opzione semplice in questa situazione. Potresti notare che l'etichetta ARIA sostituisce il testo del link originale, quindi assicurati di includere queste informazioni 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 automatizzato, Lighthouse non è riuscito a rilevare l'SVG incorporato che funge da immagine di copertina principale nella nostra pagina demo. Tuttavia, lo screen reader lo trova e lo annuncia come "immagine" senza ulteriori informazioni. Questo vale anche senza aggiungere esplicitamente l'attributo role="img" all'SVG.

<div class="section-right">
  <svg>...</svg>
</div>

Risolviamo il problema.

Per risolvere il problema, dobbiamo prima decidere se l'immagine è informativa o decorativa. In base a questa decisione, dobbiamo aggiungere il testo alternativo dell'immagine appropriato (immagine informativa) o nascondere l'immagine agli utenti di screen reader (decorativa).

Abbiamo valutato i vantaggi e gli svantaggi del modo migliore per classificare l'immagine e abbiamo deciso che è 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, lo screen reader salta l'immagine e non la elenca nel gruppo di immagini.

<div class="section-right">
  <svg role="presentation">...</svg>
</div>

Problema 4: decorazione dei punti elenco

Potresti aver notato che lo screen reader legge l'immagine dell'elenco puntato CSS nella sezione dedicata alle malattie rare. Sebbene questa immagine non sia la stessa di quella di cui abbiamo parlato nel modulo Immagini, deve comunque essere modificata perché interrompe il flusso dei contenuti e potrebbe distrarre o confondere un utente di screen reader.

<p class="bullet">...</p>

Risolviamo il problema.

Come nell'esempio di immagine decorativa discusso in precedenza, puoi aggiungere un role="presentation" all'HTML con la classe elenco puntato per nasconderlo allo screen reader. Allo stesso modo, andrebbe 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 modulo

Nel modulo Moduli abbiamo appreso che tutti i campi del modulo devono avere anche un'etichetta visiva e programmatica. Questa etichetta deve rimanere sempre visibile.

Nella nostra demo mancano sia un'etichetta visiva che una programmatica nel campo email di iscrizione alla newsletter. Esiste un elemento segnaposto di testo, ma questo non sostituisce l'etichetta perché 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>

Risolviamo il problema.

Per risolvere il problema, sostituisci il segnaposto di testo con un elemento etichetta simile. L'elemento 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 esaminare 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 il maggior numero possibile di problemi che un utente potrebbe potenzialmente incontrare. Tuttavia, ciò non significa che il tuo sito web o la tua app siano perfettamente accessibili una volta terminato. Per ottenere i risultati migliori, progetta il tuo sito web o la tua app con l'accessibilità durante tutto il processo e incorpora questi test con gli altri test pre-lancio.