Accessibilità HTML5: ARIA basics
ARIA (Accessible Rich Internet Applications) è un set di attributi HTML che migliora l'accessibilità per utenti con disabilità che usano tecnologie assistive come screen reader. Mentre HTML5 semantico copre molti casi, ARIA aggiunge informazioni cruciali per componenti dinamici e interattivi. Vediamo i fondamentali per scrivere markup veramente accessibile a tutti, partendo dai pattern più comuni.
La prima regola di ARIA
La prima regola di ARIA è: non usare ARIA se non necessario. Se un'elemento HTML semantico copre il caso d'uso (button, nav, main, article), usalo invece di applicare role ARIA. ARIA serve quando i tag standard non bastano, ad esempio in widget custom complessi, tab panel personalizzate, comboboxes con autocomplete, alberi di selezione. Markup semantico è sempre la base, ARIA è l'aggiunta strategica.
Attributi più usati
role definisce il tipo di componente (button, dialog, navigation, alert). aria-label fornisce un'etichetta accessibile quando manca testo visibile. aria-labelledby riferisce un'id che contiene l'etichetta. aria-describedby riferisce descrizioni estese. aria-hidden="true" nasconde dall'albero accessibility (utile per icone decorative). aria-live regola annunci dinamici per screen reader. aria-expanded/aria-selected gestiscono stati interattivi.
Landmark regions
I landmark sono macro-aree della pagina che aiutano gli utenti screen reader a navigare velocemente: header (banner), nav (navigation), main (contenuto principale), aside (complementary), footer (contentinfo), search (search), form (form). HTML5 ha tag dedicati che hanno role landmark impliciti. La regola: usa <nav> invece di <div role="navigation">. Solo un <main> per pagina. Distingui nav multipli con aria-label ("primaria", "footer"). Screen reader presentano una lista di landmark che permette navigazione rapida tra sezioni con tastiera o gesture mobile dedicate.
Focus management
La gestione del focus è critica per accessibility: tab order logico, focus visibile (mai outline: none senza alternativa), focus trap nei modal, focus restore alla chiusura. Usa tabindex="0" per rendere focusable elementi non-interattivi, tabindex="-1" per programmatic focus senza tab order. Per skip link "Salta al contenuto" all'inizio della pagina aiuta utenti tastiera. CSS :focus-visible mostra focus ring solo per navigazione tastiera (non click). Test essenziale: prova la pagina solo con tastiera, senza mouse, navigando con Tab e Shift+Tab.
Live regions in pratica
Le live region annunciano dinamicamente i cambiamenti di contenuto a screen reader. aria-live="polite" annuncia dopo che l'utente ha finito l'azione corrente, ideale per notifiche non urgenti. aria-live="assertive" interrompe immediatamente, riservato a errori critici e allarmi. role="status" e role="alert" sono shorthand per polite e assertive. Esempio: un toast "Salvato con successo" usa polite; un'errore "Connessione persa" usa assertive. Best practice: non abusare di assertive (affatica l'utente), usa contenuto stringa semplice (HTML complesso confonde screen reader), considera anche tempo di permanenza del messaggio.
Test con screen reader
Audit automatici come Lighthouse axe identificano ~30% dei problemi di accessibility. Il resto va verificato manualmente con screen reader reali: NVDA su Windows (gratuito), VoiceOver su Mac/iOS (built-in, attivabile con Cmd+F5), TalkBack su Android, JAWS in ambito enterprise. Test routine: naviga la pagina senza vedere lo schermo, usando solo tastiera + voce. Identifica messaggi confusi, focus indicators mancanti, contenuto inaccessibile. Imparare lo screen reader richiede pratica ma è essenziale per sviluppare UI veramente accessibili. Per team grandi, audit periodici con esperti di accessibility certificati garantiscono compliance WCAG.
Risorse e learning
Risorse per imparare accessibility: W3C WAI tutorials (gratuito, autorevole), WebAIM articles e community, MDN Accessibility section, A11y Project con checklist e patterns. Libri: "Inclusive Components" di Heydon Pickering, "Accessibility for Everyone" di Laura Kalbag. Newsletter: A11y Weekly, Tatiana Mac. Per certificazione professionale: IAAP (International Association of Accessibility Professionals). Tool quotidiani: axe DevTools, Lighthouse Accessibility audit, Color Contrast Analyzer, NVDA per Windows, VoiceOver iOS/Mac. Investimento in skill di accessibility paga: 15% della popolazione ha disabilità, normative legali (European Accessibility Act 2025) richiedono conformità, e codice accessibile è migliore per tutti.
Procedura passo-passo
- Per icone solo decorative usa aria-hidden="true" sull'icona o sul wrapper.
- Per pulsanti con solo icona aggiungi aria-label="Chiudi" descrittivo.
- Per regioni di pagina usa landmark: <nav>, <main>, <aside> o role corrispondenti.
- Per modal nativi usa <dialog> con showModal; ARIA è gestito automaticamente.
- Per messaggi dinamici usa aria-live="polite" o "assertive" per urgenze.
- Per stati expand/collapse usa aria-expanded="true|false" sul trigger.
- Testa con screen reader reali: NVDA (Windows gratuito), VoiceOver (Mac), TalkBack (Android).
Errori comuni e come risolverli
- role su elementi semantici: <button role="button"> è ridondante; usa solo per overrides specifici.
- aria-label che duplica testo: se c'è testo visibile non serve aria-label; usa aria-labelledby invece.
- aria-hidden con focus: nascondere un'elemento focusable rompe la navigazione tastiera.
- Live regions su tutto: troppi annunci confondono; usa polite solo dove serve.
- Test solo con browser: prova sempre con uno screen reader reale per validare davvero.
Domande frequenti
D: Devo aggiungere role a ogni elemento?
R: No, gli elementi HTML5 semantici hanno role impliciti. Aggiungi solo quando serve override o personalizzazione.
D: ARIA risolve tutti i problemi di accessibility?
R: No, è un complemento. Markup semantico, contrasto colori, navigazione tastiera sono altrettanto importanti.
D: aria-label funziona su qualsiasi elemento?
R: Funziona su elementi interattivi e landmark. Su contenuti generici è ignorato.
D: Come testo l'accessibility?
R: Usa axe DevTools, Lighthouse, WAVE per audit automatici. Poi testa manualmente con screen reader e solo tastiera.
Hai bisogno di aiuto?
Se vuoi sviluppo web con il team di G Tech Group, scrivici tramite il modulo di contatto.