ACCESSIBILITÀ PER SVILUPPATORI E TESTER QA
Panoramica
Questi documenti coprono tutte le fondamenta chiave del design e dovrebbero inoltre essere rivisti all'inizio di un progetto dal team. Coprono tutte le migliori pratiche chiave per l'accessibilità dei siti web che non sono correlate a un design di componente specifico. Come per molti dei documenti sui componenti, contengono test che il Project Manager può usare come criteri di accettazione per il QA e tecniche che gli Sviluppatori possono usare per soddisfare tali criteri.
Queste guide sono progettate per supportare qualsiasi sistema di design, incluso il Material Design, e possono anche essere utilizzate per supportare il design accessibile per piattaforme di terze parti come Wordpress, SAP e Salesforce, e come tali possono essere usate in ogni sprint di qualsiasi progetto.
Ulteriore formazione e consigli sull'accessibilità possono essere trovati sui seguenti canali Youtube:
1. Creazione di componenti accessibili
Quando si sviluppano nuovi design di componenti possono sorgere problemi di accessibilità che non sono coperti dalle linee guida sull'accessibilità perché sono specifici di un particolare design di interazione.
In questi casi è necessaria una ricerca aggiuntiva per identificare le migliori pratiche disponibili altrove sul web, quindi la pagina seguente ti fornirà un elenco di componenti che necessitano di ulteriori ricerche e delle tecniche e metodologie che puoi utilizzare per garantire che il tuo componente soddisfi le aspettative degli utenti.
Quando appropriato, i documenti di orientamento contengono implementazioni di riferimento che dimostrano i comportamenti di codice richiesti e forniscono test di QA raccomandati.
Test
Per consentire ai team di integrare criteri di test nel loro piano di lavoro, il seguente script di test per l'accessibilità aiuterà sia i Project Manager che gli Sviluppatori a raggiungere i criteri di successo per l'accessibilità. Sono disponibili anche test automatizzati tramite UTS Test Magic, Cypress, Sa11y per Salesforce e dovrebbero essere usati in combinazione con il seguente script di test manuale: Script di test per sviluppatori Colt.
Per testare l'accessibilità con screen reader, usa Windows Narrator per verificare l'accessibilità del tuo componente o applicazione. La guida Using Windows Narrator to Test Web Accessibility delinea i controlli, l'approccio e i numeri previsti.
Le pagine web possono essere testate parzialmente utilizzando plugin del browser. Esistono diversi strumenti commerciali e non commerciali che funzionano in Microsoft Edge e Google Chrome. Uno affidabile, gratuito e che produce fogli di calcolo utilizzabili per tracciare i bug è l'Equal Access Tracker di IBM:
Diversi strumenti di test automatizzati possono dare risultati differenti, alcuni sono commerciali o semi-commerciali e non tutti generano report. Assicurati che tutti i membri del team prodotto stiano usando lo stesso strumento.
Usato in combinazione con i test manuali nelle linee guida e i test con Windows Narrator, la maggior parte dei problemi di accessibilità d'uso sarà facile da individuare e correggere.
Questa panoramica di Sparkbox copre tutte le funzionalità chiave dello strumento di test IBM.
Guide per i componenti
Le seguenti guide di migliori pratiche sono tratte da vari sistemi di design, blog o risorse documentali di terze parti affidabili e, sebbene i design possano non essere esattamente gli stessi di quelli implementati da Colt, le metodologie e le tecniche sono comunque un modo valido per comprendere eventuali problemi e le loro soluzioni.
Navigazione
Contenuti interattivi
Campi meta
Inserimento dati
2. Accessibilità della piattaforma
Se stai creando pagine web, app o componenti su una piattaforma o framework di terze parti come Salesforce, SAP o Wordpress, ciascuna di queste piattaforme fornisce indicazioni specifiche per tali piattaforme. Queste dovrebbero essere utilizzate in aggiunta alle Guide di accessibilità Colt.
Wordpress
Salesforce
SAP
3. Percezione dei colori
Ogni colore è percepito in modo leggermente e talvolta significativamente diverso da persone diverse, e molte persone non riescono a distinguere affatto tra alcune sfumature. Assicurarsi che i design delle pagine web di Colt non dipendano dalla percezione accurata dei colori significa che nessuno verrà escluso perché alcune funzionalità si basano sul colore nel design.
Un uso attento dei colori del brand Colt, tuttavia, può aumentare l'accessibilità per alcuni utenti e migliorare l'usabilità per molti utenti. Quindi, piuttosto che evitare un significato basato sul colore in una pagina web, assicurati che quando il colore è usato come indicatore visivo vengano forniti anche indicatori visivi alternativi non basati sul colore. Questo è spesso definito nel design e nell'ingegneria come 'ridondanza.'
La deficienza della visione rosso-verde è la forma più comune delle cosiddette disfunzioni del daltonismo. Colpisce circa 1 uomo su 12 e 1 donna su 200. La deficienza della percezione blu-giallo è molto meno comune, e il daltonismo monocromatico è ancora più raro. Esistono anche altre condizioni come Sineddoche, Glaucoma, Sindrome di Irlen e alcune persone con ASC che possono creare problemi per le persone nel processare i colori.
Come testare questo
Per ogni pagina web, esegui i seguenti controlli. Registra una risposta, "sì" o "no" a ciascuna domanda. Il risultato di superamento è indicato in maiuscolo dopo ogni domanda, ad esempio [Y/N] dove Y è richiesto per superare. Per ogni risultato non superato, documentalo come uno dei seguenti:
Come difetto
Un difetto, ma con una spiegazione del perché dovrebbe essere consentito come eccezione
Un difetto, ma con una spiegazione del perché non è applicabile
Test che dovrebbero essere eseguiti manualmente
Di seguito sono riportati un paio di esempi di domande chiave che dovresti porre:
Considerando ciascuno dei link nella pagina, sono tutti visivamente identificabili senza usare il colore? [Y/N]
Interagendo con ciascuna delle funzionalità nella pagina (come convalide o indicatori di avanzamento), è possibile sapere in quale stato si trova ciascuna, anche con il colore disabilitato? [Y/N]
Per quanto riguarda grafici e diagrammi, le categorie o i dataset visualizzati nel grafico sono indicati con un trattamento visivo diverso dal colore? [Y/N]
Metodi e strategie di test aggiuntivi
Se non sei daltonico, puoi testare una pagina web con un simulatore di daltonismo. L'app Sim Daltonism può essere installata sul tuo telefono cellulare e aprirà un visualizzatore che applicherà un filtro per il daltonismo a tutto ciò che è davanti alla fotocamera.
4. Interazioni con i moduli
I moduli possono essere impegnativi per gli utenti con disabilità visive e/o cognitive. Assicurarsi che i moduli siano ben progettati e accessibili significa garantire che gli utenti comprendano e utilizzino quei moduli come previsto.
Quando i moduli web applicano convenzioni e buone pratiche di usabilità, gli utenti sono in grado di completare i moduli più rapidamente e con meno errori al primo tentativo. I moduli possono essere porte d'accesso ai contenuti e ai servizi di Colt tramite il login, opportunità di impiego, il passaggio finale per diventare cliente o anche l'unico modo per segnalare un problema o un reclamo. Se i moduli sono progettati o implementati male, escludono completamente gli utenti con disabilità.
Come testare questo
Per ogni pagina web, esegui i seguenti controlli. Registra una risposta, "sì" o "no" a ciascuna domanda. Il risultato di superamento è indicato in maiuscolo dopo ogni domanda, ad esempio [Y/N] dove Y è richiesto per superare. Per ogni risultato non superato, documentalo come uno dei seguenti:
Come difetto
Un difetto, ma con una spiegazione del perché dovrebbe essere consentito come eccezione
Un difetto, ma con una spiegazione del perché non è applicabile
Test che potrebbero essere automatizzati
Di seguito è riportato un esempio di test che non richiede la scansione manuale:
Ogni elemento di input ha un elemento label HTML semanticamente valido associato? [Y/N]
Test che dovrebbero essere eseguiti manualmente
Di seguito sono riportati un paio di esempi di domande chiave che dovresti porre:
L'intero modulo può essere compilato, incluse le correzioni di eventuali errori, e inviato usando solo la tastiera? [Y/N]
L'ordine di tabulazione attraverso il modulo (come mostrato da un indicatore di messa a fuoco visibile) è logico e prevedibile per un utente vedente che usa la tastiera? [Y/N]
I campi di input obbligatori sono visivamente contrassegnati come tali, e usano un attributo HTML input required sull'elemento di input? [Y/N]
I messaggi di errore sono scritti e mostrati in modo da rendere chiaro quali campi di input hanno rifiutato i dati, perché i dati non sono stati accettati e cosa fare per correggerli? [Y/N]
Ripristini, tempi & convalida
Pulsanti di ripristino
Evita di usare un Pulsante di Ripristino nei moduli. Sono raramente usati e può essere esasperante vedere un intero modulo compilato cancellato con un solo clic accidentale. Nota che senza un pulsante di ripristino, i gruppi di radio button possono essere un problema in alcuni casi. Una delle loro caratteristiche è che non puoi "deselezionare" il gruppo una volta che è stata selezionata un'opzione; puoi solo spostare la selezione su un altro radio button dello stesso gruppo. Per questo motivo, si raccomanda di includere un'opzione del tipo "nessuna delle precedenti" quando appropriato.
Tempi
I moduli che scadono troppo presto possono essere frustranti, specialmente se il processo è stato lungo, come inserire una specifica per un preventivo o candidarsi per un lavoro. Se non vi è una necessità specifica di avere un timeout su un modulo, assicurati che i dati siano conservati per almeno 20 ore. Se deve esserci un timeout, assicurati che sia almeno 5 volte più lungo del tempo necessario a un utente vedente medio e che i tempi siano comunicati nelle istruzioni.
Convalida
Quando si convalida un modulo, assicurati che il valore originale inserito dall'utente che ha causato l'errore non venga cancellato. Preservando il valore originale dell'utente, l'utente può identificare più facilmente l'errore e poi correggerlo modificandolo. L'uso degli attributi WAI-ARIA può aiutare a rendere gli errori di convalida più facili da seguire per gli utenti di tecnologie assistive. Usa l' attributo aria-invalid per contrassegnare ogni campo di input non valido come avente un errore, e l' attributo aria-describedby per associare il messaggio di errore specifico a quel campo di input.
Messaggi di errore
Quando i messaggi di errore non vengono visualizzati affatto, ciò dovrebbe essere considerato un difetto grave. Quando l'invio di un modulo viene rifiutato e non c'è feedback che spieghi cosa deve essere corretto per continuare, il modulo diventa inutilizzabile.
I messaggi di errore dovrebbero essere concisi e specifici nel spiegare perché l'invio del modulo è stato rifiutato e dovrebbero evitare di includere lunghe stringhe di gergo tecnico. Eventuali codici di errore dovrebbero essere spiegati in modo non tecnico.
Verifica che tutti i messaggi di errore che possono essere visualizzati soddisfino i seguenti requisiti:
Specifico: Dire semplicemente "si è verificato un errore" o "il modulo non è valido" non è utile. Il messaggio dovrebbe indicare chiaramente quale campo di input, o quali campi se ce ne sono più di uno, era non valido e perché è stato rifiutato. Il nome del campo di input nel messaggio di errore dovrebbe corrispondere esattamente all'etichetta del campo di input dove si è verificato l'errore.
Amichevole: Anche se l'utente ha commesso un errore, l'esperienza dovrebbe risultare utile. Evita frasi che suonano aggressive, come "errore utente: input non valido" anche se tecnicamente corrette, poiché non creano una buona esperienza utente.
Azione consigliata: Comunicare che c'è un problema e quale sia è solo parte della risposta. L'utente deve anche sapere quali passaggi può intraprendere per risolvere il problema. Verifica che ci siano informazioni su cosa devono fare per procedere e, se necessario, fornisci un link alle FAQ e a un helpdesk.
Testo segnaposto
Queste sono parole che appaiono all'interno di un campo di input del modulo e sono pensate come un suggerimento opzionale. Non sono sostituti di etichette appropriate e non dovrebbero duplicare un'etichetta, ma fornire istruzioni o suggerimenti aggiuntivi.
I segnaposto che sostituiscono le etichette sono difficili da usare per gli utenti da tastiera perché non appena un utente tabula nel campo di testo le istruzioni scompaiono. Il contrasto del testo segnaposto è deliberatamente basso, il che è un'altra ragione per cui non sono sostituti delle etichette, e il testo segnaposto non può andare a capo, quindi su schermi stretti l'utente potrebbe non riuscire a vederlo per intero.
5. Accesso tramite tastiera
Sebbene esistano molti diversi tipi di tastiere (o dispositivi di commutazione) che le persone possono usare per navigare le pagine web, dal punto di vista dell'implementazione dobbiamo considerare i seguenti gruppi:
Tutti gli altri utenti da tastiera, ovvero utenti che possono almeno in parte vedere lo schermo, che possono o meno usare uno screen reader per completare la loro esperienza, ma che dipendono da indizi visivi mostrati sullo schermo per navigare.
Utenti che non hanno accesso a un dispositivo puntatore come un trackpad o un mouse o che hanno condizioni fisiche come RSI, paralisi cerebrale o differenze agli arti e per i quali la tastiera è un metodo migliore.
La Linee guida per l'accessibilità dei contenuti web (WCAG) richiede ai fornitori di pagine web "di assicurare che, ove possibile, i contenuti possano essere azionati tramite tastiera o interfaccia tastiera."" Senza il supporto della tastiera questi utenti saranno esclusi dall'accesso alla tua pagina web. Un indagine WebAIM sugli utenti di lettori di schermo ha rilevato che una parte significativa degli utenti ha indicato che "la mancanza di accessibilità tramite tastiera" era un problema per loro. L'accesso può includere l'uso di moduli, menu di navigazione, widget interattivi, pop-up, avvisi e qualsiasi altro tipo di componente in una pagina.
Elementi di controllo focalizzabili
Link: Il tasto Invio dovrebbe attivare/seguire il link
Pulsante: Il tasto Invio o la Barra spaziatrice dovrebbero attivare/premere il pulsante
Caselle di controllo/Pulsanti di opzione: I tasti Freccia dovrebbero spostare l'elemento evidenziato, la Barra spaziatrice dovrebbe selezionare o deselezionare l'elemento evidenziato
Select (menu a discesa): I tasti Freccia dovrebbero spostare l'elemento evidenziato, il tasto Invio dovrebbe selezionare l'elemento evidenziato
Dialogo: Il tasto Esc dovrebbe chiudere il dialogo
Mantenere il focus visibile
I browser web sono già accessibili per quanto riguarda l'indicazione di quale elemento in una pagina web ha il focus aggiungendo un contorno visibile. Utilizzando il CSS per stilizzare quel focus, l'indicatore può essere personalizzato o addirittura disattivato. Un indicatore di focus assente o difficile da vedere dovrebbe essere considerato un difetto.
Nota n.1: Usare solo il cambiamento di colore per indicare il focus sarebbe inaccessibile per gli utenti che non possono percepire il colore.
Nota n.2: Non disabilitare le funzionalità necessarie per la navigazione tramite tastiera, ad es. :focus {outline:none;}
Visibile quando focalizzato
Il contenuto che è visivamente nascosto sullo schermo, ma che può ricevere il focus tramite la navigazione con tastiera, dovrebbe essere creato in modo che il contenuto diventi visibile una volta che ha il focus. Un esempio di ciò sarebbe un link "Salta al contenuto principale", pensato per permettere agli utenti di saltare rapidamente tutto il contenuto di navigazione in cima a ogni pagina e continuare al contenuto principale.
Convalida
Quando si convalida un modulo, assicurati che il valore originale inserito dall'utente che ha causato l'errore non venga cancellato. Preservando il valore originale dell'utente, l'utente può identificare più facilmente l'errore e poi correggerlo modificandolo. L'uso degli attributi WAI-ARIA può aiutare a rendere gli errori di convalida più facili da seguire per gli utenti di tecnologie assistive. Usa l' attributo aria-invalid per contrassegnare ogni campo di input non valido come avente un errore, e l' attributo aria-describedby per associare il messaggio di errore specifico a quel campo di input.
Scorciatoie da tastiera
Sebbene esistano molte scorciatoie da tastiera note definite nelle applicazioni desktop, questo non è il caso della miriade di diverse pagine web esistenti. Sebbene sia possibile usare l'attributo accesskey per definire tasti di scelta rapida personalizzati, ciò difficilmente aumenterà l'accessibilità se gli utenti non possono prevederli o conoscerli in modo evidente. Definire tali tasti di scelta rapida potrebbe persino peggiorare le cose se entrano in conflitto con le scorciatoie standard integrate nel browser web o nella tecnologia assistiva. Vedi le scorciatoie comuni su BBC GEL Megapedia.
Evitare trappole della tastiera
Una "trappola da tastiera" esiste ogni volta che una funzionalità in una pagina web impedisce all'utente di allontanarsi da un elemento focalizzato. Questo non dovrebbe accadere ovviamente, ma JavaScript implementato male può talvolta alterare il modo in cui il focus da tastiera funziona normalmente, facendolo funzionare male in questo modo se l'autore della pagina web non presta attenzione.
Come testare questo
Per ogni pagina web, esegui i seguenti controlli. Registra una risposta, "sì" o "no" a ciascuna domanda. Il risultato di superamento è indicato in maiuscolo dopo ogni domanda, ad esempio [Y/N] dove Y è richiesto per superare. Per ogni risultato non superato, documentalo come uno dei seguenti:
Come difetto
Un difetto, ma con una spiegazione del perché dovrebbe essere consentito come eccezione
Un difetto, ma con una spiegazione del perché non è applicabile
Test che dovrebbero essere (almeno parzialmente) eseguiti manualmente
Di seguito sono riportati un paio di esempi di domande chiave che dovresti porre:
È possibile usare il tasto Tab per avanzare, e la combinazione di tasti Shift+Tab per spostare il focus in modo che ogni link e controllo possa essere raggiunto e utilizzato senza mouse o touchscreen? [S/N]
Quando si sposta il focus, dovrebbe essere chiaramente visibile quale elemento della pagina web ha attualmente il focus, ad esempio tramite un contorno coerente e visibilmente contrastante. [S/N]
Quando si sposta il focus, ogni elemento che riceve il focus segue un ordine logico e prevedibile, spostandosi dall'alto verso il basso e da sinistra a destra (per pagine web pubblicate in inglese e altre lingue da sinistra a destra)? [S/N]
Per i componenti interattivi, inclusi gli elementi dei moduli, è possibile navigare e far funzionare ogni elemento inclusa l'impostazione di eventuali opzioni usando i tasti freccia, il tasto Invio, la Barra spaziatrice, ecc.? [S/N]
Per componenti complessi che spostano automaticamente il focus quando si apre o appare nuovo contenuto, il focus ritorna all'elemento originale una volta che quel contenuto si chiude? [S/N]
Per il contenuto che è visivamente nascosto quando la pagina web viene caricata, quel contenuto diventa visibile quando il focus della tastiera si sposta sull'elemento? [S/N]
6. Etichette per elementi interattivi
I controlli dei moduli e altri elementi interattivi devono essere etichettati correttamente. Se non lo sono, sarà difficile per gli utenti di tecnologie assistive capire lo scopo del controllo. Elementi interattivi mancanti o etichettati in modo errato possono portare a problemi o confusione per i tuoi utenti.
La Le Web Content Accessibility Guidelines affermano che tutti gli elementi interattivi dovrebbero avere sia un'etichetta che un nome accessibile. L'etichetta è presentata visivamente e il nome accessibile è usato dalle tecnologie assistive, come i lettori di schermo. Spesso i due sono uguali; per esempio, se un link avvolge il testo "Home", come Home il testo "Home" è l'etichetta e il nome accessibile.
Analogamente, un pulsante contenente il testo "Invia" ha sia un'etichetta visiva sia un nome accessibile di "Invia".
Come testare questo
Per ogni pagina web, esegui i seguenti controlli. Registra una risposta, "sì" o "no" a ciascuna domanda. Il risultato di superamento è indicato in maiuscolo dopo ogni domanda, ad esempio [Y/N] dove Y è richiesto per superare. Per ogni risultato non superato, documentalo come uno dei seguenti:
Come difetto
Un difetto, ma con una spiegazione del perché dovrebbe essere consentito come eccezione
Un difetto, ma con una spiegazione del perché non è applicabile
Test che dovrebbero essere eseguiti manualmente
Di seguito sono riportati un paio di esempi di domande chiave che dovresti porre:
Esiste un'etichetta testuale visibile che identifica che tipo di informazione ci si aspetta venga inserita? [S/N]
L'etichetta è vicina al controllo che descrive, in modo che sia ovvio a quale controllo si riferisce? [S/N]
L'etichetta è ancora visibile quando il controllo ha il focus? [S/N]
Se il controllo è un gruppo di opzioni selezionabili, come un menu a discesa o un elenco di pulsanti radio o caselle di controllo, esiste un'etichetta testuale visibile che descrive la collezione di opzioni? [S/N]
Quando i controlli vengono incontrati da un lettore di schermo, l'etichetta viene letta ad alta voce come previsto? [S/N]
Esempi e informazioni aggiuntive
I tre aspetti delle etichette e dei nomi accessibili che devono essere implementati correttamente si basano sull'utente e su come interagisce con la pagina web. Avere un'etichetta visiva è ovviamente necessario per consentire agli utenti vedenti che navigano usando un cursore o un mouse di sapere cosa sono progettati per fare gli elementi interattivi: cliccare il pulsante "chiudi scheda", o passare con Tab al link "pagina di supporto" sono esempi.
Fornendo quelle etichette in modi accessibili servirai anche gli utenti di dispositivi lettori di schermo, i quali useranno quel testo per pronunciare il nome accessibile all'utente. In alcuni casi, tuttavia, è possibile applicare un'etichetta visibile che sia diversa dal nome accessibile. Questo crea potenziali problemi per gli utenti che usano il controllo vocale e il riconoscimento vocale per navigare, ad esempio dicendo "clicca Invia". Questi utenti vedranno l'etichetta e la useranno per dirigere la loro tecnologia assistiva, che a sua volta si baserà sul nome accessibile. Per questo motivo, è consigliato mantenere l'etichetta visibile uguale al nome accessibile.
Non fare affidamento sul testo segnaposto
Testo segnaposto a volte viene usato dagli autori della pagina come se fosse un'alternativa all'etichetta. Questo è talvolta un tentativo di risparmiare spazio in un modulo poiché il testo segnaposto appare all'interno del campo di input invece che accanto ad esso. Ma è proprio per questo che non è adatto come etichetta. Oltre a essere di contrasto basso per impostazione predefinita, per progettazione scompare non appena l'utente inizia a inserire testo nell'input. E a quel punto non c'è più alcuna etichetta visibile. Gli utenti con deficit della memoria a breve termine o anche quelli che sono distratti e si sono girati potrebbero non sapere più a cosa serve quell'input.
Non aggiungere un attributo title
Un attributo title a volte viene aggiunto agli elementi di input del modulo. Sebbene sia vero che la maggior parte dei lettori di schermo pronuncerà l'attributo title, non c'è alcun beneficio in questo: usare il più semantico elemento label funzionerebbe altrettanto bene e ha il vantaggio che l'etichetta può essere cliccata per impostare il focus sull'input. Avere sia un'etichetta che un attributo title ovviamente significa che entrambe queste stringhe di testo verranno lette, portando a duplicazioni.
Nascondere parti delle etichette ai lettori di schermo
In alcuni casi, parti specifiche del testo usato in un'etichetta hanno un significato convenzionale, ma solo quando vengono viste. Per esempio, l'asterisco è spesso usato per indicare visivamente all'utente che un elemento del modulo è obbligatorio. Mentre alcuni lettori di schermo possono leggere l'asterisco, molti lettori di schermo non lo faranno. È accettabile nascondere l'asterisco dai lettori di schermo se l'informazione è resa chiara in un modo alternativo.
Nascondere parti delle etichette ai non lettori di schermo
Un'etichetta è spesso testo semplice ma può essere un elemento con testo alternativo, come un'immagine, a condizione che l'immagine sia un'icona ben compresa. Quando un'etichetta è visibile solo come icona, deve essere fornito un testo alternativo per gli utenti che non possono vedere l'icona. Idealmente il controllo renderebbe quel testo visibile per tutti insieme all'icona, ma le limitazioni di design potrebbero non rendere questo ideale. In tal caso, fornire testo come etichetta accessibile solo a un lettore di schermo è accettabile, a condizione che l'icona sia ben nota e compresa dagli utenti vedenti senza il testo (ad esempio un'icona a forma di "lente d'ingrandimento", come etichetta per un modulo di ricerca).
L'esempio seguente usa una delle tecniche da Testo alternativo per le immagini sezione. Questi testi alternativi saranno naturalmente nascosti agli utenti che guardano l'immagine.
7. Landmarks
Aggiungendo landmark HTML alle tue pagine web, permetti alle tecnologie assistive di identificare le regioni a cui un utente potrebbe voler saltare rapidamente, per esempio usando i tag header, nav, main, section e footer. Guida W3C agli ARIA Landmarks.
Un'indagine WebAIM sugli utenti di lettori di schermo ha rivelato che più della metà dei rispondenti userà almeno talvolta i landmark HTML per navigare all'interno di una pagina web. Sebbene altre funzionalità, come Intestazioni e Link, possano essere usate più frequentemente secondo l'indagine, aggiungere landmark HTML all'insieme di segnaletiche virtuali può solo essere d'aiuto, in particolare per gli utenti che non possono scansionare visivamente un documento per decidere dove iniziare.
Navigare tramite landmark HTML è una tecnica che può essere utilizzata sia dagli utenti vedenti sia da quelli non vedenti, anche senza l'ausilio di un lettore di schermo.
Per gli utenti che non hanno accesso alle funzionalità di navigazione per landmark integrate nel loro browser o nella tecnologia assistiva, puoi fornire ciò che è noto come "link di salto" come caratteristica della pagina web stessa. I link di salto dovrebbero essere il primo contenuto nel body della pagina web e dovrebbero collegarsi al contenuto identificato usando il landmark main.
Questo è utile per gli utenti che altrimenti dovrebbero scorrere molti link di navigazione e contenuti di intestazione con una tastiera, per esempio, prima di raggiungere il contenuto che vogliono consultare. È accettabile nascondere questi link di salto per evitare di ingombrare la pagina web per gli utenti che navigano tramite puntatore (mouse o touch, ad esempio) applicando CSS che fa sì che il link sia visivamente nascosto fino a quando non riceve il focus della tastiera.
Come testare questo
Per ogni pagina web, esegui i seguenti controlli. Registra una risposta, "sì" o "no" a ciascuna domanda. Il risultato di superamento è indicato in maiuscolo dopo ogni domanda, ad esempio [Y/N] dove Y è richiesto per superare. Per ogni risultato non superato, documentalo come uno dei seguenti:
Come difetto
Un difetto, ma con una spiegazione del perché dovrebbe essere consentito come eccezione
Un difetto, ma con una spiegazione del perché non è applicabile
Test che potrebbero essere automatizzati:
Di seguito sono riportati un paio di esempi di domande chiave che dovresti porre:
La pagina web ha esattamente una regione identificata con il landmark main? [S/N]
Tutto il contenuto della pagina web è contenuto all'interno di una regione landmark? [S/N]
Test che dovrebbero essere (almeno parzialmente) eseguiti manualmente:
Di seguito sono riportati un paio di esempi di domande chiave che dovresti porre:
Le aree della pagina web principalmente destinate a mostrare link di navigazione sono identificate usando il landmark nav? [S/N]
Il contenuto dell'intestazione della pagina web è identificato usando il landmark header? [S/N]
Il contenuto del footer della pagina web è identificato usando il landmark footer? [S/N]
Considerando altri landmark, se vengono usati, ciascuno comunica correttamente il contenuto che contiene: section, article, aside? [S/N]
Se esiste un link di salto, quel link si trova in cima o vicino alla parte superiore della pagina web e può essere usato durante la navigazione con la tastiera per saltare al contenuto principale? [S/N]
8. Link
Quando si scrive il testo di un link, usa un testo conciso ma completo che descriva la risorsa collegata. Questo è particolarmente importante per le persone che usano un lettore di schermo per scansionare l'intera pagina web e leggere un elenco solo di link, dove ogni link non avrà contesto e deve essere compreso da solo.
Per esempio, una serie di riepiloghi di articoli, ognuno contenente il link con il testo "Leggi di più" verrà presentata come un elenco di molti frammenti "Leggi di più" all'utente del lettore di schermo, senza alcuna indicazione su cosa permetterà di leggere di più seguendo ciascun link.
Utente lettore di schermo: "Leggi di più" cosa?
Aggiungere contesto al testo del link rimuoverà le barriere per gli utenti di lettori di schermo e probabilmente aiuterà anche gli utenti vedenti a tenere traccia di dove stanno navigando. In casi eccezionali, dove sarebbe ridondante o distraente per gli utenti vedenti leggere i dettagli completi nel contenuto del link, questo può essere gestito aggiungendo il contesto come testo visivamente nascosto disponibile solo agli utenti di lettori di schermo.
Sebbene il testo del link appaia visivamente solo come "Leggi di più" nel contesto dell'articolo intitolato "I nostri valori", apparirà come "Leggi di più sui nostri valori..." quando un utente di lettore di schermo apre l'elenco di tutti i link dalla pagina web. Dove possibile, dovresti mantenere il contenuto destinato agli utenti di lettori di schermo visivamente uguale al contenuto destinato agli altri utenti. Non tutti gli utenti di lettori di schermo sono ciechi, e gli utenti di lettori di schermo che possono vedere il testo potrebbero essere confusi dall'udire e vedere contenuti diversi.
Icone nei link
Sebbene avere testo descrittivo e visibile sia il modo più accessibile per etichettare un link, esistono casi d'uso in cui un'icona ben compresa sarebbe più naturale. In questi casi, deve essere fornito un testo alternativo per gli utenti di lettori di schermo che non possono vedere l'icona.
Un semplice elemento HTML img mostrerà l'icona. I lettori di schermo annunceranno che è presente un "immagine" e pronunceranno qualsiasi testo nell'attributo alt.
Vedi la guida per Testi alternativi per immagini funzionali.
Link esterni
Quando si collega a siti esterni, è buona pratica, dal punto di vista della sicurezza e della responsabilità, informare l'utente che sta per visitare contenuti di cui non sei responsabile. Questo può essere motivo di preoccupazione se l'utente è connesso al tuo sito o ha qualche altra sessione che verrebbe interrotta o persa una volta che lascia il tuo sito.
Nuove schede
Aprire i link in nuove schede o finestre può rendere l'esperienza di alcuni utenti più confusa e meno accessibile, quindi dovrebbe essere usato raramente. Un'eccezione può essere rappresentata dai link a siti esterni. Se il link apre effettivamente un Modale o una pagina in una nuova scheda o finestra, assicurati che questo sia spiegato nel testo del link.
Come testare questo
Per ogni pagina web, esegui i seguenti controlli. Registra una risposta, "sì" o "no" a ciascuna domanda. Il risultato di superamento è indicato in maiuscolo dopo ogni domanda, ad esempio [Y/N] dove Y è richiesto per superare. Per ogni risultato non superato, documentalo come uno dei seguenti:
Come difetto
Un difetto, ma con una spiegazione del perché dovrebbe essere consentito come eccezione
Un difetto, ma con una spiegazione del perché non è applicabile
Test che dovrebbero essere eseguiti manualmente:
Di seguito sono riportati un paio di esempi di domande chiave che dovresti porre:
Ogni link contiene testo visibile o un'icona convenzionale ben compresa? [S/N]
Per i link che contengono solo un'icona, è presente del testo equivalente assegnato alla grafica? [S/N]
Tutti i link sono coerentemente e visibilmente distinti dal testo circostante in modo che l'utente possa identificarli in un modo non dipendente unicamente dal colore? [S/N]
Quando si naviga la pagina web usando la tastiera, è visibilmente evidente quando un link ha il focus della tastiera. [S/N]
Quando i link sono presentati come un elenco, separati dal contesto circostante, hanno tutti un testo unico o testo alternativo che sia conciso ma descriva distintamente la risorsa collegata? [S/N]
Il testo di tutti o di uno qualsiasi dei link sulla pagina è pienamente comprensibile se letto in isolamento? Per esempio senza usare "clicca qui" o "maggiori informazioni" [S/N]
9. Metadati
I metadati sono letteralmente "dati sui dati" e sono vitali affinché una pagina web sia accessibile. Lo standard HTML definisce molteplici modi per gli autori di pagine web di fornire questi metadati, inclusa una serie di appropriati "meta tag", e vari altri tag e attributi che dichiarano cose come la lingua, il set di caratteri, il titolo e la scala viewport preferita, tutti elementi che riguardano il documento della pagina web.
Sebbene i metadati di una pagina web possano essere forniti usando una varietà di tag e attributi, ciò che hanno in comune è che seguono standard di settore ben stabiliti e quindi sono leggibili dalle macchine.
Accessibilità e SEO
I benefici di metadati accurati e ben scritti si applicano a due tipi di leggibilità macchina: gli spider dei motori di ricerca e le tecnologie assistive. Per esempio, avere un tag title HTML significativo e ben scritto per una pagina web permetterà a Google di mostrare quel titolo come intestazione cliccabile nella sua pagina di risultati, di includere il titolo quando si condivide la pagina web sui social media e di usare il titolo come nome del segnalibro nel browser dell'utente.
Inoltre, lo stesso titolo sarà usato dai lettori di schermo per annunciare il nome della pagina web quando viene caricata, così che gli utenti che potrebbero non vedere lo schermo possano ascoltare una descrizione accurata e concisa dell'argomento della pagina web.
Convalida
Validare l'HTML è sempre un buon inizio per verificare i metadati sottostanti. L'estensione per browser Web Developer semplifica questa operazione, usa la voce di menu: Tools → Validate HTML. Valutare i meta tag è anche semplificato usando questo strumento. Attiva l'opzione di menu: Information → View Meta Tag Informazioni per la pagina web in prova.
Alla fine, a causa della natura dei metadati ottimizzati per le macchine, potresti dover usare l'opzione visualizza sorgente degli strumenti per sviluppatori del tuo browser per accedere direttamente all'HTML della pagina web in prova. Cerca eventuali metadati impostati sul tag html o definiti nella sezione head del documento.
Dichiarare la lingua di una pagina web
La L'attributo lang può essere aggiunto a molti elementi HTML per indicare in quale lingua è scritto il testo in quell'elemento. Al minimo, il tag HTML più esterno deve avere dichiarata una lingua. Se parti della pagina sono scritte in una lingua diversa (per esempio quando una frase straniera è intenzionalmente citata) quell'elemento deve avere un valore corretto dell'attributo lang a seconda della lingua usata. Se la lingua usata non segue l'ordine predefinito da sinistra a destra per la lettura del testo, assicurati che venga incluso anche l'attributo dir per specificare "rtl" ad esempio, quando si cita un modello di visualizzazione da destra a sinistra.
Non impostare la lingua probabilmente danneggerà il posizionamento della tua pagina web nei motori di ricerca, renderà più difficile per gli strumenti rendere traduzioni automatiche del tuo contenuto e impedirà ai lettori di schermo di usare accuratamente il motore di pronuncia più appropriato quando leggono il tuo contenuto testuale.
Rendi i titoli sufficientemente specifici da essere distinti
Il titolo di una pagina web dovrebbe essere sufficientemente specifico da poter distinguere quella pagina web da qualsiasi altra pagina dell'intero sito web. Seguendo questa regola, dovresti ottenere che ogni pagina web abbia un titolo unico; altrimenti l'implicazione è che il titolo scelto non era abbastanza descrittivo oppure hai più pagine web con lo stesso contenuto.
Non disabilitare il 'pinch and spread' per lo zoom
I dispositivi con schermo tattile spesso supportano gesti noti come pinch and spread per permettere all'utente di ingrandire o ridurre specifiche aree visibili di una pagina web. È tecnicamente possibile definire metadati che disabilitano questo (impostando ad esempio maximum-scale=1). Se ciò si verifica, dovrebbe essere considerato un difetto.
Come testare questo
Per ogni pagina web, esegui i seguenti controlli. Registra una risposta, "sì" o "no" a ciascuna domanda. Il risultato di superamento è indicato in maiuscolo dopo ogni domanda, ad esempio [Y/N] dove Y è richiesto per superare. Per ogni risultato non superato, documentalo come uno dei seguenti:
Come difetto
Un difetto, ma con una spiegazione del perché dovrebbe essere consentito come eccezione
Un difetto, ma con una spiegazione del perché non è applicabile
Test che potrebbero essere automatizzati:
Di seguito sono riportati un paio di esempi di domande chiave che dovresti porre:
La pagina web non genera errori di validazione HTML quando viene controllata da uno strumento di validazione HTML W3C? [S/N]
La pagina web ha almeno un attributo lingua generale impostato che segue i codici lingua standard per l'HTML? [S/N]
Test che dovrebbero essere (almeno parzialmente) eseguiti manualmente:
Di seguito sono riportati un paio di esempi di domande chiave che dovresti porre:
La pagina web ha un tag title che descrive in modo accurato e conciso l'argomento dell'intera pagina? [S/N]
Se la pagina web è visualizzata su uno schermo tattile che supporta pinch and spread per lo zoom, è possibile usare questi gesti per ingrandire o ridurre la pagina? [S/N]
10. Migliorie e design reattivo
Il progressive enhancement assicura che gli utenti possano usare la più ampia gamma possibile di dispositivi e software, mentre lo scopo principale della pagina web rimane utilizzabile e comprensibile. Funzionalità aggiuntive opzionali possono essere aggiunte all'esperienza di base a beneficio di dispositivi e browser più capaci.
Accessibilità robusta
Applicare le pratiche di progressive enhancement renderà la tua pagina web più resiliente oltre che inclusiva; non tutti gli utenti avranno la connettività più veloce, il computer più potente o l'ultima versione del software installata. e talvolta una funzionalità può essere disattivata deliberatamente da un utente. Dovresti presumere che abbiano una buona ragione per questa decisione, ma non tutti gli utenti hanno una scelta.
1. Assicurarsi che il testo sia ridimensionabile
Il testo è considerato utilizzabile e leggibile quando non viene ritagliato e non sovrappone altro testo o elementi vicini. Deve andare a capo secondo necessità e mantenere le sue qualità tipografiche, consentendo ad esempio sufficiente altezza di riga e spaziatura tra lettere e righe. Assicurati che vengano usate unità relative (em o rem) per specificare le dimensioni degli elementi della pagina web come il testo e il layout. Questo permetterà alla pagina di ridimensionarsi e adattarsi in relazione alla dimensione dello schermo del dispositivo o alla sua orientazione (verticale o orizzontale).
2. Assicurarsi che la pagina web sia zoomabile
Lo zoom della pagina aumenta la dimensione apparente dell'intera pagina, mentre il ridimensionamento del testo aumenta solo la dimensione del testo. Assicurati che tutto il contenuto sia visibile e utilizzabile quando la pagina web è zoomata almeno al 200% del livello predefinito.
3. Adattare le aree di tocco per essere più grandi su schermi più piccoli
Su dispositivi mobili con touchscreen l'utente deve affrontare sia uno schermo fisico più piccolo sia l'uso di un dito per cercare di toccare gli obiettivi come link o pulsanti. Tenendo conto di ciò, la dimensione minima fisica dell'area di tocco dovrebbe essere almeno 7 x 7 mm, o più grande se possibile. Questo indubbiamente richiederà di aumentare la dimensione degli elementi interattivi su schermi più piccoli.
4. Non fare affidamento su un fallback noscript
Alcune pagine web usano il tag HTML noscript per definire contenuti alternativi per i browser dove JavaScript è stato disattivato. Ricerche fatte da Gov.uk hanno mostrato che una parte significativa degli utenti che non potevano eseguire JavaScript non aveva JavaScript disattivato. In altre parole, JavaScript era attivato ma non è stato eseguito per qualche altro motivo. Questo è importante perché un browser mostrerà il contenuto noscript solo nel caso specifico in cui JavaScript sia stato disattivato. Quando JavaScript non viene eseguito per un altro motivo, l'utente non vedrà il contenuto che richiede JavaScript, né vedrà alcun contenuto alternativo noscript.
Come testare questo
Per ogni pagina web, esegui i seguenti controlli. Registra una risposta, "sì" o "no" a ciascuna domanda. Il risultato di superamento è indicato in maiuscolo dopo ogni domanda, ad esempio [Y/N] dove Y è richiesto per superare. Per ogni risultato non superato, documentalo come uno dei seguenti:
Come difetto
Un difetto, ma con una spiegazione del perché dovrebbe essere consentito come eccezione
Un difetto, ma con una spiegazione del perché non è applicabile
Test che potrebbero essere automatizzati:
Di seguito sono riportati un paio di esempi di domande chiave che dovresti porre:
Tutte le dimensioni specificate nel design (CSS) della pagina sono dichiarate usando solo unità relative (em o rem), evitando l'uso di unità fisse in pixel come px? [S/N]
Test che dovrebbero essere (almeno parzialmente) eseguiti manualmente:
Di seguito sono riportati un paio di esempi di domande chiave che dovresti porre:
Quando la dimensione del testo viene modificata al 200% della dimensione predefinita nelle impostazioni del browser, tutto il testo sulla pagina web è ancora visibile e leggibile? [S/N]
Quando lo zoom della pagina è aumentato al 200% nel browser, tutto il testo sulla pagina web aumenta proporzionalmente? [S/N]
In DevTools, con il simulatore CPU e Network Throttle del browser impostato alle loro impostazioni più degradate, lo scopo principale della pagina è ancora fornito? [S/N]
In DevTools, quando il simulatore Device Mode del browser è impostato sullo schermo del dispositivo più piccolo disponibile, lo scopo principale della pagina è ancora raggiunto? [S/N]
Pratiche di test aggiuntive
Puoi usare strumenti come il browser Chrome DevTools, e applicare le Device Mode impostazioni per approssimare la pagina web in prova su una gamma di dispositivi: da cellulari, a tablet e desktop. Puoi anche simulare input del dispositivo per touch, geolocalizzazione e orientamento del dispositivo.
Nota che la Scheda Network ti permette di simulare il throttling della CPU e della rete.
11. Struttura semantica
All'interno di qualsiasi pagina web, le intestazioni sono usate per comunicare l'organizzazione generale e la struttura del contenuto. Le intestazioni dovrebbero fungere da struttura di alto livello del contenuto della pagina, con una graduazione logica di ogni argomento e sottoargomento in ordine gerarchico.
Un'indagine WebAIM sugli utenti di lettori di schermo ha rivelato che il 67,5% dei rispondenti è più propenso a provare prima le intestazioni per trovare informazioni in una pagina web lunga. E l'85,7% ha dichiarato che avere livelli di intestazione corretti era utile quando si navigava una pagina web tramite intestazioni.
Non fornire intestazioni utilizzabili e ben organizzate impedisce agli utenti di lettori di schermo di comprendere la struttura del tuo contenuto e di poter navigare efficacemente nella tua pagina. Mentre le intestazioni sono utili per tutti, gli utenti di tecnologie assistive sono più esclusi degli altri quando le intestazioni mancano o sono implementate in modo improprio.
Intestazioni
L'intestazione h1 dovrebbe descrivere l'argomento della pagina web nel suo insieme e quindi sarebbe simile o identica nel contenuto all'elemento title della pagina web.
È tipico che la primissima intestazione sia h1 ma non è un difetto che appaia prima una h2, per esempio. La graduazione logica e l'ordine delle intestazioni sono più importanti di quale sia la prima, ad esempio assicurarsi che nessuna h2 sia seguita immediatamente da una h4 (saltando l'attesa h3). Per illustrare, se la porzione di navigazione della pagina apparisse prima del titolo visualizzato della pagina, potresti dare all'intestazione di navigazione una classificazione h2 ma poi più in basso usare un'intestazione h1 per indicare il tema principale dell'intera pagina.
I lettori di schermo non sono in grado di riconoscere come vere intestazioni gli elementi che sono solo stilizzati visivamente come intestazioni. Usa uno strumento che possa controllare il sorgente HTML per trovare le intestazioni effettive (che è esattamente come fanno i lettori di schermo) e usa un div solo per ciò per cui è stato progettato, e non usarlo mai come sostituto di altri tag più appropriati. Per un'esperienza più autentica di navigazione delle intestazioni, usa il lettore di schermo Narrator integrato nella tua macchina Windows per testare la pagina.
Questo renderà l'importanza dell'H1 inaccessibile agli utenti di screen reader.
Come testare questo
Per ogni pagina web, esegui i seguenti controlli. Registra una risposta, "sì" o "no" a ciascuna domanda. Il risultato di superamento è indicato in maiuscolo dopo ogni domanda, ad esempio [Y/N] dove Y è richiesto per superare. Per ogni risultato non superato, documentalo come uno dei seguenti:
Come difetto
Un difetto, ma con una spiegazione del perché dovrebbe essere consentito come eccezione
Un difetto, ma con una spiegazione del perché non è applicabile
Test che potrebbero essere automatizzati:
Di seguito sono riportati un paio di esempi di domande chiave che dovresti porre:
I tag di intestazione HTML come h1 e h2 compaiono nell'HTML della pagina? [S/N]
Le intestazioni sono in ordine gerarchico senza saltare livelli di intestazione (da h2 a h4 per esempio)? [S/N]
Test che dovrebbero essere (almeno parzialmente) eseguiti manualmente:
Di seguito sono riportati un paio di esempi di domande chiave che dovresti porre:
Le intestazioni sono visualizzate in uno stile coerente e riconoscibile che le rende facili da identificare rispetto ad altri contenuti non di intestazione? [S/N]
Il testo di ciascuna intestazione descrive correttamente e concisamente l'argomento che intesta? [S/N]
L'h1 principale della pagina descrive correttamente e concisamente l'argomento dell'intera pagina? [S/N]
Tutti gli esempi di testo che visivamente appaiono come intestazioni sono implementati con un tag di intestazione HTML? [S/N]
12. Alternative testuali
Quando l'utente non ha le immagini disponibili nel proprio browser o non può vedere le immagini a causa di una disabilità, DEVONO essere fornite alternative testuali che fungano da fonte comparabile di informazione e utilità in modo che l'utente possa comunque accedere, capire e usare la pagina web per il suo scopo principale.
Questo documento copre le tecniche e i test necessari per garantire che le immagini funzionali come icone, pulsanti, controlli, loghi e asset del brand siano accessibili agli utenti di screen reader.
Copr e anche le tecniche per identificare le immagini di contenuto, tuttavia i test non dimostreranno in modo conclusivo che eventuali immagini di contenuto siano accessibili. Non fare affidamento su uno strumento automatizzato di generazione alt text basato su AI. Le immagini funzionali richiedono un'alternativa testuale che descriva cosa fanno o cosa rappresentano, piuttosto che come appaiono. Una descrizione visiva di un pulsante o di un'icona è di scarso o nessun uso per un utente.
Immagini puramente decorative
Queste immagini non aggiungono significato al contenuto della pagina web e quindi dovrebbero essere ignorate silenziosamente dai dispositivi screen reader. Per definizione, le immagini decorative potrebbero essere eliminate senza influire sulla comprensibilità e usabilità della pagina.
Allo stesso modo, le immagini di sfondo (definite in CSS) sono automaticamente ignorate dai dispositivi screen reader e devono essere utilizzate solo per scopi puramente decorativi.
Esiste un caso limite frequentemente abusato in cui l'elemento che mostra l'immagine di sfondo viene creato per contenere del testo destinato a essere un'alternativa all'immagine, invece di essere definito in un attributo alt dell'HTML.
Nota che il testo alternativo si trova nel corpo della pagina web ma è stilizzato (tramite una classe visivamente-nascosta definita dallo sviluppatore) per essere accessibile solo agli utenti di un dispositivo screen reader. Sebbene questo sia tecnicamente accessibile agli utenti di screen reader, è un approccio peggiore rispetto all'uso di un elemento img con attributo alt perché il testo visivamente nascosto non verrà mai visualizzato quando le immagini sono disabilitate o per qualsiasi motivo non vengono caricate, mentre il testo dell'attributo alt lo sarà.
Immagini di contenuto
Queste immagini sono intrinseche al contenuto o all'utilità della pagina. Usa l'attributo HTML alt per fornire un'alternativa testuale per l'immagine.
Fai attenzione a non fornire contenuti ridondanti; tuttavia, se il testo usato come alternativa per l'immagine è già vicino nel testo normale del corpo, allora il testo alternativo dovrebbe essere considerato ridondante e l'immagine dovrebbe quindi essere trattata come puramente decorativa. Altrimenti, l'esperienza con lo screen reader sarà sentire lo stesso testo letto ad alta voce due volte.
Quando valuti la qualità del testo alternativo considera il significato editoriale e lo scopo dell'immagine nel contesto della pagina circostante. Il testo alternativo dovrebbe trasmettere concisamente cosa significa l'immagine, non solo cosa mostra.
Non presumere che altre funzionalità HTML destinate a fornire testo alternativo, come gli attributi longdesc, title o figcaption, funzioneranno per gli screen reader. Non è prevedibile se un particolare dispositivo screen reader (a seconda di come è configurato) ignorerà quegli attributi o se li leggerà, in tutto o in parte.
Se la quantità di informazioni testuali necessarie è ampia o complessa, è accettabile usare un attributo ARIA per contrassegnare un altro elemento HTML adiacente come testo alternativo.
Immagini nei controlli
Quando le immagini fungono da etichetta di un controllo – pensa a un'immagine del logo di un social media che è l'unico contenuto in un link al feed social dell'azienda – il controllo deve essere accessibile per gli utenti che non possono vedere l'immagine. Usa un testo alternativo che spieghi l'azione del controllo. Un link dovrebbe descrivere la destinazione, ad esempio "Pagina principale", "Chi siamo", ecc. Un'immagine in un pulsante dovrebbe usare un testo alternativo che descriva lo scopo del pulsante, come ad esempio "Cerca", "Accedi" o "Invia".
Grafica in formato SVG
In alcuni casi, l'immagine visualizzata potrebbe non essere definita usando il tradizionale tag img, ma deve comunque essere possibile per i dispositivi screen reader accedere ad alcune alternative testuali. L'esempio qui sotto mostra una tecnica documentata da Léonie Watson che utilizza una combinazione di role e attributi aria-labelledby riferiti a un title e desc per aiutare gli utenti di tecnologie assistive ad accedere al testo che descrive la grafica.
Come testare questo
Per ogni pagina web, esegui i seguenti controlli. Registra una risposta, "sì" o "no" a ciascuna domanda. Il risultato di superamento è indicato in maiuscolo dopo ogni domanda, ad esempio [Y/N] dove Y è richiesto per superare. Per ogni risultato non superato, documentalo come uno dei seguenti:
Come difetto
Un difetto, ma con una spiegazione del perché dovrebbe essere consentito come eccezione
Un difetto, ma con una spiegazione del perché non è applicabile
Test che potrebbero essere automatizzati:
Di seguito è riportato un esempio di una domanda chiave che dovresti porre:
Ogni immagine ha un testo alternativo associato (anche se quel testo è un valore vuoto)? [S/N]
Test che dovrebbero essere (almeno parzialmente) eseguiti manualmente:
Di seguito sono riportati un paio di esempi di domande chiave che dovresti porre:
Il testo alternativo è conciso, grammaticalmente corretto e privo di errori ortografici? [S/N]
Se lo scopo dell'immagine è puramente decorativo, il testo alternativo è un valore vuoto, come alt="" ? [S/N]
Il testo alternativo descrive l'immagine in modo da comunicare un significato comparabile agli utenti che non possono vedere l'immagine? [S/N]
Se l'immagine appare come unica etichetta per un controllo, un link o un pulsante per esempio, è possibile capire cosa fa il controllo solo dal testo alternativo? [S/N]
Il testo alternativo è originale / utile e non semplicemente una ripetizione del testo adiacente del corpo? [S/N]
La lingua usata per il testo alternativo corrisponde alla lingua dichiarata per il resto del documento? [S/N]
Se l'immagine è un logo del brand e non è funzionale, dichiara semplicemente il nome del marchio? [S/N]
Se l'immagine è, per esempio, un'icona Diageo, utilizza il testo associato a quell'icona come indicato nel sistema di design? [S/N]
Test che potrebbero essere automatizzati:
Di seguito è riportato un esempio di una domanda chiave che dovresti porre:
Lo strumento automatico di controllo del contrasto indica nessun errore di contrasto? [S/N]
Test che dovrebbero essere (almeno parzialmente) eseguiti manualmente:
Di seguito sono riportati un paio di esempi di domande chiave che dovresti porre:
Con l'emulazione della visione sfocata abilitata, è possibile leggere facilmente il testo che sovrappone immagini o gradienti? [S/N] Nota: cerca le opinioni di almeno altre 2 persone coinvolte in questo progetto
Emulazione della visione sfocata
Un contrasto sufficiente è particolarmente importante quando gli utenti possono sperimentare il tuo sito con visione sfocata, in forte abbagliamento o quando sono distratti. Abilitare l'emulazione della visione sfocata è un modo eccellente per testare che il testo sia adeguatamente leggibile.
Nel browser Chrome, questa emulazione è disponibile seguendo i passaggi seguenti:
Digita i tasti: command + shift + p e poi premi invio (digita) il testo "render" per vedere tutte le opzioni di rendering disponibili
Scorri verso il basso fino al menu a tendina "Emulate vision deficiencies"
Quindi seleziona l'opzione "Blurred vision"
Per verificare contrasto e leggibilità per utenti che possono avere deficienze nella percezione dei colori, scegli l'opzione "Achromatopsia" (rimuove tutti i colori).
Informazioni aggiuntive
Disabilitare le immagini (opzione disponibile anche tramite l'estensione del browser Web Developer) è un modo efficace per assicurarsi che il testo progettato per apparire sovrapposto a un'immagine sia comunque leggibile se quell'immagine dovesse non comparire. Impostare un colore di sfondo di fallback su tali elementi con immagini di sfondo è importante per gestire questi casi.
14. Uso di Windows Narrator
Narrator è uno screen reader integrato in tutti i sistemi operativi Windows. Questa guida è pensata per aiutare sviluppatori e tester che sono nuovi a Narrator a imparare i controlli di base per testare le loro pagine web.
Attualmente Narrator funziona meglio con il browser MS Edge, ma ha anche supporto per Chrome e Firefox.
Per cominciare
Per avviare o interrompere Narrator, premi il tasto Windows + Ctrl + Invio. Questo aprirà una finestra con opzioni per saperne di più su Narrator e configurare le impostazioni. Se sei nuovo a Narrator, guarda questo video per un breve tutorial introduttivo.
Cose utili da ricordare:
Premi il tasto Windows + Ctrl + N per accedere alle impostazioni. Qui puoi modificare la voce, il volume relativo e la velocità.
Sia il tasto Caps Lock sia il tasto Insert possono essere usati come tasto "modificatore" di Narrator usato in molti comandi—noi lo chiameremo tasto Narrator.
Ctrl + Home: ti porterà all'inizio della pagina
Ctrl + R: aggiorna la pagina (utile se sei perso o se Narrator non si comporta come previsto)
Per un elenco completo delle scorciatoie di Narrator https://dequeuniversity.com/screenreaders/narrator-keyboard-shortcuts
Ascoltare contenuti web
Ci sono più modi di usare Narrator per accedere ai contenuti web. Ecco i tasti più utili:
Ctrl + ↑/↓: Legge la riga precedente/successiva
↑/↓: Legge il paragrafo o l'elemento precedente/successivo
Narrator + Tab: Rileggi l'elemento corrente
Narrator + +/-: Aumenta/diminuisce la velocità di lettura
Ctrl: Interrompe la lettura
Potresti voler esercitarti a leggere alcune pagine diverse prima di iniziare i test.
Testare la navigazione della pagina
La maggior parte degli utenti vedenti scorrerà e prenderà un'istantanea visiva di una pagina web per farsi un'idea di dove sia tutto, ma se non puoi farlo allora ciò che la pagina contiene in termini di intestazioni, immagini, elementi di modulo, messaggi ecc. è sconosciuto. Se una pagina web è ben strutturata e ha seguito le Colt Accessibility Guides, un utente dovrebbe essere in grado di navigare la pagina usando le intestazioni, i landmark, i link o le liste ecc.
Esistono diverse scorciatoie a tasto singolo per navigare rapidamente per elementi comuni della pagina. Verifica che funzionino e che tu possa accedere con successo a ciascun tipo di elemento.
Questi includono:
H: Intestazioni
1 - 6: Intestazione 1, intestazione 2, ecc.
D: Landmark
Tab: Link e controlli del modulo
F: Controlli del modulo
B: Pulsanti
K: Link
L: Liste
I: Elementi in una lista
T: Tabelle
Shift + Qualsiasi tasto di navigazione inverte l'azione.
Apri la finestra Trova e prova a cercare diversi elementi
Narrator + Ctrl + F : Apri la finestra Trova
Narrator + F3: Scorri i risultati di Ricerca di Narrator (aggiungi Shift per andare indietro)
Linee guida per l'accessibilità della navigazione
Testare i moduli
Quando un controllo di un modulo ottiene il focus da tastiera, Narrator legge l'etichetta (se presente), e poi annuncia il tipo di controllo del modulo. Se un gruppo di controlli del modulo—tipicamente gruppi di checkbox o radio button—è contenuto in un fieldset con una legend, Narrator presenta gli elementi di un fieldset come un gruppo e legge la legend quando navighi per la prima volta all'interno del gruppo.
Usa i seguenti controlli da tastiera del browser per interagire con i controlli del modulo e verificare se possono essere raggiunti tramite navigazione e se le loro etichette sono sia uniche sia descrittive.
Tab e Shift + Tab: Navigare attraverso i controlli del modulo
Spazio per selezionare e deselezionare le caselle di controllo
↑/↓: Selezionare da un gruppo di radio button
Spazio, poi ↑/↓ o la prima lettera di un'opzione: Espandere e poi selezionare un'opzione in una combo box
Invio: Inviare un modulo
Linee guida per l'accessibilità dei moduli
Testare le immagini
Le immagini possono essere funzionali, di contenuto o decorative. Le Stream Graphics sono per lo più estetiche e quindi sarebbero classificate come decorative. Questo significa che dovrebbero essere silenziose per gli screen reader. Se il testo alternativo non è definito, Narrator tipicamente dirà "immagine" o "grafica non etichettata" (la maggior parte degli altri screen reader ignora questi). Il testo alternativo di un'immagine funzionale o di contenuto sarà letto da Narrator e dovrebbe descrivere lo scopo dell'uso dell'immagine.
Esempi:
Loghi Colt dovrebbero semplicemente dire il nome del brand, "Colt Technology Services"
Loghi di co-branding dovrebbero indicare entrambi i nomi dei brand, "Colt Technology Services in Partnership with Cisco"
Icone Colt o Visuali ESG, dovrebbero semplicemente dichiarare lo scopo di ciò che l'immagine rappresenta.
Le immagini che sono link, se il logo Colt è anche un link alla Homepage, dovrebbero contenere sia il nome del brand sia la destinazione, "Homepage Colt".
Linee guida per l'accessibilità delle immagini
Testare le tabelle di dati
Per navigare alla tabella successiva in una pagina, premi il tasto T. Per navigare all'interno di una tabella di dati, tieni premuti Ctrl + Alt e usa ↑/↓/←/→ per spostarti da cella a cella. Se una tabella ha intestazioni di riga e colonna corrette, verranno lette automaticamente durante la navigazione.
Assicurati che le righe e le colonne abbiano etichette significative.
Per un elenco completo delle scorciatoie di Narrator: https://dequeuniversity.com/screenreaders/narrator-keyboard-shortcuts
15. Download
Per facilitare gli sviluppatori nel testare potenziali problemi di accessibilità, abbiamo creato una Manual Accessibility Checklist per strutturare i tuoi test.
Ultimo aggiornamento
È stato utile?