Discapacidad motriz: teclado, pulsadores, voz y mirada

La discapacidad motriz es la más heterogénea de todas: incluye desde un temblor leve en las manos hasta la tetraplejia, pasando por la artritis, la esclerosis múltiple, el párkinson, la parálisis cerebral o la amputación. Lo que tienen en común sus usuarios en la web es que el ratón, o el dedo sobre la pantalla táctil, no es su medio de interacción principal o no les resulta preciso. En esta lección verás con qué sustituyen al ratón y qué les exige eso al diseño.

El teclado como base de todo

La mayor parte de las tecnologías de apoyo para la discapacidad motriz acaban traduciéndose en pulsaciones de teclado: un pulsador emula Tab e Intro, un programa de control por voz envía órdenes que equivalen a teclas, un lector de pantalla se maneja con el teclado. Por eso el criterio 2.1.1 Teclado (nivel A) es uno de los pilares de las WCAG: toda la funcionalidad debe poder usarse mediante una interfaz de teclado.

En la práctica, un usuario de teclado se mueve con Tab y Mayús+Tab entre los elementos interactivos, activa con Intro o Espacio, se desplaza en listas y menús con las flechas y cierra con Esc. Para que esto funcione hacen falta varias cosas a la vez:

• Que todos los controles sean alcanzables: los elementos nativos (<a href>, <button>, <input>) lo son por defecto; un <div> con onclick no.
• Que el foco sea visible en todo momento (2.4.7 Foco visible, AA): si el diseño elimina el contorno con outline: none y no lo sustituye, el usuario no sabe dónde está.
• Que el orden del foco sea lógico (2.4.3 Orden del foco) y que no haya trampas en las que el foco entra y no puede salir (2.1.2 Sin trampas para el foco del teclado).
• Que el foco no quede oculto tras cabeceras fijas o banners de cookies (2.4.11 Foco no oculto (mínimo), nuevo en WCAG 2.2).

<!-- Incorrecto: no recibe el foco ni responde a Intro -->
<div class="tarjeta" onclick="abrir(12)">Ver expediente</div>

<!-- Correcto: alcanzable, activable y con nombre -->
<a href="/expedientes/12">Ver expediente</a>

Pulsadores y barrido

Un pulsador (switch) es un botón grande, o un sensor de soplido, de presión o de movimiento de la cabeza, que la persona puede activar con la parte del cuerpo que controla. Con uno o dos pulsadores se maneja todo el dispositivo mediante barrido: el sistema va resaltando elementos de forma secuencial y el usuario pulsa cuando el elemento deseado está resaltado. iOS lo incluye como Control por botón y Android como Accesibilidad con interruptores.

El barrido es lento. Cada elemento interactivo innecesario, cada enlace repetido, cada paso de más en un proceso, se traduce en segundos o minutos de espera. De ahí la importancia de:

• Un enlace para saltar al contenido principal (2.4.1 Evitar bloques).
• Procesos con el mínimo de pasos y sin campos superfluos.
• Tiempo suficiente: los límites de sesión deben poder ampliarse o desactivarse (2.2.1 Tiempo ajustable). Un formulario que caduca a los diez minutos es imposible para muchos usuarios de barrido.

Control por voz

Programas como Dragon, Acceso por voz de Windows o Control por voz de macOS e iOS permiten manejar el ordenador hablando: «pulsar Enviar», «hacer clic en Contacto», «desplazar abajo». Para que «pulsar Enviar» funcione, el software busca un control cuyo nombre accesible contenga la palabra «Enviar». Dos consecuencias prácticas:

• Los controles necesitan nombres accesibles coherentes con su texto visible. El criterio 2.5.3 Etiqueta en el nombre exige que el texto visible de un control esté incluido en su nombre accesible. Si un botón muestra «Enviar» pero su aria-label es «Remitir formulario», la orden de voz falla.
• Los controles que son solo un icono sin texto obligan al usuario a usar la cuadrícula numerada, un método mucho más lento. Añade texto visible o, al menos, un nombre accesible predecible.

Seguimiento ocular y otras alternativas

Los sistemas de seguimiento ocular (eye tracking, como los de Tobii) detectan hacia dónde mira la persona y mueven el puntero; la selección se hace manteniendo la mirada fija unos instantes o con un parpadeo. Lo usan personas con ELA, lesión medular alta o parálisis cerebral severa. También existen ratones de cabeza, joysticks y punteros bucales. Todos tienen en común una precisión limitada y una fatiga elevada, lo que lleva a varios criterios WCAG:

• 2.5.8 Tamaño del objetivo (mínimo), nuevo en 2.2, nivel AA: los objetivos deben medir al menos 24 por 24 píxeles CSS o tener espacio suficiente alrededor. Botones diminutos e iconos pegados entre sí son inalcanzables con un puntero impreciso.
• 2.5.1 Gestos del puntero: cualquier gesto complejo (pellizcar, deslizar con dos dedos, trazar una ruta) debe tener alternativa de un solo puntero.
• 2.5.7 Movimientos de arrastre, nuevo en 2.2: arrastrar y soltar debe tener una alternativa sin arrastre (botones de subir o bajar, por ejemplo).
• 2.5.2 Cancelación del puntero: la acción debe ejecutarse al soltar, no al presionar, para que un clic accidental pueda cancelarse.

Cómo comprobarlo

• Desconecta el ratón y recorre toda la web con Tab: ¿llegas a todo, ves siempre dónde estás, puedes salir de cada componente?
• Mide los objetivos táctiles más pequeños: ¿alcanzan 24 por 24 píxeles?
• Prueba con el control por voz del sistema operativo: ¿puedes activar los botones diciendo su texto visible?

Resumen

• La mayoría de las tecnologías de apoyo motrices se apoyan en el teclado: 2.1.1 Teclado es la base.
• El foco debe ser visible (2.4.7), lógico (2.4.3), sin trampas (2.1.2) y no quedar oculto (2.4.11).
• Los pulsadores con barrido son lentos: reduce pasos, ofrece enlaces de salto y tiempo ajustable (2.2.1).
• El control por voz necesita que el texto visible esté en el nombre accesible (2.5.3).
• Los punteros imprecisos exigen objetivos de 24 por 24 píxeles (2.5.8) y alternativas a gestos y arrastres (2.5.1, 2.5.7).