Test dell'accessibilità automatici

Finora in questo corso hai imparato gli aspetti individuali, commerciali e legali dell'accessibilità digitale, nonché le nozioni di base della conformità all'accessibilità digitale. Hai esplorato argomenti specifici relativi alla progettazione e alla programmazione inclusiva, tra cui quando utilizzare ARIA anziché HTML, come misurare il contrasto cromatico e quando JavaScript è essenziale.

Nei moduli rimanenti, passiamo dalla progettazione e dalla creazione ai test di accessibilità. Condividiamo un processo di test in tre fasi che include strumenti e tecniche di test automatizzati, manuali e di tecnologia assistiva. Utilizzeremo la stessa demo in tutti questi moduli di test per rendere la pagina web da inaccessibile ad accessibile.

Ogni test, automatico, manuale e con tecnologia assistiva, è fondamentale per ottenere il prodotto più accessibile possibile. I nostri test si basano sui livelli di conformità A e AA delle Web Content Accessibility Guidelines (WCAG) 2.1 come standard.

Tieni presente che il settore, il tipo di prodotto, le leggi e le norme locali e nazionali o gli obiettivi di accessibilità generali determinano quali linee guida seguire e quali livelli raggiungere. Se non richiedi uno standard specifico per il tuo progetto, ti consigliamo di seguire l'ultima versione delle WCAG. Consulta la sezione "Come viene misurata l'accessibilità digitale?" per informazioni generali su audit di accessibilità, tipi/livelli di conformità, WCAG e POUR.

Come ormai saprai, la conformità all'accessibilità non è tutto ciò che serve per supportare le persone con disabilità. Tuttavia, è un buon punto di partenza perché fornisce una metrica da testare. Ti invitiamo ad adottare le seguenti misure, oltre ai test di conformità, per creare prodotti più inclusivi:

• Esegui test di usabilità con persone con disabilità.
• Assumi persone con disabilità nel tuo team.
• Rivolgiti a un privato o a un'azienda con competenze in materia di accessibilità digitale.

Nozioni di base sui test automatici

I test di accessibilità automatizzati utilizzano un software per analizzare il tuo prodotto digitale alla ricerca di problemi di accessibilità in base a standard di conformità all'accessibilità predefiniti.

Vantaggi dei test di accessibilità automatizzati:

• Ripeti rapidamente i test in diverse fasi del ciclo di vita del prodotto.
• Bastano pochi passaggi per eseguirlo e i risultati sono molto rapidi.
• Per eseguire i test o comprendere i risultati, non sono necessarie conoscenze approfondite sull'accessibilità.

Svantaggi dei test automatici di accessibilità:

• Gli strumenti automatizzati non rilevano tutti gli errori di accessibilità nel tuo prodotto
• Falsi positivi segnalati (un problema segnalato che non è una vera violazione delle WCAG)
• Per diversi tipi di prodotti e ruoli potrebbero essere necessari più strumenti

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. Esamineremo più in dettaglio come controllare l'accessibilità degli elementi che non possono essere automatizzati nel modulo Test di accessibilità manuali.

Tipi di strumenti automatici

Uno dei primi strumenti di test automatici dell'accessibilità online è stato sviluppato nel 1996 dal Center for Applied Special Technology (CAST) e si chiamava "The Bobby Report". Oggi ci sono oltre 100 strumenti di test automatizzati tra cui scegliere.

L'implementazione di strumenti automatizzati varia dalle estensioni del browser per l'accessibilità ai linter di codice, alle applicazioni desktop e mobile, alle dashboard online e persino alle 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:

• Quali standard e livelli di conformità stai testando? Ciò può includere WCAG 2.2, WCAG 2.1, US Section 508 o un elenco modificato di regole di accessibilità.
• Che tipo di prodotto digitale stai testando? Può trattarsi di un sito web, un'app web, un'app mobile nativa, un PDF, un kiosk o un altro prodotto.
• In quale fase del ciclo di vita dello sviluppo del software stai testando il tuo prodotto?
• Quanto tempo è necessario per configurare e utilizzare lo strumento? Per un privato, un team o un'azienda?
• Chi esegue il test: designer, sviluppatori, QA o qualcun altro?
• Con quale frequenza vuoi che venga verificata l'accessibilità? Quali dettagli devono essere inclusi nel report? I problemi devono essere collegati direttamente a un sistema di gestione dei ticket?
• Quali strumenti funzionano meglio nel tuo ambiente? Per il tuo team?

Ci sono anche molti altri fattori da considerare. Per ulteriori informazioni su come selezionare lo strumento migliore per te e il tuo team, consulta l'articolo di WAI su "Selecting Web Accessibility Evaluation Tools".

Demo: test automatico

Per la demo del test di accessibilità automatizzato, utilizzeremo Lighthouse di Chrome. Lighthouse è uno strumento automatico open source creato per migliorare la qualità delle pagine web tramite diversi tipi di controlli, ad esempio 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. Alcune di queste inaccessibilità potrebbero essere visibili e alcune (ma non tutte) verranno rilevate dal nostro test automatizzato.

Passaggio 1

Utilizzando il browser Chrome, installa l'estensione Lighthouse.

Esistono molti modi per integrare Lighthouse nel flusso di lavoro di test. Per questa demo utilizziamo 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 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 3

Apri Chrome DevTools e vai alla scheda Lighthouse. Cancella tutte le opzioni della categoria tranne "Accessibilità". Mantieni la modalità predefinita e scegli il tipo di dispositivo su cui esegui i test.

Passaggio 4

Fai clic su 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 Lighthouse viene calcolato in base al numero di problemi, ai tipi di problemi e all'impatto sugli utenti dei problemi rilevati.

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 esamina un esempio di ogni problema di accessibilità automatizzato rilevato e correggi gli stili e il markup pertinenti.

Problema 1: ruoli ARIA

Il primo problema afferma: "Negli elementi con un ruolo ARIA [role] che richiedono che gli elementi secondari contengano un ruolo [role] specifico mancano alcuni o tutti questi elementi secondari obbligatori. Alcuni ruoli principali ARIA devono contenere specifici ruoli secondari per poter eseguire le funzionalità per l'accessibilità previste." Scopri di più sulle regole per i 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.

Il pulsante "Iscriviti" accanto al campo di input ha 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 per cui è possibile impostare lo stato attivo. I discendenti attivabili all'interno di un elemento [aria-hidden="true"] impediscono di mettere questi elementi interattivi a disposizione degli utenti che usano tecnologie per la disabilità come gli screen reader. Scopri di più sulle regole di aria-hidden.

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

Risolviamo il problema.

Al campo di input è stato applicato un attributo aria-hidden="true". L'aggiunta di questo attributo nasconde l'elemento (e tutto ciò che è nidificato al suo interno) dalla 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 tecnologie assistive di accedere e inserire informazioni 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 semplicemente 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 "Iscriviti" diventa il nome del pulsante accessibile. Questa funzionalità è integrata nell'elemento pulsante HTML semantico. Esistono altre opzioni di pattern da considerare per situazioni più complesse.

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

Problema 4: attributi ALT delle immagini

Negli elementi immagine 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, dal modulo immagine sai che si tratta di un'immagine interattiva e che richiede un testo alternativo che descriva lo scopo dell'immagine. Normalmente, la prima immagine della pagina è un logo, quindi puoi ragionevolmente presumere che gli utenti di tecnologie assistive lo sappiano e potresti decidere di non aggiungere queste informazioni contestuali aggiuntive 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

I link non hanno un nome distinguibile. Un testo dei link (incluso il testo alternativo delle immagini, se 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 del link.

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

Risolviamo il problema.

Tutte le immagini interattive della pagina devono includere informazioni sulla destinazione del link. Un modo per risolvere questo problema è aggiungere un testo alternativo all'immagine che ne descriva lo scopo, come hai fatto con l'immagine del logo nell'esempio. Questo metodo è ideale per un'immagine che utilizza un tag <img>, ma i tag <svg> non possono utilizzarlo.

Per le icone dei social media, che utilizzano i tag <svg>, puoi utilizzare un pattern di descrizione alternativa diverso che ha come target i file SVG, aggiungere le informazioni tra i tag <a> e <svg> e poi nasconderle visivamente agli utenti, aggiungere un attributo ARIA supportato o altre opzioni. A seconda dell'ambiente e delle limitazioni del codice, un metodo potrebbe essere preferibile a un altro.

Utilizza l'opzione di pattern più semplice con la copertura della tecnologia assistiva più ampia, ovvero l'aggiunta di un role="img" al tag <svg> e l'inclusione di un elemento <title>.

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

Problema 6: contrasto cromatico

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

Sono stati segnalati due esempi.

Risolviamo il problema.

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

Per il titolo della pagina, il testo color verde acqua deve soddisfare il requisito di contrasto cromatico 3:1, poiché si tratta di testo di grandi dimensioni a 24 px. Tuttavia, i pulsanti verde acqua sono considerati testo di dimensioni normali a 16 px in grassetto, pertanto devono soddisfare il requisito di contrasto di colore di 4,5:1.

In questo caso, potremmo trovare un colore verde acqua sufficientemente scuro da soddisfare il rapporto 4,5:1 oppure potremmo aumentare la dimensione del testo del pulsante a 18,5 px in grassetto e modificare leggermente il valore del colore verde acqua. Entrambi i metodi sono in linea con l'estetica del design.

Anche tutto il testo grigio su sfondo bianco non supera il test del contrasto di colore, ad eccezione dei due titoli più grandi della pagina. Questo testo deve essere scurito per soddisfare i requisiti di contrasto cromatico di 4,5:1.

Problema 7: struttura dell'elenco

Gli elementi dell'elenco (<li>) non sono contenuti in 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 poterli descrivere in modo corretto.

Scopri di più sulle regole degli 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 funzionalità HTML semantiche intrinseche integrate in questo tag. Sostituendo la classe 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 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, spesso genera un'esperienza frustrante per gli utenti che usano tecnologie per la disabilità. Scopri di più sulle regole di tabindex.

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

Risolviamo il problema.

A meno che non esista un motivo specifico per interrompere l'ordine di tabulazione naturale in una pagina web, non è necessario avere un numero intero positivo in un attributo tabindex. Per mantenere l'ordine di tabulazione naturale, possiamo modificare l'attributo tabindex in 0 o rimuoverlo del tutto.

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

Passaggio 6

Ora che hai risolto tutti i problemi di accessibilità automatizzati, apri una nuova pagina in 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

Ottimo lavoro. Hai già fatto molto, ma non abbiamo ancora finito. Successivamente, passeremo ai controlli manuali, come descritto nel modulo Test di accessibilità manuali.