Da ex sviluppatore back-end, che si è permesso qualche piccola incursione nel mondo front-end con CSS e Javascript, mi sono sempre concentrato sull’utilizzare i ruoli previsti e la semantica adeguata per arrivare al risultato richiesto nei progetti ai quali ho lavorato. Non era ancora una questione di accessibilità (ai tempi ancora non coglievo minimamente i benefici che avrei potuto apportare a molti utenti stando più attento) ma di “attenersi alle regole”: nella mia testa un pulsante era (ed è) un pulsante, non un contenitore generico al quale ne viene affibbiato il ruolo. Dopotutto, un pulsante è un pulsante, un contenitore è un contenitore.

E ancora oggi personalmente faccio “fatica” a comprendere la logica dietro l’assegnazione di ruoli ad elementi che nativamente non sono stati creati per quella funzionalità: con HTML 5 (ora rinominato Living Standard) e CSS 3 è possibile manipolare gli elementi per ottenere risultati ottimi senza dover ricorrere per forza a workaround che potenzialmente possono portare a risultati imprevedibili, soprattutto verso le tecnologie assistive.

Implicitamente i browser, e di conseguenza esplicitamente le tecnologie assistive come gli screen reader, comunicano ruolo, valore e stato di un determinato componente (se semanticamente significativo): andare a forzarne il significato e la funzionalità è tanto semplice quanto, a volte, problematico.

HTML… E gli altri linguaggi?

Sì parla di HTML e non vengono menzionati, in questo caso, Javascript, React, PHP o altri linguaggi di sviluppo poiché l’output che viene generato è sempre HTML (soprattutto nel caso di quelli interpretati di tipo server side). Stanno cominciano a nascere anche linguaggi che non restituiscono vero e proprio HTML, come ad esempio Flutter Web, ma creano un canvas che calcola pixel per pixel la posizione degli elementi che viene aggiornato in caso di scrolling e assegna ruoli ad ogni elemento (anche il semplice testo) e tag custom non riconducibili ad HTML (che è consentito fare con HTML LS, ma ad ogni tag poi dovranno essere assegnate tutte le caratteristiche del tag standard per fare in modo che venga percepito correttamente).

Comodità oppure imprevedibilità?

La scorciatoia che permette di assegnare ruoli ad elementi che nativamente non sono stati creati per una data funzionalità, apre nuove prospettive da non prendere sottogamba.

Ad esempio, il focus da tastiera (nel caso di elementi che lo prevedano) si ottiene anche dopo questa modifica? In caso contrario si dovrà assegnare un attributo tabindex per permettere che questo lo riceva nuovamente.

Sono previsti diversi stati, impliciti, per ogni elemento che sono stati persi dopo l’assegnazione del ruolo? Se presenti, dovranno essere inseriti nuovamente (questa volta in maniera esplicita) e modificati on-the-fly in caso di modifica (ad esempio per una selezione o un pulsante).

Ma tanto ci sono i ruoli e WAI-ARIA…

La via più semplice da prendere è quella di pensare che la possibilità di assegnare ruoli agli elementi e gli attributi WAI-ARIA (Web Accessibile Initiative – Accessible Rich Internet Application) siano la panacea di tutti i mali e possano sistemare tutti i “vuoti” creati da questi elementi non default.

… ed è proprio vero?

Ma cosa sono e a cosa servono gli attributi WAI-ARIA? Questi sono una serie di elementi che possono essere aggiunti ai tag HTML in modo tale da comunicare alle tecnologie assistive il ruolo, lo stato, il nome e le proprietà tramite le Accessibility API.

In questo modo è possibile fornire un metodo coerente per far percepire le informazioni necessarie agli utenti che ne hanno bisogno. Tutto questo è nato per “integrare” le informazioni implicita del browser verso le tecnologie assistive, ad esempio comunicano lo stato espanso o contratto di un oggetto che permette questo tipo di interazione. Nel corso degli ultimi anni sono gli attributi ARIA sono stati utilizzati per modificare “a piacimento” degli elementi in maniera non “prevista”.

Non si tratta, quindi, di scrivere semplicemente role=“button”, “link” o qualsiasi altro ruolo che è possibile assegnare: a livello di accessibilità si trovano di conseguenze molto più profonde.

Utilizzare i ruoli, anche se può sembrare un metodo facilissimo per modificare l’originale, non trasforma magicamente un elemento.

Elementi Default e Custom

Andiamo ad analizzare il comportamento di un link creato tramite tag <a> ed un <div> al quale è ne è stato assegnato il ruolo.

<a href=“#”>Leggi l’articolo</a>

<div role=“link”>Leggi l’articolo</div>

La semantica del codice non sembra essere poi così diversa: andiamo ad verificarne le eventuali differenze per le tecnologie assistive.

Assegnare un ruolo ad un elemento che di default non dovrebbe possedere tali caratteristiche rischia di essere deleterio per un sistema: quindi non basta assegnare un role per “trasformare” un contenitore <div> in un link ma è necessario inserire anche gli attributi impliciti che permettono di modificarne le caratteristiche, ricostruendo effettivamente quello originale, partendo dal focus della tastiera, passando per la sottolineatura della parola o frase contenuta nel link (tramite CSS) per chiudere con l’aggiunta del codice aggiuntivo, ad esempio in Javascript, necessario per compiere l’azione corretta (ossia l’interazione).

Impiegare più tempo per ricostruire un elemento che, di default, esiste già e presenta già implicitamente tutte le caratteristiche necessarie non permette di essere efficienti ed efficaci nello sviluppo e, inoltre, apre la strada a possibili errori di accessibilità (ma non solo) lungo il cammino.

E quindi?

L’uso corretto della semantica HTML e degli attributi WAI-ARIA è fondamentale per garantire l’accessibilità delle applicazioni web. Assegnare ruoli a elementi che non sono stati progettati per una data funzione può sembrare una scorciatoia utile, ma spesso porta a una serie di problemi di usabilità e accessibilità.

Seguire le “regole” della semantica HTML non è solo una questione di conformità agli standard, ma un metodo che permette di assicurarsi che tutti gli utenti, indipendentemente dalle loro capacità o necessità, possano interagire con i contenuti web in modo efficace. Ruoli e attributi WAI-ARIA offrono strumenti potenti per migliorare l’accessibilità, ma devono essere utilizzati con attenzione.