Accessibilità per tutti
Se la forma di un oggetto risulterà “bella” sarà merito della strutturazione logica e dell’esattezza nella soluzione dei vari componenti. Il “bello” è la conseguenza del “giusto”. Una progettazione esatta dà un oggetto bello.
Bruno Munari, Arte come mestiere
Negli ultimi anni chi crea servizi web si sarà molto probabilmente imbattuto nell’esigenza di rendere accessibile alle persone con disabilità questi servizi.
Soprattutto se il sito web è quello di un’azienda presente sul mercato statunitense, è molto probabile che questa sia stata (o sarà) coinvolta in cause legali per discriminazione degli utenti con disabilità, e che debba correre ai ripari a posteriori, cioè dopo aver costruito il proprio sito, con l’urgenza di una causa, in un ambito purtroppo ancora poco conosciuto, fatto di acronimi, leggi e documentazioni complesse.
In questo articolo proverò a spiegare a tutti, indipendentemente dalla competenze specifiche, perché si dovrebbe considerare l’accessibilità dei prodotti e dei servizi che si creano sin dal principio.
Innanzitutto, perché un sito web sia accessibile, tutte le sue funzionalità interattive (link, bottoni, form, ecc.) devono poter essere utilizzate sia tramite mouse che tramite tastiera. Il contenuto deve essere codificato in modo tale da poter essere convertito in una traduzione audio da quei software che si chiamano screen reader perchè leggono ad alta voce quello che appare sullo schermo. Il design deve essere semplice, intuitivo e coerente, e i video devono includere descrizioni e sottotitoli per i non udenti.
Per evitare scorciatoie di metodo, il tema dell’accessibilità si deve inquadrare fin da subito all’interno della più ampia metodologia dell’universal design, il cui proposito è quello di progettare ambienti e servizi utilizzabili da tutte le persone senza ricorrere, per quanto possibile, a soluzioni ad hoc.
Un esempio dal mondo fisico per chiarire il concetto:
Da una parte una scalinata che può essere percorsa assieme da chi si muove su una sedia a rotelle, in bicicletta, camminando, trasportando un passeggino o un trolley. Dall’altra una rampa di scale posticcia, formalmente accessibile ma sostanzialmente brutta e sbagliata, perché costringe parte degli utenti ad un’esperienza diversa ed avvilente.
Utenti vs. Aziende
Negli Stati Uniti il sistema giudiziario permette agli utenti con disabilità di fare causa alle aziende i cui siti web sono inaccessibili, appellandosi principalmente a due leggi: l’Americans with Disabilities Act (ADA) e la Section 508.
Nonostante l’ADA sia una legge del 1990, epoca pre web, i servizi digitali vengono ora giustamente equiparati agli ambienti e ai servizi fisici, e di conseguenza vengono valutati come discriminatori gli ostacoli ed impedimenti posti dalla tecnologia.
Secondo il report di UsableNet del 2019, negli ultimi anni c’è stato un aumento esponenziale delle cause: da 262 cause nel 2016 a ben 2235 nel 2019.
In Italia, per ora, sono solo i siti web della pubblica amministrazione ad essere obbligati dalla “Legge Stanca” ad essere accessibili, ma il sistema di controllo è più burocratico di quello statunitense e non incentiva le cause civili da parte degli utenti.
L’Europa dovrebbe diventare presto più esigente con l’entrata in vigore dello European Accessibility Act (EAA), che definisce i requisiti di accessibilità di diversi servizi digitali (di un sito e-commerce come di uno sportello per il prelievo).
I procedimenti legali negli Stati Uniti hanno avuto il merito di riportare l’attenzione di chi crea siti web sul destinatario di quei servizi, gli utenti.
Utenti
Secondo la World Bank, il 15% della popolazione mondiale ha una qualche forma di disabilità.
Le persone possono avere disturbi della vista come il daltonismo, l’ipovisione o la cecità; possono avere disabilità motorie più o meno gravi dovute a paralisi cerebrali infantili, incidenti o malattie; possono essere affette da sordità più o meno profonda; possono avere disabilità cognitive, in cui ricadono oltre alla sindrome di Down o i disturbi dello spettro autistico, anche i disturbi dell’apprendimento, come la dislessia o il deficit dell’attenzione.
Questa ampia varietà di persone come può utilizzare un sito web?
Chi non vede molto probabilmente utilizzerà uno screen reader, un software che legge ad alta voce quello che appare o succede sullo schermo; per interagire con gli elementi interattivi dell’interfaccia userà solo la tastiera, non potendo vedere il puntatore del mouse. VoiceOver è lo screen reader che si trova già installato su ogni Mac e iPhone, su Windows è possibile installare gratuitamente NVDA, mentre su Android troviamo TalkBack.
Chi è affetto da ipovisione probabilmente ingrandirà moltissimo lo schermo, o potrebbe attivare una visualizzazione del sistema operativo ad alto contrasto e colori invertiti (testo bianco su sfondo nero).
Gli screen reader non sono utilizzati solo da chi ha problemi di vista, ma anche da chi, avendo disturbi come la dislessia, potrebbe trovare più semplice seguire qualcuno che gli legge un testo.
Chi ha disabilità motorie che coinvolgono gli arti superiore probabilmente userà solo la tastiera per interagire con le pagine, che potrebbe essere una tastiera fisica o virtuale, con cui interagire tramite adaptive switches, bottoni e joystick che si possono premere col movimento della testa, per esempio.
Per quanto riguarda le persone con sordità, si potrebbe superficialmente pensare che possano usufruire facilmente di un sito web, ad eccezione dei contenuti video per i quali ovviamente necessitano di sottotitoli. In realtà per un sordo potrebbe essere un problema comprendere i contenuti più complessi, poiché chi è sordo dalla nascita non sempre conosce la lingua italiana nella sua completezza.
Abbiamo elencato brevemente una serie di disabilità — visive, uditive, motorie e cognitive — e una serie di tecnologie assistive — tastiera, screen readers, adaptive switches. Anche i software di riconoscimento vocale, che si stanno diffondendo per tutti, possono apportare un grande miglioramento nell’autonomia di una persona con disabilità.
Vale la pena aggiungere che i problemi elencati possono essere permanenti, temporanei o dipendere dalla situazione. La sindrome del tunnel carpale, per esempio, o una frattura, sono impedimenti temporanei. Ma anche trovarsi in ambiente molto luminoso, o tenere in braccio un bambino, possono causare una difficoltà maggiore (seppur momentanea) nell’utilizzo di un dispositivo mobile.
Gli accorgimenti che introdurremo, volti a migliorare l’accessibilità, migliorano l’usabilità per tutti gli utenti.
Accessibility means that people with a disability can do what they need to do in a similar amount of time and effort as someone that does not have a disability. It means that people are empowered, can be independent, and will not be frustrated by something that is poorly designed or implemented.
Come disegnare per tutti gli utenti
Per quanto disorientante possa sembrare questa varietà di modi di utilizzo, per progettare un servizio digitale in modo da includere tutti, bisogna seguire gli standard, che per i designer sono le convenzioni di design e le regole definite dal W3C.
Iniziamo da alcune indicazioni elementari, molto spesso ignorate:
- I testi ed i controlli interattivi (form, bottoni, link) devono essere di un colore sufficientemente contrastato con lo sfondo, per facilitarne la lettura e l’individuazione.
- Le informazioni, come gli errori di compilazione di un form, devono essere trasmesse attraverso una combinazione di colore, forma e testo.
I layout delle pagine di un sito devono essere logici, semplici e coerenti, in modo tale da non costringere gli utenti a continui sforzi cognitivi per comprendere la struttura delle informazioni.
Un altro aspetto importante della progettazione riguarda i pattern UX. L’utente riconosce immediatamente la funzione e l’interazione richiesta da un componente dell’interfaccia, se il design segue delle convenzioni comuni tra le interfacce digitali.
Nel momento in cui si inventa un pattern nuovo — o si utilizza un pattern nato per assolvere una funzione per un altro scopo — si va incontro ad un problema di usabilità e di accessibilità.
Il W3C descrive in modo molto analitico quelli che sono i pattern standard più diffusi e le interazioni (tramite tastiera) che l’utente si aspetta da tali pattern. Il sito è estremamente dettagliato e richiede tempo per orientarsi. Ma è interessante perché precisa alcuni termini: che differenza c’è tra una select e una combobox? E tra una modal e una dialog?
Come sviluppare per tutti gli utenti
Gli sviluppatori hanno due responsabilità importanti: la prima è che il sito web funzioni tramite l’utilizzo della sola tastiera, la seconda è che sia convertito dagli screen reader in una traduzione audio sensata.
Sviluppare per chi utilizza la tastiera
Forse non tutti sanno che… tramite tasto Tab e Shift Tab si naviga tra gli elementi interattivi della pagina. Tramite Frecce, Barra spaziatrice e Invio si interagisce con gli elementi interattivi, per esempio, modificando l’opzione selezionata di un menu, selezionando una checkbox o seguendo un link.
Quando un utente naviga tramite tastiera:
1 — Tutte le funzionalità interattive devono essere disponibili usando la tastiera.
2 — La navigazione tramite Tab deve seguire l’ordine logico di lettura (dall’alto in basso, da sinistra a destra).
3 — Gli elementi interattivi attivi, cioè con il focus della tastiera, devono essere individuabili tramite un outline visibile.
Sviluppare per chi utilizza gli screen reader
Abbiamo detto prima, parlando di pattern UX, che gli utenti capiscono il l’interazione possibile di un componente perché la forma include degli indizi visivi che rimandano l’utente ad altri componenti simili già visti. Ad esempio, se vediamo delle frecce rivolte a destra e sinistra in prossimità di un’immagine, possiamo facilmente dedurre che cliccandole l’immagine cambierà.
Gli utenti che non vedono non possono basarsi sulla forma degli elementi dell’interfaccia per riconoscerne il significato, devono basarsi sulla traduzione che lo screen reader gliene fa. Affinché gli screen reader traducano correttamente il significato degli elementi è fondamentale che gli elementi HTML scelti per codificare la pagina siano semantici.
(Per costruire un link ci vuole un tag <a>; per creare un bottone, che cliccato provoca un evento in pagina, ci vuole un <button>, e così via.)
E’ quindi importante seguire gli standard e le regole base dell’HTML. Soprattutto è necessario:
- associare i campi dei form con le rispettive label;
- strutturare le pagine in modo semantico con titoli opportuni (headings) e gli elementi strutturali messi a disposizione da HTML5 (landmarks);
- attribuire alle immagini un testo alternativo, usando sempre l’attributo alt, che può essere vuoto, nel caso di immagini decorative o con significato ridondante rispetto al contesto, ma deve contenere testi alternativi se le immagini sono informative o interattive.
Quando l’HTML standard non è sufficiente ad esprimere il significato di un componente complesso, diventa necessario seguire un ulteriore standard, che si chiama WAI-ARIA, o semplicemente ARIA.
ARIA è una specifica prodotta dal W3C, che definisce una serie di attributi HTML addizionali che possono essere applicati agli elementi per fornire maggior valore semantico.
(Attenzione: applicare gli attributi ARIA non aggiunge comportamenti, aggiunge solo significati e aspettative sulle interazioni tramite tastiera, che poi andranno implementate tramite Javascript.)
Come misurare l’accessibilità web
Il W3C oltre a definire e descrivere i pattern di sviluppo e design, ha stilato le linee guida che sono diventate lo standard internazionale per misurare e valutare l’accessibilità dei contenuti digitali. Si chiamano Web Content Accessibility Guidelines (WCAG), la versione di riferimento è la 2.1 ed il livello a cui solitamente è richiesto conformarsi è quello indicato come AA.
Le linee guida ufficiali del W3C sono molto dettagliate e complesse, per iniziare ad orientarsi è meglio fare riferimento all’interpretazione più pragmatica fatta da WebAIM.
Per orientarsi basti sapere che ci sono 78 Success Criteria, requisiti oggettivi e testabili, suddivisi in 4 principi generali: Perceivable, Operable, Understandable e Robust (ricordatevi l’acronimo P.O.U.R).
Perceivable
Sotto il principio Perceivable troviamo tutti quei requisiti che riguardano il fatto che l’utente sia in grado di percepire (con uno dei cinque sensi) il contenuto presente in pagina.
Operable
Sotto il principio Operable ricadono tutti quei requisiti che riguardano il fatto che l’utente sia in grado di interagire con gli elementi interattivi dell’interfaccia.
Understandable
Nel principio Understandable rientrano i Success Criteria che concernono il fatto che l’utente sia in grado di capire le informazioni e le interazioni possibili.
Robust
Infine, nell’ultimo principio, Robust, troviamo solo pochissimi requisiti il cui scopo è quello di assicurarsi che il contenuto web sia resista all’evolversi della tecnologia.
Come testare l’accessibilità di un sito
Se siete arrivati fin qui nella lettura, avrete capito quanto gli standard possano diventare complessi, e vi starete chiedendo se ci siano strumenti per testare automaticamente l’accessibilità di un sito. Purtroppo solo parte dei requisiti (il 30-40%) possono essere testati automaticamente. Strumenti come Lighthouse, Axe e Wave offrono un valido aiuto in questo, ma il loro output va sempre interpretato.
Ad esempio, Lighthouse può capire se ci sono immagini senza testo alternativo, ma non può valutare se il testo alternativo a un’immagine ha senso nel contesto.
Inoltre aspetti fondamentali, come il fatto che la navigazione tramite tastiera funzioni, devono essere testati manualmente, usando prima la tastiera, poi lo screen reader.
In fin dei conti, l’accessibilità è una questione di usabilità, e solo un umano può valutare la sensatezza e la pertinenza dell’interfaccia web nel suo complesso.
Conclusione
I procedimenti legali negli Stati Uniti hanno avuto il merito di riportare l’attenzione sugli utenti e sull’importanza dell’usabilità universale come criterio logico per la costruzione di un servizio web.
Purtroppo, intervenire a posteriori per correggere gli errori di design e sviluppo è poco efficace, costoso, ed il rischio di ricorrere a soluzioni posticce come la rampa vista sopra è molto alto. Inoltre, dopo il rimedio d’emergenza tutti rischiano di dimenticarsi dei requisiti di accessibilità, per il semplice fatto che la maggior parte di essi sono invisibili. I manager dei progetti difficilmente utilizzeranno uno screen reader per navigare, e non si può contare solo sulla buona volontà di designer e sviluppatori.
L’accessibilità dovrebbe diventare parte organica, condivisa ed esplicita del processo che si adotta per la creazione dei servizi digitali.
