Accessibilità ≠ Overlay: ARIA non corregge magicamente un HTML costruito male
Dopo l’HTML semantico arriva un equivoco frequente: gli attributi ARIA non rendono automaticamente accessibile un componente costruito male. ARIA comunica semantica alle tecnologie assistive, ma non sostituisce comportamento, tastiera, focus o una buona base HTML.
ARIA è importante, ma non è un livello di riparazione
WAI-ARIA comunica ruoli, stati e proprietà alle tecnologie assistive, soprattutto per contenuti dinamici e controlli avanzati. Completa HTML; non è una patch universale.
Prima regola: usa HTML nativo quando puoi
W3C raccomanda di massimizzare l’uso di HTML semantico nativo. Se un elemento HTML offre già semantica e comportamento, è in genere più robusto di un elemento generico con ARIA.
Un ruolo è una promessa
W3C riassume un principio essenziale: «un ruolo è una promessa». <div role="button"> promette il comportamento di un pulsante, ma il ruolo non aggiunge da solo l’interazione da tastiera.
ARIA comunica semantica, non crea comportamento
ARIA può comunicare che qualcosa è un pulsante, è espanso o selezionato, ma non implementa automaticamente Tab, Invio, Spazio, frecce, focus o logica JavaScript. Semantica e comportamento devono coincidere.
Nome, ruolo, stato e valore
WCAG 4.1.2 richiede nome e ruolo determinabili programmaticamente e stati, proprietà e valori pertinenti disponibili. I controlli HTML standard forniscono già molte di queste informazioni se usati correttamente.
ARIA errato può peggiorare l’esperienza
ARIA errato non è neutro. W3C avverte: «No ARIA is better than Bad ARIA». Una semantica errata può rappresentare male l’interfaccia per chi dipende da un’esperienza non visiva.
ARIA richiede test reali
Gli esempi ARIA Authoring Practices segnalano differenze di supporto e raccomandano test prima della produzione.
Che cosa c’entra con gli overlay?
Vale anche per gli overlay. Un livello può modificare attributi dopo il caricamento, ma l’accessibilità dipende dal funzionamento congiunto di semantica, interazione, tastiera, focus e stati. Aggiungere ARIA dall’esterno non ripara automaticamente un’interfaccia difettosa.
E Blind Reader?
Blind Reader appartiene all’assistenza all’utente. Può aiutare la persona, ma non va presentato come correzione automatica di ARIA o HTML né come prova di conformità WCAG. Il sito resta responsabile.
L’idea da ricordare
ARIA è potente quando serve ed è implementato bene. Prima HTML nativo e semantico quando possibile; poi ARIA quando necessario; sempre comportamento corretto, tastiera, focus e test.