Lección 4 de 10 · 11 min de lectura · Revisado el 26/10/2026
Pruebas con teclado, zoom al 200 y 400 %, alto contraste y control por voz
No todas las personas con discapacidad usan un lector de pantalla. Quien tiene una discapacidad motriz navega con teclado, con un pulsador o con la voz; quien tiene baja visión amplía la pantalla, cambia los colores o ajusta el espaciado del texto. Estas pruebas son baratas, no requieren software especializado y detectan una parte enorme de los problemas de los principios Operable y Perceptible. Esta lección las organiza por tipo, indica qué criterios cubren y cómo registrar los resultados.
Pruebas con teclado
Deja el ratón a un lado y recorre la página con Tab, Mayús+Tab, Enter, Espacio, flechas y Escape. Comprueba:
- 2.1.1 Teclado: todo lo que se puede hacer con ratón (abrir menús, cerrar modales, cambiar de pestaña, mover un control deslizante, cerrar un aviso) se puede hacer con teclado. Los enlaces se activan con Enter; los botones, con Enter y Espacio; los controles compuestos (pestañas, menús, radios, combos), con flechas según los patrones de la APG (se abre en una ventana nueva).
- 2.1.2 Sin trampas para el foco del teclado: se puede entrar y salir de cualquier componente (reproductor, mapa, iframe, modal) solo con teclado.
- 2.4.3 Orden del foco: la secuencia de Tab sigue el orden visual y lógico; no hay saltos a la cabecera desde la mitad de un formulario ni elementos invisibles que reciben el foco.
- 2.4.7 Foco visible: en todo momento sabes dónde estás; el indicador no se ha eliminado con
outline: none. - 2.4.11 Foco no oculto (mínimo): el elemento con foco no queda totalmente tapado por cabeceras fijas, pies o banners de cookies.
- 2.4.1 Evitar bloques: existe un enlace para saltar al contenido o landmarks que lo permiten.
- 2.1.4 Atajos de teclado de un solo carácter: si el sitio define atajos de una sola tecla, se pueden desactivar o remapear, o solo actúan con el foco en un componente.
- 3.2.1 Al recibir el foco: tabular a un elemento no provoca cambios de contexto (no abre nada ni envía el formulario).
En macOS, Safari necesita la opción «Pulsar Tab para resaltar cada elemento» y Firefox depende del ajuste del sistema «Navegación por teclado» en Teclado; sin ellos Tab salta los enlaces y parecerá un fallo del sitio.
Ejemplo
Banca en línea, pantalla de transferencia. Con Tab, el foco pasa del importe al botón «Continuar» saltándose el selector de cuenta de destino, que es un componente personalizado sin tabindex. Es imposible completar la transferencia sin ratón: fallo de 2.1.1 en un proceso completo, severidad máxima. Evidencia: vídeo de 20 segundos mostrando la secuencia de Tab y el DOM del selector.
Zoom y reflow
Hay tres pruebas distintas, para tres criterios distintos:
- 1.4.4 Cambio de tamaño del texto (AA): con el zoom del navegador al 200 % (Ctrl + «+» hasta que el navegador indique 200 %), el texto es legible y no se superpone, no se corta ni se pierde funcionalidad. Firefox permite además «Solo zoom de texto» (menú Ver, Zoom), que es más exigente porque no escala el resto de la maquetación.
- 1.4.10 Reajuste de los elementos (AA): el contenido debe presentarse sin desplazamiento en dos dimensiones a 320 píxeles CSS de ancho para el contenido con desplazamiento vertical (equivale a una ventana de 1280 px al 400 %) y a 256 px de alto para contenido con desplazamiento horizontal. Prueba: ventana a 1280 px y zoom 400 %, o herramientas de desarrollo con viewport de 320 px. Se exceptúa el contenido que necesita dos dimensiones (tablas de datos, mapas, diagramas, vídeo, barras de herramientas).
- 1.4.12 Espaciado del texto (AA): aplicando interlineado 1,5, espacio entre párrafos 2 veces el tamaño de fuente, espaciado entre letras 0,12 em y entre palabras 0,16 em, no se pierde contenido ni funcionalidad. Se prueba con un bookmarklet o una hoja de estilos de usuario que inyecte esas propiedades con
!important.
Fallos típicos al ampliar: menús que desaparecen y no se sustituyen por un botón, textos cortados en botones de ancho fijo, contenido en overflow: hidden, modales cuyo botón de cierre queda fuera de la pantalla, cabeceras fijas que ocupan media pantalla al 400 %.
Alto contraste y colores forzados
Muchas personas con baja visión usan los temas de contraste de Windows (Configuración, Accesibilidad, Temas de contraste; atajo Alt izq+Mayús izq+Impr Pant), que sustituyen todos los colores de la página por una paleta del sistema y eliminan las imágenes de fondo. Al probar con uno activo, comprueba que:
- los botones, enlaces y campos siguen distinguiéndose (los bordes no dependen de un fondo de color que ha desaparecido);
- el indicador de foco sigue siendo visible;
- los iconos que eran imágenes de fondo CSS no han desaparecido dejando botones vacíos;
- el estado seleccionado de pestañas, filtros o pasos no se indica solo con un color de fondo.
Las WCAG 2.2 no tienen un criterio específico para modos de contraste forzado, pero los fallos que revelan suelen ser de 1.4.1 Uso del color, 1.4.11 Contraste no textual o 2.4.7 Foco visible, y además afectan a personas usuarias reales. En CSS, la consulta @media (forced-colors: active) y las palabras clave de colores del sistema (CanvasText, ButtonText, Highlight) permiten corregirlos.
Comprueba también la preferencia prefers-reduced-motion (animaciones) y prefers-color-scheme (modo oscuro): si el sitio ofrece modo oscuro, mide el contraste en él; es una versión más de la página.
Control por voz
Dragon (Nuance) y Acceso por voz de Windows 11, Control por voz de macOS e iOS y Voice Access de Android permiten activar controles diciendo su nombre («pulsar Enviar») o mostrando números sobre cada elemento interactivo («mostrar números», «pulsar 7»). Para auditar basta con el control por voz integrado en macOS o iOS:
- 2.5.3 Etiqueta en el nombre: el nombre accesible de un control debe contener el texto visible. Si el botón muestra «Buscar» pero su
aria-labeles «Enviar consulta», decir «pulsar Buscar» no funciona. - 4.1.2: controles sin nombre o que no son controles reales no reciben número ni responden a órdenes.
- 1.1.1 y 2.4.4: botones solo con icono necesitan un nombre pronunciable y razonable («Cerrar», no «Icono X»).
Punto clave
Las pruebas con teclado, zoom, contraste forzado y voz no necesitan tecnologías de apoyo caras y detectan problemas que ningún lector de pantalla ni herramienta automática muestra. Deben formar parte del protocolo de todas las páginas de la muestra, no ser una comprobación ocasional.
Otras ayudas que conviene conocer
Magnificadores (Lupa de Windows con Win+«+», Zoom de macOS, ZoomText) amplían una parte de la pantalla: con ellos se detectan tooltips y menús que aparecen lejos del puntero, y contenido que depende de ver toda la pantalla a la vez (1.4.13, 3.3.1). Los pulsadores (Control por botón en iOS, Accesibilidad con interruptores en Android) recorren los elementos interactivos de forma secuencial: todo lo que falla con teclado falla con ellos, y además castigan el exceso de elementos enfocables.
Error frecuente
Probar el zoom al 200 % y dar por cubierto 1.4.10. El reflow se evalúa al 400 % (o a 320 px), que es donde los menús se transforman y las rejillas colapsan. Son dos criterios con dos pruebas diferentes.
Resumen
- Teclado: Tab, Mayús+Tab, Enter, Espacio, flechas y Escape cubren 2.1.1, 2.1.2, 2.4.3, 2.4.7, 2.4.11, 2.4.1, 2.1.4 y 3.2.1; configura Safari y Firefox en macOS antes.
- Zoom: 200 % para 1.4.4; 400 % o 320 px para 1.4.10 Reajuste de los elementos; bookmarklet de espaciado para 1.4.12.
- Temas de contraste de Windows y
forced-colorsrevelan fallos de 1.4.1, 1.4.11 y 2.4.7; mide también el modo oscuro si existe. - Control por voz comprueba 2.5.3 Etiqueta en el nombre y nombres accesibles de controles e iconos.
- Magnificadores y pulsadores completan la batería; todas estas pruebas van en el protocolo de cada página.
Comprueba lo que has aprendido
Esta lección se puede leer libremente. Para hacer su test de 3 preguntas, los ejercicios prácticos con páginas reales, guardar tu avance y optar al examen y al certificado, matricúlate en el curso.
Matricularme · nivel 4 (49 €)