El teclat i les tecnologies de suport: lectors de pantalla, veu, commutadors i ampliadors

Dèiem en començar el curs que, si una interfície funciona amb teclat, funciona amb la majoria de les tecnologies de suport. És cert com a punt de partida, però no n'hi ha prou: un lector de pantalla, un programa de control per veu o un commutador no es comporten exactament com una persona que prem Tab. Fan servir el focus, sí, però també intercepten tecles, activen els controls pel seu compte i depenen dels noms i rols que exposa el teu codi. Aquesta lliçó explica com interactuen amb el teclat i el focus les principals tecnologies de suport i quines conseqüències té això per a qui desenvolupa. El seu ús per auditar el veuràs al nivell d'auditoria.

Què entenen les WCAG per «interfície de teclat»

Les WCAG defineixen la interfície de teclat com la que fa servir el programari per rebre pulsacions de tecles, i aclareixen que també la fan servir altres dispositius que les emulen: teclats en pantalla, sistemes de reconeixement de veu o dispositius de bufar i aspirar. Per això el 2.1.1 Teclat protegeix molta més gent que qui fa servir un teclat físic. Però aquestes tecnologies no només envien tecles: també llegeixen l'arbre d'accessibilitat i demanen al navegador que executi accions sobre els elements. Una interfície que només respon a esdeveniments de teclat concrets pot passar la prova amb teclat i fallar amb aquestes tecnologies.

Lectors de pantalla a l'ordinador: dos modes i dos cursors

NVDA i JAWS a Windows treballen amb dos modes:

• Mode d'exploració (o mode virtual): el lector presenta la pàgina com un document que es recorre amb les fletxes, línia a línia, i fa servir lletres soltes per saltar per elements. A NVDA, H va a l'encapçalament següent, K a l'enllaç següent, B al botó següent, F al camp de formulari següent i D a la regió següent. Aquestes tecles no arriben a la pàgina: les consumeix el lector.
• Mode de focus (o mode formulari): en entrar en un camp de text o en molts components amb rol compost, el lector deixa passar les tecles a la pàgina. Només llavors el teu gestor de keydown rep les fletxes i les lletres. A NVDA es pot alternar manualment amb Insert+Espai.

D'aquí en surten tres conseqüències pràctiques:

1. L'activació ha de ser a l'esdeveniment click. En mode d'exploració, quan la persona prem Retorn o Espai sobre un element, el lector no reenvia la tecla: demana al navegador que activi l'element, cosa que normalment genera un click. Un control personalitzat que només escolta keydown funciona amb teclat i no funciona amb el lector.
2. El cursor del lector no és el focus. Llegir amb les fletxes en mode d'exploració no sempre mou document.activeElement. Si una informació o un botó només existeix al DOM quan alguna cosa rep el focus, qui llegeix amb les fletxes pot no trobar-lo mai.
3. Els rols decideixen el mode. El rol que poses a un component influeix en si el lector canvia a mode de focus. Per això un rol equivocat (un role="menu" a la navegació del lloc, per exemple) canvia les tecles que funcionen.

<div role="button" tabindex="0" id="favorito">Afegeix als preferits</div>
<script>
favorito.addEventListener('keydown', (e) => {
  if (e.key === 'Enter') marcarFavorito();
});
</script>

Hi ha un rol que desactiva el mode d'exploració en tota una regió: role="application". Amb aquest rol, el lector deixa d'oferir la navegació per encapçalaments i enllaços i passa totes les tecles al teu codi. Només té sentit en interfícies que funcionen com una aplicació d'escriptori i tenen un model de teclat complet i documentat, com un editor gràfic. En un web de continguts o en un formulari, gairebé mai no és la resposta.

Mòbils i tauletes

Amb VoiceOver a iOS i TalkBack a Android, els gestos mouen el focus del lector d'element en element i el doble toc activa l'element enfocat. No hi ha cap keydown: una altra raó perquè l'activació sigui sempre a click. Quan el teu codi crida focus() (en obrir una finestra modal o canviar de vista), els lectors mòbils solen portar el seu focus a aquest element, així que la gestió del focus que vam veure en lliçons anteriors també protegeix qui fa servir el mòbil.

A més, cada vegada més persones fan servir un teclat físic amb la tauleta o el mòbil. iOS i iPadOS inclouen l'opció «Accés total amb el teclat» (a Configuració, Accessibilitat, Teclats), i Android permet recórrer la interfície amb Tab i les fletxes des d'un teclat extern. Els criteris de teclat s'apliquen igual a la versió mòbil del teu web.

Control per veu

Dragon a Windows, Control per veu a macOS i iOS, Accés per veu a Windows 11 i Voice Access a Android permeten fer anar la interfície parlant. La persona té tres maneres d'actuar:

• Dir el nom del control: «prem Envia la sol·licitud». El programa busca un element interactiu el nom accessible del qual coincideixi amb el que s'ha dit.
• Demanar números o etiquetes: «mostra els números» superposa un número a cada element interactiu i la persona diu «prem 12». Només es numeren els elements que el navegador exposa com a interactius.
• Dictar tecles: «prem Tab», «prem fletxa avall». Aquí torna el teclat i, amb ell, el risc de les dreceres d'una sola tecla que vam veure al 2.1.4.

Perquè la primera funcioni hi ha el criteri 2.5.3 Etiqueta en el nom (nivell A): quan un control té una etiqueta visible amb text, el seu nom accessible ha de contenir aquest text, preferiblement al principi. Perquè funcioni la segona, els elements clicables han de ser natius o tenir un rol interactiu; un div amb onclick sovint no rep número.

<!-- Incorrecte: diu «Continua», però el seu nom és «Botó principal» -->
<button type="button" aria-label="Botó principal">Continua</button>

<!-- Correcte: el nom comença pel text visible -->
<button type="button" aria-label="Continua al pas 3, data i hora">Continua</button>

Commutadors i ampliadors de pantalla

Qui fa servir un o dos commutadors (polsadors que s'accionen amb la mà, el cap o el peu) sol treballar per escombratge: el sistema ressalta els elements interactius un per un, o per grups, i la persona prem quan arriba al que vol. Cada parada innecessària (un tabindex="0" en una targeta, 31 dies d'un calendari sense roving tabindex) costa segons per pulsació, i els límits de temps que no es poden ampliar poden fer impossible la tasca (2.2.1 Temps ajustable).

Els ampliadors de pantalla (Lupa de Windows, Zoom de macOS, ZoomText) mostren només una part de la pantalla molt augmentada i segueixen el focus del teclat i el cursor de text. Si el focus salta a un lloc imprevist, si una finestra modal s'obre sense rebre el focus o si un missatge apareix a l'altra cantonada, la persona simplement no se n'assabenta: el que passa fora de la seva finestra d'augment no existeix per a ella.

Resum

• Per a les WCAG, la interfície de teclat inclou els dispositius que emulen pulsacions, però les tecnologies de suport també activen controls mitjançant accions del navegador.
• En mode d'exploració, els lectors de pantalla consumeixen les fletxes i les lletres i converteixen Retorn en un click: l'activació ha de ser a l'esdeveniment click.
• El cursor del lector no sempre mou el focus: no facis dependre del focus l'existència de contingut; reserva role="application" per a casos excepcionals.
• El control per veu necessita noms que continguin el text visible (2.5.3) i controls amb rol interactiu.
• Els commutadors i els ampliadors castiguen les parades sobreres i els moviments de focus imprevistos.