WCAG 2.1.4: Atajos de teclas de caracteres

Qué significa esta regla

WCAG 2.1.4 — Atajos de teclas de carácter es un criterio de éxito de Nivel A introducido en WCAG 2.1. Aborda un riesgo de accesibilidad específico pero grave: cuando una aplicación web asigna atajos de teclado que consisten en un solo carácter imprimible —una letra, número, signo de puntuación o símbolo— sin requerir una tecla modificadora como Ctrl, Alt, Meta o Shift junto con él.

El criterio establece que, si se implementa un atajo de teclado en el contenido usando solo una tecla de carácter, al menos una de las siguientes condiciones debe cumplirse:

• Desactivar: Hay disponible un mecanismo que permite a la persona usuaria desactivar por completo el atajo.
• Reasignar: Hay disponible un mecanismo que permite a la persona usuaria reasignar el atajo para usar una o más teclas modificadoras no imprimibles (como Ctrl o Alt).
• Activo solo con foco: El atajo de teclado para un componente de la interfaz de usuario solo está activo cuando ese componente tiene el foco.

Un atajo de tecla de un solo carácter es aquel que se activa al pulsar una sola tecla que produce un carácter imprimible —por ejemplo, pulsar G para abrir una galería, pulsar / para enfocar una barra de búsqueda o pulsar N para redactar un mensaje nuevo. Estos difieren fundamentalmente de atajos como Ctrl+S o Alt+F4, que requieren una tecla modificadora no imprimible y, por lo tanto, quedan fuera del alcance de este criterio.

Un atajo cumple este criterio si la aplicación: (1) proporciona una página de configuración o preferencias donde los atajos de una sola tecla puedan desactivarse o cambiarse a combinaciones de varias teclas; (2) se reasigna automáticamente a atajos basados en modificadores; o (3) solo dispara el atajo cuando el propio elemento desencadenante tiene el foco del teclado, lo que significa que pulsar la tecla mientras el foco está en otro lugar no hace nada.

Un atajo incumple si una pulsación de una sola tecla de carácter dispara una acción global en cualquier momento, independientemente de qué elemento tenga el foco, y no hay forma de que la persona usuaria lo desactive o lo cambie. Un ejemplo común en el mundo real es una aplicación de una sola página que dispara una acción de navegación cada vez que la persona usuaria pulsa una tecla de letra, incluso mientras está rellenando un campo de texto o dictando texto.

El criterio incluye una excepción oficial importante: no se aplica cuando el atajo solo está activo mientras un componente específico tiene el foco. Por ejemplo, un widget de lista desplegable personalizado que escucha teclas de letras solo cuando la propia lista desplegable está abierta y enfocada es aceptable, porque la contención del foco limita el riesgo de activación accidental.

Por qué es importante

Este criterio existe principalmente para proteger a dos grupos de personas usuarias, aunque sus beneficios se extienden más allá.

Las personas usuarias de entrada por voz son las más directamente afectadas. Las personas con discapacidades motoras a menudo controlan sus computadoras completamente mediante software de reconocimiento de voz como Dragon NaturallySpeaking (ahora Dragon Professional). Al dictar texto o emitir comandos de voz, estas herramientas generan pulsaciones de teclas que pueden activar inadvertidamente atajos de un solo carácter en la página web activa. Imagine a una persona usuaria que dicta un formulario médico y dice “next” —si la aplicación escucha la letra N de forma global, puede navegar fuera del formulario, destruyendo el trabajo de la persona usuaria. Según los CDC, aproximadamente 61 millones de personas adultas en Estados Unidos viven con una discapacidad, y una proporción significativa depende de métodos de entrada alternativos, incluido el reconocimiento de voz.

Las personas con discapacidad motora que usan acceso por pulsador, dispositivos de soplo y succión o navegación solo con teclado también están en riesgo. Estas personas pueden pulsar teclas inadvertidamente o pasar por varias teclas mientras intentan alcanzar un objetivo. Una sola pulsación errónea que desencadene una acción irreversible —como archivar un correo electrónico, eliminar un archivo o enviar un formulario— puede causar una gran frustración y pérdida de datos.

Las personas con discapacidad cognitiva también pueden verse perjudicadas. Las personas con trastornos de atención o quienes no están familiarizadas con una interfaz pueden pulsar teclas de forma experimental para explorar la página, sin saber que los atajos de un solo carácter están activos. Navegaciones o cambios de estado inesperados aumentan la carga cognitiva y la desorientación.

Considere este escenario real: una plataforma de comercio electrónico turca implementa atajos de una sola tecla para personas usuarias avanzadas —pulsar C para ir al carrito de compras, pulsar F para ir a favoritos. Una persona usuaria que utiliza entrada por voz intenta dictar su dirección de envío en un campo de formulario. Al decir “Caddesi” (la palabra turca para “calle”), el software de voz emite la letra C antes de que el foco entre completamente en la entrada, lo que desencadena la navegación a la página del carrito. La dirección introducida parcialmente se pierde. La persona usuaria debe empezar de nuevo y, si la experiencia se repite, puede abandonar el sitio por completo.

Más allá de la accesibilidad, corregir este criterio mejora la usabilidad general. Proporcionar una interfaz de personalización de atajos indica un producto maduro y respetuoso con las personas usuarias. También puede reducir los tickets de soporte de personas frustradas que activan atajos accidentalmente.

Reglas relacionadas de Axe-core

WCAG 2.1.4 requiere pruebas manuales porque las herramientas automatizadas no pueden detectar de forma fiable todos los atajos de teclado de un solo carácter ni verificar si existe un mecanismo de reasignación/desactivación. Esta es la razón por la que la automatización se queda corta y lo que las personas evaluadoras deben buscar manualmente:

• Sin regla específica de axe-core (se requiere comprobación manual): Axe-core y Lighthouse no tienen una regla automatizada que señale específicamente los atajos de teclado de un solo carácter. La razón es arquitectónica: el comportamiento de los atajos de teclado se implementa en escuchas de eventos de JavaScript (keydown, keyup, keypress), y el análisis estático del DOM no puede determinar qué acción desencadenará una pulsación determinada, si esa acción es global o limitada al foco, o si existe un mecanismo de desactivación/reasignación visible para la persona usuaria. Una herramienta tendría que simular pulsaciones para todas las posibles entradas de caracteres y observar los cambios resultantes en el estado de la aplicación, una tarea combinatoriamente costosa y dependiente del contexto que excede las capacidades actuales de las pruebas automatizadas.
• Inspección de escuchas de eventos (automatización parcial): Las DevTools del navegador pueden enumerar las escuchas de eventos adjuntas a los elementos document, window o body. Si un sitio adjunta una escucha de keydown a document y al inspeccionar su código fuente se revela lógica de coincidencia de caracteres individuales, esto es una señal fuerte que requiere verificación manual. Sin embargo, la herramienta no puede determinar por sí sola si el comportamiento resultante constituye un atajo o si existe un mecanismo de desactivación.
• Bibliotecas de atajos específicas de frameworks: Muchas aplicaciones React, Vue o Angular usan bibliotecas como react-hotkeys-hook, tinykeys o Mousetrap que registran atajos globales. Una auditoría manual debe comprobar estas dependencias en el código fuente de la página o en la pestaña de red y luego probar cada atajo registrado frente a los requisitos del criterio.

Cómo probar

1. Revisar la aplicación en busca de atajos conocidos de un solo carácter: Lea cualquier documentación disponible, páginas de ayuda o cuadros de referencia de atajos de teclado (a menudo se abren con ? o son accesibles mediante un menú de Ayuda). Enumere todos los atajos documentados que usan un solo carácter sin tecla modificadora.
2. Inspeccionar las escuchas de eventos de JavaScript: Abra Chrome DevTools o Firefox DevTools, vaya al panel Elements o Sources y use la pestaña Event Listeners para inspeccionar las escuchas en document, window y body. Busque manejadores de keydown, keyup o keypress. Expanda y lea el código fuente del manejador para ver si se prueban teclas de un solo carácter sin comprobaciones de modificadores (es decir, el código comprueba event.key === 'n' sin comprobar también event.ctrlKey || event.metaKey || event.altKey).
3. Probar los atajos de teclado mientras el foco está en una entrada de texto: Haga clic en un campo de texto, cuadro de búsqueda o área de texto. Luego pulse cada atajo de un solo carácter que haya identificado. Si el atajo se dispara (se produce una navegación, se activa una acción, cambia el estado), eso es un fallo: el atajo no está limitado al foco y está activo incluso cuando la persona usuaria está escribiendo.
4. Probar con NVDA + Firefox: Active el modo Browse de NVDA (Insert+Espacio para alternar). En el modo Browse, NVDA usa teclas de navegación de una sola letra (H para encabezados, B para botones, etc.). Inicie la aplicación web que se va a probar. Cambie al modo Focus (Insert+Espacio) y dicte o escriba texto. Verifique que los atajos de un solo carácter de la página no entren en conflicto con las pulsaciones del modo Browse de NVDA y que no se disparen acciones no deseadas.
5. Probar con JAWS + Chrome: De forma similar, JAWS usa teclas de navegación rápida de una sola letra. Inicie la aplicación, navegue mediante el cursor virtual de JAWS y verifique que los atajos de la aplicación no se disparen de forma inesperada mientras JAWS procesa las pulsaciones.
6. Probar con VoiceOver + Safari (macOS): Active VoiceOver (Cmd+F5). Use VO+Shift+Flecha abajo para interactuar con las áreas de contenido. Verifique que los atajos de letras en la página no interfieran con los comandos de navegación de VoiceOver.
7. Simular la entrada por voz: Si dispone de Dragon NaturallySpeaking o Windows Speech Recognition, dicte texto en un campo de formulario mientras la aplicación está abierta. Diga palabras y frases comunes que comiencen con letras usadas como atajos. Verifique que no se disparen acciones no deseadas.
8. Verificar el mecanismo de desactivación o reasignación: Si existen atajos de un solo carácter, localice la interfaz de configuración o preferencias que permite desactivarlos o reasignarlos. Confirme que se puede acceder a ella solo con el teclado y que funciona correctamente. Pruebe que, después de desactivar un atajo, pulsar el carácter ya no dispara la acción.

Cómo corregir

Atajo global de un solo carácter sin comprobación de modificador — Incorrecto

<!-- JavaScript adjunto a document se dispara con cualquier pulsación global de 'n' -->
<script>
document.addEventListener('keydown', function(event) {
  if (event.key === 'n') {
    // Navegar para redactar un mensaje nuevo
    openComposeWindow();
  }
});
</script>

Atajo global de un solo carácter — Correcto: añadir requisito de modificador y un interruptor de desactivación

<!-- Enfoque correcto 1: Requerir una tecla modificadora (Ctrl+N) para evitar activaciones accidentales -->
<script>
document.addEventListener('keydown', function(event) {
  // Solo se dispara cuando Ctrl o Meta (Cmd en Mac) también están pulsadas
  if ((event.ctrlKey || event.metaKey) && event.key === 'n') {
    openComposeWindow();
  }
});
</script>

<!-- Enfoque correcto 2: Si se requiere un atajo de un solo carácter, proporcionar un interruptor de desactivación -->
<button type='button' id='toggle-shortcuts' aria-pressed='true'>
  Keyboard shortcuts enabled
</button>
<script>
let shortcutsEnabled = true;
document.getElementById('toggle-shortcuts').addEventListener('click', function() {
  shortcutsEnabled = !shortcutsEnabled;
  this.setAttribute('aria-pressed', shortcutsEnabled.toString());
  this.textContent = shortcutsEnabled ? 'Keyboard shortcuts enabled' : 'Keyboard shortcuts disabled';
});

document.addEventListener('keydown', function(event) {
  if (!shortcutsEnabled) return; // Respetar la preferencia de la persona usuaria
  if (event.key === 'n') {
    openComposeWindow();
  }
});
</script>

Atajo activo dentro de un widget enfocado — Incorrecto

<!-- El atajo escucha en todo el document, no está limitado al widget -->
<div id='autocomplete-list' role='listbox'>
  <div role='option'>Istanbul</div>
  <div role='option'>Ankara</div>
</div>
<script>
// ERROR: adjunto a document, se dispara incluso cuando el autocompletado no tiene el foco
document.addEventListener('keydown', function(e) {
  if (e.key === 'Enter') selectHighlightedOption();
});
</script>

Atajo activo dentro de un widget enfocado — Correcto: limitar la escucha al widget

<!-- Correcto: la escucha está en el elemento del widget; el atajo solo se dispara cuando tiene el foco -->
<div id='autocomplete-list' role='listbox' tabindex='0'>
  <div role='option'>Istanbul</div>
  <div role='option'>Ankara</div>
</div>
<script>
var widget = document.getElementById('autocomplete-list');
// Escucha en el propio widget: Enter solo se dispara cuando la lista tiene el foco
widget.addEventListener('keydown', function(e) {
  if (e.key === 'Enter') selectHighlightedOption();
});
</script>

Sin interfaz de reasignación accesible para la persona usuaria — Incorrecto

<!-- La aplicación registra atajos con una biblioteca pero no ofrece una página de configuración -->
<!-- La persona usuaria no tiene forma de cambiar o desactivar 'g' (ir a la galería) o 'c' (ir al carrito) -->
<script src='hotkeys.min.js'></script>
<script>
hotkeys('g', function() { goToGallery(); });
hotkeys('c', function() { goToCart(); });
</script>

Sin interfaz de reasignación accesible para la persona usuaria — Correcto: añadir un panel de configuración accesible

<!-- Panel de configuración accesible mediante teclado; permite a la persona usuaria activar o desactivar todos los atajos de un solo carácter -->
<nav aria-label='Accessibility settings'>
  <button type='button' id='open-shortcut-settings'>Keyboard shortcut settings</button>
</nav>

<dialog id='shortcut-settings-dialog' aria-labelledby='dialog-title'>
  <h2 id='dialog-title'>Keyboard Shortcuts</h2>
  <label>
    <input type='checkbox' id='enable-single-char' checked />
    Enable single-character keyboard shortcuts (G, C, N...)
  </label>
  <p>Disable this if you use speech recognition software or experience accidental activations.</p>
  <button type='button' id='close-dialog'>Save and close</button>
</dialog>

<script src='hotkeys.min.js'></script>
<script>
var checkbox = document.getElementById('enable-single-char');

function applyShortcuts() {
  if (checkbox.checked) {
    hotkeys('g', function() { goToGallery(); });
    hotkeys('c', function() { goToCart(); });
  } else {
    hotkeys.unbind('g');
    hotkeys.unbind('c');
  }
}

applyShortcuts();
checkbox.addEventListener('change', applyShortcuts);

document.getElementById('open-shortcut-settings').addEventListener('click', function() {
  document.getElementById('shortcut-settings-dialog').showModal();
});
document.getElementById('close-dialog').addEventListener('click', function() {
  document.getElementById('shortcut-settings-dialog').close();
});
</script>

Errores comunes

• Registrar atajos en document o window sin comprobar si un elemento de entrada tiene el foco en ese momento: Incluso si existe un mecanismo de desactivación, muchas implementaciones olvidan comprobar document.activeElement y suprimir el atajo cuando la persona usuaria está dentro de un elemento <input>, <textarea> o contenteditable, lo que provoca interferencias con la escritura normal.
• Tratar el atajo ? (abrir ayuda) como exento: El signo de interrogación es un carácter imprimible y un atajo de un solo carácter. No está exento de este criterio a menos que esté limitado al foco o exista un mecanismo de desactivación/reasignación.
• Solo desactivar atajos en entradas de texto pero no en regiones contenteditable o editores de texto enriquecido: Las personas usuarias de entrada por voz a menudo dictan en elementos contenteditable usados por editores de texto enriquecido (como los de plataformas CMS). No suprimir los atajos globales en estos contextos sigue violando el criterio.
• Almacenar la preferencia de atajos de la persona usuaria solo en memoria de sesión: Si la persona usuaria desactiva los atajos y luego actualiza la página, la preferencia debe persistir (en localStorage o en una configuración de perfil de usuario) para que no tenga que desactivar los atajos en cada visita.
• Hacer que la propia interfaz de configuración de atajos sea inaccesible: Colocar la opción de desactivación/reasignación en un menú profundo al que no se puede acceder con el teclado, o usar un widget de interruptor personalizado sin un role='switch' adecuado y sin aria-checked, significa que el mecanismo de corrección es inutilizable para las mismas personas a las que pretende ayudar.
• Suponer que solo importan las teclas de letras: Las teclas numéricas (1–9), las teclas de puntuación (/, ., coma, punto y coma) y las teclas de símbolos (#, @, !) son todos caracteres imprimibles. Los atajos de una sola tecla que usan estos caracteres también están sujetos al criterio.
• No documentar qué atajos existen: Incluso si existe un mecanismo de desactivación, las personas usuarias no pueden usarlo eficazmente si no saben qué atajos están activos. Se recomienda encarecidamente proporcionar una referencia visible y accesible por teclado de los atajos (como un cuadro de diálogo que se abra mediante un botón de Ayuda).
• Usar la configuración predeterminada de una biblioteca de atajos que se vincula globalmente sin leer su documentación: Bibliotecas como Mousetrap, Hotkeys.js y tinykeys se vinculan al ámbito global de forma predeterminada. Las personas desarrolladoras a menudo las usan sin leer la documentación sobre la restricción de ámbito o los requisitos de modificadores, creando inadvertidamente violaciones del criterio a gran escala.
• No probar con reconocimiento de voz antes del lanzamiento: Los equipos que no tienen Dragon NaturallySpeaking en su conjunto de herramientas de QA a menudo descubren conflictos con atajos de un solo carácter solo después del despliegue, cuando las personas usuarias de entrada por voz informan de problemas.
• Creer que, porque el atajo es “opcional” o “para personas usuarias avanzadas”, está exento: El criterio se aplica a todos los atajos de un solo carácter, independientemente de si se comercializan como funciones avanzadas. El carácter opcional de la función no la exime del requisito 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.º 32933 el 21 de junio de 2025, establece requisitos obligatorios de accesibilidad web y móvil alineados con WCAG 2.2. WCAG 2.1.4 — Atajos de teclas de carácter es un criterio de éxito de Nivel A, lo que lo sitúa en el nivel de obligaciones de máxima prioridad según la circular.

La circular abarca una amplia gama de entidades que operan en Turquía. Las instituciones públicas —incluidos ministerios, municipios, universidades estatales, hospitales públicos y organismos gubernamentales— deben lograr la conformidad completa de Nivel A en el plazo de un año a partir de la fecha de publicación de la circular. Las entidades del sector privado en las categorías cubiertas disponen de un plazo de dos años para cumplir. Las entidades privadas cubiertas incluyen plataformas de comercio electrónico, bancos e instituciones financieras, hospitales y proveedores de atención sanitaria, 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, no cumplir con WCAG 2.1.4 no es solo una cuestión de buenas prácticas, sino una obligación legal. Un sitio de comercio electrónico turco que implemente atajos de navegación de productos de un solo carácter sin un mecanismo de desactivación, o el portal en línea de un banco turco que use atajos de teclas de letras en su flujo de transacciones, estaría en violación directa de los requisitos de la circular.

En la práctica, los equipos de cumplimiento de las entidades cubiertas deben auditar sus bases de código JavaScript y cualquier biblioteca de widgets de terceros en busca de atajos globales de un solo carácter como una tarea específica durante sus proyectos de remediación de Nivel A de WCAG 2.2. Dado que este criterio requiere pruebas manuales, los análisis automatizados de accesibilidad por sí solos no revelarán las infracciones: se requiere una fase dedicada de pruebas con teclado y entrada por voz. Las organizaciones que usan sistemas de gestión de contenidos o frameworks de front-end deben revisar las implementaciones de atajos a nivel de plataforma (por ejemplo, los atajos de teclado predeterminados del panel de administración de un CMS expuestos en páginas de cara al cliente) además del código de aplicación personalizado.

El SDK de superposición de Accsible ayuda a las entidades cubiertas proporcionando un panel de preferencias de accesibilidad accesible para la persona usuaria que puede exponer un interruptor de desactivación de atajos a las personas usuarias finales, ayudando a las organizaciones a cumplir el requisito de “mecanismo para desactivar” de WCAG 2.1.4 sin requerir una refactorización completa de la base de código. Esto es especialmente valioso para organizaciones que gestionan aplicaciones heredadas en las que modificar la lógica subyacente de atajos de JavaScript requiere muchos recursos. Sin embargo, las organizaciones deben tener en cuenta que depender únicamente de una superposición para el cumplimiento no sustituye a abordar las implementaciones subyacentes de atajos, y que un enfoque por capas que combine herramientas de superposición con remediación en el código fuente proporciona la vía más sólida hacia la conformidad según la circular presidencial.