Tu informe de auditoría dice que el 2.1.1 falla en cada elemento. Cómo saber si es cierto.

Alguien te envía una auditoría de accesibilidad. Bajo 2.1.1 Teclado, todos los elementos de la página llevan el mismo veredicto: no hay alternativa al uso exclusivo del ratón. Desenchufas el ratón, recorres la página con el tabulador y funciona todo — el foco se mueve, el anillo se ve, Intro activa lo que debe.

Uno de los dos se equivoca. Averiguar cuál no es cuestión de opiniones, y la respuesta es más interesante que «el proveedor está inflando el informe».

Primero: el 2.1.1 no significa lo que el informe probablemente supone

El criterio dice:

Toda la funcionalidad del contenido es operable a través de una interfaz de teclado sin que se requieran tiempos específicos para las pulsaciones individuales, excepto cuando la función subyacente requiere una entrada que depende del trayecto del movimiento del usuario y no solo de los puntos inicial y final.

Nivel A. Fíjate en lo que falta: cualquier mención a una tecla concreta.

El documento Understanding es explícito:

los botones que tienen el foco generalmente pueden activarse tanto con la tecla Intro como con la barra espaciadora. Si un control de botón personalizado en una aplicación web reacciona en cambio solo a Intro (o incluso a una tecla o combinación completamente propia), esto sigue satisfaciendo los requisitos de este criterio de conformidad.

Así que «Intro no hizo nada, luego 2.1.1» no es un hallazgo. Tampoco «este control quiere una tecla que no he adivinado». La pregunta que hace el 2.1.1 es si la función puede realizarse desde el teclado, no si puede realizarse como tú esperabas.

Y corta en ambas direcciones. Descarta toda una clase de falsos positivos, pero también significa que un control puede cumplir el 2.1.1 siendo en la práctica inutilizable, porque nadie adivina la tecla. Es un problema real, pero pertenece a otros criterios y a la usabilidad sin más, no a este.

Segundo: tres cosas que se archivan bajo 2.1.1 y son criterios distintos

Importa, porque si el informe mete todo bajo un único número, eso ya dice algo de cómo se produjo.

Quedarse atrapado es 2.1.2 Sin trampas para el foco del teclado (A). Entras con el tabulador y no puedes salir. Criterio distinto.

Ver dónde estás es 2.4.7 Foco visible (AA). Ese anillo grueso que observaste es prueba del 2.4.7. No es prueba ni a favor ni en contra del 2.1.1 — una página puede tener un indicador de foco perfecto en cada control y aun así incumplir el 2.1.1, y puede cumplir el 2.1.1 sin ningún foco visible.

El foco tapado por una cabecera fija es 2.4.11 Foco no oscurecido (mínimo) (AA), nuevo en WCAG 2.2. Tampoco es 2.1.1.

Si tu propia prueba consistió en «tabulé, veía el foco e Intro funcionaba», has reunido buenas pruebas sobre el 2.4.7 y pruebas solo parciales sobre el 2.1.1.

Qué aspecto tiene un hallazgo 2.1.1 de verdad

Un incumplimiento de este criterio tiene que nombrar una función que no puede realizarse. No un elemento que existe. Así que un hallazgo utilizable contiene:

• el elemento, y qué intentabas hacer con él
• los pasos para reproducirlo
• resultado esperado frente a resultado real
• navegador, sistema operativo y qué tecnología de apoyo en qué versión

No es un listón alto. Es lo que la persona que probó anotó mientras probaba, porque lo necesitaba para saber que fallaba. Cualquier auditoría que valga lo que cuesta ya lo tiene.

Si todos los elementos llevan un veredicto idéntico, eso no es un resultado: es una plantilla. Una lista de comprobación rellenada una vez y copiada columna abajo tiene exactamente ese aspecto. Y también un informe donde «no probado» se exportó como «falla».

Vuelve y pide pasos de reproducción para dos o tres de los puntos señalados. Es una petición factual que pueden satisfacer o no, y zanja la discusión sin que nadie tenga que debatir la redacción de un criterio.

Pero no concluyas que tu prueba ha absuelto la página

Aquí es donde quien tiene razón sobre el informe suele acabar equivocándose sobre su propio sitio.

Desenchufar el ratón y pulsar Tab es una prueba real, y se le escapan la mayoría de los fallos que de verdad aparecen en las auditorías:

• Contenido que solo aparece al pasar el puntero. Tu puntero ya no está, así que nunca lo ves, y quien usa el teclado tampoco. (Relacionado: 1.4.13 Contenido al pasar el puntero o al recibir el foco, AA.)
• Todo lo que exige arrastrar. Deslizadores, listas reordenables, desplazar mapas. WCAG 2.2 añadió 2.5.7 Movimientos de arrastre (AA) precisamente porque esto seguía pasando.
• Widgets compuestos donde el tabulador llega al componente pero las flechas de dentro nunca se conectaron. Una lista o un juego de pestañas personalizados en los que entras y no navegas.
• Modales que se abren perfectamente y no se cierran sin puntero. Eso es 2.1.2, y es el defecto grave de teclado más común que veo.
• Todo lo que está por debajo de una trampa de teclado, que nunca alcanzarás, y cuya ausencia de tus notas parece un aprobado.

Por qué podéis tener razón los dos

Esta es la resolución que suele aplicarse, y que casi nadie comprueba: solo teclado y teclado con un lector de pantalla en marcha son dos pruebas distintas.

NVDA y JAWS en modo exploración interceptan las pulsaciones antes de que lleguen a la página. Un elemento accesible con el tabulador y el lector apagado puede ser inalcanzable en modo exploración, y ocasionalmente al revés. Quien prueba con NVDA y quien desarrolla sin nada observan de verdad comportamientos distintos en la misma página.

Así que si el proveedor probó con tecnología de apoyo encendida y tú con ella apagada, ninguno miente y ninguno tiene el cuadro completo. Por eso la línea del entorno en un hallazgo no es burocracia: sin ella, el hallazgo no se puede reproducir ni refutar.

Qué hacer, por orden

1. Pide pasos de reproducción para dos o tres puntos señalados.
2. Prueba esos mismos tú, con NVDA en marcha, en modo exploración, sobre Windows. Firefox o Chrome, el que hayan indicado.
3. Si se reproducen, has aprendido algo real sobre tu sitio.
4. Si no se reproducen y el proveedor no sabe dar los pasos, tienes motivos para rechazar la columna — y para preguntar qué más del informe se generó igual.

Un escáner automático, el mío incluido, no te resolverá esto. La operabilidad por teclado no es detectable de forma fiable por una máquina: una herramienta puede señalar un tabindex positivo, un elemento oculto a las tecnologías de apoyo pero aún enfocable, o un control sin nombre accesible, y eso merece la pena. Si una persona puede realmente completar tu proceso de pago sin ratón sigue siendo una pregunta que requiere una persona.

La salvedad

Estoy describiendo cómo evaluar un informe, no diciéndote que tu sitio aprueba. Si la auditoría tiene razón, que esté mal escrita no la vuelve equivocada: la vuelve mal escrita. Pide los pasos, y luego toma en serio lo que vuelva.

Fuentes: Understanding SC 2.1.1 Keyboard · WebAIM: Keyboard Accessibility