Navegación por Teclado: Haciendo Tu Sitio Web Usable Sin Ratón

Introducción

La navegación por teclado es la capacidad de usar un sitio web solo con el teclado—sin ratón, touchpad o pantalla táctil requeridos. Esto no es solo conveniencia; es un requisito fundamental de accesibilidad. WCAG 2.1.1 exige que toda la funcionalidad debe estar disponible desde un teclado, haciendo este uno de los criterios de accesibilidad más críticos.

Millones de usuarios dependen de la navegación por teclado: personas con discapacidades motoras que no pueden usar un ratón, usuarios ciegos que navegan con lectores de pantalla, usuarios avanzados que prefieren atajos de teclado, y cualquiera con una lesión temporal que afecte el uso del ratón.

Quién Necesita Navegación por Teclado

Usuarios Principales

1. Usuarios con discapacidades motoras - Pueden usar dispositivos de entrada alternativos que emulan teclados
2. Usuarios ciegos - Los lectores de pantalla dependen de la navegación por teclado
3. Usuarios con baja visión - A menudo combinan teclado con magnificación de pantalla
4. Lesión por esfuerzo repetitivo - El teclado puede ser menos doloroso que el ratón
5. Usuarios avanzados - Prefieren atajos de teclado por eficiencia

Dispositivos de Entrada Alternativos Comunes

Dispositivo	Función	Emula
Dispositivo de conmutación	Uno o múltiples interruptores para entrada	Teclas de teclado
Sip-and-puff	Entrada controlada por respiración	Teclado/ratón
Seguimiento ocular	Selección basada en mirada	Ratón/teclado
Control por voz	Comandos de voz	Teclado/ratón
Puntero de cabeza	Seguimiento del movimiento de la cabeza	Ratón

Todos estos dispositivos finalmente funcionan a través de interacción de teclado, haciendo la accesibilidad de teclado la base para soporte de dispositivos más amplio.

Operaciones Esenciales de Teclado

Teclas de Navegación Estándar

Tecla	Función
Tab	Mover al siguiente elemento enfocable
Shift + Tab	Mover al elemento enfocable anterior
Enter	Activar enlaces y botones
Espacio	Activar botones, alternar checkboxes
Teclas de flecha	Navegar dentro de componentes (menús, tabs, grillas)
Escape	Cerrar diálogos, cancelar operaciones
Home/End	Saltar al primer/último elemento en listas

Requisitos de Teclado WCAG

Criterio	Nivel	Requisito
2.1.1 Teclado	A	Toda funcionalidad accesible vía teclado
2.1.2 Sin Trampa de Teclado	A	El foco siempre puede moverse fuera de cualquier elemento
2.1.4 Atajos de Tecla de Carácter	A	Los atajos de una sola tecla pueden desactivarse/remapearse
2.4.3 Orden del Foco	A	La secuencia de foco debe ser lógica

Problemas Comunes de Accesibilidad de Teclado

1. Elementos Interactivos No Enfocables

<!-- MAL: div usado como botón - no accesible por teclado -->
<div onclick="submitForm()">Enviar</div>

<!-- BIEN: Botón nativo - accesible por teclado por defecto -->
<button type="submit">Enviar</button>

<!-- ACEPTABLE: div con ARIA y tabindex apropiados -->
<div role="button" tabindex="0" onclick="submitForm()" onkeydown="handleKey(event)">
  Enviar
</div>

2. Trampas de Teclado

// MAL: Modal que no puede cerrarse con teclado
modal.addEventListener('keydown', (e) => {
  e.preventDefault(); // ¡Atrapa todas las teclas!
});

// BIEN: Permitir Escape para cerrar, Tab para ciclar
modal.addEventListener('keydown', (e) => {
  if (e.key === 'Escape') closeModal();
  if (e.key === 'Tab') handleFocusTrap(e);
});

3. Skip Links Faltantes

<!-- MAL: Sin forma de saltar la navegación -->
<nav>
  <!-- 50 enlaces de navegación -->
</nav>
<main>Contenido aquí</main>

<!-- BIEN: Skip link al inicio -->
<a href="#main-content" class="skip-link">Saltar al contenido principal</a>
<nav>
  <!-- Enlaces de navegación -->
</nav>
<main id="main-content">Contenido aquí</main>

4. Orden de Foco Ilógico

<!-- MAL: El orden visual no coincide con el orden del DOM -->
<div style="display: flex; flex-direction: row-reverse;">
  <button>Tercero visualmente, primero en DOM</button>
  <button>Segundo visualmente y en DOM</button>
  <button>Primero visualmente, tercero en DOM</button>
</div>

<!-- El orden de Tab será opuesto al orden visual -->

5. Interacciones Solo por Hover

/* MAL: El menú solo se muestra en hover */
.dropdown-menu {
  display: none;
}
.dropdown:hover .dropdown-menu {
  display: block;
}

/* BIEN: También responde al foco */
.dropdown:hover .dropdown-menu,
.dropdown:focus-within .dropdown-menu {
  display: block;
}

Probando Navegación por Teclado

Prueba Manual Rápida

1. Desconecta tu ratón o déjalo a un lado
2. Presiona Tab - ¿El foco se mueve a través de todos los elementos interactivos?
3. Verifica visibilidad del foco - ¿Puedes ver dónde estás?
4. Prueba activación - ¿Enter y Espacio funcionan correctamente?
5. Busca trampas - ¿Siempre puedes navegar con Tab fuera de cualquier elemento?
6. Verifica modales - ¿Puedes cerrarlos con Escape?

Qué Verificar en Cada Página

• [ ] Todos los enlaces pueden alcanzarse y activarse
• [ ] Todos los botones pueden alcanzarse y activarse
• [ ] Todos los campos de formulario pueden llenarse y enviarse
• [ ] Todos los menús/dropdowns pueden abrirse y navegarse
• [ ] Todos los modales pueden abrirse y cerrarse
• [ ] El orden del foco coincide con el orden visual/de lectura
• [ ] No existen trampas de teclado
• [ ] Los skip links están disponibles

Áreas Problemáticas Comunes

1. Dropdowns personalizados - A menudo les falta soporte de teclado
2. Carruseles/sliders - Pueden atrapar el foco o saltar controles
3. Diálogos modales - Necesitan trampa de foco y Escape para cerrar
4. Mega menús - Patrones de navegación complejos
5. Reproductores de video - Los controles personalizados a menudo son inaccesibles
6. Elementos canvas - Necesitan alternativas de teclado

Elementos Nativos vs Personalizados

Usar Elementos Nativos Cuando Sea Posible

Elemento Nativo	Alternativa Personalizada	Teclado Incorporado
<button>	<div role="button">	✅ Nativo lo tiene
<a href>	<span onclick>	✅ Nativo lo tiene
<select>	Dropdown personalizado	✅ Nativo lo tiene
<input type="checkbox">	Toggle personalizado	✅ Nativo lo tiene
<details>	Acordeón personalizado	✅ Nativo lo tiene

Cuando Se Necesitan Componentes Personalizados

Si debes usar componentes personalizados, implementa:

1. tabindex=“0” - Hace el elemento enfocable
2. Role - Indica a los lectores de pantalla qué es
3. Manejadores de teclado - Enter, Espacio, teclas de flecha según corresponda
4. Gestión de foco - Mover el foco cuando sea necesario

Correcciones Rápidas

Haciendo un Div Clickeable y Accesible por Teclado

<!-- Antes: Solo ratón -->
<div onclick="doAction()">Haz click</div>

<!-- Después: Ratón y teclado -->
<div
  role="button"
  tabindex="0"
  onclick="doAction()"
  onkeydown="if(event.key==='Enter'||event.key===' ')doAction()"
>
  Haz click
</div>

<!-- Mejor: Solo usa un botón -->
<button onclick="doAction()">Haz click</button>

Agregando un Skip Link

<!-- Agregar como primer elemento enfocable -->
<a href="#main" class="skip-link">Saltar al contenido principal</a>

<!-- Estilo para mostrar solo en foco -->
<style>
.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  padding: 8px;
  background: #000;
  color: #fff;
  z-index: 100;
}
.skip-link:focus {
  top: 0;
}
</style>

Resumen de Mejores Prácticas

Hacer	No Hacer
Usar elementos HTML nativos	Construir controles personalizados innecesariamente
Probar sin ratón	Asumir que probar con ratón cubre teclado
Proporcionar skip links	Forzar a usuarios a través de toda la navegación
Hacer el foco visible	Eliminar indicadores de foco
Usar orden de tab lógico	Usar valores de tabindex positivos
Soportar Enter y Espacio	Requerir hover para funcionalidad

Artículos Relacionados

• Guía de Implementación de Navegación por Teclado - Patrones detallados
• Guía de Indicadores de Foco - Haciendo el foco visible
• Hub de Cumplimiento WCAG - Todos los evaluadores de accesibilidad

---

Referencias

1. W3C - WCAG 2.2 SC 2.1.1 Keyboard
2. W3C - WCAG 2.2 SC 2.1.2 No Keyboard Trap
3. WebAIM - Keyboard Accessibility
4. MDN - Keyboard-navigable JavaScript widgets