Navegación por teclado y accesibilidad: cómo probar su sitio sin ratón

Por qué la navegación por teclado es clave para la accesibilidad

El W3C explica que un contenido manejable con el teclado puede usarlo una persona ciega, que no puede utilizar dispositivos como el ratón porque requieren coordinación ojo-mano. También pueden usarlo quienes emplean teclados alternativos o dispositivos que emulan el teclado: software de entrada por voz, sistemas de soplo y succión (sip-and-puff), teclados en pantalla, software de barrido y diversas tecnologías de apoyo.

Las personas con baja visión pueden tener dificultades para encontrar o seguir el puntero en pantalla; para ellas, un programa puede ser mucho más fácil, o solo posible, de usar con el teclado. Algunas personas con temblor en las manos encuentran el ratón muy difícil de usar y por eso suelen utilizar el teclado. El criterio 2.4.7 beneficia además a las personas con limitaciones de atención, de memoria a corto plazo o de las funciones ejecutivas, a quienes les ayuda poder descubrir dónde está el foco.

Un malentendido frecuente: las MouseKeys, que mueven el puntero con las teclas, no bastan para cumplir el criterio 2.1.1. Para la aplicación se comportan como un ratón, no como un teclado.

Preparar la prueba de navegación por teclado

Elija algunas páginas representativas: la portada, una página de contenido, un formulario y los recorridos importantes para sus visitantes, como un registro o una compra. Deje el ratón a un lado y, si hace falta, haga clic una vez en la barra de direcciones para empezar desde el principio de la página.

Durante toda la prueba, use solo estas teclas:

• Tab para avanzar al siguiente elemento interactivo y Mayús+Tab para retroceder;
• Intro y Espacio para activar elementos: el W3C señala que los botones con el foco suelen activarse con ambas teclas. Seguir esta convención es una buena práctica, pero un botón personalizado que solo reacciona a Intro cumple igualmente el criterio 2.1.1;
• las flechas para moverse dentro de un componente cuando Tab no basta;
• Esc para cerrar un cuadro de diálogo o salir de un componente.

Paso 1: ¿todo funciona con el teclado (criterio 2.1.1)?

El criterio 2.1.1 exige que toda la funcionalidad del contenido pueda manejarse mediante una interfaz de teclado sin requerir tiempos específicos para cada pulsación. El W3C da ejemplos de esos tiempos: tener que repetir o ejecutar varias pulsaciones en un periodo corto, o mantener una tecla pulsada durante mucho tiempo antes de que se registre.

La única excepción se refiere a funciones cuya naturaleza depende de la trayectoria del movimiento y no solo de sus extremos, como el dibujo a mano alzada o un programa de acuarela en el que el trazo varía según la velocidad y la duración del gesto. La excepción se aplica a la función, no a la técnica de entrada: la escritura a mano depende de la trayectoria, pero la entrada de texto que produce no está exenta. Del mismo modo, trazar líneas rectas, redimensionar ventanas o arrastrar objetos a un lugar, cuando el camino hasta ese lugar no importa, no entran en la excepción.

El criterio no obliga a que cada control visible reciba el foco: debe existir una forma de realizar la misma acción, o una comparable, con el teclado. El W3C cita un formulario de búsqueda cuyo botón de envío no recibe el foco, pero que cumple porque se puede pulsar Intro en el campo de texto. Igualmente, una función de arrastrar y soltar puede ofrecer cortar y pegar o controles de formulario para mover objetos.

Qué anotar durante la prueba:

• un menú, pestaña, carrusel o botón que reacciona al ratón pero nunca al teclado, sin otra forma de realizar la acción con el teclado (fallo F54: usar solo controladores de eventos propios del dispositivo apuntador, gestos incluidos);
• un elemento que emula un enlace (fallo F42, que también afecta a los criterios 1.3.1, 2.1.3 y 4.1.2) y que no funciona con el teclado;
• un elemento que pierde el foco en cuanto lo recibe por culpa de un script (fallo F55);
• un iframe con elementos interactivos excluido del orden de tabulación, o un contenido desplazable al que no se llega con la navegación secuencial.

Paso 2: ninguna trampa de teclado (criterio 2.1.2)

El criterio 2.1.2 exige que, si el foco puede llevarse a un componente con el teclado, también pueda sacarse de él solo con el teclado. Si para ello hace falta algo más que las flechas o Tab sin modificadores u otros métodos de salida estándar, hay que informar al usuario del método. El W3C indica que, en la mayoría de entornos con teclado físico, Esc es un método de salida estándar de uso común.

Este criterio se aplica a todo el contenido de la página, incluso al que no sirve para cumplir otros criterios: una sola trampa puede interferir en el uso de toda la página. Las trampas aparecen a menudo con contenidos mostrados mediante plug-ins o aplicaciones incrustadas, o con componentes personalizados creados sin pensar en el teclado.

Restringir el foco no siempre es un fallo. En un cuadro de diálogo modal, el foco puede pasar del último control al primero, siempre que el usuario sepa cómo salir, por ejemplo cerrándolo con Cancelar, Aceptar o Esc. En un editor de texto enriquecido donde Tab sirve para sangrar, una instrucción puede indicar el atajo para salir, como Alt+F10 en el ejemplo del W3C.

Para probarlo, entre en cada componente (reproductor de vídeo, mapa, editor, widget de terceros, modal) e intente salir con Tab, Mayús+Tab, las flechas y Esc. El criterio solo exime de instrucciones cuando la salida funciona con Tab o las flechas sin modificadores, o con un método de salida estándar; el W3C precisa que la especificación no define esos métodos, que dependen del hardware, del agente de usuario y del sistema operativo. Si no puede salir con el teclado, o si salir exige otro atajo que ninguna instrucción menciona, es un fallo.

Paso 3: ¿el foco está siempre visible (criterio 2.4.7)?

El criterio 2.4.7 exige que toda interfaz manejable con el teclado tenga un modo de funcionamiento en el que el indicador del foco sea visible. El W3C es claro: sin indicador de foco, las personas videntes que navegan con el teclado no pueden usar la página. El indicador no debe estar limitado en el tiempo: cuando se muestra el foco, debe seguir visible.

Los navegadores pueden mostrar el foco solo cuando se usa el teclado, y eso es admisible. En cambio, el fallo F78 se refiere a dar estilo a contornos y bordes de forma que el indicador desaparezca o quede invisible. Entre las técnicas reconocidas están el indicador por defecto del navegador o de la plataforma, un indicador visible propio, un indicador de dos colores para garantizar el contraste o la pseudoclase CSS :focus-visible.

Cuidado con el contraste: como el indicador de foco suele ser contenido no textual, por ejemplo un contorno, también está sujeto al criterio 1.4.11 de contraste no textual (nivel AA). El criterio 2.4.13 (nivel AAA) da pautas sobre el tamaño y la forma del indicador.

Durante la prueba, cada vez que pulse Tab debe poder decir enseguida qué elemento tiene el foco: un borde alrededor de un botón o un cursor de texto en un campo.

Lista de comprobación de la navegación por teclado

Tenga esta lista a mano, página por página, y anote cada problema con el elemento afectado:

• Cada enlace, botón, campo y control personalizado puede alcanzarse con el teclado, o su acción puede realizarse de otra forma con él.
• Ninguna acción exige pulsaciones rápidas repetidas ni mantener una tecla pulsada mucho tiempo.
• Los contenidos desplazables y los iframes interactivos son accesibles con la navegación secuencial.
• Se puede salir de cada componente con Tab o las flechas sin modificadores, o con un método de salida estándar como Esc; si no, una instrucción explica cómo.
• Se puede salir de cada cuadro de diálogo modal con el teclado, por ejemplo cerrándolo con Esc o un botón.
• El foco es visible en cada elemento y no desaparece al cabo de un momento.
• Ningún script quita el foco a un elemento en el momento en que lo recibe.
• Buena práctica adicional, fuera de los tres criterios tratados aquí: anote cualquier orden del foco que resulte confuso respecto a la lectura de la página.

Completar la prueba manual con una supervisión continua

La prueba con teclado sigue siendo una tarea humana: alguien tiene que recorrer las páginas y valorar lo que ve. Para que una regresión no pase desapercibida entre dos pruebas, puede lanzar un test gratuito de su sitio con Conformly, activar después la supervisión continua y reservar las pasadas manuales con teclado para los recorridos clave.

Preguntas frecuentes

Más sobre el tema en Conformly

• Corregir un foco invisible en HTML
• Criterio RGAA 12.9 sobre trampas de teclado
• Criterio RGAA 7.3 sobre scripts y teclado

Fuentes

Este artículo se basa en las fuentes oficiales citadas al final de la página.

• W3C — Comprendre 2.1.1
• W3C — Comprendre 2.1.2
• W3C — Comprendre 2.4.7