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: supporti per testa e bocca, 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: pulsanti di attivazione/disattivazione, tastiere ergonomiche, dispositivo braille con aggiornamento automatico
• Software: programmi di sintesi vocale, sottotitoli codificati dal vivo, 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. Poi 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 è progettata in base a 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 completata la configurazione corretta del 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à utilizzato uno screen reader, ti consigliamo 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 l'utilizzo di un AT per testare il codice rispetto a un insieme di regole e chiedere agli utenti la 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 come 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 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

Intestazioni e punti di riferimento sono uno dei modi principali in cui le persone navigano utilizzando gli screen reader. Se non sono presenti, un 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 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 del 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 altre 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 schemi diversi che possiamo prendere in considerazione per aggiungere ulteriori informazioni sui link. Poiché il nostro ambiente supporta una sola lingua, in questa situazione un'etichetta ARIA è un'opzione semplice. 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 automatico, Lighthouse non è stato in grado di rilevare l'SVG in linea che funge da immagine di splash principale nella nostra pagina di 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

Potresti aver notato che lo screen reader legge l'immagine del punto elenco CSS nelle sezioni relative alle malattie rare. Anche se non è il tipo di immagine tradizionale discusso nel modulo Immagini, l'immagine 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 per l'esempio di immagine decorativa discusso in precedenza, puoi aggiungere un carattere 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 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 appreso che tutti i campi del modulo devono avere anche un'etichetta visiva e programmatica. Questa etichetta deve rimanere visibilie in qualsiasi 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. L'elemento dell'etichetta è collegato in modo programmatico al campo del modulo e il movimento è stato aggiunto con JavaScript per mantenere visibile l'etichetta 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 riscontrare. Tuttavia, ciò non significa che il tuo sito web o la tua app sia perfettamente accessibile al termine dell'operazione. Per ottenere il massimo risultato, progetta il tuo sito web o la tua app tenendo conto dell'accessibilità durante tutto il processo e integrando questi test con gli altri test pre-lancio.

Verificare di aver compreso

Metti alla prova le tue conoscenze sui test di accessibilità automatica.