- Las pruebas manuales con teclado complementan a las herramientas automáticas y son imprescindibles para cumplir con las WCAG.
- Es clave validar contraste, orden de tabulación, foco visible, uso del color y calidad de los textos y alternativas.
- Combinar validadores como Axe o CCA con chequeos manuales y lectores de pantalla ofrece una visión completa.
- Una estrategia continua de pruebas y auditorías mejora UX, reduce riesgos legales y amplía el alcance del sitio.
La accesibilidad web basada en pruebas manuales con teclado es ya una pieza clave en cualquier proyecto digital serio: no basta con pasar el típico escáner automático y quedarse tranquilo, porque ahí solo se destapa una parte de los problemas reales que tienen las personas usuarias.
Incorporar revisiones manuales, navegación por teclado y tecnologías de asistencia permite detectar barreras que un validador de código nunca verá: órdenes de tabulación extraños, focos que desaparecen, mensajes que no se leen con lector de pantalla o componentes imposibles de manejar sin ratón.
Pruebas de accesibilidad manual: por qué no basta con lo automático
Las pruebas de accesibilidad automatizadas son un primer filtro imprescindible, pero solo cubren una parte de los criterios de éxito de las WCAG; se centran en lo medible vía código (atributos que faltan, estructuras erróneas, ratios de contraste básicos, etc.).
Las pruebas manuales complementan esta visión técnica con una verificación real del uso: cómo se percibe, cómo se opera, cómo se entiende y qué tan robusto es el sitio con herramientas de asistencia como lectores de pantalla, amplificadores o dispositivos de entrada alternativos.
Entre las ventajas de estas pruebas manuales destacan su rapidez y sencillez para muchos chequeos (teclado, enfoque visual, textos alternativos), su capacidad para encontrar muchos más problemas que un escáner y la necesidad de muy pocas herramientas para empezar.
Sus desventajas principales son el tiempo y la experiencia que exigen: analizar flujos complejos de usuario, decidir si un texto alternativo es adecuado o si un aviso de error es suficientemente claro requiere práctica y criterio en accesibilidad.
La realidad actual es que una estrategia madura combina herramientas automáticas y pruebas manuales, ajustadas a los criterios WCAG aplicables, a la legislación del país y al contexto de uso (sector público, banca, e‑commerce, educación, etc.).
Tipos de pruebas de accesibilidad manual
Al revisar la accesibilidad de una web o app de forma manual conviene organizar el trabajo en tres grandes bloques: funcionamiento con teclado, comprobaciones visuales y verificaciones de contenido.
Las pruebas centradas en teclado se encargan de validar que todo el sitio puede usarse sin ratón, algo vital para personas con discapacidad motora, para quienes usan lectores de pantalla o para usuarios de software de reconocimiento de voz que emula pulsaciones de teclado.
Las revisiones visuales se orientan a aspectos como contraste, zoom, diseño y movimiento, utilizando herramientas como el zoom del navegador o software de magnificación para comprobar que el contenido sigue siendo legible y operable en distintas condiciones.
Las verificaciones de contenido ponen el foco en la calidad y claridad del texto: títulos, encabezados, enlaces, alternativas de imágenes, lenguaje llano, cambios de idioma o uso del color para transmitir información.
Muchas organizaciones además incluyen pruebas con tecnologías de asistencia (lectores de pantalla, líneas braille, software de reconocimiento de voz, teclados especiales), ya que comparten buena parte de la lógica de las pruebas manuales pero requieren un nivel de especialización más alto.
Verificaciones del teclado: núcleo de la accesibilidad operable
Aproximadamente una cuarta parte de los problemas habituales de accesibilidad en sitios web tiene que ver con que no se pueden manejar correctamente mediante teclado, lo que genera barreras serias para muchísima gente.
Un sistema con navegación por teclado bien resuelta debe permitir usar todas las funciones solo con teclas y atajos de teclado como Tab, Shift+Tab, Intro, Espacio, las flechas y combinaciones específicas según el contexto (por ejemplo, flechas en menús desplegables o deslizadores).
Las preguntas clave que hay que hacerse al probar con teclado son muy directas: ¿se puede usar el sitio sin ratón?, ¿el orden de tabulación es coherente?, ¿cada elemento interactivo recibe foco?, ¿el indicador de foco es visible en todo momento?
También conviene comprobar que nunca se produce un “atrapamiento” del foco, es decir, que un componente como un modal, un menú o un widget no impide seguir navegando con Tab o salir de él con facilidad.
Por último, al cerrar diálogos o componentes que capturan el foco, hay que verificar que el foco del teclado vuelve a un lugar lógico, normalmente al elemento que disparó esa ventana o a un punto cercano dentro del flujo.
Buenas prácticas de navegación por teclado y WCAG
Las WCAG definen criterios concretos para la operabilidad mediante teclado, que ayudan a aterrizar las pruebas manuales y a saber qué se está cumpliendo y qué no.
El criterio 2.1.1 “Teclado” exige que todo el contenido y la funcionalidad estén disponibles a través del teclado, de modo que cualquier formulario, botón o enlace se pueda accionar con teclas estándar, sin requerir gestos de ratón.
El criterio 2.1.2 “Sin trampa para el teclado” impide que el foco se quede encerrado dentro de un componente: si se entra a un elemento con Tab, se debe poder salir también con teclado sin maniobras extrañas.
El criterio 2.4.3 “Orden de enfoque” obliga a que el recorrido con Tab siga una secuencia lógica, normalmente de izquierda a derecha y de arriba abajo, y acorde a la estructura visual y semántica de la página.
El criterio 2.4.7 “Enfoque visible” garantiza que el elemento actualmente enfocado se vea claramente, ya sea con un borde, subrayado, cambio de color u otro estilo destacado que no dependa solo del color.
Tabindex, focos y trampas habituales
El atributo tabindex es una herramienta potente y peligrosa a la vez: bien usado permite ajustar el orden de tabulación, pero si se abusa de valores positivos complica el recorrido y confunde a quien navega con teclado.
Lo recomendable es dejar que los elementos sigan el orden natural del DOM, usando tabindex=»0″ solo para incluir en el flujo componentes personalizados (por ejemplo, un botón construido con un <div>) y evitando valores superiores a cero salvo casos muy justificados.
Un error muy típico es eliminar de forma agresiva los estilos de foco con reglas CSS como :focus { outline: none; }, dejando a los usuarios sin pista visual de dónde están; lo correcto es personalizar el estilo, no borrarlo.
Otro fallo frecuente es sacar campos importantes del orden de tabulación con tabindex=»-1″ cuando, en realidad, deberían poder enfocarse, como ocurre a menudo con formularios de registro, banners o enlaces ocultos visualmente.
En modales y diálogos es clave mover el foco al abrir y devolverlo al cerrar, limitando la tabulación al contenido del diálogo mientras está activo y evitando que se pueda “saltar” detrás de él con Tab.
Verificaciones visuales: contraste, zoom y diseño
Las comprobaciones visuales sirven para analizar todos los elementos que dependen de la vista: combinaciones de color, jerarquía visual, animaciones, parpadeos, espaciados y consistencia de los componentes.
Un primer bloque de pruebas se centra en el contraste de color, revisando que el texto y los iconos esenciales tengan suficiente contraste con su fondo, incluidos los casos más puñeteros como texto sobre gradientes o sobre imágenes.
En el caso de los enlaces, si no están subrayados deben cumplir un doble requisito: además del contraste mínimo con el fondo, se necesita un contraste suficiente respecto al texto circundante para que el enlace se identifique como interactivo.
Los iconos que aportan significado (por ejemplo, redes sociales, estados, acciones) deben alcanzar una relación de contraste de al menos 3:1 frente al fondo, mientras que elementos puramente decorativos no están sujetos a esa exigencia.
Otro punto importante es revisar el diseño tipográfico: texto completamente justificado puede generar “ríos” de espacio en blanco que dificultan la lectura, por lo que suele preferirse alineación a la izquierda y un espaciado cómodo entre líneas y párrafos.
Las pruebas de zoom o “zooming” son críticas para personas con baja visión; hay que comprobar que la página funciona correctamente al 200% de zoom o con herramientas de magnificación, sin recortes de contenido ni solapamientos que impidan entender o usar la interfaz.
Verificaciones de contenido: claridad, contexto y alternativas
Más allá de lo visual, la accesibilidad también se juega en las palabras: cómo se titulan las páginas, qué dicen los encabezados, cómo se describen los campos y qué textos se usan en enlaces y botones.
Los títulos de página, encabezados y etiquetas de formularios deben ser claros y descriptivos, de forma que cualquier persona (y cualquier lector de pantalla) entienda rápidamente de qué va cada sección y qué se espera introducir en cada campo.
Las alternativas de las imágenes han de ser concisas, precisas y útiles: no basta con que exista un atributo alt, el contenido tiene que describir el propósito de la imagen; si es decorativa, conviene dejar el alt vacío y marcarla como irrelevante para las tecnologías de asistencia.
Una regla fundamental es no usar solo el color para transmitir información: si un campo es obligatorio o tiene un error, además de cambiar el color hay que incluir iconos, mensajes de texto y, si procede, ayudas adicionales.
Los enlaces han de ser autoexplicativos sin depender del contexto visual inmediato, evitando fórmulas genéricas tipo “haz clic aquí” o “más información” sin detalles; esto ayuda especialmente a quienes navegan con lectores de pantalla saltando de enlace en enlace.
También se debe indicar cualquier cambio de idioma dentro de una página, y se recomienda usar un lenguaje sencillo, explicando siglas y acrónimos la primera vez que aparecen para reducir la carga cognitiva.
Estándares de accesibilidad: WCAG, principios P.O.U.R. y niveles
Las Pautas de Accesibilidad para el Contenido Web (WCAG) del W3C son el marco de referencia global para evaluar el nivel de accesibilidad de un sitio o aplicación, tanto web como móvil.
La evolución de WCAG pasa por varias versiones importantes: la 1.0 de 1999, centrada en principios generales; la 2.0 de 2008, con un enfoque más amplio; la 2.1 de 2018, hoy la versión estable más usada, y el trabajo en curso en 2.2 y en el proyecto “Silver” o WCAG 3.0.
La estructura actual de WCAG se basa en cuatro principios: que el contenido sea perceptible, operable, comprensible y robusto (P.O.U.R.), que a su vez se desglosan en lineamientos y criterios de éxito medibles.
Los criterios se agrupan en tres niveles de conformidad: A (mínimo), AA (recomendado y más habitual en normativas) y AAA (avanzado y más estricto, no siempre viable en todo tipo de contenido).
En la práctica, muchos requisitos legales y de sector público exigen llegar al nivel AA, lo que implica garantizar contraste adecuado, navegación por teclado, textos claros, alternativas a multimedia y una base semántica sólida en el marcado.
Herramientas automáticas que apoyan las pruebas manuales
Aunque el foco esté en lo manual, las herramientas automáticas son aliadas necesarias; ayudan a hacer un primer barrido y a generar informes rápidos sobre puntos débiles del sitio.
Axe (Axe DevTools) es una de las soluciones más usadas para revisar estructuras y errores relacionados con WCAG y otros estándares: se integra en el navegador, escanea la página completa o fragmentos concretos y ofrece un listado de hallazgos con severidad y sugerencias.
Colour Contrast Analyzer (CCA) es clave para validar ratios de contraste entre texto y fondo, incluyendo recomendaciones específicas según tamaño de tipografía y nivel de conformidad (AA o AAA).
Otras soluciones permiten analizar de forma masiva un sitio, integrarse en pipelines de integración continua o generar reportes para auditorías, pero siempre con el matiz de que no sustituyen el criterio humano.
Incluso se pueden crear utilidades internas sencillas, como lints que detecten expresiones problemáticas (“haz clic aquí”, textos vacíos en botones, etc.), siempre entendiendo que la corrección final la tiene que realizar una persona.
Pruebas manuales orientadas a distintos tipos de discapacidad
Una forma útil de enfocar las pruebas manuales es pensar en situaciones de discapacidad concretas y definir baterías de pruebas adaptadas a cada una.
Las pruebas de uso de color se centran en usuarios con baja sensibilidad al contraste o daltonismo, comprobando que la interfaz no depende solo del color para transmitir estados (errores, confirmaciones, categorías).
Las pruebas de foco en campos validan que personas con discapacidad motriz puedan seguir fácilmente la posición del cursor, con indicadores de enfoque visibles en todos los elementos interactivos.
Las pruebas de navegación con teclado buscan asegurar un recorrido completo por la interfaz, revisando que Tab y Shift+Tab siguen un orden lógico, sin zonas inaccesibles ni saltos extraños.
Las pruebas de zoom verifican que el sistema responde bien a aumentos de tamaño, sin romper diseños, ocultar información crucial o impedir la interacción con componentes.
Las pruebas con lector de pantalla detectan problemas semánticos y de feedback, por ejemplo campos de formulario sin etiqueta leíble, encabezados desordenados o elementos interactivos que no anuncian su estado.
Navegación por teclado bien implementada: ejemplos y patrones
Hay sitios que se han convertido en buen ejemplo de navegación por teclado, mostrando en la práctica cómo aplicar los criterios WCAG en entornos reales con mucho contenido.
En portales complejos como medios de comunicación o grandes tiendas online se observa una navegación por teclado completa: todos los enlaces, botones y menús desplegables se pueden usar sin ratón.
Los indicadores de foco visibles son consistentes en toda la interfaz, ayudando a localizar exactamente qué elemento está seleccionado en cada momento, algo vital cuando hay muchos módulos y bloques.
El orden de tabulación respeta la jerarquía del contenido: primero navegación principal, después búsquedas o filtros clave, más tarde listados de resultados y, finalmente, detalles o acciones específicas.
Los enlaces “skip to content” o “saltar al contenido principal” son otra pieza muy útil, ya que permiten a quienes usan teclado evitar menús repetitivos y llegar directamente a la información central de la página.
Pruebas, auditorías y mejora continua
Implementar accesibilidad no es un esfuerzo puntual, sino un proceso continuo que se alimenta de pruebas regulares, feedback de personas usuarias y revisión ante cambios de diseño o funcionalidad.
Las auditorías de accesibilidad, internas o externas, permiten medir el grado de cumplimiento frente a WCAG (a menudo orientadas al nivel AA) y priorizar un plan de acción realista según el impacto de cada problema.
Cuando no se dispone de presupuesto para auditorías externas, se puede optar por una combinación de herramientas automáticas, listas de chequeo manuales y sesiones de prueba con usuarios reales o con perfiles que simulen distintas situaciones.
En entornos como WordPress y otros CMS es posible combinar plugins y buenas prácticas de desarrollo para asegurar formularios accesibles, etiquetas ARIA bien usadas, paletas de color adecuadas y estructuras semánticas correctas.
En paralelo, es buena idea documentar lo que se va haciendo: patrones de diseño accesibles, componentes ya validados, ejemplos de errores recurrentes y guías internas para que todo el equipo vaya incorporando la accesibilidad de forma natural.
Al final, unas pruebas de accesibilidad manual bien planteadas, con fuerte foco en el uso del teclado y complementadas por herramientas automáticas y tecnologías de asistencia, se convierten en una palanca potente para que webs y aplicaciones sean realmente utilizables por más personas, ofrezcan mejor experiencia de usuario y cumplan con estándares y leyes sin renunciar a un diseño moderno.
