Cómo usar (y testear) una web solo con teclado: guía de accesibilidad

Si puedes hacer TODO en una web sin tocar el ratón, esa web no solo es “más accesible”: es más usable, más rápida y menos laberinto. Esta guía es práctica (modo Teclados Chulos): qué teclas mandan cuando navegas “keyboard-only” y cómo auditar una web en 3 minutos sin volverte loco.

Por qué “teclado-only” no es un capricho (y a quién ayuda)

La navegación solo con teclado es accesibilidad real. No es “nice to have”: para mucha gente es la única forma de usar una web sin depender de un ratón o trackpad.

• Personas ciegas o con baja visión (a menudo combinan teclado + lector de pantalla).
• Personas con movilidad reducida (usar mouse puede ser lento, doloroso o directamente imposible).
• Usuarios avanzados (si una web respeta teclado, se siente rápida y “pro”).
• Situaciones reales: trackpad muerto, mano lesionada, ratón sin pilas, portátil en una mesa minúscula…

Idea simple: si tu web solo funciona “bien” con ratón, alguien se queda fuera. Y si alguien se queda fuera, tu web también pierde conversiones.

Las teclas clave (y qué hacen de verdad)

Tab / Shift+Tab (foco)

Tab recorre los elementos “enfocables” (enlaces, botones, campos, selectores…). Shift + Tab va hacia atrás.

• Lo importante: el foco debe verse SIEMPRE (si no lo ves, estás jugando a “¿dónde está Wally?” con la accesibilidad).
• El orden importa: el foco debería seguir una lógica visual (de arriba a abajo, izquierda a derecha) y no saltar como un canguro.
• Tip para auditar: pulsa Tab desde el inicio y di en voz alta dónde estás. Si te pierdes tú, imagina quien depende 100% del teclado.

Extra: si al pulsar Shift 5 veces se abre una ventana rara, es Teclas pegajosas (Windows). Aquí tienes cómo desactivarlas: desactivar teclas pegajosas.

Enter / Espacio (activar)

En web, Enter y Espacio no siempre son intercambiables:

• Enlaces (<a href>): normalmente se activan con Enter.
• Botones (<button>): suelen activarse con Enter y Espacio.
• Checkbox / switches: Espacio suele alternar el estado (marcar/desmarcar).

Regla de oro: si algo es “clicable”, debería ser <button> o <a href>. Si es un <div> disfrazado… ya empezamos mal.

Esc (salir/cerrar)

Esc es el “botón de pánico” universal del teclado. Si abres un modal, un menú desplegable o un popup, Esc debería cerrarlo (y devolverte el foco al sitio correcto).

• Si Esc no hace nada, el usuario keyboard-only puede quedarse atrapado.
• Si al cerrar un modal el foco “desaparece”, la persona tiene que tabular a ciegas hasta reencontrarse.

Flechas (menús, listas, radios…)

Cuando el foco ya está dentro de un componente (un menú, un carrusel, un grupo de radios…), las ←→↑↓ suelen ser la forma esperada de moverse.

• Radios: flechas cambian la opción.
• Menús: flechas se mueven por opciones, Enter activa, Esc cierra.
• Selects / listas: flechas navegan; a veces Espacio abre.

---

Checklist de prueba en 3 minutos (modo auditor)

Este test es brutalmente simple: aparta el ratón. En serio. Déjalo lejos, como si fuese una galleta en dieta. Ahora:

1. Empieza arriba del todo y pulsa Tab 15–20 veces.
2. Abre navegación / menú (si hay hamburguesa, pruébala).
3. Abre un modal (login, newsletter, cookie banner… lo que sea).
4. Interactúa con un formulario (si hay: busca campos, errores, enviar).

¿Hay indicador de foco visible?

• ✅ Ves claramente dónde estás (borde/underline/fondo… lo que sea, pero visible).
• ❌ “He tabulado y no sé dónde estoy” = fallo serio.

Pista rápida: si en CSS alguien metió outline: none; “para que se vea más limpio”, ha roto el teclado. Limpio no es lo mismo que usable.

¿El orden de tab tiene sentido?

• ✅ Header → navegación → contenido → sidebar → footer (o similar).
• ❌ Saltos raros (del header al footer y luego al medio) = el orden DOM y el visual no se entienden.

¿Puedes abrir/cerrar modales y volver al sitio correcto?

• ✅ Al abrir, el foco entra al modal.
• ✅ Dentro del modal puedes llegar a todo (y salir con Esc o botón “Cerrar”).
• ✅ Al cerrar, el foco vuelve al botón/enlace que lo abrió.
• ❌ Si te quedas atrapado o el foco se pierde, la experiencia se rompe.

---

Errores típicos que rompen la experiencia (y cómo se arreglan)

“div clicable” sin teclado

El clásico: un <div> con onclick que funciona con ratón… pero no con teclado.

Arreglo pro: usa elementos nativos.

<!-- MAL -->
<div onclick="abrirMenu()">Abrir menú</div>

<!-- BIEN -->
<button type="button" onclick="abrirMenu()">Abrir menú</button>

Por qué: un <button> ya trae teclado, foco, roles y comportamiento esperado. No reinventes la rueda… que luego se cae.

tabindex mal usado

tabindex sirve, pero también es una trampa si se usa “a lo loco”.

• Bien: tabindex="0" para hacer enfocable un elemento custom (si de verdad no hay opción nativa).
• Peligro: tabindex="1", tabindex="2"… (orden artificial) suele crear un “tab order” que no coincide con lo visual.
• Mejor: arreglar el orden en el HTML (DOM) y luego maquetar con CSS.

Quitar el foco “porque queda feo”

Si el foco no se ve, el usuario no navega: adivina. Solución: define un estilo de foco visible.

/* Ejemplo simple: respeta :focus-visible */
:focus-visible {
  outline: 3px solid currentColor;
  outline-offset: 3px;
}

---

Mini-guía para equipos (dev/diseño): qué revisar antes de publicar

Checklist para diseño (UI/UX)

• ✅ El foco se ve en todos los componentes (incluidos links en cards, menús, carruseles, tabs).
• ✅ Los estados “hover” también tienen equivalente “focus”.
• ✅ Botones y enlaces tienen tamaño y separación decente (nada de objetivos microscópicos).
• ✅ Si hay “Skip link” (Saltar al contenido), no se esconde o queda ilegible.

Checklist para desarrollo

• ✅ Usa <button> / <a href> para interacción (evita divs clicables).
• ✅ No rompas el foco con outline: none sin alternativa.
• ✅ El orden del DOM es lógico (y el tab order acompaña).
• ✅ Modales: foco entra al abrir, no hay “keyboard trap”, se cierra con Esc y devuelve el foco al disparador.
• ✅ Componentes custom (menús, tabs, acordeones): siguen patrones de teclado esperables (flechas, Enter/Espacio, Esc).

Si solo haces UNA cosa: prueba tu web 3 minutos sin ratón antes de publicar. Es la auditoría más barata y con mejor ROI del planeta.

---

Conclusión

La navegación solo con teclado no es “una feature”: es un mínimo de calidad. Si tu web tiene foco visible, orden lógico y modales sin trampas, de repente se siente más profesional para TODOS.

Más: si quieres pulir tu “modo teclado”, empieza por aquí:
Tecla Tab y luego pasa por
Atajos de teclado más usados.

---

Preguntas frecuentes

¿Qué es la “navegación solo con teclado”?

Es poder usar una web sin ratón: moverte por enlaces y botones con Tab, activar con Enter/Espacio y cerrar cosas con Esc, sin quedarte atascado.

No veo el foco cuando tabulo, ¿qué pasa?

Normalmente el CSS lo está ocultando (por ejemplo con outline: none) o el estilo de foco no tiene contraste. Sin foco visible, la navegación keyboard-only se rompe.

¿Qué es el orden de tabulación?

Es el orden en el que el foco salta al pulsar Tab. Lo ideal es que siga la lógica visual y del contenido (no saltos aleatorios).

Me quedo atrapado en un popup/modal, ¿eso es un fallo?

Sí, suele ser un “keyboard trap”. Un modal accesible debe permitir salir (por ejemplo con Esc) y devolver el foco al elemento que lo abrió.

¿Enter y Espacio hacen lo mismo?

No siempre: Enter activa enlaces y botones; Espacio es clave para checkboxes y muchos botones. Por eso es importante usar elementos nativos (button/link).

También te puede interesar