Scrivo questo articolo in quanto molte amministrazioni pubbliche mi hanno contattato preoccupate dal ricevimento di missive (che il Garante per la Protezione dei dati Personali tramite twitter conferma essere in violazione delle vigenti normative) di segnalazione “generica” da parte di una sconosciuta associazione “web” di violazione delle normative in materia di accessibilità risolvibili con l’ausilio di sistemi “ripara tutto”, indicati come “le” soluzioni disponibili.
Su questo tema avevo già scritto un articolo su Techeconomy nel mese di aprile 2021 ma lo voglio riprendere in questo sito che, come sapete, è la risorsa ufficiale di IWA Italy, l’associazione nazionale (l’unica accreditata) che raccoglie, tra gli altri, i professionisti web che operano anche nel campo dell’accessibilità.
Dove nasce il problema?
Sembra impossibile, ma i problemi di accessibilità sono causati per ignoranza in materia da parte di tutti gli attori coinvolti nella produzione e gestione di un sito web. Le criticità di accessibilità possono nascere già dalla fase di prototipazione, addirittura dai cosiddetti “mockup” dove si possono nascondere criticità che successivamente devono essere risolte. E le criticità possono nascere anche da non corrette implementazioni dei designer o dei developer che per cultura professionale non hanno affrontato il tema dell’accessibilità. Ed è qui che poi alla fine, purtroppo, viene coinvolto l’esperto di accessibilità web (Web Accessibility Expert, una figura normata dalla norma tecnica UNI 11621-3), necessario ora ma che potrebbe non essere necessario in queste fasi “semplici” se tutti operassero nel modo corretto.
Al termine poi il prodotto viene utilizzato da utenti che producono contenuti e anche in questo caso per scarsa conoscenza del tema possono creare sia problemi nei contenuti web, sia nei documenti pubblicati nei siti web, il classico e diffuso problema dei documenti scansionati, inaccessibili non solo alle persone non vedenti e/o ipovedenti ma non fruibili da tutti noi.
Come per tutte le problematiche, la vita scorre liscia senza problemi finché qualcuno giustamente fa notare che quel determinato sito web, app mobile o servizio digitale lo discrimina e gli impedisce di interagire con un’amministrazione, fare acquisiti on line, prenotare un servizio, effettuare un’operazione bancaria, ecc.
Accessibilità: verifica umana o automatizzata?
La domanda che viene sempre posta è: esiste uno strumento che verifica l’accessibilità di un sito web e mi fornisce la conformità rispetto alle regole di accessibilità vigenti (attualmente WCAG 2.1)? La risposta è: no.
E la risposta viene direttamente dalle WCAG, dove nell’introduzione, quando si parla di “Cosa sono le WCAG 2“, è chiaramente indicato quanto segue:
0.1 Cosa sono le WCAG 2
Le WCAG 2.1 si basano sulle WCAG 2.0 [WCAG20], che a loro volta si basano sulle WCAG 1.0 [WAI-WEBCONTENT ] e sono progettate per applicarsi in modo esteso a diverse tecnologie Web sia adesso che in futuro, nonché per essere verificabili tramite una combinazione di test automatici e valutazione umana.
Quindi è ben chiaro: la verifica di accessibilità è fatta da una combinazione di attività fatte da esseri umani che utilizzano come supporto strumenti informatici.
Il ruolo degli strumenti automatizzati a supporto della riparazione
Un ruolo importante ce l’hanno gli strumenti di valutazione automatizzati che supportano l’esperto di accessibilità, ma anche il designer e lo sviluppatore o il gestore di contenuti a comprendere dove vi siano criticità (errori reali), dove potrebbero esserci (errori potenziali) oppure dove lo strumento non può arrivare (controlli da effettuarsi manualmente).
Un buon strumento di supporto alla valutazione deve essere in grado di analizzare l’intero sito web e fornire delle indicazioni puntuali sulle criticità rilevate, in quanto in questo modo consente al gestore del sito di poter identificare le aree (e quindi i responsabili delle stesse) in cui l’accessibilità non è ancora allineata agli standard di riferimento. Una caratteristica aggiuntiva che deve avere lo strumento è la semplicità di linguaggio informativo, ossia deve saper “parlare” al target di utenza. Se ad esempio identifico un errore, non è sufficiente dire che quel contenuto viola il criterio di successo X.Y.Z. delle WCAG 2.1 ma va chiaramente identificato e spiegato perché si tratta di una criticità e come risolverla.
Accessibilità: la riparazione automatizzata è possibile?
Abbiamo visto nel blocco precedente che non è possibile identificare automaticamente tutte le problematiche di accessibilità e pertanto è necessaria una gestione umana supportata eventualmente da strumenti informatici idonei all’analisi.
A questo punto, quindi, possiamo chiederci: ma gli strumenti che dicono di rendere conforme i siti web alla vigente normativa, senza modificare il sito web ma intervenendo in modalità automatizzata aggiungendo “livelli personalizzati”, ci possono garantire l’accessibilità o comunque una conformità alle normative vigenti? No.
Cosa non può fare uno strumento automatico di riparazione?
Ci sono moltissimi casi, di cui riporto solo alcuni elementi esemplificativi, che non possono essere risolti con un sistema che si basa su livelli personalizzati:
- assegnare una etichetta ad un campo modulo che non ce l’ha o ce l’ha errata;
- consentire o meno di effettuare l’ingrandimento in modo adeguato dei contenuti;
- consentire la visualizzazione del contenuto in una larghezza minima;
- consentire l’identificazione di tabelle di impaginazione;
- modificare collegamenti ambigui (clicca qui, approfondisci, ecc.);
- fornire adeguati testi alle immagini contenenti testo, quando necessario;
- garantire un corretto ordine dello spostamento dell’utente (focus) nella pagina;
- identificare in modo coerente gli oggetti “non accessibili” in tutto il sito web;
- garantire la navigabilità con la sola tastiera;
- impedire che l’utente resti bloccato all’interno di oggetti navigando tramite tastiera;
- garantire l’identificazione di errori e la loro prevenzione nella compilazione di moduli;
- garantire una corretta struttura delle intestazioni (livello di titolazione e relativo contenuto);
- correggere automaticamente i link non funzionanti;
- bloccare il cambiamento automatico derivante da azioni dell’utente senza informarlo;
- garantire la correttezza semantica;
- garantire adeguatezza delle etichette e informazioni strutturali aggiuntive per tecnologie assistive;
- identificare la lingua corretta per il contenuto;
- garantire la possibilità di consultare i contenuti ruotando lo schermo;
- garantire responsive design di qualità;
- produrre sottotitoli per i contenuti multimediali;
- garantire l’accessibilità dei documenti pubblicati (es: PDF scansionati).
L’elenco come noterete non è così ristretto e le problematiche che restano sono particolarmente serie per specifiche disabilità. Ad esempio, con tali soluzioni una persona con disabilità motorie non otterrà alcun beneficio. Così come, con altri strumenti, la presenza di plug-in che consentono agli utenti di poter personalizzare la visualizzazione dei contenuti (pulsante per avere testo in alto contrasto, lettura dello schermo, ecc.) sono praticamente inutili in quanto le persone con disabilità hanno già la loro configurazione che utilizzano agevolmente se il sito web è conforme agli standard.
I problemi non risolti “grazie” agli strumenti automatici
Il problema più contingente dei sistemi di riparazione con livelli aggiuntivi è la mancata considerazione dell’accessibilità strutturale e contenutistica.
In parole più semplici, posizionare uno strumento che promette di rimuovere le barriere digitali senza modificare il sito web ma aggiungendo caratteristiche (i livelli) disponibili finché il servizio è attivo, significa, oltre a non essere comunque conformi alla normativa per i punti descritti sopra:
- non risolvere i problemi di accessibilità sia strutturali che di contenuti;
- non attuare modifiche tecnico-organizzative per la predisposizione di contenuti accessibili;
- non essere comunque conformi alla normativa vigente in quanto il sito deve essere nativamente accessibile.
Su questo ultimo punto poi una precisazione: non devono esserci dei “livelli differenti” azionabili dagli utenti altrimenti si ritorna al concetto del sito parallelo. L’utente è l’unico soggetto che deve poter personalizzare con i suoi strumenti la visualizzazione, non deve cercare nella pagina delle opzioni per personalizzare il sito, navigando contenuti non accessibili sino al raggiungimento della personalizzazione.
A volte poi ci si scontra con problematiche identificabili e risolvibili con strumenti automatizzati di verifica che vengono accentuate da strumenti di riparazione. Qualche settimana fa mi è capitato un sito web di un’amministrazione pubblica i cui colori non erano conformi rispetto al rapporto di contrasto delle WCAG 2.1 e la personalizzazione per “ipovedenti” peggiorava pure la situazione.
Conclusioni
In conclusione all’articolo, in materia di accessibilità web, possiamo concludere sintetizzando che:
- la verifica di accessibilità è una combinazione di analisi umana e automatizzata (può anche essere solo analisi umana, ma non potrà mai essere analisi solo automatizzata;
- nessun strumento di verifica dell’accessibilità automatizzata può garantire la conformità totale con normative vigenti;
- nessuno strumento di “personalizzazione” o “adattamento” del codice inaccessibile può garantire la conformità totale con normative vigenti;
- utilizzare strumenti di “personalizzazione” o “adattamento” non risolve problemi ma potenzialmente li “sospende”, come un idraulico che mette una pezza al tubo anziché ripararlo;
- coinvolgere utenti con disabilità, direttamente o tramite loro associazioni, per un supporto alla verifica;
- solamente con una attività di analisi, interventi mirati e soprattutto formazione del personale ad ogni livello si può garantire un adeguato livello di accessibilità.