Migliorare l'accessibilità web con gli ARIA labels: una porta verso una User Experience inclusiva

Nel mondo interconnesso di oggi, il web è diventato parte integrante della nostra vita: è un canale di accesso a informazioni, comunicazioni e innumerevoli esperienze digitali. Tuttavia, è importante comprendere che non tutti interagiscono con il mondo digitale nello stesso modo. La mancanza di accessibilità può creare barriere significative per le persone con disabilità, limitandone la possibilità di accedere e navigare siti web e applicazioni.

Uno degli strumenti più importanti a disposizione di un Web Developer per migliorare l’accessibilità è l’uso degli ARIA labels (Accessible Rich Internet Applications). Questi consentono di trasmettere informazioni fondamentali alle tecnologie assistive, come gli screen reader, permettendo a chi ha disabilità visive di percepire e comprendere i contenuti delle pagine web in modo efficace.

In Buildo crediamo fermamente nella forza dell’accessibilità e nel suo impatto positivo sul web e sui suoi utenti. Per questo ci impegniamo a sensibilizzare e promuovere un cambiamento concreto nel panorama digitale.

In questo articolo esploreremo il significato degli ARIA labels e il loro impatto sull’accessibilità web. Integrandoli nei propri progetti, i web developer possono compiere un passo significativo verso la creazione di contenuti digitali realmente fruibili da tutti, indipendentemente dalle capacità individuali.

Cosa sono gli ARIA labels?

Gli ARIA labels sono attributi che possono essere aggiunti agli elementi HTML che non hanno contenuti testuali sufficienti o che richiedono un contesto aggiuntivo per essere interpretati correttamente dalle tecnologie assistive.

Si possono implementare usando attributi come aria-label, aria-labelledby o aria-describedby, in modo che le informazioni vengano comunicate correttamente agli utenti delle tecnologie assistive.

Il loro utilizzo è descritto nella specifica WAI-ARIA (Web Accessibility Initiative - ARIA), un documento tecnico creato dal W3C per migliorare l’accessibilità dei contenuti web attraverso attributi, ruoli e stati aggiunti agli elementi HTML, così da trasmettere informazioni sul loro scopo, comportamento e funzionalità interattive.

Partiamo da un esempio semplice: immaginiamo un pulsante in una pagina web che mostra un’icona a forma di cuore, che rappresenta l’azione di mettere “mi piace” a un contenuto.

Un pulsante “like” con un’icona a forma di cuore

Per gli utenti vedenti il significato è immediato, ma per chi si affida a tecnologie assistive come gli screen reader potrebbe non essere altrettanto chiaro. Con un ARIA label possiamo aggiungere una descrizione breve e significativa dello scopo del pulsante, assicurandoci che tutti gli utenti, indipendentemente dalle loro capacità, ne comprendano la funzione. In questo caso, l’ARIA label “Like” o “Favorite” può essere aggiunta al pulsante, rendendolo percepibile e interpretabile dalle tecnologie assistive. Questa semplice implementazione trasforma un’icona altrimenti ambigua in un elemento di interfaccia chiaro e accessibile, migliorando l’esperienza complessiva e l’inclusività dell’applicazione web.

<button type="button" aria-label="Like">
  <img src="heart.png" alt="">
</button>

Quando gli ARIA labels servono a nascondere contenuto

Nell’esempio precedente avrai notato che all’immagine del cuore abbiamo assegnato un alt text vuoto. L’alt text è l’equivalente di un aria-label per le immagini, perché permette di fornire un testo alternativo. Anche se impostarlo come stringa vuota può sembrare scorretto — stiamo decidendo esplicitamente di non fornire alcuna descrizione testuale dell’immagine alle tecnologie assistive — in questo caso è la scelta migliore per garantire una buona esperienza utente: l’informazione testuale dell’elemento interattivo è già fornita dall’aria-label sul pulsante che contiene l’immagine, quindi l’icona può essere considerata puramente decorativa. Se invece fornissimo un testo alternativo (o omettessimo del tutto l’attributo alt), le tecnologie assistive leggerebbero la stessa informazione due volte, generando più confusione per gli utenti con disabilità visive.

Le specifiche WAI-ARIA e le WCAG (Web Content Accessibility Guidelines) consigliano questa strategia ogni volta che vogliamo nascondere elementi alle tecnologie assistive, per esempio perché puramente decorativi o, come nel caso precedente, ridondanti. Impostando un aria-label vuoto (o un testo alternativo vuoto) preveniamo la trasmissione di informazioni superflue o fuorvianti agli utenti che si affidano alle tecnologie assistive, aiutandoli a concentrarsi su contenuti e interazioni rilevanti senza essere interrotti da elementi visivi non essenziali.

Cosa fare e cosa evitare per nascondere i contenuti

ARIA labels nei campi dei form

I form sul web possono risultare frustranti persino per gli utenti senza disabilità. A volte è molto difficile capire quale errore stia impedendo l’invio e come risolverlo. Per una persona con disabilità può essere ancora più complesso comprendere anche solo la struttura del form o la corrispondenza tra un errore e il campo a cui si riferisce.

Per questo motivo gli ARIA labels svolgono un ruolo fondamentale nel migliorare l’accessibilità dei campi dei form, fornendo un modo per aggiungere informazioni utili a comprenderne la struttura.

In questo contesto è essenziale riconoscere le differenze nel modo di percepire e comprendere i contenuti tra utenti vedenti e utenti con disabilità visive.

Consideriamo l’esempio seguente:

Il feedback di errore su un campo di form

Nell’immagine sopra, un utente vedente può facilmente associare l’etichetta (”Nickname”) al campo corrispondente e individuare il messaggio di errore (in rosso) grazie alla loro vicinanza visiva e alla disposizione spaziale.

Per un utente con disabilità visive, invece, non è possibile fare affidamento su indizi visivi o sulla posizione degli elementi. È qui che gli ARIA labels assumono un ruolo fondamentale nel colmare il divario di accessibilità. Implementando gli ARIA labels, lo screen reader può comunicare esplicitamente all’utente l’etichetta “Nickname”, assicurandosi che ne comprenda lo scopo. Inoltre, se il messaggio di errore viene associato al campo tramite un ARIA label, lo screen reader potrà annunciarlo ad alta voce, fornendo un feedback fondamentale sul requisito di validazione specifico.

<label id="nickname-label" for="nickname">Nickname</label>
<input type="text" id="nickname" aria-labelledby="nickname-label" aria-describedby="nickname-error" aria-invalid="true">
<p id="nickname-error" role="alert" aria-live="assertive">Please insert at least 3 characters.</p>

Come si vede nel codice qui sopra, aggiungiamo diversi suggerimenti semantici agli elementi del campo, che verranno utilizzati dalle tecnologie assistive per fornire informazioni più dettagliate all’utente:

• L’elemento <label> associa il testo dell’etichetta “Nickname” al campo di input corrispondente tramite l’attributo for e l’id dell’input. La stessa informazione viene trasmessa anche attraverso l’attributo aria-labelledby impostato sull’elemento <input>, che punta all’id del label;

Impostare entrambi gli attributi può sembrare ridondante, poiché l’uso dell’attributo for è generalmente sufficiente per la maggior parte delle tecnologie assistive, ma aria-labelledby diventa utile quando si vuole associare l’input a più etichette o quando, per qualsiasi motivo, il codice non utilizza un elemento <label>.

• L’attributo aria-describedby viene aggiunto al campo di input e fa riferimento all’id del paragrafo contenente il messaggio di errore. Questa associazione permette alle tecnologie assistive di collegare il messaggio di errore al campo di testo corrispondente.
• L’attributo aria-invalid sull’elemento <input> indica che il campo contiene un errore;
• L’attributo role="alert" sull’elemento <p> evidenzia l’importanza del paragrafo come messaggio di errore;
• L’attributo aria-live="assertive" sull’elemento <p> fa in modo che il messaggio venga annunciato immediatamente dalle tecnologie assistive non appena compare nella pagina.

Vediamo come abbiamo applicato queste tecniche in uno dei nostri case study.

Assistere Gruppo San Donato nel miglioramento dell’accessibilità

Il Gruppo San Donato è uno dei più grandi gruppi sanitari in Italia e, per il contesto in cui opera, deve prestare particolare attenzione a garantire che le proprie applicazioni siano accessibili. Per questo motivo ha chiesto a Buildo di supportarlo nel percorso di miglioramento dell’usabilità e dell’accessibilità del proprio software.

Il nostro lavoro è iniziato con una valutazione della loro web application, testandola in base ai principi e ai criteri delle WCAG 2.1. Seguendo un processo ben definito e replicabile, abbiamo analizzato diversi aspetti della piattaforma, dal design e copywriting fino al codice sottostante, assicurandoci che fosse conforme agli standard di accessibilità richiesti dall’European Accessibility Act.

In particolare ci siamo concentrati sul fornire indicazioni per migliorare l’accessibilità dei form web, utilizzati ad esempio per raccogliere dati dei pazienti. Il GSD aveva già fatto un ottimo lavoro nel fornire messaggi di errore chiari e significativi, posizionandoli vicino ai campi di riferimento ed evidenziando sia il campo errato sia il messaggio con un colore dedicato all’errore:

Un campo con errore nell’applicazione GSD

Tuttavia, oltre a questi indizi visivi, le tecnologie assistive non avevano modo di identificare i campi errati e i relativi messaggi di errore basandosi solo sul codice HTML, poiché in caso di errore l’unica informazione aggiunta era costituita dalle classi CSS utilizzate per applicare lo stile:

<div class="gsd_field_wrapper">
  <label class="gsd_field_label" for="email">Indirizzo email</label>
  <input name="email" type="text" class="gsd_field_input gsd_field_error" value="campa.applause+perme1l">
  <span class="gsd_validation_message gsd_error">Indirizzo email non valido</span>
</div>

Per questo, nel nostro report abbiamo raccomandato di utilizzare attributi ARIA come aria-invalid, aria-describedby e aria-live="assertive", come descritto in precedenza. Includere questi accorgimenti direttamente nel design system del GSD è un modo semplice per migliorare l’accessibilità di tutti i campi dei form in una volta sola, con un impegno minimo e grandi benefici per gli utenti.

Per saperne di più su come abbiamo aiutato il GSD a migliorare l’accessibilità delle proprie app, dai un’occhiata al case study sul nostro sito.

Conclusioni

Abbiamo visto come, integrando gli ARIA labels nelle applicazioni web, sia possibile migliorare in modo significativo l’esperienza degli utenti con disabilità. Gli ARIA labels sono strumenti potenti che permettono di fornire testi alternativi, descrivere elementi interattivi e trasmettere informazioni importanti agli utenti delle tecnologie assistive.

L’inclusione degli ARIA labels rappresenta però solo una parte del più ampio mosaico dell’accessibilità. Per creare esperienze web realmente inclusive è fondamentale seguire le linee guida di accessibilità, eseguire test approfonditi e coinvolgere le persone con disabilità nel processo di design e sviluppo.

In vista dell’entrata in vigore dell’European Accessibility Act (EAA), che promuove l’accesso paritario a beni e servizi per le persone con disabilità, è essenziale iniziare a pensare all’accessibilità fin da subito, così da garantire la conformità normativa e rispondere in modo proattivo alle esigenze delle persone con disabilità.

Dando priorità all’accessibilità e adottando tecnologie come gli ARIA labels, possiamo costruire un web accessibile a tutti, capace di abbattere le barriere e consentire a persone con abilità diverse di partecipare pienamente al mondo digitale. È anche ciò in cui crediamo noi di Buildo: considerare l’accessibilità un valore fondamentale, integrandola nel nostro lavoro per creare soluzioni digitali fruibili da chiunque e contribuire a un mondo più inclusivo ed equo.