Del codi al lector: arbre d'accessibilitat, API i modes del lector

A la lliçó anterior vam veure que ARIA actua exclusivament sobre l'arbre d'accessibilitat, que ja vas conèixer al curs N3-C1. Ara el mirem des d'ARIA: quin camí recorre un atribut des del teu codi fins a l'oïda (o els dits, amb una línia braille) de qui navega, per què el mateix marcatge sona diferent a NVDA, JAWS, VoiceOver o TalkBack i com els modes del lector de pantalla canvien el que significa cada rol.

La cadena completa: del DOM a la persona

Entre el teu HTML i la persona usuària hi ha quatre baules, i quan alguna cosa «no s'anuncia» la fallada pot ser a qualsevol d'elles.

1. El DOM. El document tal com és a la memòria: el teu HTML i tot el que JavaScript hagi canviat després. És l'únic que controles directament.
2. L'arbre d'accessibilitat. El navegador recorre el DOM i, per a cada node rellevant, calcula el seu rol, el seu nom, la seva descripció, els seus estats, les seves propietats i les seves relacions. Descarta el que no aporta significat (bona part dels <div> i <span> genèrics) i el que està amagat. ARIA intervé exactament aquí: sobreescriu o completa el que el navegador hauria deduït de l'HTML.
3. L'API d'accessibilitat de la plataforma. El navegador no parla directament amb el lector de pantalla: publica l'arbre a través de la interfície d'accessibilitat del sistema operatiu. A Windows, UI Automation i IAccessible2 (a més de l'antiga MSAA); a macOS, l'API d'accessibilitat de Cocoa (NSAccessibility); a iOS, UIAccessibility; a Linux, ATK i AT-SPI; a Android, l'API d'accessibilitat del sistema. Les especificacions de correspondència del W3C (Core-AAM per als rols i atributs ARIA, HTML-AAM per als elements HTML) indiquen com s'ha de traduir cada rol i cada estat a cadascuna d'aquestes API.
4. La tecnologia de suport. El lector de pantalla, l'ampliador o el control per veu consulten aquesta API, en reben els esdeveniments i decideixen com presentar la informació: quina paraula fan servir per al rol, en quin ordre, què mostren a la línia braille.

Què decideix ARIA i què decideix el navegador

Quan un element porta l'atribut role, el navegador exposa aquest rol en lloc de l'implícit. Hi ha matisos que expliquen molts comportaments aparentment estranys:

• L'atribut role admet una llista de valors. El navegador fa servir el primer que reconegui i descarta la resta. role="switch checkbox" s'exposa com a interruptor on es conegui switch i com a casella on no. Si cap valor no és vàlid (role="boton"), l'element conserva el seu rol implícit, com si no haguessis escrit res.
• Alguns rols tenen fills presentacionals. En rols com button, checkbox, img, tab, switch, slider, progressbar o option, l'especificació indica que el contingut s'aplana: el navegador n'exposa el text, però qualsevol semàntica interior (un encapçalament, una llista, una taula) desapareix de l'arbre. Per això un encapçalament dins d'un botó deixa de ser un encapçalament i la forma correcta és la inversa: el botó dins de l'encapçalament.
• Els canvis generen esdeveniments. Quan JavaScript modifica aria-expanded, aria-checked o el text d'una regió activa, el navegador actualitza l'arbre i llança un esdeveniment d'accessibilitat («ha canviat l'estat», «ha canviat el nom», «ha aparegut contingut»). La tecnologia de suport escolta aquests esdeveniments. Així es compleix, a la pràctica, la part de 4.1.2 Nom, funció i valor que exigeix notificar els canvis.
• El navegador també repara el marcatge contradictori amb regles de resolució de conflictes (les veurem a la lliçó sobre amagar i anul·lar semàntica). No et refiïs d'aquestes reparacions.

<div role="button" tabindex="0" class="tarjeta">
  <h3>Empadronament</h3>
  <p>Alta, baixa i canvi de domicili</p>
</div>

No busquis la mateixa frase a tots els lectors

El mateix <button aria-expanded="false">Menú</button> no sona igual a tot arreu: cada lector ordena a la seva manera nom, rol i estat, fa servir les seves pròpies paraules i aplica la verbositat que hagi triat la persona. És normal. El que ha de coincidir és la informació (es diu «Menú», és un botó, està contret), no la frase. Si en algun lector falta una d'aquestes peces, llavors sí que hi ha un problema.

Els modes del lector de pantalla

Els lectors de Windows més utilitzats, NVDA i JAWS, treballen sobre una representació virtual de la pàgina i tenen dues formes de funcionar que canvien completament què fa cada tecla:

• Mode d'exploració (NVDA) o cursor virtual (JAWS): les pulsacions no arriben a la pàgina. Les fletxes llegeixen línia a línia i les lletres són dreceres de navegació ràpida; per exemple, a NVDA H salta al següent encapçalament i D al següent landmark (regió de referència com main o nav).
• Mode de focus (NVDA) o mode de formulari (JAWS): les pulsacions passen a la pàgina perquè puguis escriure en un camp o manejar un control amb fletxes. El lector canvia de mode automàticament en entrar en un camp de text i en molts ginys compostos, com llistes d'opcions, arbres o graelles; la persona també el pot canviar a mà (a NVDA, amb NVDA + Espai).

VoiceOver a macOS no té aquesta dualitat: les tecles arriben a la pàgina llevat que es combinin amb Control + Opció, i la navegació per tipus d'element es fa amb el rotor. Al mòbil, VoiceOver i TalkBack es manegen amb gestos.

La conseqüència per a ARIA és directa: el rol influeix en el mode. Si programes un component que respon a les fletxes (unes pestanyes, una llista d'opcions, un arbre de carpetes) però no li dones un rol de giny, en mode d'exploració les fletxes no arriben mai als teus gestors: el lector les consumeix per llegir la línia següent. El component funciona amb el teclat sense lector i falla amb lector. Els rols de giny són el senyal que el lector necessita per cedir el teclat.

role="application": l'interruptor que gairebé mai no has de prémer

role="application" indica a la tecnologia de suport que aquella zona és una aplicació que gestiona totes les pulsacions per si mateixa. Molts lectors deixen llavors d'interceptar el teclat: dins d'aquella zona la persona perd la lectura amb fletxes, els salts per encapçalaments i les dreceres de navegació. Només té sentit en superfícies amb un model de teclat propi i complet per a les quals no hi ha cap rol de giny adequat (un editor gràfic, un mapa amb controls propis), limitat al mínim element possible.

<!-- Incorrecte: tota la intranet es converteix en «aplicació» -->
<body role="application">
  …
</body>

Com veure el que veu el lector

No cal endevinar què hi ha a l'arbre. Aquestes eines el mostren:

• Chrome i Edge: panell Elements, pestanya Accessibilitat. Mostra el rol, el nom calculat i el seu origen, els estats i les propietats, i permet veure l'arbre complet.
• Firefox: l'Inspector d'accessibilitat mostra l'arbre, les propietats de cada node i avisos de problemes habituals. A Safari, l'inspector web mostra les propietats d'accessibilitat del node.
• Nivell de plataforma: Accessibility Insights for Windows i l'Inspector d'Accessibilitat de Xcode a macOS mostren el que rep el sistema operatiu, útil quan el navegador mostra una cosa correcta i el lector es comporta d'una altra manera.
• El mateix lector: el Visualitzador de veu de NVDA (menú de NVDA, Eines) mostra per escrit el que diu; serveix per comparar i desar evidències.

Resum

• La informació viatja del DOM a l'arbre d'accessibilitat, d'aquí a l'API de la plataforma i d'aquí a la tecnologia de suport; ARIA actua en el pas del DOM a l'arbre.
• El navegador fa servir el primer rol vàlid de la llista, aplana el contingut dels rols amb fills presentacionals i llança esdeveniments quan canvien estats i textos.
• Cada lector verbalitza a la seva manera: exigeix que arribi la mateixa informació, no la mateixa frase.
• A NVDA i JAWS el rol influeix en el pas al mode de focus; un component amb fletxes sense rol de giny falla amb lector, i role="application" desactiva la lectura normal, així que gairebé mai no està justificat.
• Inspecciona l'arbre amb les eines del navegador i escolta amb el Visualitzador de veu abans de donar res per bo.