Del símptoma a la causa: inspeccionar l'arbre d'accessibilitat

Quan un lector de pantalla anuncia una cosa estranya, o no anuncia res, l'auditor ha de respondre una pregunta abans d'escriure la troballa: el problema és al codi, al navegador, al lector o a la configuració del seu propi equip? I l'equip de desenvolupament necessita alguna cosa més que «NVDA diu “botó”»: necessita la causa. A la primera lliçó vas veure que el lector llegeix l'arbre d'accessibilitat, i al protocol de proves el farem servir com a evidència; en aquesta aprendràs a inspeccionar-lo per passar del símptoma a la causa.

Les capes: del codi a la veu

Entre l'HTML i el que sent la persona usuària hi ha diverses capes. El navegador combina DOM, CSS i ARIA per calcular l'arbre d'accessibilitat (rols, noms, estats, relacions). Després l'exposa a través de l'API d'accessibilitat del sistema operatiu: UI Automation i IAccessible2 a Windows, l'API d'accessibilitat de macOS, UIAccessibility a iOS o la d'Android. Finalment, el lector interpreta aquesta informació i la verbalitza segons la seva configuració. Una fallada pot entrar en qualsevol de les capes:

Eines d'inspecció

Chrome i Edge

A les eines per a desenvolupadors (F12), panell Elements, la pestanya Accessibilitat mostra per al node seleccionat la seva posició a l'arbre d'accessibilitat, els atributs ARIA i les propietats calculades: rol, nom i la font de la qual prové (aria-labelledby, aria-label, contingut, title…), i estats com ara si pot rebre el focus o si està expandit. Les versions recents permeten a més veure l'arbre d'accessibilitat complet de la pàgina en lloc del DOM.

Firefox

L'Inspector d'accessibilitat (pestanya Accessibilitat de les eines per a desenvolupadors) mostra l'arbre complet i les propietats de cada node, i hi afegeix utilitats molt pràctiques per auditar: comprovació de problemes de contrast, teclat i etiquetes de text, visualització de l'ordre de tabulació sobre la mateixa pàgina i simulació de deficiències en la visió del color.

Safari

Amb les funcions per a desenvolupadors activades als ajustos avançats de Safari, l'Inspector web mostra a la barra lateral del panell Elements una secció d'accessibilitat amb el rol, l'etiqueta i els estats que exposa WebKit. És útil perquè VoiceOver amb Safari sovint es comporta de manera diferent de Chrome.

Eines del sistema i del lector

Accessibility Insights for Windows (Microsoft, gratuïta) i l'Inspector d'accessibilitat de macOS (inclòs amb Xcode) mostren el que realment arriba a l'API del sistema. A NVDA, NVDA+F1 bolca al visor de registre la informació de desenvolupador de l'objecte actual: rol, nom, estats i atributs tal com els rep el lector.

Com es calcula el nom accessible

Bona part de les troballes del 4.1.2 Nom, funció i valor i del 2.5.3 Etiqueta en el nom s'expliquen amb l'algoritme de càlcul del nom accessible (Accessible Name and Description Computation 1.2 del W3C). Simplificat, l'ordre de prioritat és:

1. aria-labelledby: el text dels elements referenciats; guanya a tota la resta.
2. aria-label.
3. El mecanisme natiu d'HTML: <label> associat, alt, <caption>, <legend>, el valor d'un botó de tipus input.
4. El contingut de l'element, només en rols que admeten nom a partir del contingut: botons, enllaços, encapçalaments, cel·les, pestanyes, opcions; no camps de text ni llistes.
5. title i, en camps, placeholder, com a últim recurs (no s'han de fer servir com a etiqueta).

El panell de Chrome enumera les fonts possibles i indica quina s'ha fet servir i quines han quedat descartades. Amb això pots explicar, per exemple, per què un botó que mostra «Cercar» s'anuncia com a «Enviar la consulta»: té un aria-label que substitueix el contingut visible.

<!-- Nom buit: la icona és un fons CSS i no hi ha text -->
<a href="/carrito" class="icono-carrito"></a>

<!-- Nom correcte: text accessible i SVG decoratiu ocult -->
<a href="/carrito">
  <svg aria-hidden="true" focusable="false">…</svg>
  <span class="sr-only">Carretó</span>
</a>

Aïllar la fallada pas a pas

1. Reprodueix i anota el símptoma literal. Copia la sortida del visor de veu i apunta la combinació exacta i les seves versions.
2. Inspecciona el node. Rol, nom, estat i relacions són els que exigeix el patró? Si l'arbre ja està malament, la causa és al codi o en com l'interpreta el navegador: revisa l'HTML, el CSS i l'script que modifica el component.
3. Canvia una sola variable cada vegada. Mateix lector amb un altre navegador; mateix navegador amb un altre lector. Si falla en totes, gairebé segur que és el codi. Si falla només en una, sospita d'un problema de suport o d'un defecte del navegador o del lector.
4. Redueix-ho a un cas mínim. Copia el component a un fitxer HTML local amb el que és imprescindible. Si el cas mínim funciona, la causa és en alguna cosa que has tret: un full d'estils, un script, el framework.
5. Atribueix i documenta. Troballa del lloc amb la seva causa tècnica i la seva recomanació, o bé observació de suport, amb la combinació afectada. La lliçó següent explica com prendre aquesta decisió.

Causes que només revela l'arbre

• aria-hidden="true" heretat. En obrir un modal, un script oculta el contingut principal amb aria-hidden i s'oblida de treure'l en tancar-lo. La pàgina es veu perfectament, però per al lector està buida. A l'inspector, tots els nodes apareixen ignorats.
• Estats congelats. El panell s'obre visualment, però aria-expanded continua en false perquè l'script canvia una classe CSS i no l'atribut.
• CSS que altera la semàntica. display: contents ha eliminat en diversos navegadors el rol de botons o taules, i WebKit deixa d'exposar com a llista algunes llistes a les quals es treuen les vinyetes amb list-style: none. L'HTML és correcte, però l'arbre no.
• Referències trencades. aria-labelledby o aria-describedby que apunten a un id inexistent o duplicat: el nom o la descripció queden buits o equivocats.

Resum

• Una fallada pot néixer al codi, al navegador, al lector o a la configuració de l'auditor; l'arbre d'accessibilitat permet saber en quina capa és.
• Chrome i Edge (pestanya Accessibilitat), Firefox (Inspector d'accessibilitat), Safari (Inspector web), Accessibility Insights, l'Inspector de macOS i NVDA+F1 són les eines d'inspecció.
• El nom accessible segueix un ordre: aria-labelledby, aria-label, mecanisme natiu, contingut i, finalment, title o placeholder.
• Per aïllar: reproduir, inspeccionar, canviar una variable cada vegada, reduir a cas mínim, atribuir i documentar.
• L'inspector no substitueix la prova amb lector: la complementa i aporta la causa tècnica a l'informe.