Da qualche anno ho cominciato a riflettere sul perché proprio ora si senta parlare - più spesso - di accessibilità legata alle app e ai siti web, come se finalmente ora fosse diventato un tema sociale. Come, dopo la lotta alle barriere architettoniche, per i marciapiedi con gli scivoli, per i parcheggi riservati, finalmente arrivasse il turno di tutti gli utenti web e mobile di poter fruire dei contenuti digitali e utilizzare i servizi, acquistare i prodotti online, con la stessa semplicità (oddio, magari fosse sempre vero per tutti) di ogni utente dotato di ogni senso, ogni capacità motoria e cognitiva.
Sì, di accessibilità, non di accesso nel senso di login o disponibilità di siti e app come ancora qualcuno crede di capire, ma del diritto di tutti gli utenti, anche i meno fortunati, quelli che per vari motivi, evidenti o meno, hanno difficoltà a usare un PC o uno smartphone, un sito web o un’app. In inglese si usa il termine impaired, forse perché nel nostro paese abbiamo ancora qualche difficoltà ad accettare le diversità e le disabilità e quindi adottiamo inglesismi per edulcorare il concetto.
Le disabilità che possono compromettere il corretto uso di un contenuto digitale sono svariate (ah! to impair vuol dire compromettere). Siamo probabilmente troppo abituati a pensare alle capacità visive ridotte o assenti, ma la palette di casistiche è molto varia per organo e per età. Si va dagli occhi appunto, all’utilizzo delle mani, alla capacità di lettura, di comprensione e memorizzazione del testo, di movimento e guida del mouse, di ascolto, all’uso di qualunque arto, all’uso o non uso della voce, alla capacità di esprimersi… probabilmente troveremmo un argomento per ogni capitolo dell’Anatomia del Gray (sì, proprio lui, il nome della serie TV che sfida il record di Beautiful è un gioco di parole sul più famoso Manuale di Anatomia di fine ‘800 giunto fino ai giorni nostri nelle aule di medicina).
Ebbene, stiamo parlando, dunque, da un lato di difficoltà neuro-psico-motorie esistite probabilmente da… sempre… che impattano il 15% della popolazione mondiale secondo le stime delle Nazioni Unite e dell’OMS e di contenuti digitali e funzioni elettroniche come usare un PC, un telefono poi diventato smart (forse), un call center, una segreteria telefonica, un’app, un e-commerce, un chatbot, un’assistente virtuale, visori 3D, VR, AR. Ho il pallino della matematica: tutti questi gadget e queste bellissime cose con cui siamo nati e cresciuti, rendendoci la vita facile, smart, allegra, veloce etc hanno un target di 85 persone su 100 ($ e reperibilità permettendo)?
Ecco, per fortuna non è sempre così, e non è stato sempre così. Ci sono tanti ma e tanti se, ma tutto diventerebbe più semplice se ognuno di noi nel proprio lavoro, nel proprio quotidiano si domandasse cosa farebbe almeno 1 di quel 15%.
Io posso raccontarvi quello che è successo da quando il web e poi il mobile hanno preso piede, di come certi illuminati si sono attrezzati alla grande, e di come ho vissuto io questo percorso che inizia proprio con la storia che vi sto per raccontare e arriva ai giorni nostri.
La fine degli anni ’90 e il W3C
In realtà già dalla diffusione del WWW e con la creazione dei primi siti web rigorosamente da guarda in bianco e nero o in monocromatico, e con modem a 33K, e guai se ci fosse stata una foto, ci avresti passato un pomeriggio intero… Il consorzio W3C aveva emanato una serie di linee guida che oltre a permettere globalmente di accedere al WWW senza distinzione di hardware, software, luogo, lingua e abilità informatica, raccomandava speciale attenzione alle categorie con disabilità visive, uditive, cognitive e motorie.
Il messaggio era chiaro: il web è inclusivo. Ricordate questo termine, ci torneremo molto più avanti. C’era grande attenzione nella descrizione delle immagini (alt-text), nella possibilità di potersi muovere tra i form anche senza il mouse, magari con il tab dando un ordine ai campi (tab-order).
Nascono i primi strumenti di mercato screenreader, semplici TTS (text-to-speech) o sintetizzatori vocali, in grado di leggere all’utente ciò che appariva sul video e di suggerire quali erano le informazioni e quali erano le azioni possibili che poteva compiere, semplicemente premendo la barra. Se volete provare questo dialogo nel buio col sito di UNGUESS, lo trovate qui JAWS.
In Italia intanto
Per una volta intanto in Italia non stiamo a guardare. Agli inizi del 2004, tra i primi in Europa, su proposta dell’allora Ministro dell’Innovazione e infrastrutture tecnologiche Lucio Stanca, viene pubblicata la legge che porta il suo nome e che impone il requisito di Accessibilità come indica il W3C a tutti i siti della Pubblica Amministrazione, aziende collegate con servizi pubblici, incluse le aziende informatiche che con esse collaborano, aziende di trasporto pubbliche, sanitarie etc…
Oggi se ne occupa AGID con una procedura che prevede l’introduzione dell’accessibilità per le app Mobile e le postazioni di lavoro per i lavoratori con disabilità. Inoltre, introduce la valutazione soggettiva delle iniziative da effettuare (rispetto ai costi/benefici sulla finanza pubblica) con i soggetti interessati, un moderatore, focus group a seconda dei contesti e della tipologia di utenti da coinvolgere. Dopo la dichiarazione di accessibilità, l’ente certificato può fregiarsi del badge emesso dall’ente certificatore.
Anche nella grande community di AppQuality siamo stati in grado di condurre test in particolari condizioni e con utenti molto entusiasti di condurre un tema sull’accessibilità. A volte non sono solo le PA a farlo “per normativa”, ma come dicevamo prima ci sono aziende di prodotti e servizi che ormai non posso trascurare più quel 15% dei loro clienti e girarsi dall’altra parte.
I pilastri dell’accessibilità
#1 — Il contenuto deve essere PERCEPIBILE
Anche se un utente ha deficit visivi o ha difficoltà a sentire, i contenuti e gli elementi funzionali devono essere chiari e fruibili. Ciò comporta tutta una serie di strategie che includono: il contrasto del colore, il dimensionamento dei caratteri e l’obbligo di inserire un Alt-text accurato e descrittivo.
#2 — Il contenuto deve essere OPERABILE
Un utente può operare e navigare attraverso il sito? Non tutti possono usare un mouse! Ci devono essere altri modi di utilizzare il sito (es. tasti o voce). Le informazioni importanti devono essere mostrate lentamente e quando serve, poiché alcuni disturbi cognitivi possono rallentare notevolmente la comprensione della lettura. Anche la dislessia rende difficile usare il web e le app.
#3 — Il contenuto deve essere COMPRENSIBILE
Il contenuto della pagina è organizzato e presentato in modo da evitare confusione? Il sito è strutturato in modo prevedibile e coerente? Usa un linguaggio chiaro? Gli utenti possono avere diverse capacità cognitive e visive, sia a causa di un disturbo fisico o per la mancanza di istruzione nelle aree rurali.
#4 — Il contenuto deve essere ROBUSTO
I siti web più accessibili sono quelli costruiti con HTML, CSS e JS in modo compatibile con il maggior numero di browser e funzionano con la stragrande maggioranza dei tool assistivi. La conoscenza della tecnologia futura, così come i tool obsoleti che alcuni utenti potrebbero ancora utilizzare, sono sempre importanti da tenere in considerazione.
Una rinfrescata di HTML
Il mio Nerd interiore reclama la sua parte. Vi mostro cosa vuol dire per uno sviluppatore “adempiere” a questi requisiti. In realtà lo faccio perché nello storytelling questo punto e come sono andate le cose ci ha fatto arrivare agli anni 202X con tutte queste app e siti che di accessibile hanno poco. Anzi alcuni siti non sono nemmeno cross browser. O cross smartphone. Anche alcune app. O Sistema Operativo. UNGUESS pensaci tu!
- Separate la presentazione di un documento dal suo contenuto: ciò significa che, da un lato, occorre evitare di inserire nel codice (X)HTML vincoli di presentazione, dall’altro occorre usare i CSS per definire la formattazione del documento e la sua eventuale presentazione per altri media (stampa, sintetizzatori vocali, mobile, TV, ecc.)
- Usate la Dtd strict di XHTML 1.0 o, in alternativa, la Dtd di XHTML 1.1: sono le più adeguate a raggiungere lo scopo di separare la presentazione dal contenuto
- Non affidate nessuna informazione esclusivamente all’uso del colore
- Evidenziate la struttura logica dei contenuti testuali, usando nel modo più appropriato gli appositi elementi e attributi strutturali di (X)HTML
- Realizzate moduli accessibili, utilizzando gli appositi elementi e attributi – FIELDSET, LABEL, ecc. – e i CSS per rendere i vari campi più visibili nella pagina (ed eventualmente ingrandibili a discrezione dell’utente)
- Rendete accessibili le tabelle di dati, utilizzando gli appositi elementi e attributi strutturali previsti a partire da HTML 4: CAPTION, TH, COL, COLGROUP, summary, scope, headers, id, ecc.
- Sostituite le tabelle usate a scopo di impaginazione con soluzioni basate sui CSS. Se decidete di utilizzare comunque delle tabelle di impaginazione, evitate possibilmente di annidare più tabelle una nell’altra e, soprattutto, di formattarne le celle per mezzo di elementi e attributi di presentazione (X)HTML. Per la loro formattazione usate piuttosto i CSS e, soprattutto, assicuratevi che il contenuto di ciascuna tabella di impaginazione venga linearizzato correttamente, se letto in modalità non grafica
- Scrivete alt-text che svolgano una funzione equivalente a quella del contenuto non testuale che sostituiscono.
- Scrivete testi accessibili, in cui sia esaltata la semplicità, la correttezza e l’adeguatezza del linguaggio, e siano allo stesso tempo evitate le deformazioni e le incomprensibilità proprie dello stile pubblicitario, dello stile tecnicistico e dello stile burocratico.
- Non utilizzate frame. Esistono altri modi più accessibili di costruire un’interfaccia di navigazione
- Realizzate pagine i cui contenuti rimangano accessibili nelle più disparate condizioni d’uso, piuttosto che pagine che si vedano allo stesso modo su tutti i principali browser grafici e device: liberatevi, cioè, dal “pregiudizio della stampa”
- Scrivete pagine basate su codice (X)HTML e CSS valido
- Usate strumenti automatici per scoprire gli errori di accessibilità legati al codice
- Usate la revisione umana per verificare l’accessibilità di tutti gli elementi della pagina non controllabili in automatico (proprietà e correttezza dei testi, comprensibilità dei meccanismi di navigazione, contrasto primo piano/sfondo, ecc.)
- Ponetevi come obiettivo il raggiungimento di un’accessibilità reale, verificata per mezzo di test e riscontri con individui umani, piuttosto che la sterile esposizione di bollini di conformità.
Io personalmente concordo sugli ultimissimi punti, non me ne vogliano i dev, sono stato sviluppatore anche io, ma pensare come e dove verrà visualizzato un contenuto o dovrà essere compilato un form la dice lunga su come dovrete scegliere i componenti migliori, il codice corretto e poi i test da fare, quali fare, a chi farli fare, e mettere l’utente prima di tutto, al centro. Piuttosto che il bollino.