WCAG 2.1.1: Teclado

Qué significa esta regla

WCAG 2.1.1 (Teclado) exige que cada parte de la funcionalidad en una página web o aplicación sea operable mediante una interfaz de teclado. Esto significa que si una persona usuaria puede hacer clic en un botón, arrastrar un elemento, pasar el cursor para revelar un menú o interactuar con cualquier otro elemento usando un ratón, debe poder realizar exactamente la misma acción usando solo entradas de teclado — normalmente las teclas Tab, Shift+Tab, Enter, Space y las flechas.

El criterio se aplica a todos los elementos interactivos: enlaces, botones, controles de formulario, widgets personalizados, cuadros de diálogo modales, menús desplegables, acordeones, carruseles, selectores de fecha, interfaces de arrastrar y soltar, interacciones basadas en canvas y cualquier otro componente que responda a la entrada de la persona usuaria. Si el contenido requiere que la persona usuaria realice un trazo de dibujo (donde el trazo en sí es la entrada, no solo el punto final), esa es la única excepción reconocida formalmente en WCAG. Fuera de esa excepción limitada, cualquier otra pieza de funcionalidad debe ser accesible mediante teclado.

Un aprobado significa que una persona que solo usa el teclado puede llegar a cada elemento interactivo mediante navegación con Tab o teclas de flecha, activarlo con Enter o Space y completar la acción prevista sin necesitar un ratón en ningún momento. Un fallo se produce cuando se cumple cualquiera de las siguientes condiciones: un elemento interactivo no recibe foco en absoluto; recibe foco pero el elemento no puede activarse; una función se desencadena exclusivamente por un evento de ratón como onmouseover u ondblclick sin un equivalente de teclado; o un contenedor desplazable no es alcanzable mediante teclado, atrapando contenido en su interior.

Es importante distinguir WCAG 2.1.1 de WCAG 2.1.2 (Sin trampa de teclado). El criterio 2.1.1 garantiza que las personas usuarias de teclado puedan llegar a y usar todo; el criterio 2.1.2 garantiza que las personas usuarias de teclado nunca queden atrapadas dentro de un componente. Ambos deben cumplirse para lograr la conformidad completa de Nivel A.

Por qué es importante

La accesibilidad mediante teclado no es una preocupación marginal. Se estima que 1 de cada 4 personas adultas en Estados Unidos vive con algún tipo de discapacidad, y las discapacidades motoras — incluidas afecciones como la enfermedad de Parkinson, la esclerosis múltiple, lesiones de la médula espinal, lesiones por esfuerzo repetitivo (RSI), diferencias en las extremidades y temblores — con frecuencia impiden que las personas usuarias operen un ratón estándar o una pantalla táctil. Estas personas dependen por completo de teclados, controles por pulsadores, dispositivos de soplo y succión, punteros de cabeza u otras tecnologías de apoyo que en última instancia emulan la entrada de teclado a nivel del sistema operativo.

Las personas ciegas y con baja visión que dependen de lectores de pantalla como NVDA, JAWS o VoiceOver navegan completamente mediante el teclado. Si un elemento no es alcanzable con el teclado, el lector de pantalla nunca lo anunciará, lo que hace que el contenido sea completamente invisible para esa persona usuaria. Según la Organización Mundial de la Salud, al menos 2.2 mil millones de personas en todo el mundo tienen algún tipo de discapacidad visual de cerca o de lejos.

Considere un escenario concreto: una persona usuaria con artritis reumatoide avanzada en ambas manos visita una página de pago de comercio electrónico. El selector de método de pago personalizado del sitio está implementado como una serie de elementos <div> con estilo que responden solo a clics de ratón. La persona puede usar Tab para llegar al contenedor, pero ninguna opción individual recibe foco y al presionar Enter no ocurre nada. No puede completar la compra. Esto no es una molestia menor: es una exclusión completa de una transacción comercial y representa tanto un riesgo legal como un escenario de pérdida significativa de ingresos para la empresa.

Más allá de la discapacidad, la accesibilidad mediante teclado beneficia a personas usuarias avanzadas que prefieren atajos de teclado por rapidez, a personas usuarias en entornos empresariales o gubernamentales donde el uso del ratón está restringido por políticas, y a personas usuarias con dispositivos de entrada no estándar. También se correlaciona positivamente con estructuras HTML limpias y semánticas que los motores de búsqueda analizan de forma más fiable, contribuyendo a un mejor rendimiento SEO y a la mantenibilidad a largo plazo de la base de código.

Reglas relacionadas de Axe-core

• scrollable-region-focusable: Esta regla comprueba si cualquier elemento que tiene contenido desbordado (es decir, que es desplazable) es alcanzable mediante teclado. Cuando un contenedor tiene propiedades CSS como overflow: auto o overflow: scroll, las personas usuarias videntes que usan ratón pueden desplazarlo con la rueda del ratón o el trackpad. Las personas usuarias de teclado, sin embargo, deben poder usar Tab para entrar en el contenedor o usar las teclas de flecha para desplazarlo. La regla marca las regiones desplazables que no tienen atributo tabindex ni ningún elemento hijo naturalmente enfocable, lo que significa que una persona que solo usa el teclado no tendría forma de acceder al contenido desbordado. La detección automatizada es fiable aquí porque axe puede inspeccionar los estilos calculados y el árbol DOM para identificar elementos con desbordamiento desplazable que carecen de capacidad de foco mediante teclado.
• server-side-image-map: Esta regla marca el uso de mapas de imagen del lado del servidor — elementos HTML <img> con el atributo ismap. Los mapas de imagen del lado del servidor envían las coordenadas de píxeles crudas de un clic de ratón al servidor para determinar qué enlace se activó. Debido a que la acción depende por completo de coordenadas de píxeles derivadas de un dispositivo apuntador, no existe un mecanismo equivalente de teclado. A diferencia de los mapas de imagen del lado del cliente (que usan elementos <map> y <area> y pueden hacerse accesibles mediante teclado), los mapas de imagen del lado del servidor son fundamentalmente incompatibles con la navegación solo con teclado. Axe marca cualquier elemento <img ismap> como un fallo de accesibilidad de teclado. La verificación manual debe confirmar si el mapa de imagen es la única forma de acceder a la navegación o funcionalidad subyacente.

Es fundamental entender que las herramientas automatizadas como axe-core solo pueden detectar un subconjunto de fallos de accesibilidad de teclado. Muchas infracciones requieren pruebas manuales porque implican escuchas de eventos JavaScript personalizados, gestión dinámica del foco o patrones de interacción complejos que el análisis estático no puede evaluar por completo. Por ejemplo, un botón implementado como un <div> con un listener de evento click puede recibir foco mediante tabindex='0' pero no responder a las pulsaciones de las teclas Enter o Space — un fallo que axe no siempre puede detectar sin ejecutar la interacción.

Cómo probar

1. Análisis automatizado con axe DevTools o Lighthouse: Instale la extensión de navegador axe DevTools para Chrome o Firefox. Navegue a la página que se va a probar y ejecute un análisis de página completa. Filtre los resultados por reglas etiquetadas con wcag2a y keyboard. Busque específicamente infracciones de scrollable-region-focusable y server-side-image-map. En Lighthouse (Chrome DevTools), ejecute una auditoría de Accesibilidad y revise la categoría "Keyboard". Tenga en cuenta que estas herramientas mostrarán fallos estructurales evidentes pero no detectarán todos los problemas de widgets personalizados.
2. Prueba manual de navegación con teclado: Desconecte o aparte el ratón por completo. Comenzando desde la barra de direcciones del navegador, presione Tab repetidamente para avanzar por todos los elementos enfocables de la página. Presione Shift+Tab para retroceder. Para cada elemento interactivo — enlaces, botones, campos de entrada, desplegables personalizados, modales, controles deslizantes — verifique que: (a) recibe un indicador de foco visible; (b) al presionar Enter o Space se activa como se espera; (c) cualquier cuadro de diálogo o panel resultante también puede navegarse y cerrarse mediante teclado. Use las teclas de flecha dentro de widgets que implementan patrones compuestos (menús, listas de pestañas, grupos de botones de opción, cuadros de lista).
3. Prueba con lector de pantalla + teclado con NVDA y Firefox: Inicie NVDA (gratuito, Windows) y abra Firefox. Use el Modo de exploración de NVDA (teclas de flecha) para leer la página e identificar todos los elementos interactivos. Cambie al Modo de foco (Insert+Space o automático en campos de formulario) para interactuar con los controles. Verifique que los widgets personalizados anuncian su rol, estado y nombre, y que toda la funcionalidad puede completarse sin ratón. Pruebe cualquier contenedor desplazable intentando entrar en él con Tab y usar las teclas de flecha para desplazarse.
4. Prueba con lector de pantalla con VoiceOver y Safari (macOS/iOS): Active VoiceOver (Command+F5 en macOS). Use VO+flecha derecha para navegar linealmente por la página. Use Tab para moverse entre elementos interactivos. Confirme que las regiones desplazables son alcanzables y que ninguna funcionalidad requiere un gesto de deslizamiento o interacción con puntero sin una alternativa accesible mediante teclado.
5. Prueba con JAWS y Chrome: Con JAWS en ejecución, abra Chrome y navegue a la página. Use el Cursor Virtual de JAWS para explorar el contenido y la tecla Tab para moverse entre elementos interactivos. Pruebe específicamente cualquier widget JavaScript personalizado — acordeones, carruseles, cuadros de diálogo modales, cuadros de selección personalizados — usando Tab para llegar a ellos e intentando su operación completa mediante teclado. Registre cualquier elemento que reciba foco pero no pueda activarse, o cualquier funcionalidad que solo sea alcanzable mediante pasar el ratón por encima.
6. Prueba específica de regiones desplazables: Identifique todos los contenedores de la página con barras de desplazamiento visibles o que contengan más contenido que su área visible. Intente entrar en cada contenedor con Tab. Si Tab no mueve el foco dentro del contenedor y no hay elementos hijos enfocables, es probable que el contenedor sea un fallo de accesibilidad de teclado. Intente presionar las teclas de flecha mientras el contenedor o un elemento cercano tiene el foco para ver si es posible desplazarse.

Cómo corregir

Escenario 1: Contenedor desplazable — Incorrecto

<!-- Scrollable div with no tabindex: keyboard users cannot scroll this content -->
<div style='height: 200px; overflow-y: auto;'>
  <p>Long list of terms and conditions text...</p>
  <p>More text that overflows the container...</p>
</div>

Escenario 1: Contenedor desplazable — Correcto

<!-- Adding tabindex='0' makes the container focusable so keyboard users
     can scroll it with arrow keys once it receives focus -->
<div
  tabindex='0'
  role='region'
  aria-label='Terms and Conditions'
  style='height: 200px; overflow-y: auto;'
>
  <p>Long list of terms and conditions text...</p>
  <p>More text that overflows the container...</p>
</div>

Escenario 2: Mapa de imagen del lado del servidor — Incorrecto

<!-- ismap sends pixel coordinates to the server — no keyboard equivalent exists -->
<a href='/map-handler'>
  <img src='navigation-map.png' ismap alt='Site navigation map' />
</a>

Escenario 2: Mapa de imagen del lado del servidor — Correcto

<!-- Replace with a client-side image map using <map> and <area> elements.
     Each <area> is focusable and activatable by keyboard. -->
<img
  src='navigation-map.png'
  alt='Site navigation map'
  usemap='#site-nav'
/>
<map name='site-nav'>
  <area shape='rect' coords='0,0,100,50' href='/home' alt='Home' />
  <area shape='rect' coords='100,0,200,50' href='/about' alt='About Us' />
  <area shape='rect' coords='200,0,300,50' href='/contact' alt='Contact' />
</map>

Escenario 3: Widget personalizado que usa solo eventos de ratón — Incorrecto

<!-- div acting as a button with only onclick: keyboard users pressing Enter
     or Space will get no response -->
<div onclick='submitForm()'>Submit Order</div>

Escenario 3: Widget personalizado que usa solo eventos de ratón — Correcto

<!-- Option A: Use a native <button> — it handles keyboard activation natively -->
<button type='submit' onclick='submitForm()'>Submit Order</button>

<!-- Option B: If a custom element is required, add tabindex, role, and
     a keydown listener for Enter (13) and Space (32) -->
<div
  role='button'
  tabindex='0'
  onclick='submitForm()'
  onkeydown='if(event.key==="Enter"||event.key===" "){submitForm();}'
>
  Submit Order
</div>

Escenario 4: Menú desplegable solo por hover — Incorrecto

<!-- Menu only appears on CSS :hover — keyboard focus on the parent
     does not reveal the submenu -->
<nav>
  <ul>
    <li class='has-dropdown'>
      <a href='/products'>Products</a>
      <ul class='dropdown'> <!-- only visible on :hover in CSS -->
        <li><a href='/products/a'>Product A</a></li>
        <li><a href='/products/b'>Product B</a></li>
      </ul>
    </li>
  </ul>
</nav>

Escenario 4: Menú desplegable solo por hover — Correcto

<!-- Use a button to toggle the dropdown and manage aria-expanded.
     CSS shows the submenu when the button has aria-expanded='true'.
     Keyboard users press Enter/Space on the button to open the menu. -->
<nav>
  <ul>
    <li class='has-dropdown'>
      <button
        aria-expanded='false'
        aria-controls='products-submenu'
        onclick='toggleMenu(this)'
      >
        Products
      </button>
      <ul id='products-submenu' hidden>
        <li><a href='/products/a'>Product A</a></li>
        <li><a href='/products/b'>Product B</a></li>
      </ul>
    </li>
  </ul>
</nav>

Errores comunes

• Usar onclick como único manejador de eventos en un elemento no nativo sin añadir un manejador correspondiente onkeydown o onkeyup — los clics de ratón disparan onclick pero la activación mediante teclado en un <div> o <span> no lo hace.
• Añadir tabindex='0' a un elemento interactivo personalizado pero olvidar añadir role='button' (o el rol apropiado), lo que significa que los lectores de pantalla no comunican el propósito del elemento a la persona usuaria.
• Construir navegación desplegable que depende exclusivamente de la pseudoclase CSS :hover sin un conmutador de teclado impulsado por JavaScript, lo que hace que los submenús sean invisibles e inalcanzables para las personas usuarias de teclado.
• Implementar interfaces de arrastrar y soltar — listas ordenables, tableros kanban, zonas de carga de archivos — sin un mecanismo alternativo accesible mediante teclado, como comandos de movimiento activados por teclado o un control de reordenación separado.
• Crear contenedores desplazables (como cuadros de términos de servicio, ventanas de chat o tablas de datos dentro de contenedores de altura fija) sin tabindex='0', lo que impide que las personas usuarias de teclado se desplacen para ver todo el contenido.
• Usar <img ismap> para componentes de navegación heredados de bases de código antiguas sin reemplazarlos por mapas de imagen del lado del cliente o enlaces de navegación estándar.
• Aplicar tabindex='-1' a elementos interactivos para eliminarlos del orden natural de Tab sin proporcionar una estrategia de gestión de foco programática, lo que da como resultado controles que son permanentemente inalcanzables mediante teclado.
• Disparar funcionalidad exclusivamente en eventos mouseenter, mouseleave o mousemove (tooltips, vistas previas, menús contextuales) sin alternativas equivalentes de eventos focus, blur o de teclado.
• Suponer que un cuadro de diálogo modal gestiona el foco automáticamente — no mover el foco al cuadro de diálogo cuando se abre y no devolver el foco al elemento que lo activó cuando se cierra, dejando a las personas usuarias de teclado desorientadas en la página.
• Establecer pointer-events: none en CSS en un elemento que debería ser accesible mediante teclado, lo que, aunque no afecta directamente al comportamiento del teclado, a menudo se combina con patrones de JavaScript que también bloquean la interacción mediante teclado.

Relación con la normativa de accesibilidad de Turquía

La Circular Presidencial 2025/10 de Turquía, publicada en el Boletín Oficial n.º 32933 el 21 de junio de 2025, establece requisitos obligatorios de accesibilidad web alineados con WCAG 2.1 Nivel AA. WCAG 2.1.1 (Teclado) es un criterio de Nivel A, lo que lo sitúa en el nivel de prioridad más alto de cumplimiento requerido. La conformidad de Nivel A es el mínimo absoluto — si un sitio incumple criterios de Nivel A, se considera no accesible independientemente de cualquier otra mejora realizada.

Según la circular, los plazos de cumplimiento se diferencian por tipo de entidad: se exige que las instituciones públicas y organismos gubernamentales logren la conformidad en un plazo de un año a partir de la fecha de publicación de la circular, mientras que las entidades del sector privado cubiertas por la regulación disponen de dos años para cumplirla.

Las entidades cubiertas por la Circular Presidencial 2025/10 incluyen una amplia sección de los servicios digitales turcos: plataformas de comercio electrónico, instituciones públicas y ministerios, bancos e instituciones financieras, hospitales y proveedores de servicios de salud, empresas de telecomunicaciones con 200,000 o más abonados, agencias de viajes autorizadas, empresas de transporte privadas y escuelas privadas autorizadas por el Ministerio de Educación Nacional (MoNE).

Para todas estas entidades, no cumplir con WCAG 2.1.1 significa que las personas usuarias que dependen del teclado — incluidas ciudadanas y ciudadanos con discapacidades motoras, personas mayores y personas usuarias de lectores de pantalla — no pueden acceder a sus servicios digitales principales. Esto constituye una infracción directa de la normativa. En términos prácticos, un sitio de comercio electrónico en el que el flujo de pago no puede completarse mediante teclado, o un portal de pacientes de un hospital en el que la reserva de citas requiere interacción con el ratón, estaría incumpliendo los requisitos de la circular.

Las organizaciones sujetas a la circular deberían realizar una auditoría de accesibilidad de teclado como primer paso en su programa de corrección de accesibilidad. Debido a que los fallos de WCAG 2.1.1 suelen ser arquitectónicos — arraigados en la elección de elementos HTML, patrones de vinculación de eventos y valores predeterminados del framework de componentes — su corrección puede requerir cambios a nivel de código más que simples ajustes de configuración. El SDK de superposición de Accsible puede ayudar a detectar y corregir brechas comunes de accesibilidad de teclado en la capa de JavaScript, pero los equipos también deberían aplicar correcciones estructurales en su código fuente para lograr una conformidad sólida y auditable que satisfaga la revisión regulatoria.