Accessibilitat ≠ Overlay: ARIA no arregla màgicament un HTML mal construït
Després de l’HTML semàntic arriba una confusió habitual: afegir atributs ARIA no converteix automàticament un component mal construït en accessible. ARIA comunica semàntica a les tecnologies d’assistència, però no substitueix comportament, teclat, focus ni una bona base HTML.
ARIA és important, però no és una capa de reparació
WAI-ARIA comunica rols, estats i propietats a les tecnologies d’assistència, sobretot en contingut dinàmic i controls avançats. Complementa HTML; no és un pedaç universal.
Primera regla: utilitza HTML natiu quan puguis
W3C recomana maximitzar l’HTML semàntic natiu. Si un element HTML ja aporta semàntica i comportament, sol ser més robust que reconstruir-lo amb un element genèric i ARIA.
Un role és una promesa
W3C resumeix un principi essencial: «un role és una promesa». <div role="button"> promet comportament de botó, però el role no afegeix per si sol la interacció de teclat d’un botó natiu.
ARIA comunica semàntica; no crea comportament
ARIA pot comunicar que un element és un botó, està expandit o seleccionat. No implementa automàticament Tab, Enter, Espai, fletxes, gestió del focus o lògica JavaScript. Semàntica i comportament han de coincidir.
Nom, funció, estat i valor
WCAG 4.1.2 exigeix noms i funcions determinables programàticament i estats, propietats i valors rellevants disponibles. Els controls HTML estàndard ja aporten molta d’aquesta informació quan s’utilitzen correctament.
ARIA incorrecte pot empitjorar l’experiència
ARIA incorrecte no és neutre. W3C adverteix que «No ARIA is better than Bad ARIA». Una semàntica errònia pot representar malament la interfície per a qui depèn d’una experiència no visual.
ARIA necessita proves reals
Els exemples d’ARIA Authoring Practices adverteixen de diferències de suport entre navegadors i tecnologies d’assistència i recomanen proves abans de producció.
Què té a veure això amb els overlays?
També s’aplica als overlays. Una capa pot modificar atributs després de carregar, però l’accessibilitat depèn que semàntica, interacció, teclat, focus i estats funcionin junts. Afegir ARIA des de fora no repara automàticament una interfície defectuosa.
I Blind Reader?
Blind Reader pertany a l’assistència a l’usuari. Pot ajudar la persona, però no s’ha de presentar com una correcció automàtica d’ARIA o HTML ni com una prova de conformitat WCAG. El web continua sent responsable.
La idea que hem de recordar
ARIA és potent quan cal i s’implementa bé. Primer HTML natiu i semàntic quan sigui possible; després ARIA quan calgui; sempre comportament correcte, teclat, focus i proves amb tecnologies d’assistència.