Il tuo sito è davvero accessibile? I controlli da fare prima che sia troppo tardi

Un sito accessibile non è frutto dell'attivazione di una singola opzione nel CMS e neppure dell'installazione di uno script JavaScript. L'accessibilità dipende dal modo in cui pagine, componenti e contenuti sono progettati: il codice deve comunicare correttamente la struttura delle informazioni, le funzioni devono restare utilizzabili senza mouse e gli elementi visivi devono risultare leggibili anche da persone con capacità differenti.

Un'immagine importante priva di testo alternativo può diventare invisibile per chi utilizza uno screen reader. Un modulo senza etichette associate correttamente ai campi può risultare difficile da compilare. Un pulsante raggiungibile soltanto con il mouse esclude chi naviga tramite tastiera, mentre un contrasto insufficiente può rendere il testo quasi illeggibile.

L'European Accessibility Act ha reso il tema ancora più urgente per molte imprese che offrono prodotti e servizi digitali ai consumatori. La direttiva europea punta ad armonizzare i requisiti di accessibilità nel mercato dell'Unione e interessa, tra gli altri ambiti, commercio elettronico, servizi bancari, e-book, comunicazioni elettroniche e alcuni servizi di trasporto. L'applicazione concreta degli obblighi dipende comunque dal servizio offerto e dalle esenzioni previste.

Per sviluppatori, web designer, agenzie e gestori di siti, il problema diventa concreto: da quali controlli partire, come interpretare i risultati e quale ruolo assegnare agli strumenti automatici?

Aruba LegalBlink Accessibilità riunisce 3 funzioni utili nel percorso di adeguamento: analisi delle pagine, gestione della dichiarazione di accessibilità e integrazione di un widget che permette agli utenti di modificare alcune modalità di visualizzazione e navigazione.

Cosa significa rendere accessibile un sito web

L'accessibilità web consiste nel progettare contenuti e funzioni utilizzabili anche da persone con disabilità visive, uditive, motorie o cognitive. Non riguarda soltanto l'aspetto grafico della pagina: coinvolge il markup HTML, il comportamento degli script, l'organizzazione delle informazioni e la qualità dei testi.

Un progetto accessibile dovrebbe, per esempio, consentire di:

• comprendere la struttura della pagina anche attraverso uno screen reader;
• raggiungere link, pulsanti e campi usando la tastiera;
• individuare chiaramente l'elemento che possiede il focus;
• leggere testi e controlli grazie a un contrasto adeguato;
• ingrandire i contenuti senza perdere informazioni o funzioni;
• capire gli errori presenti nei moduli e indicare come correggerli;
• fruire dei contenuti visivi attraverso alternative testuali appropriate;
• controllare animazioni, video e altri elementi in movimento.

Questi requisiti non aiutano soltanto le persone con disabilità permanenti. Una navigazione da tastiera può essere utile a chi ha temporaneamente un braccio immobilizzato; sottotitoli e trascrizioni aiutano anche chi guarda un video senza audio; un buon contrasto migliora la leggibilità dello schermo sotto la luce del sole.

WCAG 2.1: molto più di una checklist grafica

Le Web Content Accessibility Guidelines, abbreviate in WCAG, costituiscono uno standard internazionale sviluppato nell'ambito della Web Accessibility Initiative del W3C. Descrivono criteri verificabili per rendere siti, applicazioni web e altri contenuti digitali più accessibili.

Le WCAG organizzano l'accessibilità attorno a 4 principi fondamentali. Il contenuto deve essere:

1. Percepibile, affinché informazioni e componenti dell'interfaccia possano essere fruiti in modi diversi. Rientrano qui, per esempio, testi alternativi, sottotitoli e requisiti di contrasto.
2. Utilizzabile, in modo che controlli e funzioni non dipendano esclusivamente da una modalità di interazione. La navigazione tramite tastiera e la gestione corretta del focus appartengono a quest'area.
3. Comprensibile, con testi chiari, comportamenti prevedibili e indicazioni utili quando l'utente commette un errore.
4. Robusto, affinché il contenuto possa essere interpretato correttamente da browser, screen reader e altre tecnologie assistive.

Ogni principio comprende linee guida e criteri di successo verificabili. Parlare di conformità alle WCAG significa quindi controllare il comportamento effettivo delle pagine, non certo limitarsi a verificare la presenza di un widget o di un simbolo dedicato all'accessibilità.

Aruba LegalBlink Accessibilità riunisce in un unico servizio la valutazione del sito, la gestione della dichiarazione di accessibilità e un widget destinato a migliorare alcune modalità di navigazione per organizzare il percorso di adeguamento, senza sostituire gli interventi necessari su codice, contenuti e design.

Cosa significano i livelli A e AA

Aruba LegalBlink Accessibilità concentra la valutazione sui livelli A e AA. Il livello A comprende i requisiti fondamentali; il livello AA aggiunge ulteriori criteri comunemente adottati come riferimento per i siti web. I due livelli non sono alternativi: per raggiungere AA devono essere rispettati anche i criteri classificati come A.

L'analisi svolta con Aruba LegalBlink Accessibilità fornisce una valutazione del sito rispetto ai requisiti WCAG 2.1 A e AA. I risultati offrono una preziosa fotografia iniziale dello stato delle pagine e una base per pianificare gli interventi tecnici e redazionali.

La dichiarazione di accessibilità con Aruba LegalBlink

La seconda componente del servizio Aruba LegalBlink Accessibilità riguarda la dichiarazione di accessibilità, il documento con cui il gestore comunica lo stato di conformità del sito e indica le eventuali criticità presenti.

Con Aruba LegalBlink Accessibilità Easy, l'utente può generare autonomamente la dichiarazione sulla base delle informazioni e delle valutazioni disponibili. Aruba LegalBlink Accessibilità Advanced prevede invece il coinvolgimento di consulenti legali, ai quali sono affidate l'analisi della conformità e la predisposizione del documento; il piano include inoltre un report con suggerimenti per migliorare il sito.

La dichiarazione svolge una funzione informativa e di trasparenza. Non corregge il codice, non modifica i contenuti e non rende automaticamente accessibili le pagine. Deve inoltre rispecchiare lo stato reale: dopo modifiche rilevanti al sito, al CMS, al tema o ai componenti utilizzati, è opportuno verificare che il documento sia ancora aggiornato.

HTML accessibile: la struttura viene prima dell'aspetto

Una delle basi dell'accessibilità consiste nell'utilizzare gli elementi HTML per il significato che possiedono.

Un pulsante dovrebbe essere realizzato con <button>, non con un generico <div> reso cliccabile tramite JavaScript. Un collegamento dovrebbe utilizzare <a> con una destinazione valida. Titoli, liste, tabelle e moduli dovrebbero essere descritti con gli elementi previsti dal linguaggio.

Un pulsante costruito correttamente, come nell'esempio di seguito, possiede già caratteristiche importanti: può ricevere il focus, è riconosciuto come pulsante dalle tecnologie assistive e risponde ai comandi da tastiera previsti dal browser.

<button type="button" id="open-menu">
Apri il menu
</button>

Viceversa, un elemento <div> generico non offre automaticamente le stesse informazioni e può richiedere l'aggiunta manuale di ruolo, gestione del focus ed eventi da tastiera. Anche dopo tali correzioni, usare l'elemento nativo resta in genere la soluzione più semplice e robusta. L'uso dell'attributo role="button" non conferisce automaticamente a un <div> tutti i comportamenti di un pulsante.

Problemi di questo tipo mostrano perché la valutazione fornita da Aruba LegalBlink Accessibilità debba essere accompagnata dall'intervento di uno sviluppatore: quando emerge una criticità, la correzione va applicata nel markup o nella logica dello specifico componente.

Titoli, landmark e ordine dei contenuti

Gli utenti che utilizzano uno screen reader possono spostarsi tra titoli, regioni e controlli senza leggere la pagina dall'inizio alla fine. Una struttura ben congegnata permette di capire rapidamente dove ci si trova e quali sezioni sono disponibili.

È quindi buona pratica usare un solo titolo principale pertinente (<h1>) e organizzare i sottotitoli secondo una gerarchia logica (esempio <h2>, <h3>, <h2>, <h3>, <h3> e così via).

La scelta del livello non dovrebbe dipendere dall'effetto grafico desiderato: l'aspetto si gestisce tramite CSS, mentre l'elemento HTML descrive la posizione del titolo nella struttura.

Elementi quali <header>, <nav>, <main>, <aside> e <footer> aiutano inoltre a delimitare le principali regioni della pagina. Bisogna però evitare di moltiplicare landmark e contenitori senza necessità, perché una struttura eccessivamente frammentata può diventare più difficile da esplorare.

Immagini e testi alternativi

L'attributo alt non deve contenere una descrizione meccanica di ogni immagine. Il testo alternativo deve comunicare l'informazione che l'immagine aggiunge alla pagina. Esempio:

<img
src="grafico-vendite.webp"
alt="Le vendite online aumentano del 25% tra gennaio e giugno"
>

Se l'immagine ha una funzione puramente decorativa, un attributo vuoto permette alle tecnologie assistive di ignorarla.

La presenza dell'attributo non garantisce da sola l'accessibilità. Un testo come alt="immagine" soddisfa formalmente la presenza del campo, ma non offre alcuna informazione utile. È uno degli esempi che mostrano perché l'analisi automatica debba essere affiancata da una valutazione umana.

Un controllo automatizzato può verificare la presenza di alcuni elementi tecnici, ma non sempre può stabilire se il testo alternativo descriva davvero l'informazione trasmessa dall'immagine. Anche i risultati di Aruba LegalBlink Accessibilità devono quindi essere integrati con una revisione manuale dei contenuti.

Moduli: label, istruzioni ed errori

I moduli rappresentano spesso uno dei punti più critici, soprattutto nei siti e-commerce. Segnaposti e disposizione visiva non sostituiscono un'etichetta associata programmaticamente al campo.

L'associazione tra for e id permette al browser e allo screen reader di collegare correttamente il testo al controllo. L'attributo autocomplete può inoltre aiutare l'utente a compilare più rapidamente i campi supportati.

<label for="email">Indirizzo email</label>
<input
type="email"
id="email"
name="email"
autocomplete="email"
required
>

Quando si verifica un errore nella compilazione del modulo, il messaggio restituito dovrebbe indicare sia il problema sia il modo per risolverlo. Dire soltanto "dato non valido" costringe l'utente a indovinare cosa correggere. Anche il colore non dovrebbe costituire l'unico sistema per distinguere un errore: servono testo, simboli o altre indicazioni comprensibili.

I risultati della valutazione di Aruba LegalBlink Accessibilità possono richiamare l'attenzione sulle criticità riscontrate; con il piano Advanced è previsto anche un report con suggerimenti predisposto nell'ambito dell'analisi svolta dai consulenti legali.

Navigazione da tastiera e gestione del focus

Tutte le funzioni essenziali dovrebbero poter essere utilizzate senza mouse. Durante il test è sufficiente iniziare dalla barra degli indirizzi e usare Tab, MAIUSC+Tab, Invio, barra spaziatrice e tasti freccia per verificare il comportamento dell'interfaccia.

In particolare, va controllato che il focus segua un ordine prevedibile; l'elemento selezionato sia chiaramente visibile; menu e finestre modali possano essere aperti e chiusi; il focus non rimanga bloccato senza motivo; dopo la chiusura di una finestra il focus torni al controllo che l'aveva aperta; non esistano funzioni disponibili esclusivamente al passaggio del mouse.

La rimozione indiscriminata dell'outline CSS è uno degli errori più frequenti nei siti web. L'outline è il bordo che il browser mostra intorno all'elemento attualmente selezionato durante la navigazione tramite tastiera. Serve a far capire all'utente dove si trova il focus, per esempio su un link, un pulsante o un campo di un modulo. Eliminandolo con regole come outline: none, senza introdurre un indicatore alternativo altrettanto visibile, chi usa il tasto Tab può perdere completamente il riferimento all'interno della pagina.

Dopo l'analisi svolta con Aruba LegalBlink Accessibilità, è opportuno eseguire una prova manuale dei percorsi principali. La presenza di controlli raggiungibili con il tasto Tab non garantisce, da sola, che l'ordine del focus sia logico o che un checkout risulti realmente utilizzabile da tastiera.

Cosa può fare il widget di accessibilità

Il widget di Aruba LegalBlink Accessibilità consente agli utenti di adattare alcuni aspetti dell'interfaccia. Le funzioni integrate consentono di personalizzare alcuni aspetti della visualizzazione e della navigazione, tra cui testo, contrasto, colori, animazioni ed evidenziazione degli elementi interattivi.

L'inserimento all'interno del progetto web può avvenire aggiungendo al <body> il codice fornito oppure ricorrendo a Google Tag Manager. Ciascun piano può essere utilizzato su un singolo dominio.

Dopo l'installazione è opportuno verificare che:

• il pannello sia raggiungibile e utilizzabile tramite tastiera;
• non copra comandi, banner o pulsanti;
• funzioni correttamente sia su desktop sia su mobile;
• non produca errori JavaScript;
• non modifichi il layout in modo imprevedibile;
• le preferenze applicate siano comprensibili e reversibili.

Perché il widget non rende automaticamente conforme il sito

Il widget di Aruba LegalBlink Accessibilità agisce sulle modalità di presentazione e interazione, ma non può correggere tutti gli errori originari del progetto.

Non può, ad esempio, stabilire autonomamente se il testo alternativo di una fotografia sia significativo, riscrivere un checkout confuso, correggere una gerarchia HTML priva di logica o trasformare un PDF non strutturato in un documento accessibile.

Non può neppure garantire che ogni plugin installato in futuro rispetti i criteri richiesti: se un aggiornamento introduce una finestra modale non controllabile da tastiera, il problema rimane nel componente, anche se il widget è presente.

Aruba presenta il widget come uno strumento complementare, non sostitutivo di un codice strutturalmente accessibile, e chiarisce che la sua integrazione non rende automaticamente il sito conforme ai requisiti dell'European Accessibility Act.

Aruba LegalBlink Accessibilità Easy e Advanced

Aruba propone il servizio in due configurazioni:

• Aruba LegalBlink Accessibilità Easy comprende la valutazione automatizzata del sito, la generazione autonoma della dichiarazione, il widget conforme ai requisiti WCAG 2.1 A e AA, pagine illimitate ed è consigliato per siti fino a circa 150.000 pageview mensili. Il prezzo indicato è di 19,90 euro più IVA per il primo anno, con rinnovo da 29 euro più IVA all'anno.
• Aruba LegalBlink Accessibilità Advanced affida l'analisi e la predisposizione della dichiarazione a un team di consulenti legali e include un report con suggerimenti per migliorare il sito. Comprende il widget, pagine illimitate ed è consigliato per un traffico fino a circa 300.000 pageview mensili. Il prezzo indicato è di 49,90 euro più IVA per il primo anno, con rinnovo da 69 euro più IVA all'anno.

La differenza principale riguarda quindi il livello di autonomia: Easy mette a disposizione gli strumenti per gestire il percorso con maggiore autonomia, mentre Advanced aggiunge l'intervento di consulenti legali.

L'accessibilità deve entrare nel ciclo di sviluppo

La verifica non dovrebbe essere eseguita soltanto alla fine del progetto. Correggere a posteriori template, componenti e flussi complessi può richiedere molto più lavoro rispetto alla definizione iniziale di requisiti accessibili.

Un processo sostenibile può prevedere controlli in più momenti:

1. progettazione di componenti con stati, focus e contrasti adeguati;
2. sviluppo basato sugli elementi HTML nativi e corretta gestione dell'interazione da tastiera;
3. analisi automatica durante la fase di test;
4. verifica manuale dei flussi principali;
5. controllo editoriale di immagini, titoli e link;
6. nuova analisi dopo aggiornamenti di CMS, tema o plugin.

Anche un sito inizialmente ben progettato può degradarsi nel tempo. Un redattore può inserire titoli senza rispettare la gerarchia; un nuovo plugin può produrre controlli non accessibili; un restyling può ridurre il contrasto o nascondere il focus.

Per questo la dichiarazione, l'analisi e il widget devono essere inseriti in un processo più ampio. Aruba LegalBlink Accessibilità può semplificare le attività iniziali e offrire strumenti utili agli utenti, ma la qualità finale dipende dalle decisioni prese nel codice, nel design e nella gestione quotidiana dei contenuti.

Rendere un sito accessibile significa, in definitiva, costruire interfacce che non presuppongano un unico modo di vedere, comprendere o utilizzare il web.

Le WCAG 2.1 forniscono criteri verificabili, organizzati anche nei livelli di conformità A e AA; gli strumenti automatici aiutano a trovare una parte dei problemi; dichiarazione e widget migliorano trasparenza e possibilità di personalizzazione. Tutti questi elementi, tuttavia, devono concorrere a sostenere una progettazione realmente accessibile.

In collaborazione con Aruba