WCAG 2.1.3: Teclado (Sin excepción)

Qué Significa Esta Regla

WCAG 2.1.3 — Teclado (Sin Excepción) es un criterio de conformidad de nivel AAA en WCAG 2.1 y 2.2 que amplía WCAG 2.1.1 (Teclado, Nivel A) eliminando todas las excepciones. Específicamente, establece: Toda la funcionalidad del contenido es operable a través de una interfaz de teclado sin requerir tiempos específicos para pulsaciones individuales. La diferencia crítica con 2.1.1 es la ausencia de la cláusula de excepción que exime la funcionalidad en la que la función subyacente requiere una entrada que depende de la trayectoria del movimiento de la persona usuaria, no solo de los puntos finales.

En 2.1.1, las personas desarrolladoras pueden excluir legítimamente de la compatibilidad con teclado funciones como lienzos de dibujo a mano alzada, herramientas de pintura basadas en gestos o interfaces de arrastre sensibles a la trayectoria, porque la trayectoria exacta del puntero de la persona usuaria determina el resultado. WCAG 2.1.3 elimina por completo esta excepción. Según este criterio, cada una de las funciones, incluidas las de dibujo, arrastre, gestos dependientes de la trayectoria y cualquier interacción que históricamente haya dependido del movimiento del puntero, debe ser accesible mediante teclado. Esto significa que las personas desarrolladoras deben proporcionar mecanismos alternativos de teclado (por ejemplo, una barra de herramientas accesible con herramientas de formas, modos de dibujo controlados por teclado o alternativas de entrada basadas en formularios) incluso para tareas a mano alzada o dependientes de la trayectoria.

Un aprobado requiere que cada operación en la página pueda iniciarse, navegarse y completarse usando solo el teclado. Esto incluye la gestión del foco, diálogos modales, reordenamiento mediante arrastrar y soltar, controles deslizantes personalizados, herramientas de dibujo en lienzo, interacciones con mapas, navegación de carruseles y controles de reproducción de video. No debe haber trampas de teclado (también cubiertas por 2.1.2), ninguna función que solo pueda activarse haciendo clic, pasando el cursor o usando gestos táctiles sin una ruta equivalente mediante teclado, y ninguna dependencia de trayectorias del puntero del ratón.

Se produce un fallo cuando cualquier funcionalidad —independientemente de lo específica o secundaria que pueda parecer— no puede alcanzarse o completarse solo con el teclado. Dado que este criterio no tiene excepciones, incluso una sola función no accesible por teclado constituye un fallo completo, lo que lo convierte en uno de los estándares más exigentes de WCAG.

Por Qué Importa

La accesibilidad mediante teclado es fundamental para las personas con discapacidades motoras que no pueden usar un dispositivo apuntador. Personas con afecciones como la enfermedad de Parkinson, cuadriplejia, parálisis cerebral, lesiones por esfuerzo repetitivo o diferencias en las extremidades suelen depender exclusivamente de un teclado físico, un dispositivo de conmutación, un controlador de soplo y succión o tecnología de seguimiento ocular que emula la entrada de teclado. Según la Organización Mundial de la Salud, aproximadamente 1,3 mil millones de personas en todo el mundo viven con alguna forma de discapacidad significativa, y las discapacidades motoras o físicas representan una parte sustancial de esa población. Solo en Turquía, los datos del Instituto de Estadística de Turquía (TÜİK) indican que más de 8,5 millones de personas declaran al menos una forma de limitación funcional.

Más allá de la discapacidad motora, la accesibilidad mediante teclado beneficia a las personas ciegas y con baja visión que navegan con lectores de pantalla como NVDA, JAWS o VoiceOver, los cuales dependen de comandos de teclado para recorrer e interactuar con el contenido web. Las personas con fotosensibilidad pueden evitar las pantallas táctiles, y las personas con discapacidades cognitivas suelen beneficiarse de la navegación predecible y lineal que proporciona la interacción mediante teclado.

Considere un escenario concreto del mundo real: una plataforma de diseño gráfico que ofrece una herramienta de dibujo vectorial a mano alzada. Bajo WCAG 2.1.1, esto podría estar exento porque la trayectoria del puntero define la forma. Bajo WCAG 2.1.3, la plataforma debe proporcionar una alternativa —quizás una biblioteca de formas, una serie de puntos de anclaje controlados por teclado o un editor de rutas SVG basado en texto— para que una persona con discapacidad motora pueda seguir creando ilustraciones vectoriales sin ratón. No hacerlo excluye a un segmento significativo de profesionales creativos que dependen del acceso solo por teclado.

Desde la perspectiva de usabilidad y SEO, las interfaces correctamente accesibles mediante teclado suelen presentar una gestión del foco más limpia, un orden de tabulación más lógico y jerarquías DOM bien estructuradas, todo lo cual contribuye a una mejor capacidad de rastreo y a una experiencia de usuario de mayor calidad para todas las personas, incluidas las usuarias avanzadas que prefieren atajos de teclado por rapidez.

Reglas Relacionadas de Axe-core

WCAG 2.1.3 requiere pruebas manuales. A diferencia de muchos criterios de WCAG, las herramientas automatizadas no pueden detectar de forma fiable infracciones de este criterio porque:

• La detección de funcionalidad dependiente de la trayectoria está más allá del análisis estático: Axe-core y Lighthouse inspeccionan el DOM en busca de patrones estructurales —tabindex ausente, atributos role faltantes o gestión de foco defectuosa—, pero no pueden simular que una persona usuaria intente cada función en una página y determinar si existe una alternativa mediante teclado. Puede haber un elemento canvas presente en el DOM sin atributos ARIA, y aun así una barra de herramientas accesible mediante teclado cercana puede satisfacer completamente 2.1.3. A la inversa, un botón aparentemente normal puede desencadenar una acción de JavaScript que a su vez lanza un widget solo para ratón, que las herramientas automatizadas nunca marcarían. La equivalencia lógica de las alternativas de teclado con las trayectorias controladas por ratón requiere juicio humano.
• No existe una regla específica de axe-core que se corresponda con 2.1.3: Las reglas de axe más cercanas —como scrollable-region-focusable (que comprueba si las regiones de contenido desplazable pueden recibir foco de teclado) y tabindex (que marca valores positivos de tabindex que alteran el orden natural del foco)— abordan preocupaciones relacionadas pero más limitadas bajo 2.1.1 y 2.4.3. No evalúan ni pueden evaluar si toda la funcionalidad, incluidas las operaciones sensibles a la trayectoria, tiene un equivalente mediante teclado.
• Las auditorías de widgets interactivos requieren interacción en tiempo de ejecución: Componentes personalizados de arrastrar y soltar, editores basados en canvas y carruseles controlados por gestos solo revelan su inaccesibilidad mediante teclado cuando una persona evaluadora intenta realmente usarlos sin ratón. El análisis estático del DOM de axe-core no puede disparar listeners de eventos, observar la pérdida de foco durante operaciones asíncronas ni evaluar si una operación de arrastre puede completarse mediante las teclas de flecha y Enter/Espacio.
• Qué buscar durante la auditoría manual: Las personas evaluadoras deben buscar específicamente elementos canvas usados para dibujo o interacción, listas de arrastrar y soltar o áreas de subida de archivos, controles personalizados de mapas o visualizaciones de datos, controles deslizantes basados en tiempo y cualquier componente que responda a eventos mousemove, pointermove o gestos táctiles sin controladores de eventos de teclado correspondientes.

Cómo Probar

1. Ejecutar un análisis automatizado de referencia: Use axe DevTools (extensión del navegador o CLI) o Google Lighthouse en su página para identificar fallos de accesibilidad de teclado fáciles de detectar: elementos sin foco, trampas de teclado o elementos con pointer-events: none que deberían ser interactivos. Aunque estas herramientas no detectarán directamente infracciones de 2.1.3, sacan a la luz problemas relacionados y establecen una base limpia antes de comenzar las pruebas manuales.
2. Catalogar toda la funcionalidad interactiva: Antes de probar, cree un inventario completo de cada componente interactivo en la página: botones, enlaces, formularios, modales, acordeones, carruseles, mapas, herramientas de canvas, áreas de arrastrar y soltar, menús desplegables personalizados, selectores de fecha, reproductores de video y cualquier widget que responda a eventos de ratón o táctiles. Este inventario se convierte en su lista de comprobación de pruebas.
3. Prueba de navegación solo con teclado: Desconecte o deshabilite su ratón. Use Tab y Shift+Tab para mover el foco, Enter y Espacio para activar controles, las teclas de flecha para widgets compuestos (menús, controles deslizantes, pestañas, grupos de botones de opción) y Escape para cerrar diálogos. Intente completar cada función de su lista de inventario. Anote cualquier función que no pueda iniciar, completar o salir usando solo el teclado.
4. Pruebas con lector de pantalla usando NVDA + Firefox: Inicie NVDA (Windows) con Firefox. Navegue usando el cursor virtual (H para encabezados, B para botones, F para campos de formulario, Tab para elementos interactivos). Intente cada función. Escuche el rol, nombre y estado anunciados. Identifique cualquier región interactiva que sea inalcanzable o que no produzca ningún anuncio audible.
5. Pruebas con lector de pantalla usando JAWS + Chrome: Use JAWS en Windows con Chrome. Use el cursor virtual de JAWS y el modo de formularios (conmutado con Enter). Verifique que toda la funcionalidad pueda operarse y que el foco se gestione correctamente después de cada interacción, especialmente después de que se abran diálogos modales o se cargue contenido AJAX.
6. Pruebas con lector de pantalla usando VoiceOver + Safari (macOS/iOS): Active VoiceOver (Command + F5 en macOS). Use Control + Opción + Flecha para navegar. En iOS, use gestos de deslizamiento. Confirme que todas las funciones sean alcanzables y operables. Preste especial atención a los widgets personalizados basados en gestos táctiles que puedan carecer de equivalentes mediante teclado en la versión de escritorio.
7. Auditoría de funcionalidad dependiente de la trayectoria: Para cualquier lienzo de dibujo, interacción con mapas o componente controlado por gestos, verifique si existe un mecanismo alternativo mediante teclado. Intente crear una forma, reordenar un elemento de una lista o desplazar un mapa usando solo controles de teclado. Si no existe una ruta mediante teclado, se trata de un fallo directo de 2.1.3.
8. Comprobación de visibilidad del foco: Mientras navega solo con teclado, confirme que el foco sea siempre visible en pantalla y esté ordenado lógicamente. Un foco invisible o que salta a ubicaciones inesperadas es un fallo de usabilidad y probablemente también infringe 2.4.7 y 2.4.3.

Cómo Corregir

Herramienta de Dibujo en Canvas — Incorrecto

<!-- Freehand canvas with no keyboard alternative -->
<canvas id='drawingBoard' width='800' height='600'
  onmousedown='startDraw(event)'
  onmousemove='draw(event)'
  onmouseup='endDraw()'>
</canvas>

Herramienta de Dibujo en Canvas — Correcto

<!-- Canvas with keyboard-accessible shape toolbar as alternative -->
<div role='toolbar' aria-label='Drawing tools'>
  <button id='addRect' onclick='insertShape("rectangle")'>Add Rectangle</button>
  <button id='addCircle' onclick='insertShape("circle")'>Add Circle</button>
  <button id='addLine' onclick='insertShape("line")'>Add Line</button>
  <label for='shapeColor'>Color</label>
  <input type='color' id='shapeColor' value='#000000'>
</div>
<canvas id='drawingBoard' width='800' height='600'
  aria-label='Drawing canvas — use toolbar above to add shapes'
  tabindex='0'
  onmousedown='startDraw(event)'
  onmousemove='draw(event)'
  onmouseup='endDraw()'
  onkeydown='handleCanvasKey(event)'>
</canvas>
<!-- handleCanvasKey enables arrow-key movement and Enter to place shapes -->

Reordenamiento de Lista con Arrastrar y Soltar — Incorrecto

<!-- List that only supports mouse drag for reordering -->
<ul id='sortableList'>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item One</li>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item Two</li>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item Three</li>
</ul>

Reordenamiento de Lista con Arrastrar y Soltar — Correcto

<!-- List with ARIA listbox pattern and keyboard reordering via arrow keys -->
<p id='reorderInstructions'>Tab to an item, press Space to grab it, use Up/Down arrows to move, press Space again to drop.</p>
<ul id='sortableList' role='listbox' aria-labelledby='reorderInstructions'>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item One</li>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item Two</li>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item Three</li>
</ul>
<!-- handleReorderKey: Space = grab/drop, ArrowUp/Down = move, Escape = cancel -->

Controles de Mapa Interactivo — Incorrecto

<!-- Map that only responds to mouse pan and scroll-to-zoom -->
<div id='mapContainer' style='width:100%;height:400px;'
  onwheel='zoomMap(event)'
  onmousedown='startPan(event)'
  onmousemove='pan(event)'>
</div>

Controles de Mapa Interactivo — Correcto

<!-- Map with keyboard controls and accessible zoom/pan buttons -->
<div id='mapContainer' tabindex='0'
  role='application'
  aria-label='Interactive map. Use arrow keys to pan, plus and minus to zoom.'
  onwheel='zoomMap(event)'
  onmousedown='startPan(event)'
  onmousemove='pan(event)'
  onkeydown='handleMapKey(event)'>
</div>
<div role='group' aria-label='Map controls'>
  <button onclick='zoomIn()'>Zoom In</button>
  <button onclick='zoomOut()'>Zoom Out</button>
  <button onclick='panMap("north")'>Pan North</button>
  <button onclick='panMap("south")'>Pan South</button>
  <button onclick='panMap("east")'>Pan East</button>
  <button onclick='panMap("west")'>Pan West</button>
</div>
<!-- Arrow keys pan, + / - zoom, handleMapKey dispatches these actions -->

Errores Comunes

• Suponer que la excepción de trayectoria de WCAG 2.1.1 sigue aplicando: Las personas desarrolladoras familiarizadas con el Nivel A a veces crean herramientas de dibujo a mano alzada o basadas en gestos sin alternativas mediante teclado, sin darse cuenta de que 2.1.3 elimina explícitamente esta excepción. Cada función, incluidas las sensibles a la trayectoria, debe tener un equivalente mediante teclado en este nivel.
• Adjuntar solo controladores onclick y onmousedown a elementos interactivos personalizados: Los widgets personalizados construidos con elementos <div> o <span> que solo escuchan eventos de ratón son completamente inalcanzables mediante teclado. Siempre agregue controladores onkeydown o onkeyup junto con los listeners de eventos de ratón y asegúrese de que el elemento tenga tabindex='0' y un rol ARIA apropiado.
• Usar tabindex='-1' en elementos que deberían estar en el orden de tabulación: Establecer tabindex='-1' elimina un elemento del orden secuencial de tabulación. Esto es apropiado solo para elementos gestionados de forma programática (por ejemplo, dentro de un widget compuesto usando roving tabindex). Aplicarlo a controles interactivos independientes los hace inaccesibles mediante teclado.
• Implementar arrastrar y soltar sin un mecanismo de reordenamiento basado en teclado: Bibliotecas como SortableJS o implementaciones personalizadas de arrastre a menudo no proporcionan una alternativa mediante teclado de forma predeterminada. Las personas desarrolladoras deben implementar el patrón ARIA de arrastrar y soltar o proporcionar reordenamiento con las teclas de flecha arriba/abajo para que el reordenamiento de listas sea completamente operable mediante teclado.
• Depender de CSS :hover para mostrar controles interactivos: Submenús desplegables, botones de acción basados en tooltips o controles que aparecen solo al pasar el cursor son inaccesibles para las personas usuarias de teclado a menos que también se gestionen los estados :focus y :focus-within. Una persona usuaria de teclado nunca puede hacer hover, por lo que el contenido solo visible al pasar el cursor está efectivamente oculto para ella.
• No gestionar el foco después de cambios dinámicos de contenido: Cuando se abre un modal, aparece una alerta en línea o un widget cargado por AJAX reemplaza contenido existente, el foco debe trasladarse de forma programática al contenido nuevo usando element.focus(). No hacerlo deja a las personas usuarias de teclado atrapadas en la posición donde desencadenaron el cambio, sin conciencia de que existe contenido nuevo.
• Crear controles deslizantes personalizados solo con onmousemove: Los controles deslizantes de tipo rango construidos a partir de elementos <div> que rastrean la posición del ratón para los cambios de valor también deben implementar el manejo de las teclas ArrowLeft, ArrowRight, Home y End según el patrón ARIA de slider, y exponer el valor actual mediante aria-valuenow, aria-valuemin y aria-valuemax.
• Colocar el foco de teclado dentro de iframes sin proporcionar una forma de salir: Los iframes incrustados —especialmente los que contienen widgets de terceros como mapas, formularios de pago o herramientas de chat— pueden atrapar el foco de teclado si el contenido incrustado en sí no es accesible mediante teclado y no admite la tecla Escape para devolver el foco al documento padre.
• Omitir la compatibilidad con teclado en visualizaciones de datos basadas en canvas: Los gráficos y diagramas renderizados en <canvas> son invisibles para el teclado y los lectores de pantalla a menos que se proporcione una alternativa accesible (una tabla de datos, un equivalente SVG con ARIA o puntos de datos navegables mediante teclado) junto al elemento canvas.
• Probar la accesibilidad de teclado solo con Tab y Enter, ignorando los patrones de teclas de widgets compuestos: Muchos patrones de widgets ARIA —menús, árboles, cuadrículas, paneles de pestañas, listboxes— requieren navegación con teclas de flecha dentro del widget, con un solo punto de tabulación para todo el componente (roving tabindex). Probar solo con Tab y Enter no revelará fallos en estos patrones compuestos y dará una falsa sensación de conformidad.

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úmero 32933 el 21 de junio de 2025, establece un marco integral de accesibilidad web y móvil para una amplia gama de entidades públicas y privadas que operan en Turquía. La circular exige la conformidad con estándares alineados con WCAG 2.1 y 2.2, requiriendo que las organizaciones cubiertas garanticen que sus servicios digitales sean perceptibles, operables, comprensibles y robustos para todas las personas usuarias, incluidas aquellas con discapacidad.

Las entidades cubiertas por esta regulación incluyen instituciones y organismos públicos en todos los niveles de gobierno, plataformas de comercio electrónico, bancos y proveedores de servicios financieros, hospitales e instituciones sanitarias, empresas de telecomunicaciones con 200.000 o más abonados, agencias de viajes, empresas de transporte privado y escuelas privadas que operan bajo autorización del Ministerio de Educación Nacional (MoNE). Para estas organizaciones, el cumplimiento de los criterios de éxito de Nivel A y Nivel AA es el mínimo legal de referencia.

WCAG 2.1.3 — Teclado (Sin Excepción) es un criterio de nivel AAA y, por lo tanto, no se exige explícitamente como requisito legal básico en la circular. Sin embargo, el espíritu de la regulación —garantizar un acceso digital equitativo para los millones de personas usuarias con discapacidad en Turquía— se alinea firmemente con la intención de este criterio. Las organizaciones de los sectores cubiertos que ofrecen servicios especializados a personas con discapacidades motoras, o que operan portales gubernamentales utilizados por ciudadanía que depende de tecnología de apoyo, harían bien en perseguir la conformidad AAA para el acceso mediante teclado.

Lograr la conformidad con WCAG 2.1.3 señala un compromiso de accesibilidad de primer nivel que va más allá de los mínimos regulatorios. Para las organizaciones turcas que buscan servir a la base de personas usuarias más amplia posible, demostrar responsabilidad social o participar en mercados digitales de la Unión Europea donde pueden aplicarse estándares de accesibilidad más altos, implementar una operabilidad completa mediante teclado sin excepciones es tanto una ventaja competitiva como ética. A medida que el panorama regulatorio de Turquía evolucione y los mecanismos de aplicación maduren, las personas y organizaciones que adopten tempranamente criterios de nivel AAA como 2.1.3 estarán en una posición óptima para cumplir cualquier endurecimiento regulatorio futuro sin costosas tareas de remediación.