El testing manual de accesibilidad web es la práctica de revisar tu sitio a mano, con herramientas y tecnologías asistidas, para detectar errores que ningún script automatizado puede encontrar. Si desarrollas interfaces y quieres entregar productos verdaderamente inclusivos, este enfoque es innegociable.

La razón es simple: se estima que solo el 40% de los problemas de accesibilidad pueden descubrirse con tests automáticos. El 60% restante requiere ojos humanos, oídos atentos y un poco de paciencia.

¿Por qué los tests automáticos no alcanzan en accesibilidad?

Las herramientas automáticas verifican reglas técnicas, no intención ni contexto. Y ahí es donde se cuelan los errores más graves.

Piensa en el caso del sitio diabólico visto en la clase anterior [05:12]: un enlace tenía un aria-label que reemplazaba su texto original con contenido incorrecto y redundante. Para un test automático, todo se ve impecable, porque usar aria-label es técnicamente válido. El problema no es el atributo, es el contenido dentro del atributo, y eso una máquina no lo puede juzgar.

Lo mismo pasa con el texto alternativo de una imagen. ¿Cómo sabes si tiene sentido y describe correctamente lo que se ve? Solo testeando manualmente.

¿Qué porcentaje de errores de accesibilidad detectan los tests automáticos? Aproximadamente el 40%. El 60% restante requiere revisión manual, porque los bots no pueden evaluar si el contenido de un aria-label o un texto alternativo es coherente y útil.

¿Cómo empezar a testear accesibilidad de forma manual?

Lo ideal siempre es contratar a una persona con discapacidad para tener un usuario real probando el sitio. Existen empresas especializadas en este tipo de auditorías. Pero si no tienes presupuesto o quieres hacer una primera pasada tú mismo, hay tres caminos accesibles que cualquier developer puede recorrer.

Navegación por teclado

Es el primer chequeo y el más rentable. Conecta tu teclado, olvídate del mouse y recorre tu sitio. Lo que debes verificar:

• Que los focos sean visibles y sepas siempre dónde estás parado.
• Que el orden de tabulación tenga sentido lógico.
• Que no existan loops infinitos, por ejemplo al abrir un modal que no se puede cerrar.
• Que el skip navigation funcione y permita saltar bloques repetitivos.

Si tu sitio no se puede usar con teclado, ningún lector de pantalla va a salvarlo después.

Inspector de accesibilidad de Firefox

Firefox trae una herramienta poderosa y subutilizada [09:45]. Abres tu sitio, haces clic derecho sobre una imagen o un enlace y eliges Inspeccionar las propiedades de accesibilidad. Se abre un panel con información clave:

• El rol del elemento, por ejemplo link, graphic o image.
• El name, que es lo que el lector de pantalla anunciará.
• Los estados posibles: foco, activo, presionado.
• Los shortcuts de teclado asociados, comunes en apps como Slack.
• Errores detectados, con un cartelito y un link directo a MDN para entender cómo arreglarlo.

El ejercicio más revelador es inspeccionar un logo o los íconos de redes sociales, porque ahí es donde más errores aparecen: enlaces con imágenes sin descripción adecuada.

Lectores de pantalla

Son la herramienta de mayor importancia y también la más compleja de aprender. Un lector de pantalla es un software que vive en todo el sistema operativo, no solo en el navegador, y traduce a voz lo que aparece en la pantalla.

¿Qué lectores de pantalla deberías usar para testear?

Los tres más utilizados según la encuesta anual de WebAIM son:

• NVDA: open source, exclusivo de Windows, gratuito y muy popular [16:30].
• Narrator: el lector nativo de Windows, ya viene instalado.
• VoiceOver: el lector nativo de macOS, probablemente lo activaste sin querer alguna vez.

¿Qué lector de pantalla es mejor para empezar? NVDA en Windows o VoiceOver en Mac. Ambos son nativos o gratuitos y cubren la mayoría de los casos de uso reales según las encuestas de WebAIM.

Recomendaciones para tu primer acercamiento

Vamos a ser honestos: usar un lector de pantalla por primera vez puede ponerte nervioso. La voz es mecánica, habla muy rápido y a veces no sabes cómo callarla. Por eso, antes de probar nada:

• Empieza en una computadora de escritorio, nunca en un celular. En el móvil puedes apagar la pantalla sin querer y no saber cómo volver a prenderla.
• Aprende primero el atajo para silenciarlo: en Windows y Mac, la tecla Control lo calla temporalmente.
• Ajusta la velocidad de lectura en configuración si te resulta demasiado rápida.
• Acepta que la voz es robótica a propósito: las voces mecánicas son más performantes y neutras, no le ponen drama a textos tristes ni emoción a contextos serios.

¿Qué deberías verificar con un lector de pantalla?

Prioriza la navegación básica antes que cualquier otra cosa:

• Que puedas moverte de una página a otra sin perderte.
• Que un buscador te lleve correctamente al resultado.
• Que los botones se activen y anuncien lo que hacen.
• Que las imágenes que funcionan como enlaces se describan correctamente.
• Que el orden de navegación tenga sentido.
• Que lo que anuncia coincida con lo que el usuario realmente necesita escuchar.

Vuelve al ejemplo del sitio diabólico: un lector de pantalla revelaría inmediatamente que el aria-label está anunciando algo incorrecto. Eso es exactamente lo que buscas detectar.

¿Existen atajos para profesionalizarte más rápido?

Sí. La empresa Deque, especializada en accesibilidad, publica cheat sheets gratuitos con los atajos de teclado más usados de cada lector de pantalla [22:18]. Imprímelos y déjalos al lado de tu computadora. Es la forma más rápida de pasar de tester ocasional a alguien que se mueve con soltura por NVDA o VoiceOver.

¿Cuál de estas técnicas vas a probar primero en tu sitio? Cuéntame en los comentarios qué descubriste al testear con teclado o con un lector de pantalla por primera vez.