Il modo in cui ci serviamo degli oggetti che usiamo ogni giorno è qualcosa che tendiamo a dare per scontato, ed è così anche per la fruizione del web. Possiamo usare intuitivamente tastiera e mouse, oppure le dita delle mani, possiamo guardare immagini e ascoltare suoni che veicolano i contenuti che ci interessano. Sappiamo bene, però, che non è così per tutti: fruire appieno di vista, udito e mani non è sempre possibile, ed è quindi importante per chi costruisce oggetti – nel nostro caso, siti e applicazioni Web – pensare a queste disabilità in modo che non diventino un ostacolo all’utilizzo dei contenuti che si vogliono proporre.
È questa la mentalità da assumere quando si vuole implementare una Web Application con un requisito di accessibilità, come quella che stiamo sviluppando noi per un nostro cliente. Occorre chiedersi se ogni parte della nostra applicazione, ogni contenuto esistente, o che volessimo aggiungere, sia o meno fruibile da ogni categoria di utente.
Gli strumenti utilizzati dagli utenti affetti da disabilità vengono definiti tecnologie assistive: queste hanno lo scopo di interporsi tra il browser e l’utente, permettendogli d’interagire con il contenuto della pagina. Esempi comuni sono i lettori di schermo e tastiere braille per non vedenti, oppure dispositivi come gli switch (semplice dispositivo a due tasti), i puntatori oculari e i software di riconoscimento vocale per chi è affetto da severi deficit fisici.
L’HTML generato nell’applicazione viene tradotto dal browser in un albero gerarchico contenente le informazioni come il ruolo, il nome e lo stato di ogni oggetto presente nella pagina (accessibility tree). Sulla base di queste informazioni le tecnologie assistive riescono a interpretare e descrivere all’utente quello che è visualizzato nella pagina e come è possibile interagirci. Per permettere a questi strumenti di decifrare correttamente il contenuto della pagina e fornirne agli utenti un’interpretazione coerente e utilizzabile, è importante che la semantica dei componenti della pagina sia facilmente derivabile dal codice della pagina stessa. Per ottenere ciò possiamo rifarci ad alcuni standard.
Obiettivi principali
Il World Wide Web Consortium (W3C), l’organizzazione di standardizzazione del Web, ha definito le linee guida (WCAG) che siti e applicazioni Web devono seguire per essere accessibili, dividendoli in tre livelli di compatibilità (A, AA, AAA). Dopo alcuni mesi di lavoro su questi requisiti possiamo individuare alcune linee guida che riassumono con buona approssimazione le richieste del W3C.
Contenuti alternativi
Qualunque contenuto presente sulla pagina che abbia significato per l’utente deve poter essere fruibile a prescindere dalla tecnologia di interazione (standard o assistiva) di cui l’utente si serve.
Il testo semplice è il formato più versatile, potendo essere visualizzato o riprodotto da sintetizzatori audio, display braille o altre tecnologie assistive, e quindi adattato a qualsiasi disabilità. Possono però essere necessari testi aggiuntivi per meglio spiegare la funzionalità di ogni componente: un link a una pagina di recapiti, visibile semplicemente come “Contatti” su un sito, potrebbe dover essere letto come “Vai a Contatti” per far comprendere che si tratta di un link. Se poi si volesse supportare anche un’utenza con handicap cognitivi, potrebbero servire testi con parole più semplici e grammatica elementare (un esempio è la Wikipedia in Simple English).
Un’immagine è invece pensata per la vista, quindi necessita di una descrizione alternativa (preferibilmente testuale) per chi ha handicap visivi. Allo stesso modo un audio necessita di una trascrizione per chi ha handicap uditivi. Un video richiede, di norma, sia vista che udito per la sua fruizione, in modo complementare e non alternativo: un non vedente avrà probabilmente bisogno non solo dell’audio originale, ma di una descrizione delle immagini, un non udente dovrà servirsi sia del video che di sottotitoli per una piena comprensione.
I media basati sul tempo (come audio e video) impongono poi anche un vincolo di velocità, di ritmo nel veicolare l’informazione, che non sempre è compatibile con le capacità dell’utente: anche questa esigenza può essere soddisfatta da una descrizione testuale.
Esplicitare il significato: usare HTML in modo “semantico”
Il significato di un’applicazione Web, come di qualsiasi oggetto con cui veniamo a contatto, dipende dal significato di ogni elemento che la costituisce e da come questi interagiscono. La funzionalità di invio in una webmail, per esempio, è riconoscibile in quanto composta da un pulsante, ossia un componente azionabile per scatenare un evento, e un testo (o immagine), che spieghi di quale evento si tratta. HTML, il linguaggio in cui è implementato il Web, ha avuto una evoluzione molto eterogenea. Una delle conseguenze è che, per ogni componente possibile (un pulsante, ma anche un link, un’immagine, una maschera di input, eccetera), esiste un
elemento, o tag, semanticamente pensato per quella funzione (per un pulsante c’è <button>, ad esempio), ma è anche possibile ottenere lo stesso risultato usando altri tag aventi semantica diversa, o generici. Per un utente normodotato questa ambiguità di implementazione non è un problema: quando vede sulla webmail sopracitata un elemento con un bordo rettangolare, che cambia in una mano la forma del puntatore del mouse quando vi si passa sopra, con sopra l’immagine di una busta e una freccia che parte dalla busta e va a destra (oppure il testo “Spedisci”), l’utente identifica la funzionalità di invio che gli serve per recapitare il messaggio che ha appena scritto. Per un non vedente, invece, il fatto che quel pulsante non sia un <button> ma un elemento HTML generico (<span>) “camuffato” da pulsante potrebbe rappresentare un problema, perché la tecnologia assistiva di cui si serve potrebbe non riconoscerlo come tale, privandolo della possibilità di inviare il proprio messaggio.
L’interazione tra gli elementi, da cui si origina il significato, dipende anche dall’ordine. Se ho un contratto da leggere e accettare premendo un pulsante, e questo contratto è visualizzato sotto al pulsante per motivi estetici, un utente normodotato non avrà problemi a leggere prima di cliccare sulla conferma, ma un non vedente, al quale la pagina viene letta sequenzialmente, potrebbe essere confuso nell’ascoltare “premi Invio per accettare il contratto” senza aver ascoltato alcun contratto, e senza sapere che il contratto verrà letto proseguendo con la navigazione della pagina.
È quindi necessario che la semantica abbia la precedenza sulla resa grafica nell’implementazione di una pagina Web accessibile. Tramite questa modalità di procedura si esplicita il concetto stesso di accessibilità: il contenuto è lo stesso per tutti, cambia il modo in cui esso viene proposto, in base alle capacità di ogni utente.
Notificare i cambiamenti
L’esempio sull’ordine degli elementi citato nel paragrafo precedente richiama un altro aspetto dell’interazione Web non sempre riproducibile con tecnologie assistive: la non linearità, ossia la possibilità che l’attenzione dell’utente si sposti in modo casuale tra i vari componenti della pagina, non potendo quindi prevedere un “prima” e un “dopo”. Quando poi i contenuti sono dinamici e quindi cambiano nel tempo, l’interazione diventa ancora meno predicibile e potenzialmente più difficile da riproporre su tecnologie assistive lineari, come per esempio un sintetizzatore vocale. È quindi necessario utilizzare metodologie standard per comunicare i cambi di stato, sia quelli “lineari” (come lo spostamento del focus, che deve essere visibile, o l’apertura/chiusura di una dropdown) che quelli “non lineari” (come l’aggiornamento di una tabella con i risultati di una chiamata back-end). Siccome questi aggiornamenti possono avvenire quando la tecnologia assistiva sta già leggendo un altro contenuto, dovrà anche essere deciso se l’aggiornamento dovrà attendere la conclusione della lettura in corso prima di essere annunciato, oppure interromperla.
Interazione con altri requisiti
L’accessibilità è un requisito trasversale per un’applicazione Web, impatta cioè ogni componente; per questo motivo occorre che ogni altro requisito trasversale, oltre che i requisiti specifici dei singoli componenti, siano riconsiderati in rapporto all’accessibilità stessa, per riconoscere eventuali conflitti e scegliere la strada migliore per risolverli. La compatibilità con i browser è un altro esempio di requisito trasversale che potrebbe interferire, perché alcuni browser, magari vecchi, potrebbero non supportare certe primitive utilizzate per l’accessibilità o non integrarsi al meglio con le tecnologie assistive. Anche queste ultime potrebbero a loro volta dare problemi di supporto (potenzialmente, ogni combinazione browser-tecnologia assistiva può dare risultati diversi), sarebbe quindi bene definire, come per i browser, cosa sarà supportato e cosa no.
Implicazioni sul team
La nostra esperienza ci ha insegnato che la dimensione trasversale dell’accessibilità e la varietà degli obiettivi da raggiungere dimostra che non tutto il lavoro ricade nei compiti dello sviluppatore. Molti di questi obiettivi, infatti, sono conseguibili solamente se presi in considerazione durante la fase di design e progettazione.
L’accessibilità non è solamente un’accortezza durante la stesura del codice: dal PM al Team Leader, dai designers agli sviluppatori, tutti possono contribuire all’ottenimento di un’applicazione Web accessibile ed è necessario che tutti siano allineati e abbiano ricevuto la giusta formazione.
Per quanto riguarda l’organizzazione del team, l’accessibilità deve quindi entrare a fare parte del flusso di lavoro: ne va tenuto conto all’interno delle stime di progetto e di ogni singolo task, e va predisposta una checklist di requisiti che deve essere condivisa con il team di QA. Questa va poi applicata ad ogni sviluppo e verificata nelle milestone di progetto.
A questo scopo è importante assicurarsi che anche il team di QA abbia ricevuto un’adeguata formazione e comunque valutare di coinvolgere un team di esperti per una review finale, soprattutto nel caso in cui occorra soddisfare un certo livello di compatibilità, come spesso accade in ambito bancario o nella pubblica amministrazione.
Test
Al fine di evitare regressioni, e per verificare che gli sviluppi vengano correttamente integrati, un aspetto da non sottovalutare è la modalità di test. Alcuni requisiti, soprattutto riguardanti la sintassi (la presenza di labels, un sufficiente livello contrasto, la corretta applicazione degli attributi aria e role, etc..), sono testabili in maniera automatica, ad esempio con strumenti come la libreria open source aXe-core che integrino i controlli all’interno dei test unitari.
Per altri ci si può avvalere dell’aiuto di estensioni (aXe, l’estensione supportata dall’omonima libreria, o WAVE) o funzionalità offerte direttamente dai browsers (in Chrome, per esempio, l’accessibility audit di lighthouse è uno strumento di test molto utile), oppure validatori come quello W3C unito al bookmarklet WCAG che mostra solo gli errori di validazione rilevanti per l’accessibilità.
Per quanto riguarda invece l’utilizzo delle tecnologie assistive, non vi sono alternative valide al controllo manuale, per il quale va ribadita la necessità di un’adeguata formazione per potersi bene immedesimare nell’utente con disabilità e quindi capire se il comportamento ottenuto è sufficientemente adatto per tale utente.
Conclusioni
Queste sono alcune delle dinamiche che entrano in gioco quando si parla di accessibilità. Vi sono quindi molte implicazioni legate a questo tema, sia riguardo le persone che devono utilizzare le nostre applicazioni, sia riguardo a chi ha l’ambizione di renderle un’esperienza alla portata di tutti.
È un tema a volte sottovalutato ma che non può passare in secondo piano: tutti dovremmo esserne maggiormente sensibilizzati, e sviluppare quella mentalità che ci orienti a perseguire sempre questo obiettivo, laddove i requisiti del committente lo permettano, e a sensibilizzare il committente qualora non sia stato previsto. Può sembrare un costo elevato per la ridotta fascia di utenza cui si rivolge, ma è una forma mentis che aiuta ad essere più attenti alle necessità altrui e dà un’immagine migliore alla propria azienda.
