Com veu la pàgina un motor de regles: DOM, arbre d'accessibilitat i moment de l'anàlisi

Com vam veure a la lliçó anterior, una eina automàtica només pot comprovar el que és verificable mecànicament. Per interpretar-ne els resultats cal saber, a més, què veu exactament: no el codi de l'equip de desenvolupament ni la pantalla de la persona usuària, sinó una fotografia del DOM i dels estils calculats en un instant concret. Aquesta lliçó obre la caixa: què analitza el motor, com està construïda una regla, com calcula el nom accessible i el contrast, i què se li escapa. Amb això entendràs l'origen de molts falsos positius i negatius.

Del codi font a l'arbre d'accessibilitat

Entre el que envia el servidor i el que rep un lector de pantalla hi ha quatre capes, i cada eina treballa sobre una de diferent:

1. Codi font: l'HTML que retorna el servidor (el que veus amb Ctrl + U). En una aplicació d'una sola pàgina pot ser poc més que un <div id="app"> buit.
2. DOM: l'arbre de nodes que construeix el navegador després d'analitzar l'HTML i executar el JavaScript. És el que mostra el panell Elements i canvia amb cada interacció.
3. Estils calculats: el resultat final de la cascada CSS per a cada element (color, mida, visibilitat, posició).
4. Arbre d'accessibilitat: el que el navegador exposa a les tecnologies de suport mitjançant les API d'accessibilitat del sistema operatiu (UI Automation i IAccessible2 a Windows, NSAccessibility a macOS, AT-SPI a Linux): rol, nom, estat i relacions de cada objecte.

Els motors de regles com axe-core o el d'IBM Equal Access s'executen com a JavaScript dins de la pàgina. Llegeixen el DOM i els estils calculats i, amb ells, reconstrueixen la seva pròpia aproximació a l'arbre d'accessibilitat: no consulten el que genera el navegador. Per això el nom accessible que calcula axe pot no coincidir, en casos límit, amb el que mostra el panell Accessibility de Chrome o amb el que anuncia NVDA. El validador Nu HTML, en canvi, analitza el codi font quan li dones un URL: no executa JavaScript i no veu el DOM final.

<body>
  <div id="app"></div>
  <script src="/assets/main.js"></script>
</body>

Anatomia d'una regla

Totes les regles automàtiques segueixen el mateix esquema, tant a axe-core com en el format ACT Rules del W3C que vam veure a la primera lliçó:

• Aplicabilitat: a quins elements s'aplica la regla. Per exemple, image-alt s'aplica als elements img que no estan ocults. Si no n'hi ha cap, el resultat és «inaplicable».
• Comprovacions: a axe s'agrupen en tres tipus: any (n'hi ha prou que en passi una: l'img té alt, o aria-label, o aria-labelledby vàlid, o rol de presentació), all (han de passar totes) i none (no se n'ha de donar cap, com un atribut ARIA prohibit).
• Resultat per element: passa, falla o, si alguna comprovació no pot decidir, «necessita revisió» (incomplete).

El que és important és el que no forma part de cap comprovació: el significat. La regla button-name passa si el botó té text intern, aria-label, aria-labelledby que apunti a text o title. Un botó anomenat «Botó1» o «Click» passa exactament igual que un d'anomenat «Demanar cita».

Com calcula el nom accessible

El nom accessible es calcula segons l'especificació del W3C Accessible Name and Description Computation (accname 1.2) i les regles de cada llenguatge (HTML-AAM). Simplificant, l'ordre de prioritat és:

1. aria-labelledby (encara que el text referenciat estigui ocult).
2. aria-label.
3. El mecanisme natiu del llenguatge: label associat, alt, caption, legend, value d'un botó de tipus input.
4. El contingut del mateix element, quan el rol ho permet (botons, enllaços, encapçalaments, cel·les).
5. title i, com a últim recurs en els camps, placeholder.

La conseqüència pràctica és que el que va primer substitueix el que va després. Un aria-label oculta el text visible del botó, i l'eina només comprova que el nom existeix:

<!-- Passa button-name, però el nom no conté el text visible -->
<button type="submit" aria-label="Enviar el formulari">Cercar</button>

<!-- Correcte: el nom surt del text visible -->
<button type="submit">Cercar</button>

Qui fa servir control per veu dirà «prémer Cercar» i no passarà res, perquè el nom és «Enviar el formulari»: incompleix el 2.5.3 Etiqueta en el nom. axe té una regla per a aquest cas (label-content-name-mismatch), però és experimental i ve desactivada per defecte, així que a la pràctica és un fals negatiu.

Com calcula el contrast

Per a la regla de contrast, el motor obté el color calculat del text (inclosa la seva opacitat) i busca què hi ha al darrere: recorre els elements apilats en aquell punt i combina les capes semitransparents fins a arribar a un fons opac. Després calcula la luminància relativa de tots dos colors amb la fórmula de les WCAG 2.x i decideix el llindar segons la mida: 4,5:1 per a text normal i 3:1 per a text gran, que les WCAG defineixen com a 18 punts o 14 punts en negreta (uns 24 px i 18,66 px CSS).

El càlcul funciona bé amb colors plans. Quan darrere del text hi ha una imatge, un degradat, un pseudoelement, una ombra de text o un element superposat, el motor no pot assegurar el color de fons i el deixa com a «necessita revisió». També mesura només l'estat present en el moment de l'anàlisi: si vols mesurar el focus o el pas del punter, has de forçar aquest estat (a Chrome, panell Estils, botó :hov, «Força l'estat de l'element») i tornar a analitzar. En els casos límit de mida, com un text de 18 px en negreta, confirma a mà la mida calculada abans d'acceptar el llindar que ha aplicat l'eina.

Les zones cegues: el que el motor no arriba a veure

Tot el que no és al DOM, o en l'estat adequat, quan prems «Analitzar», no existeix per a l'eina.

Resum

• Els motors de regles analitzen el DOM i els estils calculats en un instant i reconstrueixen la seva pròpia versió de l'arbre d'accessibilitat; el validador Nu analitza el codi servit.
• Cada regla té una aplicabilitat i unes comprovacions (any, all, none); cap no avalua el significat.
• El nom accessible segueix un ordre de prioritat (aria-labelledby, aria-label, mecanisme natiu, contingut, title): el que va primer substitueix el següent i pot provocar fallades del 2.5.3 que l'eina no veu.
• El contrast es calcula bé sobre colors plans; imatges, degradats, superposicions i estats exigeixen mesura manual.
• Estats d'interacció, càrrega diferida, iframes, Shadow DOM tancat, canvas, disseny adaptable i comparacions entre pàgines són zones cegues que cal cobrir a mà.