Cos’è ARIA?
ARIA (Accessible Rich Internet Applications) è un insieme di specifiche sviluppate dal W3C per migliorare l’accessibilità delle applicazioni web. Gli attributi ARIA permettono di fornire informazioni aggiuntive agli screen reader e agli altri ausili tecnologici, in modo da rendere comprensibili anche componenti complessi come menu dinamici, modali, tab panel e controlli custom.
A differenza degli elementi HTML semantici, che hanno significato intrinseco, ARIA non crea nuove funzionalità ma “arricchisce” le interfacce già esistenti. È una soluzione utile soprattutto quando la semantica standard non è sufficiente, come nei componenti interattivi personalizzati.
Importanza dell’accessibilità web
L’accessibilità è una parte centrale nella realizzazione di interfacce moderne. Non si tratta solo di conformità alle normative, ma di un vero e proprio approccio inclusivo che permette a chiunque, indipendentemente dalle abilità fisiche o cognitive, di utilizzare un sito web o un’applicazione.
HTML e CSS hanno fatto grandi progressi nell’offrire strumenti nativi. Per esempio, l’uso corretto di tag come <dialog> o <details> riduce la necessità di ARIA. Tuttavia, ARIA resta indispensabile nei casi in cui sviluppiamo controlli altamente personalizzati.
Attributi ARIA di base
Gli attributi ARIA si dividono principalmente in tre categorie:
- Ruoli (roles)
- Descrivono la funzione di un elemento, ad esempio
role="button"
. - Stati (states)
- Indicano condizioni dinamiche, come
aria-expanded="true"
. - Proprietà (properties)
- Forniscono informazioni aggiuntive, ad esempio
aria-label
.
Esempio di bottone custom con ARIA
<div role="button" aria-pressed="false" tabindex="0" class="btn-custom">
Invia
</div>
Qui usiamo role="button"
per comunicare che l’elemento è un pulsante e tabindex="0"
per renderlo accessibile via tastiera.
Esempio di menu espandibile
<button aria-controls="menu-main" aria-expanded="false" id="toggle-menu">
Menu
</button>
<ul id="menu-main" role="menu" hidden>
<li role="menuitem">Home</li>
<li role="menuitem">Servizi</li>
<li role="menuitem">Contatti</li>
</ul>
const btn = document.getElementById('toggle-menu');
const menu = document.getElementById('menu-main');
btn.addEventListener('click', () => {
const expanded = btn.getAttribute('aria-expanded') === 'true';
btn.setAttribute('aria-expanded', String(!expanded));
menu.hidden = expanded;
});
Notare come l’attributo aria-expanded
comunichi lo stato corrente agli screen reader.
Applicazione in progetti reali
In un progetto reale, ARIA deve essere usata come “aggiunta” e non sostituzione degli elementi nativi. Per esempio, un <button>
con etichetta corretta è sempre preferibile a un <div role="button">
. Tuttavia, quando costruiamo componenti come slider personalizzati, ARIA diventa fondamentale.
Esempio: slider accessibile personalizzato
<div role="slider" aria-valuemin="0" aria-valuemax="100" aria-valuenow="50"
tabindex="0" class="slider">
</div>
const slider = document.querySelector('.slider');
let value = 50;
slider.addEventListener('keydown', (e) => {
if (e.key === 'ArrowRight' && value < 100) value++;
if (e.key === 'ArrowLeft' && value > 0) value--;
slider.setAttribute('aria-valuenow', value);
});
Grazie a questi attributi, uno screen reader sarà in grado di annunciare i valori aggiornati dello slider.
Strumenti per testare l’accessibilità
Esistono diversi strumenti che aiutano a validare l’uso corretto degli attributi ARIA:
- Screen reader come NVDA, VoiceOver o JAWS.
- Estensioni browser per audit di accessibilità.
- Validatori che verificano la struttura del DOM e l’uso appropriato degli attributi.
È importante testare non solo con strumenti automatici, ma anche con interazioni reali via tastiera. Quando si progettano form, il controllo semantico rimane fondamentale: si veda ad esempio le best practice per form di contatto accessibili.
Best practices per sviluppatori
- Usare prima gli elementi semantici disponibili, e ricorre ad ARIA solo dove necessario. Ad esempio: i nuovi input HTML5 offrono già funzioni di accessibilità.
- Mantenere la sincronizzazione tra gli stati ARIA e i reali stati visivi del componente.
- Garantire sempre la navigazione via tastiera (tab, invio, frecce).
- Arricchire con attributi HTML meno conosciuti ma utili, come
autocomplete
olist
. - Verificare che i componenti siano leggibili e comprensibili anche senza CSS o JavaScript.
Un approccio combinato, che utilizza HTML semantico, CSS e ARIA, è sempre la migliore strategia. Per esempio, arricchire i contenuti multimediali con descrizioni e strutture semantiche (anche per i video) aumenta l’accessibilità complessiva.
Conclusioni e risorse utili
ARIA è uno strumento potente, ma richiede disciplina. La regola d’oro è: “Non usare ARIA quando puoi ottenere lo stesso risultato con HTML semantico”. Solo quando gli strumenti nativi non sono sufficienti, allora ARIA diventa necessaria. Il suo utilizzo mirato garantisce che le interfacce utente personalizzate rimangano comprensibili, navigabili e utilizzabili da tutti.
Lavorare con ARIA significa anche interiorizzare un approccio inclusivo allo sviluppo: non costruire semplicemente interfacce belle o performanti, ma applicazioni realmente fruibili.