Accessibilità

L'accesso alle informazioni pubbliche dev'essere garantito a tutti i tipi di utenti. Questo sito web è da subito progettato seguendo i principi di accessibilità secondo le linee guida WCAG 2.0, in modo che i contenuti possano essere utilizzati con facilità e confortevolezza anche in caso di disabilità sensoriale o motoria.

Questo sito è in aggiornamento continuo, sia nei contenuti che nelle caratteristiche, quindi alcune informazioni potrebbero non essere ancora totalmente accessibili.

Per segnalare malfunzionamenrti o richiedere informazioni si può fare riferimento a questa email.

Introduzione

Cosa sono le Web Content Accessibility Guidelines?

Le WCAG sono le linee guida redatte dal World Wide Web Consortium (W3C) all’interno della Web Accessibility Initiative (WAI).

Ogni linea guida fornisce un livello minimo di accettazione (singola A) e un livello massimo (AAA). I tre gradi (A, AA, AAA) determinano l’accessibilità di un sito web.

Le sezione del WCAG spaziano dalla correttezza semantica del HTML alla progettazione della User Experience, pertanto si rivolgono a sviluppatori di siti web, autori di contenuti, produttori di tecnologie assistive e di strumenti di validazione e forniscono criteri di successo o fallimento per ogni aspetto di un sito web.

In Italia, le WCAG sono tra i riferimenti più importanti della Legge Stanca del 2005, nonché del Trattato di Marrakech in vigore dal 2019 in tutta l’Unione Europea. Entrambe le normative ritengono che i contenuti e le piattaforme digitali editoriali debbano ottenere il grado minimo della AA.

Quasi tutti i validatori (manuali e automatici) fanno riferimento alle sezione delle WCAG per indicare errori, descrivere la problematica e a volte proporre soluzioni.

Strumenti

Validazione automatica

Per questo tipo di analisi, scegliamo due diversi motori di analisi per comparare i risultati e neutralizzare falsi positivi ed eventuali malfunzionamenti degli strumenti nel riconoscere determinati errori. Gli strumenti utilizzati in questa analisi sono due estensioni del browser.

Questi sono gli strumenti usati:

Axe: è uno strumento sviluppato da deque, azienda leader mondiale nel fornire soluzioni e consulenze sul tema dell’accessibilità. Axe è anche integrato nei devtools del browser Chrome, ma può anche essere installato come estensione
A11ygator: è un’estensione sviluppata da Chialab basata su HTML CodeSniffer. A differenza di axe, che esegue analisi statiche, A11ygator rimane in ascolto di cambiamenti nella pagina per aggiornare costantemente il report, pratica abbastanza utile nella pagine molto dinamiche o con messaggi a tempo
Pa11y: è un validatore basato su HTML CodeSniffer e sviluppato da Financial Times, che usa puppeteer per fare validazioni in ambienti di Continuous Integration
Stark: è un’estensione per i maggiori programmi di progettazione web (Adobe XD, Sketch, Figma) per controllare che i colori usati per testo e sfondo offrano sempre un livello minimo di contrasto secondo le linee guida.

Validazione manuale

La validazione manuale offre un riscontro sicuramente più affidabile del validatore automatico in termini di consultazione dei contenuti della pagina. In questo caso consideriamo non solo gli strumenti assistivi come screen reader e tastiera braille, che hanno bisogno di una struttura semantica corretta per estrarre le informazioni dalla pagina per produrre una sintesi vocale, ma anche l’esperienza di un utente con disabilità motorie, a volte temporanee, che impediscono l’utilizzo di un mouse.

Questi sono gli strumenti usati:

VoiceOver: è uno strumento disponibile per MacOS e iOS che genera la sintesi vocale dei contenuti della pagina, tenendo conto di testi alternativi e attributi ARIA
Tastiera: la tastiera è uno strumento che serve per navigare le pagine senza dispositivi di puntamento (mouse, eye tracking , ...). Il layout di una tastiera può variare a seconda delle necessità (può essere molto diverso dal modello “QWERTY” che siamo abituati ad utilizzare) ma il suo funzionamento in termini di navigazione è simile per tutti.

Progettazione

La progettazione è il primo e più importante passaggio per rendere un prodotto accessibile. Se il prodotto non viene progettato come accessibile, è molto difficile che anche rispettando tutte le regole di sviluppo e implementazione si possa ottenere un risultato soddisfacente. Tuttavia, è errato pensare che serva una progettazione ad hoc per l’accessibilità: un buon progetto è sempre confortevole per tutti gli utenti. Per raggiungere questo risultato, occorre tenere in considerazione alcuni accorgimenti e alcune pratiche che evidenziano meglio il funzionamento del sito.

Utilizzando estensioni o strumenti come Stark è possibile controllare che il contrasto tra testo e sfondo sia sempre sufficiente anche per gli utenti che hanno imparità visive (non solo non vedenti o ipovedenti).

È inoltre compito del designer stabilire il paradigma di navigazione del sito, evidenziando quali azioni richiedono una navigazione e quali un’interazione in pagina. Questo tipo di lavorazione è fondamentale anche per individuare l’esperienza di un utente che naviga il sito tramite tastiera, o meglio, senza puntatori. Per costruire una buona navigazione non “visiva” occorre prevedere testi alternativi per quei segni unicamente grafici (sprovvisti di etichetta testuale) che non sono contenuti ma che servono comunque ad indicare all’utente il tipo d’azione che sta per compiere.

In ambienti molto complessi, dove l’utente può eseguire anche molte azioni di natura diversa, scomporre le aree di interazione in contesti, ognuno con una propria navigazione interna, consente anche di definire in maniera più chiara la user experience , fornendo allo stesso tempo allo sviluppatore gli strumenti per implementarla al meglio.

Sviluppo

Il compito degli sviluppatori è utilizzare strumenti e metodologie che garantiscano un sufficiente grado di accessibilità del prodotto direttamente durante l’implementazione, e non come revisione successiva. I validatori sopra citati sono tuttavia da considerarsi come un aiuto e non come test veri e propri. Gli sviluppatori possono utilizzare le estensioni del browser per rilevare problemi durante il debug di nuove feature , mentre devono prevedere nel loro flusso di test l’integrazione con Pa11y impostato sul grado AA.

Più importante rispetto all’utilizzo dei validatori è la correttezza semantica dei tag HTML usati. Lo sviluppatore deve infatti saper usare gli opportuni elementi sia per la struttura della pagina che per l’implementazione di interazioni.

Strutturare la pagina

Esistono diversi tag di struttura, ognuno volto a determinare la semantica di una regione della pagina. I più comuni sono <header> , <main> , <nav> , <footer> , <section> e <article> , al cui interno anche le intestazioni ( <h1> , <h2> , <h3> , <h4> , ...) attribuiscono valore a seconda della posizione nell’albero e per questo hanno stili di base diversi. Per uno screen reader è importante identificare queste regioni, a volte per “passare direttamente al contenuto” (al <main> ) o per saltarne del tutto un altro non richiesto.

Bottoni e link

L’utilizzo corretto di ancore ( <a> ) e bottoni ( <button> ) è fondamentale per fornire un’esperienza di navigazione accessibile. Le prime permettono all’utente di navigare dentro o fuori al sito, dove per “navigare” intendiamo un vero e proprio cambio di url nella barra degli indirizzi e uno nuovo stato nella history del browser. I bottoni invece identificano le aree su cui l’utente può eseguire un click e che servono per interagire con il contenuto. Molto spesso, questo tipo di interazioni vengono collegate erroneamente a elementi che non sono <button> , perdendo così la possibilità di navigarli tramite tastiera con il tasto TAB e attivarli tramite il tasto ENTER, per non parlare del riconoscimento dell’area interattiva da parte degli screen reader, che appunto non sarebbe in grado di individuare la presenza di un link e di comunicarlo all’utente.

Attributi e ruoli

Nelle specifiche HTML sono presenti alcuni attributi particolari chiamati aria-* e role. Entrambe le tipologie servono ad ampliare il significato semantico dell’elemento fornendo nuove informazioni, come il testo alternativo, il tipo di azioni che si possono compiere, quale nodo figlio descrive meglio tutta l’area o che tipo di relazione c’è tra nodo parent e nodo child . In particolare, l’uso dell’attributo aria-label (il più comune) serve per fornire indicazioni o testi alternativi a contenuti o bottoni che sono caratterizzati solamente da segni grafici.

Test

Eseguire un test di accessibilità è un’operazione complessa e spesso onerosa dal punto di vista del tempo impiegato. Tuttavia, nonostante un buon flusso di progettazione/sviluppo sia in grado di prevenire la maggior parte degli errori, è un passaggio fondamentale.

Questi test possono essere delegati ad associazioni esterne (per esempio, l’istituto per ciechi di Bologna offre la possibilità di eseguire validazioni manuali) oppure eseguiti da un membro del team, utilizzando gli strumenti proposti (tastiera e sintesi vocale). Lo scopo del test è controllare che tutti i contenuti della pagina, specialmente quelli principali, siano navigabili tramite tastiera e correttamente interpretati dalla sintesi vocale. Naturalmente, la qualità del risultato della validazione dipende molto dall’esperienza del tester.

Vista la complessità (anche organizzativa) di questi test e il tempo che essi richiedono, è buona norma prevedere cicli di test sia prima del rilascio di un pacchetto di nuove feature che a intervalli di tempo che possono variare dall’esperienza del team di sviluppo (cadenza mensile per i team meno esperti, anche bimestrale per quelli più rodati).

Conclusioni

Rendere un prodotto veramente “accessibile” richiede metodologie, strumenti e competenze a tutti i livelli di produzione. Sebbene i validatori automatici siano in grado di rilevare (e a volte risolvere) i problemi più comuni e ricorrenti della fase di sviluppo, è la progettazione che crea un ambiente veramente confortevole, accessibile e abitabile. Da qui dobbiamo partire per delineare anche quelli che saranno i dettagli implementativi come il funzionamento della navigazione e dell’interazione in generale. Il Web viene definito accessibile per natura, e molto spesso lo è davvero. Conoscere quindi la semantica degli elementi HTML, il funzionamento del Accessibility Tree e del browser è necessario per non introdurre problemi di navigabilità della pagina durante lo sviluppo. Occorre tenere presente però che chi andrà ad utilizzare la pagina e ha bisogno di usare dispositivi assistivi non è un computer, ma una persona che potrebbe non comprendere il funzionamento di alcune parti del sito anche quando l’interprete del browser è in grado di capirli. Per questo fare affidamento solo sulle buone pratiche e sulle validazioni automatiche non è sufficiente, ma è richiesta una vera e propria validazione “manuale” della pagina.