Accesibilidad por teclado y foco: diseñar para quienes no usan ratón

Quién depende del teclado — y por qué es la ley

Un grupo más grande del que la mayoría de los equipos imagina. La accesibilidad por teclado importa para personas con discapacidad motriz, personas con discapacidad visual, quienes tienen lesiones por esfuerzo repetitivo, y cualquiera con una lesión temporal que impida usar el ratón — más quienes usan dispositivos de conmutación, lectores de pantalla, y los usuarios avanzados que simplemente lo prefieren (UXPin, 2026). Las cifras no son pequeñas: se estima que 2,5 millones de estadounidenses tienen discapacidades motrices que impiden usar el ratón, y la sola ausencia de indicadores de foco vuelve los sitios inutilizables para los cerca de 8 millones que dependen de la navegación por teclado (DEV, 2026; TestParty, 2026). Si tu sitio no se puede operar por completo con el teclado, los estás excluyendo por completo.

También es un requisito legal, no una cortesía. La operación por teclado está exigida por el Título III de la ADA para los negocios privados, la Sección 508 para las agencias federales, y legislación similar en todo el mundo, y los tribunales han fallado repetidamente que los sitios deben ser plenamente usables por teclado (UXPin, 2026; Level Access, 2026). Es, según la mayoría, una de las partes más importantes y más descuidadas de la accesibilidad — lo que la vuelve un lugar donde acertar con el oficio es una ventaja real.

¿Qué exige WCAG en realidad?

Un puñado de criterios, todos bajo el principio “Operable”, lo cubren. Los fundamentales son el 2.1.1 Teclado, que exige que toda la funcionalidad sea operable por teclado, y el 2.1.2 Sin trampa de teclado, que exige que el foco siempre se pueda sacar de cualquier componente — ambos de Nivel A (DEV, 2026). Sobre esos se sientan el 2.4.1 Evitar bloques (un enlace de salto que pasa la navegación repetida), el 2.4.3 Orden del foco (el foco sigue una secuencia lógica y predecible), y el 2.4.7 Foco visible (un indicador de foco visible), este último de Nivel AA (Line25, 2026).

WCAG 2.2 reforzó esta área en concreto. Añadió el 2.4.11 Foco no oscurecido (mínimo) en Nivel AA, que exige que un componente enfocado no quede completamente oculto por contenido del autor como cabeceras fijas o banners de cookies, y un criterio de Apariencia del foco que describe el tamaño y el contraste mínimos del indicador — un área de al menos un perímetro de 2px del componente y un ratio de contraste de 3:1 entre los estados enfocado y sin enfocar (Line25, 2026; GetWCAG, 2026). En términos simples: todo debe funcionar por teclado, el orden debe tener sentido, el foco debe ser visible, y nada puede ocultarlo ni atraparlo.

El pecado capital: quitar el indicador de foco

Hay un error que hace más daño que cualquier otro, y es deprimentemente común. Los indicadores de foco suelen ser lo primero que los diseñadores quitan porque sienten que chocan con el diseño — y quitarlos sin reemplazo vuelve el sitio inutilizable para los usuarios de teclado, que pierden todo sentido de dónde están, como quitar todas las señales de tráfico de una ciudad (Webability, 2026). La escala es llamativa: el análisis de WebAIM de un millón de páginas de inicio halló que el 78% tenía problemas detectables de indicador de foco (TestParty, 2026).

El código culpable es de una línea — *:focus { outline: none }, o lo mismo aplicado a botones, enlaces y campos — y la regla es simple: nunca quites el contorno de foco por defecto sin proveer un reemplazo igual o mejor (TestParty, 2026). El contorno por defecto del navegador está exento de los requisitos de contraste, pero en el momento en que lo sobrescribes te vuelves responsable de que tu versión sea visible y suficientemente contrastante (Vispero, 2026). Quitarlo no es una decisión de diseño; es un defecto.

Cómo estilizar un indicador de foco que se vea bien

La objeción de que los anillos de foco arruinan el diseño tiene una respuesta limpia: :focus-visible. Esta pseudoclase CSS aplica los estilos de foco solo cuando el navegador juzga que el usuario los necesita —durante la navegación por teclado o el uso de tecnología asistiva— mientras suprime el anillo en los clics normales de ratón, lo que resuelve la vieja tensión entre la estética y la accesibilidad (Vispero, 2026). El patrón es resetear el predeterminado y aplicar tu propio indicador:

button:focus { outline: none; }
button:focus-visible {
  outline: 2px solid #1E90FF;
  outline-offset: 2px;
  box-shadow: 0 0 0 2px rgba(30, 144, 255, 0.3);
}

El estilo en sí debe seguir unas pocas reglas: un ratio de contraste de al menos 3:1 entre los estados enfocado y sin enfocar, un contorno de al menos 2px, indicadores consistentes en elementos similares, y un color de foco que funcione en todos los fondos sobre los que el componente pueda sentarse — claro, oscuro o imagen (UXPin, 2026; TestParty, 2026). El color de foco no tiene que coincidir con tu marca exactamente; muchos sistemas de diseño usan un único acento de alto contraste para el foco en todas partes, lo que es más fácil de mantener visible y consistente.

Acierta con el orden de tabulación

El orden del foco se trata de previsibilidad: cuando alguien tabula por la página, la secuencia debe coincidir con el orden visual de lectura para que la experiencia siga siendo lógica (Vispero, 2026). Los componentes que aparecen en cierto orden visual deben recibir el foco en ese mismo orden — el criterio WCAG 2.4.3 existe justo para prevenir los saltos desorientadores que ocurren cuando no es así (Line25, 2026).

La forma de acertar con esto es en su mayoría no pelearlo. El orden de tabulación sigue el orden del DOM, así que un orden de fuente sensato y centrado en el contenido te da un orden de tabulación sensato gratis — lo que es un beneficio silencioso de una página semántica hecha a mano frente a una disposición armada fuera de orden y reposicionada con CSS. Evita los valores de tabindex positivos como tabindex="2", que anulan el orden natural y casi siempre crean confusión; usa tabindex="0" solo para añadir un elemento interactivo a medida al flujo natural, y tabindex="-1" para volver algo enfocable por script pero no parte de la secuencia de tabulación (Webability, 2026).

Modales, menús y trampas de teclado

Los componentes dinámicos son donde más a menudo se rompe el acceso por teclado. Una trampa de teclado ocurre cuando un usuario puede tabular hacia un componente pero no puede tabular fuera de él, y los diálogos modales son el infractor clásico (Level Access, 2026). Una gestión correcta del foco de un modal tiene tres partes: atrapar el foco dentro del diálogo para que Tab y Shift+Tab circulen en él, dejar que Escape lo cierre, y devolver el foco al elemento que lo abrió cuando se cierra (UXPin, 2026). Los otros componentes que la gente olvida —desplegables, deslizadores, carruseles, selectores de fecha— necesitan cada uno su propio manejo de teclas para Tab, Enter y Espacio, las flechas, y Escape (Level Access, 2026).

Aquí también un antipatrón causa la mayoría de los problemas: construir un control interactivo a partir de un <div> simple con un manejador de clic. Un <div onClick> es invisible para el teclado —no se puede tabular hacia él y Enter no hace nada— así que en el momento en que recurres a un div como botón, has creado un control inaccesible que necesita un role, un tabindex y manejadores de teclas manuales para repararlo. El camino más barato casi siempre es usar el elemento real en su lugar.

Enlaces de salto y gestión del foco

Los usuarios de teclado recorren una página de forma lineal, así que repetir toda tu navegación en cada página significa tabular más allá de ella cada vez. Un enlace de salto lo arregla: un enlace de “Saltar al contenido principal” que está oculto visualmente hasta que recibe el foco, y entonces lleva al usuario más allá de la navegación (Line25, 2026). Son unas pocas líneas de código:

<a href="#main-content" class="skip-link">Saltar al contenido principal</a>
<nav><!-- navegación --></nav>
<main id="main-content" tabindex="-1"><!-- contenido --></main>

.skip-link { position: absolute; top: -40px; left: 0; padding: 8px 16px;
  background: #000; color: #fff; z-index: 9999; }
.skip-link:focus { top: 0; }

Más allá del enlace de salto, gestionar el foco de forma deliberada importa en las aplicaciones dinámicas. Cuando el contenido cambia —se abre un diálogo, o una aplicación de una sola página intercambia la vista— mover el foco a la nueva región, a veces poniendo tabindex="-1" en un encabezado o en el elemento <main> y enfocándolo, mantiene orientados a los usuarios de teclado y de lector de pantalla (Vispero, 2026). La regla inversa también importa: no vuelvas enfocables los elementos no interactivos, porque el foco es una señal de que algo es interactivo, y ponerlo en texto plano confunde.

El HTML semántico hace casi todo el trabajo

La verdad alentadora es que el HTML nativo es accesible por teclado por defecto. Un <button>, <a href> o <input> real se puede tabular, activar y operar sin una sola línea de JavaScript extra, porque el navegador ya implementa todo ese comportamiento (UXPin, 2026). Solo necesitas roles ARIA y manejo manual de teclas cuando construyes un control a medida que la plataforma no provee — e incluso entonces, la meta es reproducir lo que el elemento nativo habría hecho gratis.

Por esto la accesibilidad por teclado va tan de la mano con cómo se construye un sitio. Las fallas se agrupan en torno a los widgets de JavaScript a medida, los contornos quitados, el tabindex positivo y el contenido pintado en un orden que no coincide con el DOM — justo los patrones que los creadores cargados de plantillas y las aplicaciones de una sola página tienden a producir. Es también por lo que un overlay de accesibilidad no puede arreglarlo de verdad: un script que pega estilos de foco sobre una página terminada no puede darle a un control basado en <div> el comportamiento de teclado real que nunca tuvo, que es el mismo punto que hace nuestra guía sobre por qué los overlays son una trampa legal. La operabilidad tiene que estar incorporada.

Cómo probarlo: aparta el ratón

La prueba definitiva no necesita herramientas especiales — solo tu teclado. Deja el ratón a un lado y tabula con Tab y Shift+Tab por toda la página, confirmando que cada elemento interactivo es alcanzable, que Enter y Espacio activan los controles, que las flechas funcionan dentro de los widgets compuestos, y que Escape cierra las superposiciones (UXPin, 2026). A medida que avanzas, revisa que el foco sea visible en cada parada, que el orden siga la disposición visual, que nada te atrape, y que el foco vuelva al disparador después de que un modal se cierra — y si usas Safari en macOS, activa primero el ajuste que deja a Tab alcanzar cada control (Level Access, 2026).

Las herramientas automáticas tienen un papel, pero limitado aquí: los escáneres detectan cerca del 40% de los problemas de teclado, en su mayoría tabindex ausente, roles incorrectos y estilos de foco ausentes, mientras que los patrones de interacción que más importan solo los puede encontrar una persona tabulando (DEV, 2026). Así es exactamente como construimos y revisamos nuestro propio trabajo — marcado semántico, un orden de fuente lógico, un indicador :focus-visible visible en el sistema de diseño, y un recorrido de teclado en cada flujo interactivo. Junto con la checklist WCAG 2.2 y la guía de contraste, es la mitad operable de la misma disciplina que cubre por completo nuestro pilar sobre si la accesibilidad es obligatoria: acierta en la fuente, y la página funciona para todos.