Semàntica: per què importa; arbre d'accessibilitat i nom accessible

Quan escrivim HTML no només dibuixem caixes en una pantalla: descrivim què és cada cosa. Un lector de pantalla, un navegador per veu o un commutador no «veuen» la pàgina; llegeixen una estructura de dades que el navegador construeix a partir del marcatge. Aquesta estructura és l'arbre d'accessibilitat, i la qualitat de l'HTML determina directament la qualitat del que rep la persona. En aquesta lliçó veurem per què la semàntica és la base de tota la resta i com es calcula la dada més important de cada element: el seu nom accessible.

Què vol dir «semàntic»

Un element HTML és semàntic quan la seva pròpia etiqueta comunica la seva funció: <button> és un botó, <nav> és una navegació, <h2> és un encapçalament de segon nivell, <table> és una taula de dades. En canvi, <div> i <span> no signifiquen res: són contenidors genèrics que només serveixen per agrupar o aplicar estils.

El navegador «regala» comportament als elements semàntics. Un <button> natiu rep el focus amb Tab, s'activa amb Retorn i Espai, exposa el rol «botó» a les tecnologies de suport, admet l'atribut disabled i participa en l'enviament de formularis. Si el substituïm per un <div> amb un gestor de clic, ho perdem tot i l'haurem de reconstruir a mà amb tabindex, esdeveniments de teclat i atributs ARIA. Gairebé mai no es fa complet.

<div class="btn" onclick="guardar()">Desa</div>

<button type="button" onclick="guardar()">Desa</button>

L'arbre d'accessibilitat

El navegador construeix el DOM a partir de l'HTML i, en paral·lel, un arbre d'accessibilitat: una versió simplificada en què cada node rellevant té cinc tipus d'informació:

• Rol: què és (botó, enllaç, encapçalament, casella de selecció, regió…).
• Nom: com es diu («Desa», «Cerca al lloc web», «Accepto les condicions»).
• Descripció: informació complementària opcional (per exemple, el text d'ajuda d'un camp).
• Estat i propietats: marcat, desplegat, deshabilitat, obligatori, nivell d'encapçalament, posició en una llista, etc.
• Valor: per als controls que en tenen (un control lliscant al 40 %, un camp amb text).

Els elements purament decoratius o sense contingut (un <div> buit que només aplica un fons) ni tan sols hi apareixen. Les tecnologies de suport consulten aquest arbre a través de les API d'accessibilitat del sistema operatiu (UI Automation i IAccessible2 a Windows, NSAccessibility a macOS, AT-SPI a Linux). Per això el criteri 4.1.2 Nom, funció, valor exigeix que el nom i el rol de tot component d'interfície es puguin determinar per programa, que els estats, les propietats i els valors que la persona pot canviar es puguin establir per programa i que els seus canvis es notifiquin a les tecnologies de suport.

El pots inspeccionar tu mateix. A Chrome i Edge, obre les eines de desenvolupament, selecciona un element i obre la pestanya Accessibility (o activa la vista completa de l'arbre des d'aquesta mateixa pestanya). A Firefox, l'Inspector té una pestanya Accessibilitat que, a més, marca problemes de contrast i de nom. Veure l'arbre és la manera més ràpida de saber què rebrà realment una persona usuària de lector de pantalla.

Com es calcula el nom accessible

El nom accessible és el que el lector de pantalla anuncia per identificar l'element, el que el control per veu necessita perquè l'ordre «prem Desa» funcioni, i el que el criteri 2.5.3 Etiqueta en el nom compara amb el text visible. El W3C defineix l'algorisme a l'especificació Accessible Name and Description Computation. De manera simplificada, el navegador recorre aquestes fonts per ordre i es queda amb la primera que doni resultat:

1. aria-labelledby: agafa el text dels elements referenciats pel seu id.
2. aria-label: fa servir el text de l'atribut.
3. La font nativa de l'element: el <label> associat en un camp, l'alt en una imatge, la <caption> en una taula, la <legend> en un <fieldset> o, en botons i enllaços, el seu propi contingut de text (inclòs l'alt de les imatges que continguin).
4. title: només com a últim recurs; a més, no és visible a les pantalles tàctils.

Si no hi ha res d'això, el nom queda buit i el lector anuncia una cosa com «botó» o «enllaç» i prou. És una de les errades més freqüents en icones i enllaços d'imatge.

<button class="cerrar"><svg aria-hidden="true">…</svg></button>

<button class="cerrar" aria-label="Tanca"><svg aria-hidden="true">…</svg></button>

Regles pràctiques sobre el nom

• Prefereix el text visible. Si el nom ve d'un text que ja és a la pantalla, fes-lo servir amb <label> o aria-labelledby; així el nom i l'etiqueta visible no es desincronitzen mai.
• Si fas servir aria-label en un control amb text visible, el text visible ha d'estar contingut a l'aria-label («Desa l'esborrany» pot ser el nom del botó visible «Desa», però «Envia» no).
• El title no substitueix una etiqueta: no es mostra amb el teclat ni al mòbil.
• Evita noms repetits sense context: cinc enllaços «Llegeix-ne més» tenen el mateix nom i no es distingeixen a la llista d'enllaços del lector de pantalla.

Com comprovar-ho

Per a cada control interactiu, verifica al tauler d'accessibilitat del navegador que té un rol correcte, un nom no buit i que aquest nom descriu l'acció. Amb un lector de pantalla (NVDA és gratuït), obre la llista d'enllaços o de controls de formulari (Insert+F7 a NVDA) i llegeix els noms fora de context: si la llista no s'entén, els noms no són bons. axe o WAVE detecten el nom buit, però no el nom incorrecte o enganyós; això només ho detecta una revisió humana.

Resum

• Els elements semàntics natius aporten rol, nom, focus, teclat i estat sense esforç; <div> i <span> no aporten res.
• Les tecnologies de suport llegeixen l'arbre d'accessibilitat, no la pantalla; el que no és en aquest arbre no existeix per a elles.
• El nom accessible es calcula en aquest ordre: aria-labelledby, aria-label, font nativa (label, alt, contingut), title.
• Tot control interactiu necessita un nom no buit i descriptiu (4.1.2) que inclogui el text visible (2.5.3).
• Inspecciona l'arbre a les eines de desenvolupament i escolta els noms fora de context amb un lector de pantalla.