Test di tecnologie per la disabilità

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

Nello spazio digitale, gli AT possono essere:

• Nessuna o bassa tecnologia: occhiali e bacchette, lenti d'ingrandimento portatili, dispositivi con pulsanti grandi
• Elettronica di alta tecnologia: dispositivi ad attivazione vocale, dispositivi di monitoraggio oculare, tastiere e mouse adattabili
• 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 di test complessivo.

Nozioni di base sui test degli screen reader

In questo modulo ci concentriamo su una delle tecnologie per la disabilità digitale 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 sordocieche, ma possono essere utili anche per le persone con problemi di vista, disturbi di lettura e disabilità cognitive.

Compatibilità del browser

Sono disponibili più 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, un determinato screen reader potrebbe essere 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 comportamenti imprevisti. Gli screen reader funzionano al meglio se utilizzati nelle seguenti combinazioni.

Comandi dello screen reader

Una volta configurato correttamente il software dello screen reader per il computer o il dispositivo mobile, consulta la documentazione dello screen reader (collegata nella tabella precedente) ed esegui alcuni comandi dello screen reader essenziali per familiarizzare con la tecnologia. Se hai già usato uno screen reader, valuta di provarne uno nuovo.

Quando utilizzi uno screen reader per i test di accessibilità, il tuo obiettivo è rilevare i 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. Di conseguenza, puoi fare molto con alcune conoscenze di base, alcuni comandi dello screen reader e un po' (o molto) di pratica.

Se vuoi comprendere ulteriormente l'esperienza utente delle persone che utilizzano screen reader e altri SA, puoi collaborare con molte organizzazioni e privati 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 da tastiera per gli screen reader per computer

Comandi principali per gli screen reader mobile

Demo di test dello screen reader

Per testare la nostra 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 riscontri alcuni errori potrebbe essere diverso da quello descritto in questo modulo.

Passaggio 1

Visita CodePen aggiornato, 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 della 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 di demo. Ti consigliamo di esaminare 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 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 in cui le persone 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 navigare in base a uno di questi elementi nella demo, scoprirai rapidamente che non esistono.

• Esempio di punto di riferimento: <div class="main">...</div>
• Esempio di titolo: <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 visitando il sito. Probabilmente ricordi l'importanza dei livelli di intestazione e dell'HTML semantico dal modulo Struttura dei contenuti. Un contenuto potrebbe sembrare un titolo, ma in realtà è racchiuso in un <div> stilizzato.

Per risolvere il problema relativo a intestazioni e punti di riferimento, devi prima identificare ogni elemento che deve essere contrassegnato come tale e aggiornare il codice HTML correlato. Assicurati di aggiornare anche il CSS correlato.

• Esempio di punto di riferimento: <main>...</main>
• Esempio di titolo: <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 agli utenti di screen reader contenuti relativi 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 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 pagina.

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

Esistono molti pattern diversi che possiamo prendere in considerazione per aggiungere ulteriori informazioni sui link. In base al nostro ambiente che supporta una sola lingua, un'etichetta ARIA è un'opzione molto 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 iniziale principale nella pagina demo. Tuttavia, lo screen reader la trova e la annuncia come "immagine" senza ulteriori informazioni. Questo vale anche senza aggiungere esplicitamente l'attributo role="img" al codice 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 appropriato per l'immagine (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 era decorativa, il che significa che vogliamo aggiungere o modificare il codice per nasconderla. Un metodo rapido è aggiungere un role="presentation" direttamente all'immagine SVG. In questo modo, lo screen reader viene informato di saltare questa immagine e di non includerla 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 nelle sezioni relative alle malattie rare. Anche se non si tratta del tipo di immagine tradizionale discusso nel modulo Immagini, l'immagine deve comunque essere modificata in quanto interrompe il flusso dei contenuti e potrebbe distrarre o confondere un utente di screen reader.

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

Risolviamo il problema.

Come per l'esempio di immagine decorativa discusso in precedenza, puoi aggiungere un role="presentation" al codice HTML con la classe di elenco per nasconderlo allo screen reader. Analogamente, andrebbe bene anche un role="none". Assicurati solo di non utilizzarearia-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 campi del modulo devono avere anche un'etichetta visiva e programmatica. Questa etichetta deve rimanere visibile in ogni momento.

Nella nostra demo mancano sia un'etichetta visiva sia un'etichetta programmatica nel campo email per l'iscrizione alla newsletter. Esiste un elemento segnaposto di testo, ma questo non sostituisce l'etichetta in quanto 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 di 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 il contenuto viene aggiunto 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 sull'accessibilità è risolvere il maggior numero possibile di problemi che un utente potrebbe incontrare. Tuttavia, ciò non significa che il tuo sito web o la tua app sia perfettamente accessibile al termine dell'operazione. Per ottenere i risultati migliori, progetta il tuo sito web o la tua app con l'accessibilità durante l'intero processo e incorpora questi test insieme agli altri test pre-lancio.

Verificare di aver compreso

Verifica le tue conoscenze sui test di accessibilità automatica