Test dell'accessibilità automatici

Finora in questo corso hai appreso cosa sono i singoli, le aziende aspetti legali dell'accessibilità digitale e le nozioni di base dell'accessibilità digitale la conformità. Hai esplorato argomenti specifici relativi al design inclusivo e programmazione, tra cui quando utilizzare ARIA rispetto a HTML, come misurare il contrasto di colore quando JavaScript è essenziale, tra gli altri argomenti.

Nei restanti moduli, passiamo dalla progettazione e dalla creazione ai test per l'accessibilità. Utilizzeremo un processo di test in tre fasi che include strumenti e tecniche di test automatici, manuali e delle tecnologie per la disabilità. Lo faremo usa la stessa demo in tutti questi moduli di test per far avanzare la pagina web inaccessibili ad accessibili.

Ogni test (automatico, manuale e con tecnologie per la disabilità) è fondamentale per raggiungere il prodotto più accessibile possibile.

I nostri test si basano sulle linee guida per l'accessibilità dei contenuti web (WCAG) 2.1 i livelli di conformità A e AA dei nostri standard. Ricorda che il settore, il tipo di prodotto, le leggi locali/paese e o gli obiettivi generali di accessibilità stabiliranno quali linee guida seguire e i livelli da raggiungere. Se non hai bisogno di uno standard specifico per il tuo è consigliabile seguire l'ultima versione delle WCAG. Fai riferimento a "Come viene misurata l'accessibilità digitale?" per informazioni generali su controlli di accessibilità, tipi/livelli di conformità, le WCAG e POUR.

Come è noto, la conformità all'accessibilità non costituisce un quadro completo quando si occupa di aiutare le persone con disabilità. È però un buon punto di partenza perché fornisce una metrica su cui eseguire il test. Ti invitiamo a prendere Altre azioni oltre ai test di conformità dell'accessibilità, come eseguire test di usabilità su persone con disabilità, assumendo persone con disabilità per lavorare nel tuo team o consultare un privato o un'azienda con competenze nell'accessibilità digitale per aiutarti a creare prodotti più inclusivi.

Nozioni di base sui test automatici

I test automatici di accessibilità utilizzano un software per scansionare il tuo prodotto digitale alla ricerca di problemi di accessibilità rispetto agli standard di conformità dell'accessibilità predefiniti.

Vantaggi dei test di accessibilità automatici:

• Test facili da ripetere in diverse fasi del ciclo di vita del prodotto
• Pochi passaggi per correre e risultati molto rapidi
• Sono necessarie poche conoscenze di accessibilità per eseguire i test o comprendere i risultati

Svantaggi dei test automatici di accessibilità:

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

I test automatici sono un ottimo primo passo per verificare se il tuo sito web o la tua app accessibilità, ma non tutti i controlli possono essere automatizzati. Le vedremo in dettaglio su come verificare l'accessibilità di elementi che non possono essere automatizzati nel Modulo di test dell'accessibilità manuale.

Tipi di strumenti automatizzati

Uno dei primi strumenti automatizzati per i test dell'accessibilità online è stato sviluppato 1996 dal Center for Applied Special Technology (CAST), chiamato "Il rapporto Bobby." Oggi, ci sono più di 100 strumenti per i test automatici tra cui scegliere da!

L'implementazione degli strumenti automatici varia da un'estensione del browser per l'accessibilità a linter di codice, applicazioni desktop e mobile, dashboard online e API open source che puoi usare 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à vengono sottoposti a test? Questo può includono WCAG 2.1, WCAG 2.0, Sezione 508 o un elenco modificato di regole di accessibilità.
• Che tipo di prodotto digitale stai testando? Potrebbe essere un sito web, app, app mobile nativa, PDF, kiosk o altri prodotti.
• 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 i privati, o un'azienda?
• Chi sta conducendo il test: progettisti, sviluppatori, QA e così via?
• Con quale frequenza vuoi che venga controllata l'accessibilità? Dettagli incluse nel report? I problemi devono essere direttamente collegati alla vendita di biglietti in un file system?
• Quali strumenti funzionano meglio nel tuo ambiente? Per il tuo team?

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

Demo: test automatico

Per la demo dei test di accessibilità automatici, utilizzeremo Lighthouse. Lighthouse è uno strumento automatizzato open source creato per migliorare la qualità pagine web tramite diversi tipi di controlli, tra cui rendimento, SEO e accessibilità.

La nostra demo è un sito web creato per un'organizzazione fittizia, i Medical Mysteries Club. Questo sito è stato intenzionalmente reso inaccessibile per la demo. Alcuni di questi l'inaccessibilità potrebbe essere visibile a te e alcuni (ma non tutti) li bloccheranno. il nostro test automatico.

Passaggio 1

Utilizzando il browser Chrome, installa l'app Estensione Lighthouse.

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

Passaggio 2

Abbiamo creato una demo in CodePen. Visualizzala in modalità di debug per procedere con i prossimi test. Questo è importante, poiché rimuove il parametro <iframe> che circonda il componente una pagina web demo, che potrebbe interferire con alcuni strumenti di test. Scopri di più su Modalità di debug di CodePen.

Passaggio 3

Apri Chrome DevTools e vai alla scheda Lighthouse. Deseleziona tutte le opzioni per le categorie tranne che "Accessibilità." Mantieni la modalità predefinita e scegli il tipo di dispositivo su cui si eseguono i test.

Passaggio 4

Fai clic su "Analizza caricamento pagina" e concedi a Lighthouse il tempo di eseguire i test.

Una volta completati i test, Lighthouse visualizza un punteggio che misura il modo in cui accessibile il prodotto che stai testando. La Punteggio Lighthouse viene calcolato in base al numero di problemi, ai tipi di problemi e all'impatto sugli utenti di i problemi rilevati.

Oltre a un punteggio, il report Lighthouse include informazioni dettagliate su cosa rilevati dai problemi rilevati e link alle risorse per scoprire di più su come risolverli che li rappresentano. Il report include anche i test superati o non applicabili e una elenco di voci aggiuntive da controllare manualmente.

Passaggio 5

Vediamo ora un esempio di ogni problema di accessibilità automatica. individuati e correggi gli stili e il markup pertinenti.

Problema 1: ruoli ARIA

Il primo problema riguarda gli elementi con un [ruolo] ARIA che richiedono a bambini e ragazzi di contengono un [role] specifico, non dispongono di alcuni o di tutti i figli obbligatori. Alcuni ruoli principali ARIA devono contenere ruoli figlio specifici per 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.

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

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

Problema 2: ARIA nascosta

Gli elementi "[aria-hidden="true"] contengono discendenti attivabili. Attivabile i discendenti all'interno di un elemento [aria-hidden="true"] impediscono quelle di essere disponibili agli utenti di tecnologie per la disabilità come lettori. 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 è stato applicato un attributo aria-hidden="true". Aggiunta in corso... questo attributo nasconde l'elemento (e tutto ciò che è nidificato al di sotto) tecnologie per la disabilità.

<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 utilizzando tecnologie per la disabilità per 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 è un nome accessibile, gli screen reader lo descrivono come "pulsante", rendendolo inutilizzabile 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 in issue 1, la parola "Abbonati" diventa il pulsante accessibile nome. Questa funzionalità è incorporata nell'elemento pulsante HTML semantico. Là sono 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 devono avere come obiettivo per formare un breve testo alternativo descrittivo. Gli elementi decorativi possono essere ignorati con un attributo alt vuoto. Scopri di più sul testo alternativo dell'immagine .

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

Risolviamo il problema.

Poiché anche l'immagine del logo è un link, modulo immagine in modo che sia chiamato immagine e richiede informazioni di testo alternative sullo scopo dell'immagine. Solitamente, la prima immagine sulla pagina è un logo, quindi si può ragionevolmente supporre i tuoi utenti AT lo sanno e puoi decidere di non aggiungere 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 dei link

I link non hanno un nome distinguibile. Testo del link (e testo alternativo per le immagini, se utilizzati come link) che sia distinguibile, univoco e attivabile migliora il esperienza di navigazione per gli utenti di screen reader. Scopri di più sulle regole relative al testo dei link.

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

Risolviamo il problema.

Tutte le immagini interattive sulla pagina devono includere informazioni sul punto il link indirizzerà gli utenti. Un metodo per risolvere il problema è aggiungere un'alternativa all'immagine sullo scopo, come hai fatto per l'immagine del logo nella dell'esempio precedente. Questo è ottimo per un'immagine che utilizza un tag <img>, ma <svg> non possono utilizzare questo metodo.

Per le icone dei social media, che utilizzano tag <svg>, puoi utilizzare un pattern descrizione alternativo diverso scegliere come target gli SVG, aggiungi le informazioni tra i tag <a> e <svg>, quindi nasconderlo visivamente agli utenti, aggiungere un elemento ARIA supportato o altre opzioni. A seconda alle restrizioni del codice e dell'ambiente, un metodo potrebbe essere preferibile rispetto a un'altra. Usiamo l'opzione di pattern più semplice con il modello tecnologia, che aggiunge un role="img" al tag <svg> e incluso 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 riportati due esempi.

di Gemini Advanced.

.

.

Risolviamo il problema.

Nella 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 per il testo di grandi dimensioni (con grassetto da almeno 18 pt / 24 px o 14 pt / 18,5 px) Le icone essenziali devono soddisfare il requisito 3:1.

Per il titolo della pagina, il testo verde acqua deve rispettare il contrasto di 3:1. poiché si tratta di testo di grandi dimensioni a 24 px. Tuttavia, i pulsanti verde acqua considerato testo di dimensioni normali in grassetto da 16 px, quindi devono rispettare il colore 4,5:1 requisito di contrasto.

In questo caso, potremmo trovare un colore verde acqua che era abbastanza scuro da soddisfare le esigenze di 4, 5:1. 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 rimarranno in linea con il design dell'estetica.

Anche tutto il testo grigio sullo sfondo bianco non funziona per il contrasto di colore, ad eccezione di per le due intestazioni più grandi nella pagina. Questo testo deve essere oscurato per soddisfare i requisiti di contrasto di colore 4,5:1.

di Gemini Advanced.

.

.

Questione n. 7 - Struttura dell'elenco

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 all'interno di un elemento padre <ul> o <ol> 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é utilizzando un tag <ul>. Quando abbiamo scritto questo codice in modo improprio, abbiamo rimosso le le funzionalità HTML semantiche integrate in questo tag. Sostituendo il corso con uno <ul> e modificando il CSS correlato, risolviamo il 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>

Questione 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 valida, spesso questo crea esperienze frustranti per gli utenti che si affidano a 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 vi sia un motivo specifico per interrompere l'ordine delle schede naturale su un sito web non è necessario avere un numero intero positivo su un attributo tabindex. A mantenere l'ordine di tabulazione naturale, possiamo cambiare il tabindex in 0 oppure rimuovere completamente l'attributo.

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

Passaggio 6

Ora che hai risolto tutti i problemi di accessibilità automatici, apri un nuovo modalità di debug. Esegui di nuovo il controllo dell'accessibilità di Lighthouse. Il tuo punteggio dovrebbe essere molto meglio rispetto alla prima esecuzione.

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

Passaggio successivo

Ottimo lavoro. Hai già fatto moltissimo, ma non abbiamo ancora finito. Poi, passeremo ai controlli manuali, come descritto in Modulo di test dell'accessibilità manuale.

Verifica le tue conoscenze

Verifica le tue conoscenze dei test automatici di accessibilità