Cómo probar la accesibilidad de tu sitio (con un lector de pantalla)

¿Por qué una herramienta no puede probarlo por mí?

Porque la mayor parte de la accesibilidad es un juicio que una máquina no puede hacer. Las herramientas automáticas cazan cerca del 30-40% de los problemas de accesibilidad, y el 60-70% restante requiere evaluación humana (Contentsquare, 2026). La forma cruda en que lo ponen los profesionales: puedes publicar un sitio que pasa axe con cero violaciones y seguir siendo inusable en un lector de pantalla (TestGuild, 2026).

La brecha es estructural, no cuestión de mejores herramientas. Un escáner puede detectar que una imagen carece de texto alternativo, pero no si alt="foto" de verdad describe la imagen; puede confirmar que los elementos son enfocables, pero no si el orden de tabulación es lógico o si existe una trampa de foco; puede revisar que los atributos ARIA estén presentes, pero no si crean una experiencia coherente para un usuario de lector de pantalla (AccessScore, 2026). Por eso WebAIM es directo en que una herramienta no puede decirte si tu contenido es accesible — solo un humano puede (Upward Engine, 2026). Trata el escaneo automático como el piso, nunca la meta final — un punto que sostiene nuestro pilar sobre si la accesibilidad web es obligatoria.

Paso uno: la base automática

El escaneo automático igual se gana su lugar — caza los problemas más comunes y demandados de forma rápida y consistente, así que es por donde empiezas. Los tres caballos de batalla gratuitos son axe DevTools, el estándar de los desarrolladores cuyo motor axe-core se ha descargado más de tres mil millones de veces e impulsa a la mayoría de las demás herramientas; WAVE, cuya superposición visual marca errores y alertas directamente en la página y conviene a quienes no programan; y Lighthouse, integrado en Chrome DevTools con una puntuación de 0 a 100 (Upward Engine, 2026). En un benchmark de 2026, axe identificó el 78% de las violaciones detectables y WAVE el 71% — alto dentro de su alcance, que sigue siendo solo una parte del total (Upward Engine, 2026).

Corre el escaneo en tus plantillas críticas en vez de cada página —inicio, formularios de contacto y login, búsqueda, navegación— porque arreglar un problema en una plantilla normalmente lo resuelve en cada página construida a partir de ella (Upward Engine, 2026). Trabaja el informe en orden: los hallazgos se clasifican en Errores (fallos definitivos), Alertas (necesitan juicio humano) y Avisos (informativos), y arreglas los Errores primero, priorizando cualquier cosa que bloquee por completo a un usuario (WebAbility, 2026). Una brecha a notar: los escáneres basados en URL suelen saltarse las páginas autenticadas como los paneles y el checkout, así que prueba esas con una extensión de navegador estando con sesión iniciada (WebAbility, 2026).

Paso dos: la prueba de teclado

La primera prueba manual no cuesta nada y toma minutos. Desconecta tu ratón y navega todo el sitio solo con el teclado — Tab y Shift+Tab para moverte, Enter y Espacio para activar, las flechas dentro de los componentes (TestGuild, 2026). Si no puedes alcanzar cada elemento interactivo de esta forma, el sitio tiene problemas de accesibilidad, punto (TestGuild, 2026).

A medida que avanzas, vigila tres fallos que un escáner detecta mal: un indicador de foco que desaparece y no te deja saber dónde estás, una trampa de teclado que no te deja pasar de un componente, y un orden de tabulación que salta de forma ilógica. Estos son justo los problemas que cubre a fondo nuestra guía sobre accesibilidad por teclado y foco — y la prueba de teclado es donde los sientes directamente en vez de leer sobre ellos.

Paso tres: la prueba de zoom

Un chequeo rápido que caza un fallo común: amplía tu navegador al 200% y luego al 400%, y observa qué pasa con el diseño (TestGuild, 2026). El contenido debería refluir y seguir legible, sin que los elementos se apilen unos sobre otros y sin forzar un desplazamiento horizontal para leer una línea de texto (Upward Engine, 2026).

Esto importa porque muchos usuarios navegan ampliados o en pantallas pequeñas, y un diseño que solo funciona a un tamaño los excluye. Toma un minuto y revela problemas que se ven bien al zoom por defecto, que es por qué pertenece a cada pasada rápida.

Paso cuatro: la prueba de lector de pantalla

Esta es la prueba más reveladora que puedes correr, y la que cambia cómo piensas sobre tu sitio. Enciende un lector de pantalla —NVDA, que es gratis y el más usado del mundo en Windows, o VoiceOver, integrado en cada Mac con Cmd+F5— e intenta usar tu propio sitio con la pantalla apagada (ADAWebPro, 2026). ¿Puedes saber qué hay en la página, llenar los formularios, y completar una compra o contactar al negocio usando solo lo que escuchas? Incluso 30 minutos revelan problemas que las herramientas automáticas se pierden por completo (12 Best, vía Contentsquare, 2026).

Unos ajustes de NVDA vuelven esto llevadero: baja la velocidad de habla al 40-50%, activa el Visor de Voz para ver una transcripción en vivo de lo que se anuncia, desactiva tu ratón para navegar como lo hace un usuario de lector de pantalla, y presiona NVDA+F7 para abrir una lista de los encabezados, enlaces y regiones de la página (Upward Engine, 2026). Escucha si los encabezados forman un esquema sensato, si cada campo del formulario se anuncia con su etiqueta, si el orden de lectura coincide con el orden visual, y si los widgets interactivos anuncian su estado — los chequeos que conectan directamente con nuestras guías sobre el texto alternativo y cuándo usar ARIA.

Lo que solo un humano puede cazar

Vale la pena nombrar exactamente qué hallan las capas manuales, porque es la diferencia entre un sitio técnicamente limpio y uno usable. Un evaluador humano juzga si el texto alternativo es de verdad descriptivo en vez de apenas presente, si el orden de lectura tiene sentido, y si las interacciones complejas de verdad funcionan con un lector de pantalla (ADAWebPro, 2026). Las máquinas detectan ausencia; los humanos detectan significado.

La lista de problemas de solo-juicio es larga e importante: si un enlace etiquetado “Más” tiene sentido fuera de contexto, si los subtítulos son precisos y están sincronizados en vez de apenas presentes, y si la carga cognitiva de la página —lenguaje claro, instrucciones claras, diseño consistente— es manejable (AccessScore, 2026). Ninguno de estos puede medirse con código, y todos deciden si una persona real puede usar tu sitio. Esta es la misma razón por la que nuestra guía sobre los overlays de accesibilidad concluye que ningún widget automático puede entregar accesibilidad — el duro 60-70% es justo lo que la automatización no puede alcanzar.

Prueba en un calendario, no una vez

La accesibilidad no es un estado que alcanzas y conservas — es una propiedad que se degrada. Las páginas nuevas, el contenido actualizado, las funciones nuevas y los cambios de diseño pueden todos reintroducir barreras, así que un sitio probado limpio al lanzar puede fallar en un mes de ediciones normales (Inclusive Web, 2026). Probar solo al lanzar es uno de los errores más comunes, justo porque trata un blanco en movimiento como uno fijo.

El arreglo es el ritmo. Corre un escaneo automático rápido más una revisión puntual de teclado y lector de pantalla tras cada actualización importante, y programa una revisión manual más completa de forma periódica (WebAbility, 2026). Los desarrolladores pueden automatizar la primera capa añadiendo una herramienta de línea de comandos como Pa11y a una tubería de integración continua, cazando las regresiones comunes antes de que lleguen a producción (Contentsquare, 2026). La meta es cazar la degradación temprano, cuando es un arreglo de una línea en vez de una lista de pendientes.

Los errores que vuelven la prueba un teatro

Tres hábitos convierten la prueba en un ejercicio de marcar casillas que no prueba nada. El primero es confiar por completo en la automatización — un escaneo limpio se siente como terminado, pero solo cubrió el 30-40% de los criterios (Inclusive Web, 2026). El segundo es probar una sola vez. El tercero es intentar arreglar todo a la vez en vez de priorizar los errores críticos que bloquean por completo a los usuarios por encima de las alertas menores (Inclusive Web, 2026).

Un cuarto pertenece aquí también, en silencio: ningún overlay ni “widget de accesibilidad” puede sustituir este proceso, porque las barreras que más importan son las que solo un evaluador humano halla. La remediación automática hace una promesa de cumplimiento que no puede sostener, que es por qué tanto los reguladores de EE. UU. como los de la UE la rechazan — el terreno que cubren nuestras guías sobre los overlays y la Ley Europea de Accesibilidad. La prueba real es una persona usando el sitio como lo haría un usuario excluido.

Por qué nuestros sitios más bien confirman que sorprenden

Así es como la forma en que un sitio está construido cambia la experiencia de probarlo. Como escribimos HTML nativo y semántico —botones reales, encabezados reales, controles de formulario etiquetados, operabilidad por teclado por defecto y casi nada de ARIA— la base automática tiende a volver limpia, ya que la mayoría de las violaciones comunes simplemente nunca se introducen. La prueba de teclado pasa porque los elementos nativos son enfocables y operables gratis. Y el lector de pantalla anuncia un esquema de encabezados coherente porque los encabezados son elementos estructurales reales, no texto con estilo.

El resultado es que probar nuestros sitios normalmente confirma lo que el build ya hizo, en vez de sacar a la luz una lista de reparaciones. Esa es la diferencia práctica entre la accesibilidad incorporada y la accesibilidad pegada — y la prueba es justo cómo distingues cuál tienes. Un sitio que necesita una larga lista de remediación tras su primera pasada de lector de pantalla se construyó sin este cuidado; uno que más bien pasa se construyó con él. Verificar eso es el último paso de la disciplina que expone nuestra checklist WCAG 2.2 — constrúyelo bien, y luego prueba que funciona.