Test dell'accessibilità automatici

Finora in questo corso hai appreso gli aspetti individuali, aziendali e legali dell'accessibilità digitale e le nozioni di base della conformità dell'accessibilità digitale. Hai esplorato argomenti specifici relativi al design inclusivo e alla programmazione, tra cui, ad esempio, quando utilizzare ARIA e HTML, come misurare il contrasto dei colori, quando JavaScript è essenziale.

Nei restanti moduli, passiamo dalla progettazione e dalla creazione ai test per l'accessibilità. Utilizzeremo una procedura di test in tre fasi che include strumenti e tecniche di test automatici, manuali e per le tecnologie per la disabilità. Utilizzeremo la stessa demo in tutti questi moduli di test per far passare la pagina web da inaccessibile ad accessibile.

Ogni test, che prevede tecnologie automatizzate, manuali e per la disabilità, è fondamentale per ottenere il prodotto più accessibile possibile.

I nostri test si basano sul livello di conformità A e AA delle linee guida per l'accessibilità dei contenuti web (WCAG) 2.1. Ricorda che le linee guida da seguire e i livelli da rispettare saranno determinati in base al settore, al tipo di prodotto, alle leggi e alle norme locali o nazionali o agli obiettivi generali di accessibilità. Se non hai bisogno di uno standard specifico per il tuo progetto, si consiglia di seguire l'ultima versione delle WCAG. Consulta di nuovo la sezione "Come viene misurata l'accessibilità digitale?" per informazioni generali su controlli dell'accessibilità, tipi/livelli di conformità, WCAG e POUR.

Come ora sai, la conformità all'accessibilità non è la questione più completa quando si tratta di supportare le persone con disabilità. Tuttavia, è un buon punto di partenza in quanto fornisce una metrica su cui eseguire il test. Ti invitiamo a intraprendere ulteriori azioni oltre ai test di conformità all'accessibilità, come eseguire test di usabilità con persone con disabilità, assumere persone con disabilità per lavorare nel tuo team o consultare una persona o un'azienda con competenze di accessibilità digitale per aiutarti a creare prodotti più inclusivi.

Nozioni di base sui test automatici

I test automatici di accessibilità utilizzano software per analizzare il prodotto digitale alla ricerca di problemi di accessibilità rispetto a standard di conformità predefiniti.

Vantaggi dei test di accessibilità automatici:

• Test facili da ripetere in diverse fasi del ciclo di vita del prodotto
• Bastano pochi passaggi per eseguire l'operazione e risultati rapidissimi
• Per eseguire i test o comprendere i risultati è necessaria poca conoscenza dell'accessibilità

Svantaggi dei test di accessibilità automatici:

• Gli strumenti automatici non rilevano tutti gli errori di accessibilità nel tuo prodotto
• Sono stati segnalati falsi positivi (viene segnalato un problema che non è una vera violazione delle WCAG)
• Potrebbero essere necessari più strumenti per i diversi tipi di prodotto e ruoli

I test automatici sono un ottimo primo passo per verificare l'accessibilità del tuo sito web o della tua app, ma non tutti i controlli possono essere automatizzati. Approfondiremo come verificare l'accessibilità degli elementi che non possono essere automatizzati nel modulo dei test di accessibilità manuali.

Tipi di strumenti automatizzati

Uno dei primi strumenti automatici per i test di accessibilità online è stato sviluppato nel 1996 dal Center for Applied Special Technology (CAST), chiamato "The Bobby Report". Oggi è possibile scegliere più di 100 strumenti di test automatici.

L'implementazione di strumenti automatizzati varia da estensioni del browser di accessibilità ai linter di codice, applicazioni desktop e mobile, dashboard online e persino API open source che puoi utilizzare per creare i tuoi strumenti automatizzati.

Lo strumento automatico che decidi di utilizzare può dipendere da molti fattori, tra cui:

• A quali standard e livelli di conformità stai eseguendo il test? Potrebbero essere inclusi le WCAG 2.1, WCAG 2.0, U.S. Section 508 o un elenco modificato di regole di accessibilità.
• Che tipo di prodotto digitale stai testando? ad esempio un sito web, un'app web, un'app mobile nativa, un PDF, un kiosk o un altro prodotto.
• Quale parte del ciclo di vita dello sviluppo del software stai testando il tuo prodotto?
• Quanto tempo occorre per configurare e utilizzare lo strumento? Per un privato, un team o un'azienda?
• Chi sta conducendo il test: designer, sviluppatori, QA e così via?
• Con quale frequenza vuoi che venga controllata l'accessibilità? Quali dettagli devono essere inclusi nel rapporto? I problemi devono essere direttamente collegati a un sistema di gestione delle richieste di assistenza?
• Quali strumenti funzionano meglio nel tuo ambiente? Per il tuo team?

Esistono anche molti altri fattori da considerare. Consulta l'articolo di WAI su "Selezionare gli strumenti di valutazione dell'accessibilità web" per ulteriori informazioni su come scegliere lo strumento migliore per te e il tuo team.

Demo: test automatico

Per la demo dei test automatici dell'accessibilità, utilizzeremo Lighthouse di Chrome. Lighthouse è uno strumento automatizzato e open source creato per migliorare la qualità delle pagine web tramite diversi tipi di controlli, come prestazioni, SEO e accessibilità.

La nostra demo è un sito web creato per un'organizzazione fittizia, il Medical Mysteries Club. Questo sito è stato reso intenzionalmente inaccessibile per la demo. Parte di questa inaccessibilità potrebbe essere visibile a te, mentre alcune (ma non tutte) saranno rilevate nel nostro test automatico.

Passaggio 1

Utilizzando il browser Chrome, installa l'estensione Lighthouse.

Esistono diversi modi per integrare Lighthouse nel flusso di lavoro di test. Per questa demo utilizzeremo l'estensione di Chrome.

Passaggio 2

Abbiamo creato una demo in CodePen. 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 3

Apri Chrome DevTools e vai alla scheda Lighthouse. Deseleziona tutte le opzioni di categoria, tranne "Accessibilità". Mantieni la modalità come predefinita e scegli il tipo di dispositivo su cui stai eseguendo i test.

Passaggio 4

Fai clic sul pulsante "Analizza caricamento pagina" e lascia a Lighthouse il tempo di eseguire i test.

Una volta completati i test, Lighthouse mostra un punteggio che misura l'accessibilità del prodotto che stai testando. Il punteggio di Lighthouse viene calcolato in base al numero di problemi, ai tipi di problemi e all'impatto dei problemi rilevati sugli utenti.

Oltre a un punteggio, il report Lighthouse include informazioni dettagliate sui problemi rilevati e link a risorse per saperne di più su come risolverli. Il report include anche i test superati o non applicabili e un elenco di elementi aggiuntivi da controllare manualmente.

Passaggio 5

Ora analizziamo un esempio di ogni problema di accessibilità automatico rilevato e correggiamo gli stili e i markup pertinenti.

Problema 1: ruoli ARIA

Il primo problema afferma: "Gli elementi con un [ruolo] ARIA che richiedono ai bambini di contenere un [ruolo] specifico mancano alcuni o tutti questi elementi secondari obbligatori. Alcuni ruoli principali ARIA devono contenere ruoli secondari specifici per eseguire le relative funzioni di accessibilità previste." Scopri di più sulle regole dei ruoli ARIA.

Nella nostra demo, il pulsante di iscrizione alla newsletter non funziona:

<button role="list" type="submit" tabindex="1">Subscribe</button>

Risolviamo il problema.

Al pulsante "Iscriviti" accanto al campo di immissione è stato applicato un ruolo ARIA errato. In questo caso, il ruolo può essere rimosso completamente.

<button type="submit" tabindex="1">Subscribe</button>

Problema 2: ARIA nascosto

Gli elementi "[aria-hidden="true"] contengono discendenti attivabili. I discendenti attivabili all'interno di un elemento [aria-hidden="true"] impediscono a questi elementi interattivi di essere disponibili per gli utenti di tecnologie per la disabilità come gli screen reader. Scopri di più sulle regole aria-hidden.

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>

Risolviamo il problema.

Al campo di immissione era applicato un attributo aria-hidden="true". L'aggiunta di questo attributo nasconde l'elemento (e tutti gli elementi nidificati) alla tecnologia assistiva.

<input type="email" placeholder="Enter your e-mail address" tabindex="-1" required>

In questo caso, devi rimuovere questo attributo dall'input per consentire alle persone che utilizzano le tecnologie per la disabilità di accedere alle informazioni e inserirle nel campo del modulo.

Problema 3: nome del pulsante

I pulsanti non hanno un nome accessibile. Quando un pulsante non ha un nome accessibile, gli screen reader lo descrivono come "pulsante", rendendolo inutilizzabile per gli utenti che si affidano agli screen reader. Scopri di più sulle regole per i nomi dei pulsanti.

<button role="list" type="submit" tabindex="1">Subscribe</button>

Risolviamo il problema.

Quando rimuovi il ruolo ARIA impreciso dall'elemento pulsante nel problema 1, la parola "Abbonati" diventa il nome del pulsante accessibile. Questa funzionalità è incorporata nell'elemento pulsante HTML semantico. Esistono ulteriori opzioni di pattern da prendere in considerazione per situazioni più complesse.

<button type="submit" tabindex="1">Subscribe</button>

Problema 4: attributi alt delle immagini

Negli elementi image mancano gli attributi [alt]. Gli elementi informativi dovrebbero mostrare testo alternativo breve e descrittivo. Gli elementi decorativi possono essere ignorati con un attributo ALT vuoto. Scopri di più sulle regole per il testo alternativo delle immagini.

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png">
</a>

Risolviamo il problema.

Poiché l'immagine del logo è anche un link, il modulo immagine è chiamato immagine interattiva e richiede informazioni di testo alternative relative allo scopo dell'immagine. Normalmente, la prima immagine della pagina è un logo, pertanto puoi ragionevolmente presumere che gli utenti di AT lo sappiano e potresti decidere di non aggiungere queste ulteriori informazioni contestuali alla descrizione dell'immagine.

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png"
    alt="Go to the home page.">
</a>

Problema 5: testo del link

Il nome dei link non è distinguibile. Un testo dei link (e il testo alternativo per le immagini, se utilizzate come link) distinguibile, univoco e attivabile migliora l'esperienza di navigazione per gli utenti di screen reader. Scopri di più sulle regole per il testo dei link.

<a href="#!"><svg><path>...</path></svg></a>

Risolviamo il problema.

Tutte le immagini interattive sulla pagina devono includere informazioni sulla posizione a cui il link indirizzerà gli utenti. Un metodo per risolvere il problema consiste nell'aggiungere all'immagine un testo alternativo relativo allo scopo, come hai fatto per l'immagine del logo nell'esempio precedente. Questo metodo funziona molto bene per un'immagine che utilizza un tag <img>, mentre i tag <svg> non possono utilizzare questo metodo.

Per le icone dei social media, che utilizzano i tag <svg>, puoi utilizzare un pattern di descrizione alternativo diverso per il targeting degli SVG, aggiungere le informazioni tra i tag <a> e <svg> e poi nasconderle visivamente agli utenti, aggiungere un ARIA supportato o altre opzioni. A seconda delle restrizioni in vigore relative all'ambiente e al codice, un metodo potrebbe essere preferibile rispetto a un altro. Utilizziamo l'opzione di pattern più semplice con la copertura della tecnologia più assistiva, che consiste nell'aggiungere un role="img" al tag <svg> e includere un elemento <title>.

<a href="#!">
  <svg role="img">
    <title>Connect on our Twitter page.</title>
    <path>...</path>
  </svg>
</a>

Problema 6: contrasto di colore

I colori di sfondo e in primo piano non hanno un rapporto di contrasto sufficiente. Il testo a basso contrasto è difficile, se non impossibile, da leggere per molti utenti. Scopri di più sulle regole per il contrasto di colore.

Sono stati segnalati due esempi.

Risolviamo il problema.

Sulla pagina web sono stati rilevati molti problemi di contrasto di colore. Come hai appreso nel modulo Colore e contrasto, il testo di dimensioni normali (meno di 18 pt / 24 px) ha un requisito di contrasto di colore di 4,5:1, mentre i testi di grandi dimensioni (almeno 18 pt / 24 px o 14 pt / 18,5 px di grassetto) e le icone essenziali devono soddisfare il requisito 3:1.

Per il titolo della pagina, il testo in colore verde acqua deve soddisfare il requisito relativo al contrasto di colore di 3:1, poiché si tratta di un testo di grandi dimensioni da 24 px. Tuttavia, i pulsanti verde acqua sono considerati testo di dimensioni normali in grassetto di 16 px, quindi devono soddisfare il requisito del contrasto dei colori di 4,5:1.

In questo caso, potremmo trovare un colore verde acqua abbastanza scuro da soddisfare 4,5:1 oppure potremmo aumentare le dimensioni del testo del pulsante impostandolo in grassetto di 18,5 px e modificare leggermente il valore del colore verde acqua. Entrambi i metodi rimarranno in linea con l'estetica del design.

Anche tutto il testo grigio sullo sfondo bianco non causa il contrasto di colore, ad eccezione delle due intestazioni più grandi nella pagina. Scurisci questo testo per soddisfare i requisiti per il contrasto di colore di 4,5:1.

Questione n. 7 - Struttura degli elenchi

Gli elementi dell'elenco (<li>) non sono contenuti negli elementi principali <ul> o <ol>. Gli screen reader richiedono che gli elementi dell'elenco (<li>) siano contenuti in un elemento <ul> o <ol> principale per essere annunciati correttamente.

Scopri di più sulle regole per gli elenchi.

<div class="ul">
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</div>

Risolviamo il problema.

In questa demo abbiamo utilizzato una classe CSS per simulare l'elenco non ordinato anziché utilizzare un tag <ul>. Quando abbiamo scritto questo codice in modo errato, abbiamo rimosso le caratteristiche semantiche dell'HTML integrate in questo tag. Sostituendo il corso con un tag <ul> reale e modificando il CSS correlato, risolviamo questo problema di accessibilità.

<ul>
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</ul>

Problema n. 8: tabindex

Alcuni elementi hanno un valore [tabindex] maggiore di 0. Un valore maggiore di 0 implica un ordine di navigazione esplicito. Sebbene sia tecnicamente valido, questo spesso crea esperienze frustranti per gli utenti che si affidano alle tecnologie per la disabilità. Scopri di più sulle regole Tabindex.

<button type="submit" tabindex="1">Subscribe</button>

Risolviamo il problema.

A meno che non ci sia un motivo specifico per interrompere l'ordine naturale di tabulazione in una pagina web, non è necessario avere un numero intero positivo in un attributo tabindex. Per mantenere l'ordine di tabulazione naturale, possiamo modificare il valore tabindex in 0 o rimuovere completamente l'attributo.

<button type="submit">Subscribe</button>

Passaggio 6

Ora che hai risolto tutti i problemi di accessibilità automatica, apri una nuova pagina della modalità di debug. Esegui di nuovo il controllo dell'accessibilità di Lighthouse. Il tuo punteggio dovrebbe essere molto migliore rispetto alla prima esecuzione.

Abbiamo applicato tutti questi aggiornamenti automatici dell'accessibilità a un nuovo CodePen.

Passaggio successivo

Eccezionale. Hai già raggiunto molti obiettivi, ma non abbiamo ancora finito. Successivamente, passeremo ai controlli manuali, come descritto nel modulo Test dell'accessibilità manuale.

Verifica la tua comprensione

Verifica le tue conoscenze dei test di accessibilità automatici