Volver a la guía

Grave WCAG 2.1 · 2.1.1 axe-core: scrollable-region-focusable

Navegación por teclado

¿Quién necesita la navegación por teclado?

La navegación por teclado no es solo para personas con discapacidad visual. La necesitan principalmente usuarios con discapacidad motriz —tremores, pérdida de movilidad de las manos, dificultades para controlar el ratón— que usan el teclado como dispositivo principal. También la usan personas que utilizan dispositivos de control alternativo (conmutadores, barras de jefe) que emiten pulsaciones de teclado.

El criterio WCAG 2.1.1 exige que todas las funcionalidades disponibles con ratón sean accesibles con teclado, sin excepciones para funciones que requieran un trayecto de ratón dependiente del camino.

Las teclas básicas de navegación

  • Tab: avanza al siguiente elemento interactivo (link, botón, campo de formulario).
  • Shift + Tab: retrocede al elemento anterior.
  • Enter / Espacio: activa el elemento que tiene el foco (botón, link, checkbox).
  • Flechas: navega dentro de componentes como menús desplegables, grupos de radio, pestañas.
  • Escape: cierra elementos como modales, menús desplegables, tooltips.

La prueba básica de teclado

Puedes hacer una prueba básica de accesibilidad de teclado en menos de 5 minutos:

  1. Abre tu web en un navegador.
  2. Cierra el ratón o apártalo.
  3. Pulsa Tab y observa qué elemento recibe el foco (tiene que ser visible).
  4. Continúa pulsando Tab por todos los elementos interactivos.
  5. Comprova que pots activar cada botó, link i camp de formulari.
  6. Comprueba que los menús desplegables se abren y se pueden navegar.
  7. Comprueba que los modales o popups se pueden cerrar con Escape.

El focus visible

Uno de los errores más habituales: el focus visible se elimina por razones estéticas. Muchos diseñadores y developers eliminan el outline del foco porque «queda feo». Pero sin indicador de focus, el usuario de teclado no sabe donde está en la página.

WCAG 2.4.7 exige que el focus del teclado sea siempre visible. Puedes personalizar el estilo del focus para integrarlo con el diseño, pero no puedes eliminarlo:

/* MAL: elimina el focus */
*:focus { outline: none; }

/* BÉ: personalitza el focus */
*:focus {
outline: 2px solid #a9552d;
outline-offset: 2px;
}

Zonas con scroll inaccesibles

La regla axe-core scrollable-region-focusable detecta un problema específico: zonas de la página que tienen scroll (overflow: auto o scroll) pero que no su accesibles por teclado porque no reciben focus.

Si una tabla de datos, un listado de elementos o una zona de contenido puede hacer scroll con el ratón pero no con el teclado, es un error de accesibilidad. La solución es añadir tabindex="0" al elemento para hacerlo focusable:

<div class="taula-scroll" tabindex="0">
<!-- contingut amb scroll horitzontal -->
</div>

Errores habituales en webs WordPress

Los errores de navegación por teclado más frecuentes en webs WordPress son: menús desplegables que se abren en hover pero no en focus de teclado, modales que no devuelven el foco al botón que les abrió al cerrarse, sliders y carruseles sin controles de teclado, y mapas integrados (Google Maps) sin alternativa accesible.

Con la herramienta de autoevaluación de webaccessible.cat puedes detectar automáticamente zonas con scroll no accesibles. Para los otros errores, la prueba manual con teclado es imprescindible.

Your content goes here. Edit or remove this text inline or in the module Content settings. You can also style every aspect of this content in the module Design settings and even apply custom CSS to this text in the module Advanced settings.

M