Components complexos amb lector de pantalla: provar els patrons de l'APG

Els components personalitzats (pestanyes, combos amb compleció automàtica, diàlegs, menús desplegables, controls lliscants) concentren bona part de les troballes greus d'una auditoria, i són justament el que les eines automàtiques no saben avaluar. A la lliçó de NVDA i JAWS vas aprendre les ordres; en aquesta aprendràs un mètode per avaluar cada component: què hauria d'anunciar, quines tecles ha d'acceptar, on ha d'anar el focus i com comprovar-ho a l'escriptori i al mòbil. La referència és l'APG (s'obre en una finestra nova) (ARIA Authoring Practices Guide, guia de pràctiques d'autoria ARIA) del W3C, que descriu el comportament que les persones usuàries esperen i que els lectors estan preparats per interpretar.

El mètode: contracte, teclat, lector i mòbil

1. Identifica el patró per la seva funció. Abans de tocar res, decideix què és el component per a qui el fa servir: un grup de pestanyes, un botó que desplega contingut (disclosure), un combo amb suggeriments, un diàleg? El rol que hagi triat l'equip de desenvolupament pot estar equivocat; la teva referència és el que fa el component, no el que diu el codi.
2. Escriu el contracte esperat. Del patró de l'APG extreu-ne tres coses: el rol, el nom i els estats que s'han d'anunciar; les tecles que han de funcionar; i on va el focus en obrir, tancar o seleccionar.
3. Prova només amb teclat, sense lector, com vas veure a la lliçó de teclat i zoom. Si no es pot fer servir amb teclat, ja tens una fallada del 2.1.1 Teclat i el lector només hi afegirà matisos.
4. Prova amb NVDA en els dos modes. Arriba al component amb Tab (el lector sol passar a mode formulari) i també en mode navegació, amb fletxes o amb les lletres de navegació ràpida, activant-lo amb Retorn o Espai. Molts components funcionen en un mode i fallen en l'altre.
5. Repeteix-ho al mòbil amb VoiceOver o TalkBack: llisca fins al component, activa'l amb doble toc i comprova que els estats també s'hi anuncien.

Taula de referència: què s'ha d'anunciar i quines tecles cal provar

Les paraules exactes canvien entre lectors i idiomes; el que importa és que la informació arribi. Fes servir aquesta taula com a guió de prova i amplia-la amb els patrons de l'APG que apareguin a la teva mostra.

Exemple detallat: el combo amb compleció automàtica

És el component que falla més i un dels més utilitzats: cercadors de carrers i municipis en seus electròniques, origen i destinació en webs de transport, cercadors de botigues. Segons WAI-ARIA 1.2 (s'obre en una finestra nova) i el patró de l'APG, el camp porta role="combobox", aria-expanded i aria-controls que apunta a una llista amb role="listbox"; cada suggeriment és un role="option" i el focus es manté al camp mentre l'opció activa es comunica amb aria-activedescendant.

Versió que només funciona per a qui veu la pantalla:

<input type="text" id="calle" placeholder="Carrer">
<ul class="sugerencias">
  <li class="activa">Carrer Major</li>
  <li>Carrer Major Alt</li>
</ul>

Versió que exposa el contracte complet a l'arbre d'accessibilitat:

<label for="calle">Carrer</label>
<input id="calle" type="text" role="combobox"
       aria-autocomplete="list" aria-expanded="true"
       aria-controls="lista-calles"
       aria-activedescendant="calle-op1">
<ul id="lista-calles" role="listbox" aria-label="Carrers suggerits">
  <li id="calle-op1" role="option" aria-selected="true">Carrer Major</li>
  <li id="calle-op2" role="option" aria-selected="false">Carrer Major Alt</li>
</ul>

Guió de prova amb NVDA i el visor de veu obert:

1. Tab fins al camp: s'ha d'anunciar el nom («Carrer»), el rol de quadre combinat i que és editable.
2. Escriu «Maj»: es comunica que hi ha suggeriments, ja sigui pel canvi a expandit o per un missatge amb el nombre de resultats?
3. Fletxa avall: es llegeix «Carrer Major» i, segons el lector, la seva posició a la llista?
4. Retorn: el valor passa al camp, la llista es tanca i el lector confirma el valor?
5. Escapada: es tanca la llista sense esborrar el que s'ha escrit?
6. A iOS amb VoiceOver: pots arribar als suggeriments lliscant i triar-ne un amb doble toc?

Diàlegs: el que només revela el lector

Amb teclat ja hauràs comprovat que el focus queda atrapat dins del diàleg i que Escapada el tanca. Amb lector hi afegeixes quatre comprovacions:

• En obrir-lo: s'anuncia que és un diàleg i el seu títol? El nom sol venir d'aria-labelledby que apunta a l'encapçalament del diàleg.
• En mode navegació: pots sortir del diàleg amb Fletxa avall o amb H i acabar llegint el contingut de fons? Amb l'element <dialog> obert mitjançant showModal(), la resta de la pàgina queda inert; amb role="dialog" depèn d'aria-modal, d'inert i del suport de cada combinació, i per això es prova en totes les de la línia base.
• En tancar-lo: el focus torna al botó que l'ha obert, o es perd i el lector comença a llegir des del principi de la pàgina?
• Al mòbil: VoiceOver o TalkBack permeten lliscar cap al contingut del darrere?

Les fallades es registren normalment al 2.4.3 Ordre del focus (focus que s'escapa o no torna) i al 4.1.2 Nom, funció i valor (diàleg sense rol o sense nom); si no se'n pot sortir amb teclat, al 2.1.2 Sense paranys per al focus del teclat.

Un cas clàssic: la navegació del lloc amb role="menu"

Els rols menu i menubar estan pensats per a menús d'aplicació, com els d'un programa d'escriptori. Quan s'apliquen a la navegació principal d'un lloc, el lector anuncia «barra de menú» i «element de menú», sol passar a mode formulari i la persona usuària espera moure's amb fletxes. Si l'script no implementa aquest model de teclat, l'experiència es trenca: les fletxes no fan res i el comportament contradiu el que s'ha anunciat. Per a la navegació d'un lloc, l'APG recomana el patró de botons desplegables amb enllaços normals.

Criteri pràctic per a l'informe: si en una combinació de la línia base el component no es pot fer servir, és una fallada (2.1.1 o 4.1.2 segons la causa). Si es pot fer servir però contradiu el que anuncia, registra-ho amb el seu criteri quan el rol o l'estat exposats siguin incorrectes, i afegeix-hi sempre la recomanació del patró adequat.

Resum

• Avalua cada component amb el mateix mètode: identificar el patró per la seva funció, escriure el contracte esperat, provar amb teclat, amb lector en tots dos modes i al mòbil.
• L'APG descriu el comportament esperat; no és obligatòria, però un rol ARIA declarat promet unes tecles i uns anuncis que s'han de complir.
• En els combos, comprova amb el visor de veu que l'opció activa s'anuncia a cada pulsació; si no, és una fallada del 4.1.2.
• En els diàlegs, verifica l'anunci de rol i títol, que el fons no sigui accessible en mode navegació i que el focus torni al disparador.
• role="menu" a la navegació del lloc és una font habitual de problemes: recomana el patró de botons desplegables.