7 errori comuni di accessibilità (e come evitarli)

<È probabile che abbiate già sentito parlare di accessibilità digitale e sapete che è importante ottimizzare il vostro prodotto online per le persone con disabilità. È comprensibile che vi sentiate sopraffatti da tutte le informazioni e le attività da svolgere per migliorare il vostro prodotto. Forse avete concluso che è così complicato che dovete assumere un esperto per fare il lavoro. Nel frattempo, vi interessa! Solo che non sapete come iniziare.

Non preoccupatevi: risolvere o evitare questi problemi spesso non richiede molto tempo! Sempre che si sappia dove cercare e cosa fare. Negli anni in cui ho lavorato come sviluppatore web e ingegnere software front-end, ho incontrato molti problemi di accessibilità. Spesso si riducono alla stessa serie di punti. Nella maggior parte dei casi, un approccio orientato all'accessibilità non richiede molto tempo. Non è più difficile o costoso. Si tratta di svolgere il lavoro quotidiano con una mentalità diversa che migliora enormemente l'accessibilità.

Ma ora veniamo al sodo: vi spiego quali sono i problemi di accessibilità più comuni e, soprattutto, come evitarli.

Errore 1: markup semantico insufficiente

Evitare i problemi di accessibilità non richiede un lavoro supplementare. Richiede semplicemente un lavoro diverso

Uno degli errori più comuni, con conseguenze purtroppo gravi, è la scarsa marcatura semantica. Se conoscete un po' di HTML, saprete che una pagina è composta da elementi definiti da HTML tags, ad esempio <h1> e <p>. La maggior parte degli elementi sono semantici: descrivono chiaramente il loro significato in modo leggibile dall'uomo e dalla macchina.

Se si visualizza il sorgente di una qualsiasi pagina web, si noteranno anche molti elementi <div> e <span>; questi sono gli elementi non semantici. Questi elementi sono contenitori generici, che non applicano alcun significato al loro contenuto.

I lettori di schermo si basano molto sull'HTML semantico. Formano un albero dell'accessibilità basato sulla semantica della pagina. Un utente con uno screen reader può saltare da un elemento all'altro usando scorciatoie. Il lettore indica quali sono i pulsanti, quali sono i titoli, dove si trova la navigazione, in che modo le informazioni della pagina sono collegate ad altri elementi della pagina e così via.

Uso eccessivo di elementi non semantici

Se si utilizzano elementi <div> e <span> al posto di un elemento semantico, si perdono immediatamente informazioni essenziali. Gli utenti con problemi di vista non riescono a capire la struttura del sito web in base a ciò che vedono. Non riescono a vedere i pulsanti o il menu di navigazione. La pagina web diventa un grande ammasso di contenuti non strutturati. Ancora peggio, spesso gli elementi interattivi, come i pulsanti, diventano completamente inutilizzabili. Navigando sul web, mi capita spesso di incontrare elementi <span> controllati da JavaScript, con lo stile di un pulsante. Il JavaScript è scritto per essere attivato da un clic del mouse. Questo funziona bene per tutti coloro che sanno usare il mouse, ma non può essere controllato dalla tastiera e spesso è impossibile per un utente di screen reader trovarlo.

Suggerimento: utilizzare l'HTML semantico

Se ha l'aspetto di un pulsante e si comporta come tale, dovrebbe essere un pulsante.

Il mio consiglio per evitare questo comportamento indesiderato probabilmente non è una sorpresa: usare il più possibile elementi HTML semantici appropriati. Gli unici casi in cui si dovrebbero usare gli elementi <div> e <span> sono quando non c'è nessun altro elemento disponibile per trasmettere il significato. Di solito si tratta solo di scopi decorativi.

L'uso di elementi semantici aumenta esponenzialmente l'accessibilità della pagina web. Infatti, questi elementi contengono informazioni per il browser su come devono essere utilizzati. Inoltre, come sviluppatore o ingegnere, farà risparmiare tempo. Non è necessario pensare di imitare il comportamento di un pulsante, ad esempio, perché funziona già in quel modo.

Utilizzo di elementi semantici sbagliati

Un altro errore comune in questa categoria è la scelta dell'elemento semantico sbagliato. Questo è spesso il risultato della scelta di un elemento per il suo aspetto invece che per il suo comportamento o il suo scopo. Forse non avete usato un <button> nativo perché vi sembrava brutto. O forse avete saltato alcuni livelli di intestazione e avete scelto un <h4> invece di un <h2>, perché vi piaceva che avesse una dimensione di carattere più piccola. Questo è il modo sbagliato di procedere; ci sono i CSS per questo scopo.

Suggerimento: scegliere un elemento per il suo significato

Utilizzate gli elementi HTML per strutturare il contenuto in base al significato di ciascun elemento, non al suo aspetto. Poi applicate gli stili a vostro piacimento con i CSS.

Suggerimento: utilizzare strumenti automatizzati

Un buon modo per aiutarvi con la semantica è usare un strumento di validazione HTML. Alcuni strumenti includono questo aspetto nei test di accessibilità automatizzati, come ad esempio axe Tools. Ricordate che gli strumenti automatici non possono testare tutto e spesso includono falsi positivi e negativi. Tuttavia, possono aiutare a individuare rapidamente gli errori che potreste aver trascurato. L'opzione migliore è quella di combinare test automatici e manuali per l'accessibilità.

Errore 2: etichette dei moduli mal strutturate

Se ha l'aspetto di un pulsante e si comporta come tale, dovrebbe essere un pulsante.

Questo errore ha molto a che fare anche con l'HTML semantico. Non fraintendetemi: progettare e implementare un modulo usabile, accessibile e dall'aspetto gradevole è una bella sfida!

Il modulo di accesso di Easy LMS. Le etichette si spostano verso l'alto quando si compila un campo del modulo, in modo da rimanere visibili.

L'ingresso e l'etichetta non sono collegati

Ogni modulo ha un campo di input e un'etichetta che lo descrive. Ad esempio, ho tre campi di input: "Nome", "Indirizzo e-mail" e "Azienda". Potrei aggiungere i nomi sopra gli input in testo semplice (ad esempio all'interno di un elemento <span>). Purtroppo, l'utente di uno screen reader troverà tre input di testo vuoti senza un'indicazione di cosa compilare.

Suggerimento: accoppiare etichetta e ingresso

L'uso di elementi HTML semantici per le etichette è già molto utile, ma se volete davvero aiutare i vostri utenti, dovreste anche accoppiare l'etichetta e l'input. Ora il browser sa che le due cose sono collegate. Noi di Easy LMS diremmo: profitto!

Utilizzo di attributi segnaposto come etichette

Un altro divieto di accessibilità è l'omissione delle etichette e l'uso di attributi segnaposto sugli input. Questa è una cattiva pratica per un paio di motivi. In primo luogo, spesso non è disponibile per molte tecnologie assistive. In secondo luogo, non appena l'utente digita l'input (o riempie automaticamente il modulo), le etichette scompaiono. In questo modo è difficile controllare che il modulo non contenga errori. Infine, un segnaposto è inteso come un suggerimento aggiuntivo, non come un'etichetta.

Suggerimento: Non sostituire un'etichetta con un segnaposto

Non omettete mai le etichette in un modulo. Se proprio dovete, usate i segnaposto solo per fornire suggerimenti aggiuntivi agli utenti (vedenti) nei moduli. Ma ancora meglio: non utilizzate affatto gli attributi segnaposto e assicuratevi che le informazioni importanti sul modulo siano disponibili a tutti.

Errore 3: utilizzare link non descrittivi

Quante volte vi siete imbattuti in link che dicevano "clicca qui", o "leggi di più", o "vai a questa pagina"? Secondo me, più di quante ne possiate contare! Una delle ragioni per cui questa è una cattiva pratica è che non permette di capire lo scopo del link al di fuori del contesto. Con le tecnologie assistive, gli utenti possono navigare rapidamente tra i link di una pagina. Immaginate che uno screen reader vi comunichi quanto segue: "Qui, link. Leggi di più, link. Questa pagina, link". Questo non vi dice nulla, vero?

Suggerimento: includere nel link l'oggetto della pagina

Quindi, come evitare questo problema? Nella maggior parte dei casi, questo problema può essere risolto facilmente includendo l'oggetto o il titolo della pagina a cui si fa riferimento all'interno del link. Vi faccio un esempio: potete saperne di più su diversi tipi di disabilità in questo articolo del W3C. Ora lo screen reader comunicherà: "diversi tipi di disabilità, link". Profitto!

Suggerimento: ottimizzare i link ripetuti

Posso immaginare che non si voglia includere il titolo in ogni link "Leggi tutto" sotto un elenco di articoli. Aggiunge molto disordine alla pagina. Esistono vari approcci diversi su come rendere accessibili i link "read more", e varia a seconda del caso d'uso quale funzionerebbe meglio. Su la panoramica di questo blog, abbiamo scelto di ottimizzare i link per gli screen reader aggiungendo un'aria-label che include il titolo dell'articolo.

Errore 4: dipendere dalle immagini come unico modo per trasmettere informazioni

Essendo un pensatore visivo, so quanto possa essere più facile capire qualcosa da un'immagine piuttosto che dalla lettura di un testo. Non voglio dire che l'uso di immagini per spiegare o fare riferimento a una spiegazione sia negativo. Anzi, incoraggerei tutti a usare le immagini in questo modo, perché per alcune disabilità (come la dislessia) migliora effettivamente l'accessibilità. Tuttavia, utilizzare le immagini come unico modo per trasmettere informazioni è una cattiva pratica.

In tutto il mondo, circa 43 milioni di persone sono cieche e circa 295 milioni di persone hanno problemi di vista da moderati a gravi. Questo numero non comprende solo la cecità totale, ma anche, ad esempio, la perdita della visione centrale o periferica e la visione offuscata. Se dipendete dalle immagini per spiegare il vostro punto di vista, rischiate che una parte del vostro pubblico si perda gran parte delle informazioni.

Screenshot

Un esempio reale di questo problema è la spiegazione dell'uso di un'interfaccia tramite schermate. Il testo recita semplicemente "fai clic sul pulsante indicato nella schermata" o "imposta la configurazione come indicato nella schermata seguente". Senza queste immagini, è impossibile sapere cosa fare con quelle istruzioni. Se si considera che questo tipo di articoli si trova spesso nelle banche della conoscenza, nella documentazione o nei tutorial, la situazione diventa ancora più problematica.

Un esempio di schermata del nostro Centro assistenza. Il testo di accompagnamento dell'articolo di aiuto recita: "È possibile regolare le impostazioni della categoria Pass selezionando Modifica".

Suggerimento: il testo deve essere comprensibile anche senza immagini.

Il pubblico deve essere in grado di comprendere le informazioni anche senza le immagini. Con le istruzioni sia nel testo che nelle immagini, il lettore può scegliere il modo preferito di recepire le informazioni o avere un ripiego in caso di difficoltà. Un trucco che uso personalmente è quello di scrivere il testo nella sua interezza e aggiungere le immagini successivamente, come ho fatto per questo articolo del blog. In questo modo, non incorrerò nella trappola di tralasciare un'informazione perché era visibile in un'immagine mentre scrivevo.

Mancanza di testo alternativo

Spesso le immagini informative che si trovano sui siti web hanno un testo alternativo scadente o non ce l'hanno affatto. L'obiettivo dei testi alternativi è quello di descrivere l'immagine per gli utenti di screen reader. Se questo testo viene lasciato vuoto, gli utenti di screen reader non sapranno cosa c'è nell'immagine o se si sono persi qualche informazione importante.

Suggerimento: aggiungere testi alternativi a immagini funzionali e informative

Il testo alternativo sarà comunicato a un utente che non può vedere l'immagine (correttamente). Invito tutti a non ignorare questi elementi, ma ad aggiungere un testo alternativo chiaro e descrittivo per l'immagine. Questo può essere fatto nel codice sorgente. In un CMS, spesso c'è un campo di inserimento dedicato.

Suggerimento: gestire in modo diverso le immagini decorative per gli screen reader

A volte le immagini vengono aggiunte solo come decorazione per rendere una pagina più attraente dal punto di vista visivo. A volte è meglio che le immagini vengano completamente ignorate da uno screen reader. Esistono diversi approcci su come gestire i testi alternativi a seconda dell'obiettivo dell'immagine.

Testo nelle immagini

Anche il testo nelle immagini non è comprensibile per le persone con problemi di vista. Sarete sorpresi dalla quantità di testo presente all'interno delle immagini (basta guardare qualsiasi piattaforma di social media). Ancora una volta, questo non è un male di per sé, ma assicuratevi di aggiungere il testo in una descrizione o come testo alternativo.

Errore 5: Scarso contrasto di colori

Scegliete un elemento HTML per il suo significato, non per il suo aspetto.

Il testo a basso contrasto è stato il problema di accessibilità più comunemente rilevato dai test automatici condotti da WebAIM. Questo problema non riguarda solo le persone ipovedenti, ma anche le persone con deficit della visione dei colori (diversi tipi di daltonismo). Circa 1 uomo su 12 e 1 donna su 200 presenta un certo grado di deficit della visione dei colori. Alcune persone non sono nemmeno consapevoli di esserne affette. Se guardate l'immagine qui sotto, quale numero vedete?

Which number do you see? Image source

Se si vede 74, è possibile che la visione dei colori sia normale. Se vedete 21 o nessun numero, potreste avere un deficienza di visione dei colori rosso-verde. In questo caso, potreste esservi imbattuti in siti web con parti difficili da leggere.

Nelle WCAG viene definito un Criterio di successo che stabilisce quando il contrasto tra il testo e lo sfondo è sufficientemente alto da consentire la lettura da parte di persone moderatamente ipovedenti. Le linee guida delle WCAG sono suddivise in tre livelli di conformità. Noi di Easy LMS puntiamo al livello AA. I rapporti di contrasto sono 4,5:1 per il testo piccolo e 3:1 per il testo grande.

Suggerimento: utilizzare uno strumento per controllare il contrasto dei colori.

Come si fa a capire se il contrasto del testo è sufficientemente alto? Esistono molti strumenti per il contrasto del colore che potete utilizzare per eseguire test sulla vostra pagina web. È anche possibile verificare manualmente il contrasto dei colori inserendo i codici dei colori di primo piano e di sfondo in un controller di contrasto online.

Suggerimento: utilizzare tonalità più scure o più chiare di un colore.

Un problema che spesso si presenta è che i colori utilizzati nell'interfaccia utente corrispondono ai colori del logo del marchio. Questo può rendere il problema difficile da risolvere, poiché i colori sembrano far parte dell'identità del marchio. Una buona pratica consiste nell'utilizzare una tonalità più scura o più chiara del colore desiderato per migliorare il contrasto. Abbiamo modificato i colori di Easy LMS per questo motivo un paio di anni fa!

Utilizzare il colore come unico mezzo per trasmettere informazioni

Prima ho accennato ai problemi che derivano dall'uso delle immagini come unico mezzo per trasmettere le informazioni. Lo stesso vale per i colori. I colori rosso e verde sono spesso utilizzati come unico modo per informare sugli stati di successo e di errore. Purtroppo, il daltonismo rosso-verde è il tipo più comune di daltonismo. Per questi utenti affetti, il rosso e il verde si assomigliano.

Suggerimento: fornire più modi per comunicare gli stati

Va bene usare il rosso e il verde per questi scopi, ma assicuratevi di fornire sempre un altro modo per comunicare gli stati, come testo, forme diverse o icone (etichettate).

Errore 6: non fornire un'indicazione visiva del focus attuale

La maggior parte degli utenti naviga sul computer con un dispositivo di puntamento, come il mouse o il trackpad di un computer portatile. Sui dispositivi mobili, usiamo le dita su uno schermo tattile. Per alcuni utenti questo è difficile o impossibile a causa della loro disabilità. Ne sono un esempio la paralisi, la mancanza di una parte del corpo, l'artrite o la lesione da stress ripetitivo. In questi casi, gli utenti passano spesso a una tastiera o a un dispositivo di input alternativo in grado di imitare il comportamento della tastiera. Gli utenti con disabilità visive utilizzano per lo più una tastiera insieme al loro lettore di schermo o ai gesti sui loro dispositivi mobili.

Premendo il tasto Tab sulla tastiera, è possibile passare da un elemento interattivo all'altro di una pagina web, come pulsanti e collegamenti. Potete provarlo in questa pagina: dopo ogni tabulazione, vedrete un'indicazione visiva della vostra posizione sullo schermo.

Stili di messa a fuoco CSS

Nei CSS è possibile aggiungere lo stile per diversi stati dei pulsanti, come hover, focus e active. Spesso alcuni o tutti questi stati vengono tralasciati e il pulsante non cambia aspetto con l'interazione. In questo caso, l'utente della tastiera si trova alla cieca.

Suggerimento: applicare gli stili di messa a fuoco insieme agli stili di passaggio del mouse

Mentre si aggiungono gli stili per lo stato hover dei pulsanti, è buona norma aggiungerli anche per lo stato focus. Idealmente, lo stile focus dovrebbe essere più evidente dello stile hover, quindi è possibile aggiungerli separatamente in una tonalità diversa.

Contorno del focus del browser

Un indicatore di messa a fuoco di base è fornito automaticamente dal browser web ed è tipicamente visualizzato come un bordo. Se avete appena sfogliato questa pagina, potreste averlo visto. Purtroppo, questo contorno viene spesso disabilitato con i CSS, per motivi estetici. Ma con il contorno disabilitato e senza stili di focalizzazione, è impossibile navigare in una pagina web solo con la tastiera.

Suggerimento: non disabilitare il contorno

Gli utenti che utilizzano il mouse non vedranno il contorno del browser che si vede quando si scorre una pagina web con la tastiera. Non disabilitate questo contorno con i CSS, perché è un aiuto essenziale per gli utenti disabili. Funziona anche bene come riserva nel caso in cui gli stili di messa a fuoco siano troppo poco chiari o manchino per sbaglio.

Tenete presente che gli indicatori di attenzione da tastiera dei browser possono variare e assumere forme diverse. Per questo motivo, non ci si può affidare completamente a loro. D'altra parte, ci vorrebbero molti test per sapere con certezza se gli stili di messa a fuoco sono sufficientemente chiari per gli utenti disabili. Ecco perché consiglio di avere sempre entrambi.

Errore 7: utilizzare icone senza etichetta nei pulsanti e nei link

Le icone utilizzate nel software diventano riconoscibili con l'uso ripetuto.

Le icone sono un ottimo modo per evitare il disordine nel vostro prodotto online. Hanno anche il potere di migliorare l'accessibilità per le varie disabilità, se non sono ambigue. La maggior parte di noi sa che l'icona della matita significa "modifica" e il cestino "cancella". Quando usiamo le icone in un'interfaccia utente, è meglio attenersi a quelle che conosciamo per evitare di fare congetture. Ma anche in questo caso, in termini di accessibilità, molte cose possono andare storte.

Le icone possono essere utilizzate accanto alla corrispondente etichetta di testo o da sole. Il più delle volte, quando sono da sole, non viene fornita alcuna etichetta. Ad esempio, aggiungo un pulsante icona per un'azione di modifica, con all'interno solo l'icona di una matita. Se non aggiungo un'etichetta di testo per questa icona, il pulsante diventa un pulsante vuoto. Esatto: uno screen reader mi comunicherà: "Pulsante". Questo non è molto utile.
Anzi di più: Parto dal presupposto che l'utente sappia che l'icona della matita significa "modifica". Ma non lo so con certezza.

Suggerimento: aggiungere un'etichetta per le icone

Se l'icona è una parte importante dell'interfaccia utente, è meglio aggiungere un'etichetta. È possibile farlo aggiungendo un aria-label all'icona. Un secondo modo è quello di aggiungere testo che si nasconde per gli schermi ma è visibile per gli utenti di screen reader. È meglio aggiungere anche un attributo titolo. In questo modo, se un utente ci passa sopra con il mouse, l'etichetta viene visualizzata.

Pulsanti icona nella dashboard di Easy LMS che mostrano un titolo quando si passa il mouse su di essi

Suggerimento: nascondere le icone decorative

Se si è aggiunta un'icona solo come zucchero in cima e l'informazione è comprensibile anche senza, allora è meglio nascondere l'elemento per gli utenti di screen reader.

Conclusione: non lavorare di più, ma in modo più intelligente.

Il pensiero di dover cambiare queste cose potrebbe essere ancora un po' opprimente. Quando ho imparato a conoscere l'accessibilità, ho avuto la stessa reazione. C'è così tanto da imparare e così tanti tipi diversi di disabilità. È difficile realizzare un'interfaccia utente perfetta per tutti.

Ma voglio dirvi che non si tratta di rivedere il vostro prodotto o il vostro sito web. Ho scoperto che il modo migliore per farlo è integrarlo nel flusso di lavoro. La volta successiva che creo o itero una parte del prodotto, applico subito ciò che ho imparato sull'accessibilità. In questo modo, possiamo migliorare l'accessibilità un passo alla volta. Come consiglia uno dei miei eroi dell'accessibilità Léonie Watson: "Non deve essere perfetto; deve solo essere un po' meglio di ieri". Predica!