In questo articolo Indice dei contenuti 2 sezioni
L’accessibilità web non si risolve spuntando una casella nel pannello del CMS, e nemmeno incollando uno script JavaScript in fondo alla pagina. Dipende da come sono costruiti codice, componenti e contenuti: la struttura delle informazioni deve essere comunicata correttamente, le funzioni devono restare utilizzabili anche senza mouse e gli elementi visivi devono risultare leggibili da persone con capacità diverse. Detto in modo pratico, un’immagine importante senza testo alternativo diventa invisibile per chi usa uno screen reader, un modulo con etichette non associate ai campi si compila a fatica, un pulsante raggiungibile solo col puntatore taglia fuori chi naviga da tastiera e un contrasto troppo basso rende il testo quasi illeggibile.
Il tema è diventato più urgente con l’European Accessibility Act, la direttiva europea che punta ad armonizzare i requisiti di accessibilità nel mercato dell’Unione. Riguarda, tra gli altri ambiti, commercio elettronico, servizi bancari, e-book, comunicazioni elettroniche e alcuni servizi di trasporto, anche se l’applicazione concreta degli obblighi cambia a seconda del servizio offerto e delle esenzioni previste. Per sviluppatori, web designer, agenzie e gestori di siti la domanda diventa molto concreta: da dove iniziare con i controlli, come leggere i risultati e quanto pesare gli strumenti automatici.
WCAG 2.1, quattro principi e due livelli da conoscere
Le Web Content Accessibility Guidelines, cioè le WCAG, sono lo standard internazionale nato nell’ambito della Web Accessibility Initiative del W3C. Descrivono criteri verificabili e ruotano attorno a 4 principi. Il contenuto deve essere percepibile, quindi fruibile in modi diversi grazie a testi alternativi, sottotitoli e contrasti adeguati. Deve essere utilizzabile, senza dipendere da una sola modalità di interazione, e qui entrano in gioco navigazione da tastiera e gestione corretta del focus. Deve essere comprensibile, con testi chiari, comportamenti prevedibili e messaggi utili quando qualcosa va storto. E deve essere robusto, cioè interpretabile da browser, screen reader e altre tecnologie assistive.
Ogni principio contiene linee guida e criteri di successo misurabili. Parlare di conformità significa quindi verificare come si comportano davvero le pagine, non controllare la presenza di un simbolo o di un pannellino. In questo quadro Aruba LegalBlink Accessibilità mette insieme 3 funzioni utili durante l’adeguamento: analisi delle pagine, gestione della dichiarazione di accessibilità e un widget che consente agli utenti di modificare alcune modalità di visualizzazione e navigazione. La valutazione si concentra sui livelli A e AA: il primo raccoglie i requisiti fondamentali, il secondo aggiunge criteri comunemente presi come riferimento per i siti web. Non sono alternativi, perché per arrivare ad AA vanno rispettati anche i criteri di livello A. Il risultato è una fotografia iniziale, base di partenza per pianificare interventi tecnici e redazionali.
La dichiarazione di accessibilità e il lavoro sul codice
La seconda componente riguarda la dichiarazione di accessibilità, il documento con cui il gestore comunica lo stato di conformità del sito e segnala le criticità. Con il piano Easy la dichiarazione si genera in autonomia, sulla base delle informazioni e delle valutazioni disponibili. Con il piano Advanced intervengono invece consulenti legali che si occupano dell’analisi di conformità e della stesura del documento, con in più un report di suggerimenti per migliorare il sito. Resta un documento informativo: non corregge il codice, non riscrive i contenuti e non rende accessibili le pagine per magia. Dopo modifiche rilevanti al sito, al CMS, al tema o ai componenti conviene controllare che sia ancora aggiornato.
Il grosso del lavoro sta altrove, nell’HTML semantico. Un pulsante va costruito con l’elemento pulsante, non con un contenitore generico reso cliccabile via JavaScript, perché l’elemento nativo riceve già il focus, viene riconosciuto dalle tecnologie assistive e risponde ai comandi da tastiera del browser. L’attributo role non regala automaticamente questi comportamenti. Stesso discorso per titoli, liste, tabelle e moduli. Una gerarchia logica dei titoli e l’uso corretto dei landmark aiutano chi naviga con uno screen reader a capire dove si trova, mentre l’aspetto grafico va gestito con i CSS. Sul fronte immagini, il testo alternativo deve trasmettere l’informazione che l’immagine aggiunge alla pagina, mentre per le immagini decorative è sufficiente un attributo vuoto. Un alt scritto come “immagine” formalmente esiste, ma non serve a niente, ed è il motivo per cui l’analisi automatica va sempre affiancata da una revisione umana. I moduli restano il punto più delicato, soprattutto negli e-commerce, dove segnaposti e semplice disposizione visiva non sostituiscono mai un’etichetta correttamente associata al campo.
