Trampas de teclado: el desencadenante oculto de demandas
Monique Reid presentó una demanda contra Colgate-Palmolive en la Corte Suprema del Estado de Nueva York, Condado de Kings, el 2 de febrero de 2026. Su demanda alegaba que el sitio web de la empresa discriminaba a los consumidores con discapacidad visual al mantener barreras que impiden el acceso con lectores de pantalla y la navegación por teclado, haciendo imposible comprar en línea sin interacciones basadas en el ratón.
El caso es uno entre miles. Pero la alegación específica sobre la navegación por teclado apunta a un fallo técnico particular que aparece repetidamente en las demandas por accesibilidad: las trampas de teclado.
Según la encuesta anual de WebAIM, el 68% de los usuarios de lectores de pantalla se encuentran con trampas de teclado o interfaces inaccesibles mensualmente. Para los aproximadamente 7 millones de estadounidenses que no pueden usar un ratón debido a discapacidades motoras, estas trampas no solo causan frustración. Hacen que los sitios web sean inutilizables.
Qué es realmente una trampa de teclado
El Criterio de éxito 2.1.2 de WCAG 2.1 es directo: si el foco del teclado puede moverse hacia un componente de la página usando una interfaz de teclado, entonces el foco debe poder moverse fuera de ese componente usando solo una interfaz de teclado.
Esa es la regla. En la práctica, una trampa de teclado ocurre cuando navegas con la tecla Tab hacia una sección de un sitio web y no puedes salir de ella con la misma tecla. Quizás el foco se queda atrapado en un menú desplegable. Quizás se abre un diálogo modal y no puedes escapar. Quizás JavaScript personalizado mantiene devolviendo el foco a un elemento particular sin importar cuántas veces presiones Tab.
El documento de comprensión del W3C lo expresa simplemente: los usuarios de teclado no se quedan atrapados. Asegúrese de que los usuarios siempre sepan cómo navegar fuera de los componentes.
Esto es importante porque las personas que dependen del teclado a menudo no tienen otro medio para navegar. Un usuario de ratón que encuentra una trampa puede simplemente hacer clic en otro lugar. Un usuario de teclado no puede.
Por qué las trampas de teclado desencadenan demandas
La ADA no menciona los sitios web. Pero el Departamento de Justicia ha dejado claro que el Título III se aplica a los espacios en línea, y los tribunales han coincidido en gran medida. Cuando el abogado de un demandante prueba un sitio y descubre que no puede navegar más allá de cierto punto, eso es una barrera concreta.
Las trampas de teclado son especialmente dañinas en los litigios porque son demostrables. Un demandante puede mostrar al tribunal exactamente lo que sucede. Presiona Tab. El foco desaparece dentro de un widget. Presiona Tab otra vez. Nada. Presiona Tab veinte veces. Sigue atrapado. No hay forma de completar una compra, enviar un formulario o acceder a la información.
La demanda contra Colgate-Palmolive alega exactamente esto: barreras que impiden la navegación por teclado, haciendo imposible comprar en línea sin interacciones basadas en el ratón. Esa es la teoría legal. Si requieres un ratón, estás excluyendo a las personas que no pueden usar uno.
Dónde se esconden las trampas de teclado
Las trampas de teclado aparecen en lugares predecibles. Los diálogos modales son el problema más común. Se abre un modal, el foco se mueve dentro, y el desarrollador olvida gestionar lo que sucede cuando el usuario alcanza el último elemento enfocable. El usuario navega con Tab más allá del último botón y el foco desaparece en el fondo, o peor, se queda atrapado por completo.
Los widgets personalizados también causan problemas. Los desarrolladores construyen menús desplegables, paneles de pestañas y carruseles usando divs y spans en lugar de HTML semántico. Añaden manejadores de clic pero olvidan los manejadores de teclado. Un usuario navega con Tab hacia el widget y no puede salir porque las teclas de flecha no hacen nada y Tab queda atrapado.
Los embebidos de terceros son otra fuente. El documento de la técnica G21 del W3C menciona específicamente los complementos como una trampa común. Si un complemento no proporciona un mecanismo de teclado para devolver el foco a la ventana padre, los usuarios pueden quedar atrapados en ese contenido. Esto era un problema mayor con Flash, pero los embebidos modernos como mapas interactivos o reproductores multimedia personalizados aún pueden atrapar el foco si no están construidos correctamente.
Los ejemplos de reglas ACT del W3C muestran un patrón de trampa simple:
html
<a href="#">Enlace 1</a> <button onblur="setTimeout(() => this.focus(), 10)"> Botón1 </button> <a href="#">Enlace 2</a>
Cuando el foco sale del botón, el setTimeout lo devuelve inmediatamente. El usuario nunca puede alcanzar el Enlace 2. Eso es una trampa.
La excepción de los diálogos modales
Hay un caso legítimo donde atrapar el foco es realmente necesario. Los diálogos modales deben atrapar el foco mientras están abiertos. Si navegas con Tab más allá del último botón de un modal y el foco se mueve a la página detrás de él, los usuarios se confunden y pueden perder el contexto por completo.
El ejemplo del W3C lo explica: cuando se ha abierto un diálogo, el foco queda atrapado dentro del diálogo. Navegar con Tab desde el último control lleva el foco al primer control. El diálogo se cierra activando el botón Cancelar o Aceptar.
Esto está permitido porque la trampa es intencional y el usuario tiene una forma clara de salir. La clave es que el usuario sepa cómo salir. Eso es lo que significa el criterio de éxito cuando dice que si requiere más que las teclas de flecha o Tab sin modificar u otros métodos de salida estándar, se informa al usuario del método.
En la práctica, eso significa que los modales deben cerrarse con la tecla Escape, y los botones para cerrar el modal deben estar claramente disponibles. El usuario nunca debe quedar atrapado sin forma de salir.
Cómo es el atrapamiento de foco adecuado
La guía de TestParty muestra una implementación correcta de modal:
javascript
modal.addEventListener('keydown', (e) => { if (e.key === 'Escape') { closeModal(); triggerButton.focus(); // Devuelve el foco al disparador } if (e.key === 'Tab') { // Atrapa el foco dentro del modal, pero permite el ciclo const focusable = modal.querySelectorAll( 'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])' ); const firstFocusable = focusable[0]; const lastFocusable = focusable[focusable.length - 1]; if (e.shiftKey && document.activeElement === firstFocusable) { e.preventDefault(); lastFocusable.focus(); } else if (!e.shiftKey && document.activeElement === lastFocusable) { e.preventDefault(); firstFocusable.focus(); } } });
Esto mantiene el foco dentro del modal mientras está abierto pero recorre los elementos disponibles. Cuando el modal se cierra, el foco regresa a lo que lo abrió. Ese es el patrón.
El ejemplo de Mozilla
Incluso las grandes organizaciones se equivocan en esto. El proyecto bedrock de Mozilla, que impulsa el sitio web de Mozilla.org, tuvo un problema reportado en marzo de 2025 sobre su menú de navegación móvil.
El problema: al abrir el menú de navegación móvil en un dispositivo con teclado externo o tecnología de asistencia, el foco no estaba confinado al menú. Los usuarios podían salir con Tab y aterrizar en elementos de página ocultos detrás del menú abierto.
El informe del problema describe el comportamiento esperado: cuando el menú de navegación móvil está abierto, el foco del teclado debe permanecer dentro del menú. Los usuarios solo deberían poder navegar por los elementos del menú hasta que el menú se cierre.
Esto es lo inverso del problema habitual de trampa. Aquí el menú no atrapaba el foco cuando debería haberlo hecho. Ambos fallos causan confusión. Los usuarios esperan que el foco permanezca en un menú abierto hasta que lo cierren intencionalmente. Cuando no es así, la navegación se vuelve impredecible.
El problema sigue abierto. Mozilla aún no lo ha solucionado.
Pruebas para detectar trampas de teclado
Probar para detectar trampas es simple pero tedioso. Necesitas recorrer cada página sin más que un teclado.
La guía de UXPin recomienda comenzar desde la barra de direcciones del navegador. Presiona Tab repetidamente hasta que regreses a la barra de direcciones. Anota cualquier elemento omitido, orden ilógico o estados de foco invisibles. Luego hazlo de nuevo con Shift+Tab para probar la navegación inversa.
Para widgets específicamente, necesitas probar que todos los elementos interactivos respondan a las teclas apropiadas. Los enlaces se activan con Enter. Los botones se activan con Enter y Espacio. Las casillas de verificación se alternan con Espacio. Los botones de opción se navegan con las teclas de flecha y se seleccionan con Espacio.
Para widgets personalizados como pestañas, acordeones y menús, necesitas probar el patrón de interacción completo. ¿Puedes abrir el menú con Enter o Espacio? ¿Puedes navegar por los elementos con las teclas de flecha? ¿Puedes cerrarlo con Escape? ¿El foco regresa a donde comenzó?
La regla ACT del W3C proporciona un enfoque de prueba más formal. La regla verifica la existencia de trampas de teclado probando si el foco puede moverse fuera de un componente en cualquier dirección. Si puedes escapar en una dirección pero no en la otra, eso todavía se considera aprobado según la regla técnica, pero se reconoce como una mala práctica.
El requisito de instrucciones
A veces las trampas son inevitables. Un widget complejo podría necesitar manejar sus propias interacciones de teclado. En esos casos, el criterio de éxito requiere que se informe al usuario del método para mover el foco fuera.
Los ejemplos del W3C muestran cómo funciona esto. En un ejemplo, dos botones crean una trampa pero se proporcionan instrucciones antes de los botones: "Presione Ctrl+M para Salir". La tecla Escape está programada para funcionar, y las instrucciones son accesibles mediante teclado. Eso aprueba.
Otro ejemplo coloca las instrucciones dentro de la propia trampa. Un párrafo dentro de la región atrapada dice "Presione Ctrl+M para Salir". Eso también aprueba.
Lo que falla es tener instrucciones que no funcionan, o no tener instrucciones en absoluto. El W3C muestra un ejemplo fallido donde las instrucciones dicen "Presione Ctrl+M para Salir" pero el script no implementa realmente esa combinación de teclas. El usuario lee el texto de ayuda, sigue las instrucciones y no sucede nada. Eso es un fallo.
El caso de negocio más allá de las demandas
El riesgo legal es real. Pero la accesibilidad del teclado es importante por razones más allá de evitar litigios.
Alrededor del 20% de los usuarios en todo el mundo viven con discapacidades que influyen en cómo interactúan con la web. Eso incluye personas con discapacidades motoras, usuarios ciegos que dependen de lectores de pantalla y personas con baja visión que encuentran difícil seguir el puntero del ratón.
También hay circunstancias temporales. Usuarios con brazos rotos, brotes de síndrome del túnel carpiano, o aquellos que trabajan en espacios reducidos pueden depender temporalmente de la navegación por teclado.
Y están los usuarios avanzados. Muchos desarrolladores y usuarios técnicos prefieren la navegación por teclado por eficiencia. Un mal soporte del teclado frustra a estos usuarios y aumenta el tiempo de finalización de tareas.
Asombrosamente, el 25% de todos los problemas de accesibilidad digital están relacionados con un mal soporte del teclado. Corregir las trampas de teclado aborda una parte significativa de las barreras de accesibilidad.
Correcciones comunes para trampas comunes
La mayoría de las trampas de teclado tienen soluciones directas una vez que sabes dónde buscar.
Diálogos modales: Implementa el patrón de atrapamiento de foco mostrado anteriormente. Asegúrate de que Escape cierre el diálogo. Devuelve el foco al elemento desencadenante cuando el diálogo se cierre.
Menús desplegables personalizados: No los construyas con divs. Usa HTML semántico con atributos ARIA adecuados si es necesario. Asegúrate de que las teclas de flecha naveguen por las opciones. Asegúrate de que Tab salga del menú cuando esté cerrado.
Embebidos de terceros: Pruébalos a fondo. Si un embebido atrapa el foco, busca comandos de teclado documentados. Si no existen, considera reemplazar el embebido o añadir instrucciones visibles antes de que los usuarios entren en él.
Manejadores de eventos que roban el foco: Verifica cualquier JavaScript que llame a .focus() en un evento blur. Los ejemplos del W3C muestran este patrón:
javascript
<button onblur="setTimeout(() => this.focus(), 10)">
Cualquier código que vuelva a enfocar un elemento cuando pierde el foco crea una trampa. Elimínalo.
Valores positivos de tabindex: Los valores positivos de tabindex crean un orden de foco impredecible. Usa elementos HTML semánticos que son naturalmente enfocables y siguen el orden del DOM. Para elementos personalizados, usa tabindex="0" para incluirlos en el orden natural.
El problema de las superposiciones
Algunas empresas venden superposiciones de accesibilidad que afirman corregir automáticamente las trampas de teclado. No lo hacen.
Las superposiciones funcionan inyectando JavaScript que intenta modificar el comportamiento después de que la página se carga. No pueden corregir problemas estructurales como la falta de manejadores de teclado. A menudo entran en conflicto con la propia tecnología de asistencia de los usuarios. Y crean la ilusión de accesibilidad sin lograrla realmente.
Si confías en una superposición para corregir las trampas de teclado, prueba tu sitio con un teclado. Retira tu ratón. Intenta navegar. Es probable que descubras que las trampas siguen ahí.
Qué significa el caso Colgate-Palmolive
La demanda de Monique Reid contra Colgate-Palmolive es típica. Alega que el sitio web discrimina a los consumidores con discapacidad visual al mantener barreras que impiden el acceso con lectores de pantalla y la navegación por teclado.
El caso está en el Condado de Kings, Nueva York, que es una jurisdicción activa para demandas por ADA. La demandante está representada por Shaked Law Group, que presenta muchas de estas demandas.
El resultado dependerá de si Colgate-Palmolive puede demostrar que su sitio no atrapa a los usuarios de teclado. Si un experto del demandante puede demostrar que el foco se atasca en widgets, modales o componentes personalizados, la empresa enfrenta responsabilidad.
La ADA en sí misma permite medidas cautelares, lo que significa que se podría ordenar a Colgate-Palmolive que arregle su sitio. Pero la ley del estado de Nueva York permite daños y perjuicios. La demanda incluye reclamaciones por discriminación por discapacidad bajo la ley estatal.
Lo que debes hacer ahora
Prueba tu sitio con un teclado hoy. Desconecta tu ratón. Comienza en la barra de direcciones. Presiona Tab a través de cada página.
Presta atención a estos problemas específicos:
- Elementos omitidos: Si no puedes alcanzar algo con Tab, es inaccesible.
- Foco invisible: Si no puedes ver dónde estás, estás perdido.
- Foco atrapado: Si entras en una sección y no puedes salir, tienes una trampa.
- Falta de rutas de escape: Si se abre un modal y Escape no lo cierra, los usuarios quedan atrapados.
- Mala gestión del foco: Si el foco no regresa al desencadenante después de que se cierra un modal, los usuarios pierden el contexto.
Documenta lo que encuentres. Arregla las trampas primero. Son violaciones de Nivel A, lo que significa que fallar en ellas implica fallar en la accesibilidad básica.
La técnica G21 del W3C proporciona un procedimiento de prueba simple. Navega con Tab por el contenido de principio a fin. Verifica que el foco del teclado no quede atrapado en ningún contenido. Si el foco parece atrapado, verifica que la información de ayuda explique cómo salir y que se pueda acceder a ella mediante teclado.
Eso es todo. No se requieren herramientas complejas. Solo un teclado y atención.
La conclusión
Monique Reid demandó a Colgate-Palmolive el 2 de febrero de 2026, alegando barreras de navegación por teclado. No es la primera ni será la última.
Las trampas de teclado son un desencadenante oculto de demandas porque son fáciles de encontrar e imposibles de defender. Cuando el abogado de un demandante navega con Tab por tu sitio y se queda atrapado, tiene evidencia. Cuando un usuario de lector de pantalla encuentra un widget del que no puede escapar, tiene una historia.
La solución es directa. Prueba con un teclado. Encuentra las trampas. Corrige el código. Documenta tu trabajo. No es caro. No es complicado. Es simplemente necesario.
El sesenta y ocho por ciento de los usuarios de lectores de pantalla encuentran estos problemas mensualmente. El veinticinco por ciento de todos los problemas de accesibilidad están relacionados con el teclado. Siete millones de estadounidenses no pueden usar un ratón.
Tu sitio debería funcionar para ellos. Si no es así, una demanda podría ser el menor de tus problemas. El costo real son los usuarios que estás excluyendo cada día.
Comments (0)
No comments yet.