Albero di accessibilità: struttura, ruoli agenti e checklist di controllo

Che cos’è l’albero di accessibilità

L’albero di accessibilità è una versione semantica dell’interfaccia che il browser espone alle tecnologie assistive attraverso un’apposita API. Per coglierne la natura conviene immaginare di progettare un sito destinato esclusivamente a chi utilizza un lettore di schermo: in quel caso non servirebbe alcun layout visivo, ma soltanto una descrizione ordinata di cosa contiene la pagina e di cosa l’utente può fare. La struttura che ne deriva ricorda il modello del documento, ma con un numero inferiore di nodi e di dettagli, perché gran parte delle informazioni del codice riguarda la resa grafica e non il significato.

Questa gerarchia di oggetti accessibili custodisce ciò che conta per l’interazione. A ciascun nodo è associato un ruolo, come pulsante, intestazione o campo di testo, e nella quasi totalità dei casi anche un nome, ricavato dal contenuto dell’elemento oppure da attributi dedicati. Il risultato somiglia a una pagina essenziale dei primi anni del web: qualche immagine, molti collegamenti, un campo e un comando. Osservare un’interfaccia tanto scarna restituisce un’idea fedele di ciò che percepisce chi naviga con un ausilio vocale, dove l’aspetto passa in secondo piano e resta soltanto la sequenza logica dei contenuti.

La rappresentazione semplificata non è un documento immutabile. Viene generata dal motore di rendering a partire dal codice della pagina e rispecchia la semantica dichiarata da chi sviluppa. Più gli elementi importanti esprimono in modo corretto la propria funzione, più la mappa risultante diventa precisa. Quando ruoli, stati e proprietà sono indicati con chiarezza, gli ausili per la disabilità ottengono tutto ciò che occorre per ricostruire un’esperienza alternativa coerente con quella visiva.

Dal DOM all’albero di accessibilità

La costruzione prende le mosse dal DOM e ne ricava un derivato più snello. Il motore di rendering del browser analizza la struttura della pagina e produce una gerarchia interna in cui scompaiono i nodi privi di significato, come i contenitori generici impiegati soltanto per applicare stili. Ciò che rimane è una rappresentazione in cui ogni oggetto utile dichiara un ruolo e, nella maggior parte dei casi, un nome leggibile.

Un esempio chiarisce il meccanismo. Una porzione di codice composta da un’etichetta, da un campo numerico e da due comandi viene convertita in una serie di nodi tipizzati: il testo dell’etichetta assume il ruolo di didascalia, il campo diventa un controllo numerico dotato di valore, mentre i due pulsanti vengono riconosciuti come tali e provvisti di nome. La mappatura avviene in automatico quando il codice esprime correttamente la funzione degli elementi, senza alcun intervento aggiuntivo.

Va precisato che la versione interna gestita dal motore di rendering contiene spesso più nodi di quanti ne raggiungano davvero gli ausili. Diversi contenitori generici restano confinati nella struttura interna e non arrivano mai allo strumento dell’utente, che riceve una gerarchia ancora più essenziale. La semplificazione, dunque, agisce su più livelli: una prima volta quando il modello del documento viene tradotto, una seconda quando i nodi non rilevanti vengono filtrati prima dell’esposizione. Il punto importante per chi scrive il codice è che l’intero processo resta a carico del browser. Il compito di chi sviluppa consiste nel rendere esplicita la semantica della pagina, così che la struttura derivata risulti accurata. Un albero dell’accessibilità costruito su markup chiaro riduce le ambiguità e permette agli strumenti di restituire un’esperienza fedele all’intento progettuale.

Ruolo, nome, stato e valore di ogni nodo

Ogni oggetto della struttura accessibile è descritto da un nucleo essenziale di informazioni che gli ausili leggono e annunciano alla persona. Quattro proprietà definiscono il modo in cui un elemento viene compreso: il ruolo indica di che tipo di componente si tratta, il nome lo identifica con un’etichetta, lo stato comunica la sua condizione del momento e il valore riporta l’eventuale dato contenuto.

Il ruolo risponde alla domanda più immediata, ovvero se l’elemento sia un pulsante, un’intestazione, una casella di controllo o un collegamento. Il nome accessibile fornisce l’etichetta con cui quel componente viene pronunciato e può provenire dal testo presente nell’elemento oppure da attributi specifici, come quelli dello standard ARIA. Lo stato descrive situazioni dinamiche, come una casella selezionata o un pannello espanso, mentre il valore restituisce contenuti quali il testo digitato in un campo. La combinazione di questi dati consente a un lettore di schermo di pronunciare, ad esempio, che un elemento ha ruolo di casella di controllo, si trova in stato selezionato e porta un certo nome.

Quando si adoperano gli elementi nativi corretti, ruolo, stato e valore risultano già coperti dal comportamento predefinito del linguaggio. Resta però un aspetto da curare con attenzione: il nome deve essere reso rilevabile. Per i contenuti testuali questo accade da sé, perché l’elemento racchiude già delle parole. Per i campi di inserimento, per i controlli e per i contenuti non testuali come le immagini, invece, occorre specificare un’etichetta esplicita. La precisione di queste quattro proprietà determina la qualità complessiva dell’albero di accessibilità, perché un nodo privo di nome o con uno stato non dichiarato genera un’esperienza incompleta per chi non vede lo schermo.

Semantica nativa dell’HTML e accessibilità integrata

Il browser riesce a trasformare il modello del documento in una mappa accessibile perché gran parte del codice possiede già un significato implicito. Gli elementi nativi del linguaggio sono riconosciuti dai browser e si comportano in modo prevedibile su piattaforme diverse, il che rende automatica la gestione dell’accessibilità per componenti come collegamenti e pulsanti. Scrivere markup che dichiari con precisione la funzione di ciascun elemento equivale a sfruttare questa accessibilità integrata senza lavoro aggiuntivo.

Il problema sorge quando si impiegano elementi che sembrano nativi ma non lo sono. Un blocco costruito per assomigliare a un pulsante, ad esempio un contenitore generico a cui è stato applicato uno stile grafico, non viene interpretato come un comando. Lo strumento dell’utente non dispone di alcun indizio sul tipo di elemento incontrato e il componente, così com’è codificato, può essere attivato soltanto con il mouse. Per renderlo utilizzabile anche da tastiera bisogna aggiungere manualmente la possibilità di riceverne il focus, replicando con fatica comportamenti che un elemento autentico offrirebbe da solo.

La soluzione è semplice e consiste nell’usare il pulsante reale previsto dal linguaggio anziché un contenitore travestito. Un elemento autentico gestisce in autonomia le interazioni da tastiera e si inserisce correttamente nella gerarchia degli oggetti accessibili, con ruolo, stato e valore già definiti. L’aspetto grafico non rappresenta un ostacolo: gli elementi nativi si personalizzano liberamente con i fogli di stile, mantenendo intatta la semantica e il comportamento impliciti. Rinunciare all’effetto visivo desiderato non è mai necessario. La regola pratica che emerge da questo confronto orienta gran parte del lavoro accessibile: esprimere la funzione degli elementi con il markup giusto consente al browser di alimentare un albero di accessibilità coerente, mentre la riproduzione artificiale dei componenti tramite contenitori neutri impone codice supplementare e introduce fragilità evitabili.

Nomi accessibili ed etichette per gli elementi interattivi

Fornire un nome accessibile a ogni elemento interattivo costituisce una delle priorità più riconosciute nelle liste di controllo dedicate all’accessibilità. Gli ausili annunciano ruolo, nome, stato e valore di un componente, e se uno di questi dati manca l’esperienza diventa incompleta. I nomi si dividono in due categorie: le etichette visibili, percepite da tutte le persone per attribuire un significato a un elemento, e il testo alternativo, riservato ai casi in cui un’etichetta a schermo non serve.

Per i contenuti testuali non occorre alcun intervento, poiché le parole presenti svolgono già la funzione di nome. La situazione cambia per i campi di inserimento, per i controlli e per le immagini, dove un’etichetta esplicita diventa indispensabile. Le indicazioni più diffuse raccomandano che ogni campo di un modulo disponga di un’etichetta testuale associata, così da risultare comprensibile sia con la vista sia tramite lo strumento dell’utente.

Esistono due modi per collegare un’etichetta a un controllo come una casella di selezione. Il primo consiste nell’inserire il campo all’interno dell’elemento che ne descrive il testo, creando un legame diretto tra i due. Il secondo prevede un riferimento esplicito tra l’identificativo del campo e l’attributo che lo richiama nell’etichetta. Entrambe le tecniche producono un beneficio aggiuntivo, perché il testo dell’etichetta diventa anche un’area attivabile, comoda per chi usa mouse o schermo tattile. Una volta stabilito il collegamento, il lettore di schermo può segnalare che l’elemento ha ruolo di casella di controllo, si trova in stato selezionato e porta un nome preciso. La cura dei nomi incide in modo diretto sulla completezza dell’albero di accessibilità, perché ogni etichetta assente si traduce in un nodo muto. Scorrere la pagina verificando ruoli, stati e nomi pronunciati permette di individuare i collegamenti realizzati in modo improprio e di correggerli prima della pubblicazione.

Le tecnologie assistive e gli agenti che leggono l’albero

Nella maggior parte dei casi gli ausili non leggono direttamente la pagina, ma si interfacciano con la sua versione ad albero accessibile. Il flusso di comunicazione segue uno schema preciso: un’applicazione, che sia il browser o un altro programma, espone una versione semantica della propria interfaccia tramite un’API dedicata; lo strumento assistivo legge quelle informazioni e costruisce un’interfaccia alternativa, come avviene in un lettore di schermo che genera una resa parlata dei contenuti.

Il dialogo procede anche nella direzione opposta. La tecnologia assistiva consente alla persona di agire sull’interfaccia in modi diversi, ad esempio simulando un clic o un tocco, e ritrasmette quell’intenzione all’applicazione attraverso la stessa API. Spetta poi al programma interpretare l’azione nel contesto dell’interfaccia originale. Nei browser lo scambio prevede un passaggio aggiuntivo in entrambi i sensi, perché il browser funziona da piattaforma per le applicazioni web che ospita: deve tradurre l’app in una mappa accessibile e garantire che le azioni provenienti dallo strumento dell’utente attivino gli eventi corretti nel codice.

Il pubblico che trae beneficio da questa architettura non si esaurisce nelle persone con disabilità. Gli agenti software e i crawler dei motori di ricerca esplorano i siti senza vista né udito, navigando di fatto come farebbe chi usa solo la tastiera, e individuano gli elementi interattivi proprio analizzando l’albero di accessibilità. Un’etichetta assente penalizza allo stesso modo chi naviga con un ausilio vocale e un agente automatico, mentre una struttura completa rende la scansione più efficace.

Diverse categorie di pubblico rientrano in questo perimetro più ampio:

• chi vive una disabilità temporanea, come un arto immobilizzato dopo un intervento;
• chi si trova in una condizione svantaggiosa legata al contesto, ad esempio in un ambiente troppo rumoroso o eccessivamente luminoso;
• chi ha una disabilità lieve e necessita di occhiali o di sottotitoli;
• chi non padroneggia la lingua dei contenuti e richiede più tempo di lettura;
• le persone anziane con sensi affievoliti dall’età;
• i bot di ottimizzazione per i motori di ricerca, privi di vista e udito.

A questo insieme si affiancano gli strumenti che rendono operativa l’interazione: software di lettura dello schermo, ingranditori, dispositivi braille, interruttori adattivi, sistemi di puntamento oculare e comandi vocali. Ognuno ricostruisce, a partire dalla medesima mappa semantica, un canale d’accesso calibrato sulle esigenze di chi lo utilizza.

Come ispezionare l’albero di accessibilità negli strumenti per sviluppatori

Gli strumenti per sviluppatori integrati nei browser permettono di osservare la mappa accessibile di una pagina e di capire come i contenuti vengono presentati agli ausili. Selezionando un nodo, un apposito riquadro mostra le proprietà di accessibilità corrispondenti insieme ai suoi antenati e ai suoi figli immediati. Le versioni più recenti vanno oltre la singola selezione e propongono la visualizzazione completa dell’intera gerarchia, sincronizzata con il modello del documento e attivabile con un semplice passaggio, così da rendere l’esplorazione più agevole.

Per garantire prestazioni adeguate anche sui siti più estesi, la struttura viene costruita in modo progressivo: i nodi figli vengono recuperati soltanto quando un ramo viene espanso, evitando di caricare in anticipo informazioni superflue. La rappresentazione è inoltre dinamica e si aggiorna in tempo reale ogni volta che l’albero di accessibilità cambia nel motore di rendering, sfruttando lo stesso meccanismo che notifica le modifiche agli ausili durante la navigazione.

La realtà sottostante è più articolata di un singolo albero. I contenuti di schede diverse, e i documenti provenienti da origini differenti, vengono isolati in processi separati: ciascuno viene interrogato in modo indipendente e i risultati vengono uniti per restituire l’illusione di una gerarchia coerente. Allo stesso modo, ogni piattaforma adotta un’interfaccia di accessibilità propria pur conservando la medesima forma generale, e per ridurre il disordine i nodi ignorati o privi di significato vengono nascosti prima della visualizzazione.

L’analisi non si esaurisce nell’ispezione manuale. Gli strumenti di verifica automatica assegnano un punteggio di accessibilità calcolato come media ponderata dei singoli controlli, dove ciascun esame viene superato per intero o fallito senza punteggi parziali. Il peso di ogni voce riflette l’impatto sull’esperienza delle persone, motivo per cui i controlli legati ai nomi accessibili, agli attributi e alle immagini incidono più di altri.

La distribuzione dei pesi rende evidente una priorità: gli aspetti che stabiliscono se un elemento è identificabile e utilizzabile contano più di quelli puramente formali, e proprio su questi si concentra il valore di una verifica accurata.  Qui l’elenco degli elementi da controllare.

Perché un albero di accessibilità completo conta per persone e mercato

La completezza della struttura accessibile non è un dettaglio tecnico astratto: stabilisce se milioni di persone riescono davvero a utilizzare un prodotto digitale, con ricadute che toccano la sfera individuale, quella economica e quella normativa. Le stime dell’OMS indicano che oltre il quindici per cento della popolazione mondiale, pari a circa 1,3 miliardi di persone, si identifica come persona con disabilità, il gruppo di minoranza più numeroso del pianeta. La cifra è destinata a crescere con l’invecchiamento della popolazione e con la diffusione delle malattie croniche.

Le diverse condizioni interagiscono con il mondo digitale in modi specifici, e una mappa semantica incompleta penalizza ciascuna in maniera differente:

Disabilità visive

Comprendono cecità, ipovisione e daltonismo; circa 253 milioni di persone convivono con una riduzione della vista e si affidano a lettori di schermo, ingranditori e dispositivi braille.

Disabilità motorie

Includono artrite, paralisi e amputazioni; una persona su sette incontra difficoltà di mobilità e ricorre a interruttori adattivi, puntamento oculare o input vocale.

Disabilità uditive

Vanno dalla sordità all’ipoacusia; oltre un miliardo e mezzo di persone presenta una perdita uditiva da lieve a moderata e dipende da sottotitoli e trascrizioni.

Disabilità cognitive

Raggruppano condizioni come dislessia, autismo e disturbi dell’attenzione; richiedono interfacce lineari, spaziatura adeguata e caratteri leggibili.

Crisi epilettiche e disturbi vestibolari

Riguardano epilessia e problemi di equilibrio; circa 50 milioni di persone convivono con l’epilessia e traggono vantaggio da impostazioni che riducono le animazioni.

Disturbi del linguaggio

Comprendono difficoltà nella produzione dei suoni del parlato; interessano milioni di persone e rendono problematica la tecnologia ad attivazione vocale.

Il valore economico di questo pubblico è rilevante. Il reddito disponibile delle persone con disabilità in età lavorativa raggiunge cifre paragonabili a quelle di altri grandi segmenti di mercato, e se si considerano familiari e cerchie di relazioni il bacino complessivo arriva a toccare oltre la metà dei consumatori, configurandosi come il più ampio mercato emergente. A ciò si aggiunge la spinta all’innovazione: numerose soluzioni nate per rispondere a esigenze di accessibilità, dalla tastiera ai comandi vocali fino al controllo oculare, sono poi diventate strumenti di uso quotidiano per chiunque.

Esiste infine una dimensione legale sempre più concreta. In diversi ordinamenti gli enti pubblici sono tenuti a rispettare regole di accessibilità digitale, e in aree come Unione Europea, Regno Unito, Canada, Giappone e Australia tali obblighi si estendono anche al settore privato. Le contestazioni in tribunale sono in aumento e colpiscono soprattutto i siti di commercio elettronico, che nel 2021 hanno rappresentato oltre il settanta per cento delle cause. Ogni nodo privo di nome, ogni controllo non associato a un’etichetta, contribuisce a un albero di accessibilità incompleto che esclude una parte del pubblico e, allo stesso tempo, espone l’organizzazione a un rischio crescente.

Checklist per controllare l’albero di accessibilità

Come funziona una checklist di accessibilità

Una lista di controllo dell’accessibilità funziona per esito binario: ogni verifica viene superata per intero oppure fallisce, e non esistono punteggi parziali. Se in una pagina alcuni pulsanti dispongono di un nome accessibile e altri ne sono privi, l’intero controllo relativo ai nomi risulta non superato. Questa rigidità ha una ragione pratica, perché un singolo elemento muto basta a bloccare chi dipende dagli ausili.

Il valore complessivo che molti strumenti di verifica automatica restituiscono è una media ponderata dei singoli esami. Il peso di ogni voce non è arbitrario, ma rispecchia quanto quel difetto incide sull’esperienza delle persone. I controlli più pesanti, intorno al valore massimo, riguardano gli elementi senza i quali l’interazione si interrompe del tutto, come un comando privo di nome o un attributo dichiarato in modo errato. I controlli intermedi segnalano problemi rilevanti ma spesso aggirabili, mentre quelli di peso ridotto incidono su aspetti di rifinitura. Leggere la checklist di accessibilità in quest’ordine consente di stabilire una sequenza di interventi sensata, dal difetto che esclude il maggior numero di utenti a quello marginale.

L’obiettivo finale di ogni verifica è sempre lo stesso: rendere accurata la rappresentazione semantica che il browser ricava dal DOM e consegna agli ausili. Un albero di accessibilità coerente nasce quando ruoli, nomi, stati e relazioni tra gli elementi sono dichiarati senza ambiguità, e la lista serve a confermare, voce per voce, che questa condizione sia rispettata. Alcuni termini ricorrono in qualunque elenco di verifiche e conviene fissarne il significato:

Nome accessibile

L’etichetta con cui un ausilio annuncia un elemento, ricavata dal testo contenuto, da un attributo dedicato o da un riferimento esplicito.

Area di riferimento

Una regione della pagina con un ruolo strutturale riconoscibile, come l’intestazione o il contenuto principale, che facilita la navigazione rapida.

Skip link

Un collegamento iniziale che permette di saltare i blocchi ripetuti e raggiungere subito il contenuto centrale.

Nomi accessibili per pulsanti, campi e immagini

Il primo blocco da affrontare riguarda i nomi, perché raccoglie i controlli dal peso più alto e tocca gli elementi con cui le persone interagiscono di più. Un comando deve sempre esporre un nome accessibile, così come i pulsanti realizzati tramite campi di inserimento devono contenere un testo distinguibile e le immagini usate come pulsanti devono fornire un’alternativa testuale. Allo stesso modo, ogni campo di un modulo va collegato a un’etichetta esplicita: senza questo legame l’ausilio non sa comunicare a cosa serva il controllo.

Esistono modi consolidati per soddisfare queste verifiche. Per i collegamenti e i pulsanti standard è sufficiente il testo contenuto nell’elemento. Per i campi di un modulo si collega l’etichetta racchiudendo il campo nell’elemento che ne descrive il testo, oppure mettendo in relazione l’identificativo del campo con l’attributo che lo richiama. Per le immagini informative si fornisce un’alternativa testuale che ne riassuma il contenuto, mentre per quelle puramente decorative si lascia un’alternativa vuota, in modo che l’ausilio le ignori senza confondere chi ascolta.

Accanto agli elementi più comuni, una checklist di accessibilità completa verifica anche i componenti più ricchi. I campi e i widget basati su attributi specifici, come indicatori di avanzamento, cursori, interruttori, suggerimenti e voci di struttura ad albero, devono tutti possedere un nome riconoscibile. Le finestre di dialogo e gli avvisi modali vanno nominati con la stessa cura, così come gli elementi che incorporano contenuti esterni e i riquadri annidati, che richiedono un titolo descrittivo. Quando un elemento mostra un’etichetta visibile, il nome annunciato dall’ausilio deve coincidere con quel testo, per evitare discrepanze tra ciò che si vede e ciò che si sente.

La regola che unifica tutte queste verifiche è semplice: ogni elemento attivo deve poter essere chiamato per nome. Nell’albero di accessibilità un nodo senza nome è un nodo muto, che blocca allo stesso modo chi naviga con un ausilio e l’agente automatico che esplora la pagina. Controllare i nomi prima di ogni altra cosa produce quindi il guadagno più immediato sul punteggio e sull’usabilità reale.

Attributi ARIA corretti e coerenti

Il secondo gruppo di voci di una checklist di accessibilità, anch’esso dal peso massimo, riguarda la correttezza degli attributi che arricchiscono la semantica. Questi attributi modellano direttamente la rappresentazione consegnata agli ausili, e un errore al loro interno non passa inosservato perché corrompe il modo in cui un elemento viene interpretato. Per questo i controlli pretendono che ogni attributo ARIA sia coerente con il ruolo a cui si applica, che gli elementi con un ruolo dichiarato possiedano tutti gli attributi obbligatori previsti, e che i valori dei ruoli e degli attributi siano validi e privi di errori di battitura.

Soddisfare queste condizioni richiede un principio guida che precede ogni tecnica: ricorrere agli attributi aggiuntivi solo quando l’HTML nativo non basta. Un elemento autentico porta con sé ruolo, stato e relazioni corretti, mentre un’aggiunta superflua introduce occasioni di errore. Quando l’uso di un ruolo è inevitabile, occorre verificarne il nome rispetto alla specifica, assegnare tutti gli attributi richiesti e controllare l’ortografia dei valori, perché una sigla scritta male equivale a un’istruzione ignorata.

Diverse verifiche tutelano poi la struttura delle relazioni. Alcuni ruoli devono trovarsi all’interno di un elemento contenitore preciso, e altri richiedono che i propri figli abbiano un ruolo specifico: un elenco di voci selezionabili, ad esempio, perde significato se i suoi discendenti non rispettano la gerarchia attesa. Gli identificativi usati negli attributi devono inoltre restare univoci nell’intero documento, altrimenti i riferimenti tra elementi si confondono.

Un’attenzione particolare spetta agli elementi nascosti agli ausili. Quando una porzione di pagina viene marcata come non rilevante per la tecnologia assistiva, non deve contenere al suo interno elementi capaci di ricevere il focus, perché si creerebbe la situazione paradossale di un comando raggiungibile da tastiera ma invisibile a chi usa un lettore di schermo. Allo stesso modo, l’intero corpo del documento non va mai dichiarato nascosto. Curare questo insieme di controlli è ciò che mantiene pulito l’albero di accessibilità, evitando che un singolo attributo errato propaghi ambiguità su un intero ramo della struttura.

Struttura, lingua e ordine del documento

La terza area di verifica guarda all’impalcatura della pagina e a come questa orienta la navigazione non visiva. Un documento deve dichiarare un titolo, esporre almeno un’area di riferimento principale che identifichi il contenuto centrale e offrire un punto d’appoggio iniziale, come un titolo, uno skip link o una regione strutturale. Le intestazioni vanno disposte in ordine gerarchico decrescente, senza salti dettati da ragioni estetiche, perché chi naviga per intestazioni costruisce mentalmente la mappa del documento proprio seguendo quella sequenza.

La lingua merita un capitolo a sé. L’elemento radice del documento deve indicare la lingua dei contenuti tramite l’apposito attributo, e quel valore deve essere valido, così che la sintesi vocale pronunci correttamente le parole. Quando è presente anche la dichiarazione in formato esteso, le due indicazioni devono concordare sulla stessa lingua di base, per non generare interpretazioni contrastanti.

Per intervenire su questi punti si parte sempre dal codice. Un titolo descrittivo va inserito una sola volta e deve riassumere il contenuto della pagina. L’area di riferimento principale si ottiene marcando il blocco centrale con il ruolo strutturale adeguato, mentre i collegamenti di salto devono poter ricevere il focus da tastiera, altrimenti perdono la loro funzione. Va inoltre evitato qualunque ordine di tabulazione forzato: assegnare valori positivi all’attributo che governa la sequenza del focus stravolge il percorso naturale e disorienta chi non usa il mouse, mentre lasciare che sia l’ordine del codice a guidare la navigazione produce un risultato prevedibile.

Restano infine i conflitti di identificativi. Gli elementi che possono ricevere il focus devono avere un identificativo univoco, e lo stesso vale per le scorciatoie da tastiera, che non vanno mai duplicate. Curare l’impalcatura significa fornire all’albero di accessibilità una struttura navigabile, fatta di regioni riconoscibili e di un ordine coerente, sulla quale gli ausili possono offrire scorciatoie e spostamenti rapidi. Una checklist di accessibilità che trascuri questi aspetti lascerebbe l’utente senza punti di riferimento, costretto a percorrere la pagina dall’inizio alla fine a ogni visita.

Elenchi, definizioni e tabelle ben formati

La quarta categoria di controlli riguarda gli elementi che organizzano informazioni in serie o in griglie, dove la struttura conta quanto il contenuto. Gli elenchi puntati e numerati devono contenere soltanto le voci previste, senza altri elementi inseriti come figli diretti, e ogni voce deve trovarsi all’interno di un contenitore di elenco valido. Le liste di definizioni seguono una regola analoga, perché i termini e le rispettive spiegazioni vanno raggruppati nell’apposito contenitore e disposti nell’ordine corretto, senza elementi estranei a interromperne la sequenza.

Il rispetto di queste condizioni si ottiene curando l’annidamento. Quando un elenco contiene solo le sue voci legittime, l’ausilio può annunciare quante sono e permettere all’utente di spostarsi tra loro; l’inserimento di elementi non pertinenti, al contrario, spezza questa lettura ordinata. Lo stesso vale per le definizioni, che acquistano senso solo se ogni termine resta legato alla propria descrizione all’interno della struttura prevista.

Le tabelle richiedono un’attenzione ancora maggiore, perché trasmettono relazioni tra dati. Una tabella deve fornire una didascalia tramite l’elemento dedicato, anziché simularla con celle estese artificialmente. Nelle griglie più ampie ogni cella di dati deve poter essere ricondotta a una o più intestazioni, e quando si usano riferimenti espliciti tra celle questi devono puntare a elementi della stessa tabella. Le intestazioni, infine, vanno dichiarate in modo che risulti chiaro quali dati descrivono, assegnando a ciascuna l’ambito di competenza per colonna o per riga.

Per costruire una tabella accessibile conviene quindi separare l’intestazione dal corpo, indicare con precisione il ruolo di ogni cella di testata e collegare i dati alle rispettive intestazioni. Una checklist di accessibilità che includa questi passaggi garantisce che l’albero di accessibilità rappresenti la griglia nel modo giusto, restituendo a chi non vede lo schermo la stessa logica di righe e colonne percepita visivamente. Senza queste accortezze, una tabella complessa si trasforma in una sequenza confusa di valori privi di contesto.

Collegamenti, contrasto e percezione visiva

La quinta area di verifica affronta ciò che rende i contenuti percepibili e i collegamenti riconoscibili. Un link deve risultare distinguibile senza affidarsi unicamente al colore, perché chi non percepisce le differenze cromatiche non noterebbe la presenza del collegamento; allo stesso tempo ogni link deve possedere un nome chiaro che ne riveli la destinazione. A questi due controlli si affianca la verifica sul contrasto tra il testo e lo sfondo, che deve mantenersi sufficiente per garantire la leggibilità.

Per soddisfare la prima condizione si abbinano al colore altri segnali visivi, come la sottolineatura, un’icona o una variazione di stile percepibile anche in scala di grigi. In questo modo il collegamento resta individuabile a prescindere dalla capacità di distinguere le tinte. Il colore può continuare a svolgere il suo ruolo, ma non deve mai essere l’unico indizio che comunica un’informazione.

La chiarezza dei nomi dei collegamenti incide direttamente sulla navigazione non visiva. Molti ausili permettono di consultare l’elenco di tutti i link di una pagina, estratti dal loro contesto: in quella vista, formule generiche come un invito a fare clic privo di destinazione risultano inutilizzabili. Un nome descrittivo, che anticipi dove conduce il collegamento, rende invece l’elenco navigabile e comprensibile. Quando più link puntano alla stessa risorsa, conviene che condividano lo stesso nome e lo stesso scopo, per non generare ambiguità.

Il contrasto, infine, riguarda chiunque, ma in particolare chi ha una percezione visiva ridotta o utilizza lo schermo in condizioni di luce sfavorevoli. Scegliere combinazioni di testo e fondale con una differenza di luminosità adeguata garantisce che le parole restino leggibili senza sforzo. Una checklist di accessibilità accurata tratta questi tre aspetti insieme, perché collegamenti riconoscibili e testo leggibile completano l’esperienza che l’albero di accessibilità rende possibile sul piano semantico, unendo la chiarezza della struttura a quella della superficie visibile.

Zoom, reindirizzamenti e controllo dell’utente

La sesta area di verifica difende il controllo che la persona ha sulla pagina e sul proprio dispositivo. Un documento non deve forzare un aggiornamento o un reindirizzamento automatico tramite l’apposita istruzione, perché un cambiamento improvviso interrompe la lettura, sposta il punto di attenzione e penalizza chi impiega più tempo a elaborare i contenuti. La pagina deve inoltre consentire l’ingrandimento, dato che disabilitare lo zoom, vietando il ridimensionamento o limitando in modo eccessivo il fattore di scala, impedisce a chi ha una vista ridotta di adattare il testo alle proprie esigenze.

Soddisfare questi controlli significa rinunciare a comportamenti che tolgono autonomia all’utente. Al posto di un aggiornamento temporizzato conviene segnalare le novità senza ricaricare la pagina, lasciando che sia la persona a decidere quando proseguire. Per il viewport va evitata qualunque impostazione che blocchi l’ingrandimento, mantenendo la possibilità di zoomare fino a un livello generoso. Chi ingrandisce i caratteri non sta esprimendo una preferenza estetica, ma una necessità concreta, e una pagina accessibile non deve mai ostacolarla.

Allo stesso ambito appartiene la verifica sui contenuti video, che devono includere una traccia di sottotitoli sincronizzati. I sottotitoli rendono il parlato accessibile a chi non sente l’audio, ma risultano utili anche in contesti rumorosi o quando l’ascolto non è possibile. Inserire una traccia dedicata, anziché affidarsi a trascrizioni assenti o generate in modo impreciso, completa l’esperienza multimediale.

Questi controlli condividono un principio: la persona deve restare padrona del proprio percorso, dei tempi di lettura e del modo in cui adatta l’interfaccia. Una checklist di accessibilità non si limita perciò a misurare la struttura semantica che alimenta l’albero di accessibilità, ma verifica anche che la pagina non imponga vincoli arbitrari, perché un contenuto perfettamente etichettato resta inutilizzabile se nega all’utente il diritto di ingrandirlo, metterlo in pausa o seguirlo con i propri tempi.

Priorità di una checklist di accessibilità in base al peso

Conoscere il peso di ogni controllo permette di organizzare il lavoro secondo un criterio di efficacia, affrontando per primi i difetti che escludono il maggior numero di persone. Le voci dal valore più alto si concentrano su tre fronti:

• i nomi mancanti su pulsanti, campi e immagini, che rendono muti gli elementi interattivi;
• gli attributi semantici dichiarati in modo errato o con identificativi duplicati, che corrompono l’interpretazione degli elementi;
• i comportamenti che sottraggono controllo all’utente, come il blocco dello zoom o gli aggiornamenti forzati.

Sistemare questi punti produce il miglioramento più consistente, sia sull’usabilità reale sia sul valore restituito dagli strumenti di verifica. I controlli di peso intermedio raccolgono problemi importanti ma spesso meno bloccanti, come il contrasto insufficiente, i collegamenti dal nome ambiguo o la lingua del documento non dichiarata. Le voci di peso ridotto, infine, riguardano rifiniture che migliorano l’esperienza senza esserne il fondamento, come l’ordine delle intestazioni o la presenza di un’unica etichetta per campo. Affrontare l’elenco in questa sequenza evita di disperdere energie su dettagli marginali mentre restano aperti difetti capaci di impedire del tutto l’interazione.

Il quadro seguente riassume le verifiche a maggiore impatto e indica, per ciascuna, l’intervento corretto:

La sequenza dei pesi non è soltanto un criterio di efficienza, ma una bussola che riconduce ogni intervento al suo effetto concreto. Ogni voce sistemata aggiunge un nodo correttamente descritto all’albero di accessibilità, amplia la platea di persone in grado di usare il sito e riduce il rischio che un agente automatico o un utente con disabilità trovi una porta chiusa. Una checklist di accessibilità applicata con metodo, dalla voce più pesante a quella più lieve, trasforma una verifica formale in un guadagno misurabile di inclusione e di qualità.