Mentre in passato le tecnologie assistive interagivano direttamente con il mark up attualmente si affidano principalmente ai browser per interpretare il contenuto delle pagine e presentarlo agli utenti sottoforma di rendering alternativo. 

I browser interpretano il codice delle pagine web in una rappresentazione ad albero degli elementi, una struttura gerarchica a oggetti che presenta proprietà, metodi ed eventi disponibili chiamata Document Object Model, DOM. Sulla base del DOM, le API di accessibilità specifiche della piattaforma elaborano l’albero di accessibilità, una rappresentazione semantica degli oggetti che viene utilizzata per fornire una rappresentazione utilizzabile dalle tecnologie assistive. 

Definire gli elementi secondo le specifiche rende disponibili alle tecnologie assistive nome, ruolo, valore e stato attraverso il Document Object Model, DOM, e le API di accessibilità specifiche della piattaforma.  

Le API di accessibilità comunicano alle tecnologie assistive le informazioni sui componenti delle interfacce utente: 

• Proprietà come ruolo, nome, valore, posizione etc. 
• Stati  
• Eventi, ad esempio digitazione in una casella di testo, selezione di un valore da una select, click di un link 
• Azioni disponibili per l’utente come aprire una pagina, cliccare, selezionare, attivare, digitare etc. 
• Relazioni fra gli oggetti che esprimono un contenuto semantico, ad esempio la didascalia è collegata all’immagine, il punto elenco fa parte di tre punti elenco totali  
• Contenuto testuale 

Le API di accessibilità comprendono gli algoritmi per calcolare e recuperare il nome accessibile e le proprietà per ogni oggetto dell’albero di accessibilità. 

Sono approfonditi di seguito i requisiti richiesti dal criterio di successo 4.1.2 per garantire la compatibilità di componenti dell’interfaccia utente: 

• nome e ruolo possono essere determinati programmaticamente 
• stati, proprietà e valori che possono essere impostati dall’utente possono essere impostabili da programma 
• le notifiche sui cambi di stato di questi elementi sono rese disponibili ai programmi utente, incluse le tecnologie assistive 

Il criterio di successo 4.1.2 richiede che tutti i componenti dell’interfaccia abbiano un nome associato tramite codice. Il nome, definito anche “nome accessibile “perché utilizzato dalle tecnologie assistive, deve essere: 

• significativo per la finalità del componente nell’interfaccia 
• coerente con il nome visibile nell’interfaccia utente 

Il nome accessibile è una breve descrizione che fornisce informazioni sullo scopo dell’oggetto, dovrebbe essere uguale all’etichetta visibile agli utenti, se presente, in modo che gli utenti di tecnologie assistive che usano i comandi vocali siano in grado di attivare gli oggetti. Ad esempio, se sul pulsante di ricerca è visualizzato “cerca” il nome accessibile dovrebbe essere “cerca“ e non “ricerca”, “trova” etc, vedi criterio di successo 2.5.3 “Etichetta nel nome”. 

Il nome accessibile viene calcolato sulla base di un algoritmo a seconda del componente e non corrisponde all’attributo HTML <name>, usato in programmazione ma non intercettato dalle tecnologie assistive. 

Il ruolo invece definisce la tipologia di componente, input, link, select etc., e fornisce alla tecnologia assistiva le informazioni su come interagire. 

Nome e ruolo devono essere definiti dagli autori del software in modo che siano determinabili programmaticamente, cioè che le informazioni che contengono possano essere estratte e rappresentate sotto altre forme dai programmi utente e in particolare dalle tecnologie assistive. Per un’icona non decorativa, ad esempio, il nome accessibile, “errore”, può essere fornito tramite l’alternativa testuale.  

Come specificato nella nota del criterio di successo, il ruolo è definito per gli elementi standard dell’HTML, come i campi di input, i pulsanti, i collegamenti ipertestuali etc., se usati secondo le specifiche, documentate e supportate per esporre queste proprietà alle tecnologie assistive, vedi paragrafo Utilizzo di HTML secondo le specifiche. I componenti standard HTML cioè sono definiti in modo tale da offrire queste informazioni ma gli autori devono garantire che le informazioni siano disponibili. Il nome accessibile di un campo di input, ad esempio, può essere veicolato dall’etichetta associata; è richiesto quindi che gli autori creino, associno e valorizzino opportunamente un’etichetta al campo di input. 

Per questo motivo si consiglia di usare sempre, ove possibile, i componenti HTML standard. Nel caso sia necessario definire un componente personalizzato, oppure se gli elementi dell’interfaccia sono definiti dinamicamente con un ruolo diverso da quello usuale, il criterio di successo richiede che sia fornito con gli attributi necessari per poter interagire con le tecnologie assistive. 

l criterio di successo richiede che sia possibile interagire con i comandi presenti nella pagina ricevendo e impostando il valore tramite programma utente o tecnologia assistiva. Tramite screen reader, ad esempio, deve essere possibile selezionare una voce da un componente option, assegnare un valore ad un campo di input oppure cambiare lo stato di una pratica da “in lavorazione” a “lavorazione conclusa”. Il valore di un collegamento ipertestuale è rappresentato dall’attributo href che contiene il link a cui punta, il valore di un campo di input è il suo contenuto mentre il valore di una lista di elementi selezionabili è l’elemento selezionato.

Per poter interagire correttamente con i componenti di una pagina web è necessario ottenere informazioni sui cambiamenti di stato di un oggetto, ad esempio se un elemento espandibile come un menu è chiuso o aperto o se un elemento di selezione è stato selezionato. 

I principali browser web di mercato permettono di consultare l’albero di accessibilità tramite gli strumenti di sviluppo.  

L’albero di accessibilità del browser rappresenta gli oggetti a disposizione delle tecnologie assistive per interrogare attributi e proprietà ed eseguire azioni. 

Ispezionando l’albero dell’accessibilità è possibile verificare la rispondenza ai requisiti delineati dal criterio di successo e individuare alcune problematiche di accessibilità. Di seguito una checklist di verifica: 

• sono rappresentati tutti gli elementi della pagina? 
• sono presenti nomi e descrizioni appropriati per tutti gli oggetti?  
• lo scopo di ogni oggetto è definito in modo da essere comprensibile con il rendering alternativo?  
• cambiando lo stato di un elemento (ad esempio, comprimendo un menu o facendo clic su una casella di controllo) l’albero di accessibilità si aggiorna? 

Per soddisfare il criterio di successo 4.1.2 si consiglia di utilizzare solo le funzionalità definite nelle specifiche seguendo le modalità previste dalle specifiche. Ad esempio, l’HTML prevede tag semantici codificati, componenti cioè che contengono una rappresentazione non ambigua del proprio significato comprensibile dal browser e dalle tecnologie assistive. HTML5, in particolare, ha introdotto tag semantici per l’organizzazione dei contenuti della pagina. Alcuni esempi sono: 

• le intestazioni <header>,  
• i piè di pagina <footer>,  
• le sezioni in cui organizzare ulteriormente il contenuto <section>,  
• le immagini e le relative didascalie <figure> e <figcaption> 

Il tag <footer>, ad esempio, è l’elemento che contiene la parte inferiore delle pagine ed espone contenuti come contatti, riferimenti ai social, link utili e, nel caso delle pubbliche amministrazioni, i link agli adempimenti legali, fra cui la dichiarazione di accessibilità. Definire l’intestazione della pagina nel tag <footer> è un esempio grossolano di utilizzo improprio del tag semantico.  

Usare i tag definiti nelle specifiche nelle modalità previste, cioè seguendo le indicazioni in termini di attributi e valori, garantisce che i componenti siano correttamente interpretati e presentati agli utenti. Ad esempio, definire correttamente le sezioni <section> consente a chi naviga con lo screen reader di scorrere il contenuto navigando fra le sezioni per comprendere rapidamente l’organizzazione e focalizzarsi sul contenuto di interesse. 

Le tecnologie assistive utilizzano le API di accessibilità per ottenere informazioni necessarie per il rendering alternativo come nome, valore, ruolo e stato. Nella tabella viene mostrato come si ricavano tali attributi per alcuni componenti HTML standard di uso comune: 

• nome: fornito dal testo associato all’elemento 
• ruolo: fornito dall’elemento HTML 
• valori e stati, vengono resi disponibili a seconda dell’elemento 

Il nome, ad esempio può essere associato al componente tramite un attributo obbligatorio, la <label> o l’attributo ‘title’ per gli input con ruolo ‘testo editabile’.  

Nei paragrafi successivi sono fornite indicazioni di dettaglio per l’implementazione. 

Il nome accessibile con l’elemento <label>

È possibile fornire il nome tramite il tag <label>: 

• per numerose tipologie di campi di input e per la textarea che consente la digitazione su più righe  
• per gli elementi di selezione multipla radio, checkbox, select 
• per gli elementi che visualizzano la scala in un intervallo, <meter> e il progresso di un’operazione, ad esempio, nel caricamento di un file, <progress> 

L’utilizzo dell’elemento label per associare l’etichetta al componente offre numerosi vantaggi: 

• è associato tramite l’attributo univoco “id” che contraddistingue ogni elemento in programmazione 
• è programmaticamente determinabile: grazie all’“id” i programmi utente, ad esempio lo screen reader, riescono ad estrarre le informazioni necessarie per offrire la presentazione in un altro formato

Il nome accessibile per i raggruppamenti: <legend>  <fieldset>

Il tag <fieldset> si utilizza per raggruppare ed enfatizzare il legame semantico fra gli elementi a selezione multipla di tipo radiobutton e chechbox, ad esempio per selezionare le modalità di spedizione di un pacco. Consente infatti sia di raggruppare visivamente gli oggetti che di collegarli ad una didascalia:  

• tramite le proprietà del tag <fieldset> è possibile rendere visibile una cornice che identifichi visivamente il raggruppamento 
•  il tag <legend>, utilizzabile solo insieme al tag <fieldset>, consente di inserire una didascalia riferita a tutto il raggruppamento 

Il nome accessibile, l’etichetta, dei singoli elementi è fornito tramite il tag <label>. Anche i tag <fieldset> e <legend> sono programmaticamente determinabili. 

Un altro utilizzo del tag <fieldset> consiste nel raggruppare elementi che insieme sono logicamente correlati per definire un’entità, ad esempio, il bonifico bancario: 

• ordinante,  
• beneficiario,  
• IBAN beneficiario,  
• importo,  
• causale etc.  

Raggruppare gli elementi correlati e definirli con una legenda valida per tutti come il tag <legend> agevola la comprensione del form. 

Nel paragrafo Come le Tecnologie Assistive interagiscono con le pagine web, sono state presentate le API di accessibilità specifiche per piattaforma. Se si opta per definire un componente tramite programmazione numerose piattaforme sono fornite di componenti predisposti per interfacciarsi con le API di accessibilità. I componenti predefiniti della piattaforma devono essere forniti di nome, ruolo e valore ovvero proprietà e stati necessari ad interagire con le tecnologie assistive.  

Nei casi in cui non è possibile usare un componente predefinito ma se ne definisce uno personalizzato è necessario realizzare un’implementazione compatibile con l’API di accessibilità utilizzando gli attributi WAI-ARIA. 

È sempre necessario definire i componenti, sia predisposti dalle piattaforme che personalizzati, in modo che sia consentita l’interazione da tastiera secondo la Linea guida 2.1 “Accessibile da tastiera”. 

Si consiglia di effettuare sempre dei test con le tecnologie assistive per verificare che il risultato ottenuto sia quello atteso con diverse combinazioni di sistema operativo, browser, dispositivo (pc, tablet, smartphone). 

Gli attributi WAI-ARIA, Web Accessibility Initiative – Accessible Rich Internet Applications, rendono le applicazioni Web più accessibili per le tecnologie assistive. Associano ai componenti dell’interfaccia le informazioni semantiche necessarie alle tecnologie assistive per interagire correttamente con i componenti. Gli attributi WAI-ARIA costituiscono una raccolta di stati e proprietà di accessibilità utilizzati per supportare le API di accessibilità di numerose piattaforme. Le tecnologie assistive possono accedere a queste informazioni attraverso il DOM o la mappatura delle API di accessibilità. Stati e proprietà, insieme al ruolo possono fornire alle tecnologie assistive informazioni sull’interfaccia utente da trasmettere all’utente in qualsiasi momento. Ogni modifica agli stati o alle proprietà comporta una notifica alle tecnologie assistive, che sono messe così in grado di avvisare l’utente dei cambiamenti.  

Gli attributi WAI-ARIA possono essere utilizzati per fornire nome, ruolo, valore e stato per i componenti personalizzati o per sovrascrivere o integrare nome, ruolo, valore e stato dei componenti HTML standard. 

Nel W3C Working draft “Using ARIA” sono riassunte le best practice per l’utilizzo di WAI-ARIA: 

1. Se puoi utilizzare un componente HTML standard o un attributo già predisposto con la semantica e il comportamento necessario invece di modificare un componente aggiungendo un ruolo, stato o proprietà ARIA per renderlo accessibile, allora fallo. 
2. Non modificare la semantica nativa, a meno che non sia realmente necessario 
3. Tutti i componenti interattivi ARIA devono essere utilizzabili con la tastiera 
4. Non utilizzare gli attributi role=”presentation” (nasconde il componente dal DOM) o aria-hidden=”true” (rimuove il componente dal DOM) su elementi che ricevono il focus  
5. Tutti gli elementi interattivi devono avere un nome accessibile 

Abbiamo affrontato le prime due best practice nel paragrafo, Usare componenti e link HTML standard. I punti 3 e 4 affrontano il tema dell’accessibilità da tastiera e del focus che deve essere garantita e implementata anche per tutti i componenti personalizzati, vedi paragrafo Definire componenti personalizzati accessibili. Il punto 5 affronta il tema del nome accessibile descritto nel dettaglio nei paragrafi seguenti. 

Definire correttamente tutti gli attributi di un componente personalizzato è molto più complesso che implementare un componente HTML standard e aumenta in maniera considerevole l’onere della manutenzione. Si consiglia quindi di utilizzare gli attributi WAI-ARIA solo quando è strettamente necessario e di effettuare sempre dei test con le tecnologie assistive per verificare che il risultato ottenuto sia quello atteso con diverse combinazioni di sistema operativo, browser, dispositivo (pc, tablet, smartphone). 

Sono presentati di seguito alcuni casi di implementazione particolarmente significativi. 

L’attributo aria-label viene utilizzato per: 

• attribuire un nome accessibile ad un elemento html che ne è privo 
• sovrascrivere il nome accessibile di un elemento html  

L’elemento HTML <div> è un elemento contenitore di titoli, paragrafi, immagini etc. risulta molto versatile ma è privo di un nome accessibile. Tramite l’aria-label è possibile fornire una descrizione del contenuto presentato nel <div>. 

Il tag aria-label viene spesso utilizzato per tradurre nel rendering alternativo lo scopo di un elemento veicolato dal contesto e dall’aspetto di un componente. Ad esempio, la X maiuscola che indica il pulsante di chiusura di una finestra modale è un indicatore sufficiente per gli utenti vedenti. Il nome accessibile del pulsante corrisponde al contenuto racchiuso nel tag <button></button>, in questo caso “X”, poco significativo per un utente di screen reader. Il tag aria-label che, secondo l’algoritmo di calcolo sovrascrive il nome del pulsante, può essere associato all’elemento button per fornire agli utenti di tecnologie assistive un nome accessibile, come “Chiudi”. 

L’attributo aria-label si usa quando nella pagina non è presente un testo da utilizzare come nome accessibile.  Se è già presente nella pagina un testo che fornisce il nome accessibile è possibile associarlo al componente tramite l’attributo aria-labelledby. 

Nell’esempio di notifica con pulsante di chiusura disponibile nella libreria Bootstrap Italia, il nome accessibile “Titolo notifica” è presente nel titolo h2 e viene associato al div tramite l’id=”not1dms-title”. 

<div class=”container test-docs”> 

  <div class=”row”> 

    <div class=”col-12 col-md-6 mb-4 mb-md-0″> 

      <p class=”mb-4″><strong>Notifica eliminabile con testo</strong></p> 

      <div class=”notification dismissable” role=”alert” aria-labelledby=”not1dms-title” id=”not1dms”> 

        <h2 id=”not1dms-title” class=”h5 “>Titolo notifica</h2> 

        <button type=”button” class=”btn notification-close”> 

          <svg class=”icon”><use href=”/bootstrap-italia/dist/svg/sprites.svg#it-close”></use></svg> 

          <span class=”visually-hidden”>Chiudi notifica: Titolo notifica</span> 

        </button> 

      </div> 

    </div> 

  </div> 

</div> 

Bootstrap Italia è una libreria open source, costruita  su Bootstrap 5.2.3, di cui eredita tutte le funzionalità personalizzate secondo le indicazioni in termini di design, usabilità e accessibilità definite nelle nuove “Linee guida di design per i siti internet e i servizi digitali della Pubblica Amministrazione“, e nel “Manuale operativo di design” a supporto. Bootstrap Italia usa i pattern e i componenti definiti nello UI KIT Designers Italia versione 3.0.1 e li trasforma in codice pronto all’uso. 

L’aria-labelledby permette di concatenare più valori referenziati attraverso i rispettivi identificativi univoci, id; questa proprietà è particolarmente utile se è necessario concatenare più valori oppure per fornire le informazioni di contesto disponibili agli utenti vedenti. Per fornire etichette significative per un grafico a barre, ad esempio, bisogna concatenare opportunamente i valori delle assi e delle quantità rappresentate. Analogamente per comprendere il significato di un dato numerico in una tabella è necessario concatenare il valore con il titolo della relativa riga e colonna.  

Per gli utenti di tecnologie assistive il contenuto delle proprietà aria-label e aria-labelledby  integra o sostituisce quello dell’elemento html nativo, ad esempio la label. 

Il nome accessibile viene ricavato a seconda dell’elemento dell’interfaccia utente e potrebbe anche non essere impostato.  

Le API di accessibilità creano una struttura parallela chiamata albero dell’accessibilità, che rappresenta gli oggetti accessibili del Document Object Model, DOM. Il nome accessibile viene calcolato secondo un algoritmo che cambia a seconda degli attributi che sono presenti per l’elemento.  

Per i campi di input di tipo “text”, “password”,”number”, “search”, “tel”, “email”,”url” e per i componenti di tipo textarea, ad esempio, l’algoritmo per il calcolo del nome accessibile valuta in ordine gerarchico gli attributi presenti per l’elemento: 

1. in prima battuta l’attributo aria-label o aria-labelledby, se è presente  
2. altrimenti l’elemento label  
3. altrimenti l’attributo title 
4. altrimenti il valore del placeholder, l’attributo placeholder compare all’interno del campo di input dove è attesa la compilazione dell’utente 
5. se nessuno dei precedenti produce una stringa di testo utilizzabile non esiste un nome accessibile 

Per l’elemento immagine, tag <img>, l’algoritmo per il calcolo del nome accessibile attribuisce in prima battuta il valore: 

1. aria-labelledby se è presente  
2. altrimenti aria-label 
3. altrimenti l’attributo alt 
4. altrimenti l’attributo title  
5. Se nessuno dei precedenti produce una stringa di testo utilizzabile, non esiste un nome accessibile 

L’attributo role fornisce informazioni alle tecnologie assistive su come elaborare i componenti: 

• una descrizione  
• informazioni gerarchiche sui ruoli correlati, il ruolo “searchbox”, ad esempio, caratterizza una casella di testo utilizzata per la ricerca 
• contesto del ruolo, ad esempio, una voce fa parte di un elenco 
• stati e proprietà supportati per ciascun ruolo, per la checkbox, ad esempio è disponibile lo stato selezionato, “aria-checked”  

I ruoli possono definire come interagire con un singolo componente, ad esempio “button” per indicare un pulsante, oppure come il componente è definito nella struttura della pagina, ad esempio “textbox” per le caselle di testo. 

Quando i ruoli WAI-ARIA sovrascrivono la semantica del linguaggio non ci sono modifiche nel DOM ma solo nell’albero dell’accessibilità . 

Anche per i documenti non web è necessario fornire nome, ruolo e valore per gli elementi che compongono il documento. Gli utenti di tecnologie assistive devono essere messi in grado di riconoscere i componenti del documento non web e di poter interagire. 

Se per l’HTML è possibile ricorrere ai componenti standard che sono dotati degli attributi necessari per i documenti non web si fa ricorso agli oggetti nativi messi a disposizione dai programmi. Gli autori di documenti non web si affidano quindi ai programmi seguendo le istruzioni per realizzazione di oggetti accessibili. 

Si raccomanda di verificare sempre i documenti non web realizzati e di effettuare test con le tecnologie assistive per verificare che il risultato ottenuto sia quello atteso con diverse combinazioni di sistema operativo, browser, dispositivo (pc, tablet, smartphone). 

Il caso di studio proposto è la realizzazione di una casella di input per un modulo pdf editabile. Il programma utilizzato è l’editor di testo “Writer” della suite open source “Libre Office” che permette di esportare file in formato pdf.  

Il nome accessibile è rappresentato dall’etichetta che trasmette lo scopo di ciascun controllo del modulo. Il ruolo dipende dal componente dei “controlli del formulario” selezionato, casella di testo, campo data, pulsante di scelta etc. Il valore può essere specificato se necessario tramite le “proprietà del controllo”.  

Per associare il nome accessibile, l’etichetta, alla casella di testo sono necessari i seguenti passaggi. Dalla barra degli strumenti “Controlli per il formulario” è possibile selezionare l’oggetto “Etichetta” fra i numerosi componenti interattivi disponibili: la casella di testo, il campo data, il campo numerico, il campo valuta, il pulsante, l’elemento di selezione file per l’upload, etc. Selezionato il componente desiderato il cursore del mouse cambia aspetto per indicare che è possibile disegnare l’oggetto. Cliccando con il tasto destro su “Proprietà del controllo” è possibile definire le proprietà generali e relative all’aspetto (carattere, dimensioni del carattere etc.) ad esempio: 

• il “Nome”, necessario a distinguere l’etichetta dalle altre disponibili nella pagina, corrisponde all’attributo “name” dell’HTML. È possibile lasciare il nome suggerito ad esempio “Testo fisso 2” 
• la “Didascalia” è il nome accessibile e il testo visibile dell’etichetta, nell’esempio “Ufficio di riferimento” 

Dalla barra degli strumenti “Controlli per il formulario” selezionando “Casella di testo” o dal percorso “Formulario\Casella di testo” è possibile creare un nuovo oggetto di questa tipologia. Anche per la casella di testo è presente un nome predefinito, mentre dalla voce “Campo didascalia” delle “Proprietà del controllo” è possibile visualizzare le etichette presenti nel formulario per selezionare l’etichetta desiderata da associare al componente, in questo esempio l’etichetta “Ufficio di riferimento”, creata al passaggio precedente.  

Per una casella di input il “valore” è il contenuto del campo. A seconda del significato del campo è possibile inserire un valore di default, se opportuno, tramite la proprietà “Testo predefinito” cliccando con il tasto destro su “Proprietà del controllo”. Nell’esempio la proprietà “Testo predefinito” è stata valorizzata a “Ufficio Roma Centro”. 

È opportuno impostare ulteriori proprietà che forniscono indicazioni per l’interazione necessarie alla navigazione da tastiera e a definire l’aspetto al focus: 

• tabulazione: la tabulazione è necessaria per la navigazione da tastiera ma può essere disattivata tramite questa proprietà 
• sequenza di attivazione: indica l’ordine sequenziale da 0 a n con cui il focus passerà da un oggetto all’altro del documento e deve seguire l’ordine logico di interazione. Se la tabulazione è disattivata viene disattivata anche la sequenza di attivazione 
• fra gli eventi disponibili selezionare “al ricevimento del fuoco” e “alla perdita del fuoco” e la relativa macro predefinita 

Per esportare il file in formato pdf è possibile selezionare dal menu “File” la voce “Esporta come\ Esporta direttamente in pdf” oppure “Esporta come\ Esporta nel formato pdf” selezionando le voci: 

• Generale\PDF con tag 
• Generale\Crea formulario PDF – Formato di invio dati: PDF 
• Struttura\Esporta la struttura 
• Struttura\Esporta segnaposti