Probar con lector de pantalla: del inicio al informe de prueba

Primero, prepara un entorno de pruebas que conozcas

En Windows tienes, por ejemplo, NVDA; en el Mac, VoiceOver viene integrado. Usa la guía oficial de tu software y aprende primero a iniciarlo y detenerlo, a navegar elemento por elemento y a interrumpir la voz. Los atajos de teclado varían según el sistema operativo, la distribución del teclado y la configuración. Evita aprender a la vez una web nueva y el manejo básico del lector de pantalla.

Anota el lector de pantalla, el navegador, el sistema operativo y sus versiones. Estos datos ayudan a reproducir el problema. Un hallazgo en una combinación no debe trasladarse sin más pruebas a todos los navegadores y productos de apoyo.

Elegir una tarea con un final reconocible

Una buena primera prueba es: «Encuentra el horario de apertura y después envía una solicitud de contacto». Prepara un entorno de pruebas adecuado para que no se generen mensajes ni reservas no deseados. Define qué información y qué acciones forman parte de completar la tarea con éxito. Revisa primero la página en su presentación normal; después puedes analizar por separado los ajustes personales o un menú adicional.

Entender la página a través de su estructura

Explora el título de la página, las regiones principales y los encabezados. Los lectores de pantalla ofrecen sus propias formas de saltar a estos elementos: NVDA usa, entre otras cosas, teclas rápidas de una sola letra en modo exploración, y VoiceOver ofrece el rotor. Comprueba si los encabezados nombran las secciones de forma lógica. Una línea visualmente grande sin la estructura HTML adecuada no ayuda en esta navegación.

Después, recorre los enlaces o los elementos del formulario. Las etiquetas repetidas, como «Más», se vuelven problemáticas cuando se pierde el contexto al navegar. Por eso, valora la etiqueta que se anuncia realmente junto con el contexto disponible.

Recorrer la introducción de datos, los errores y el éxito

1. 1Llega a cada campo de formulario necesario y escucha si su nombre, su finalidad y, en su caso, su carácter obligatorio son comprensibles.
2. 2Provoca un error típico y comprueba si se entienden la causa y la forma de corregirlo.
3. 3Abre un diálogo y comprueba la orientación, las acciones disponibles y el camino de vuelta al cerrarlo.
4. 4Envía datos de prueba válidos y comprueba si la finalización se entiende sin ver un cambio de color.
5. 5Repite los cambios dinámicos, como resultados de filtros o una actualización del carrito, y anota los anuncios que falten o molesten.

Redactar un ticket útil

No te limites a escribir «El lector de pantalla lee mal». Un ticket útil indica la URL, la tarea, los pasos exactos, la información esperada y la salida que se ha oído realmente. Ejemplo: «Al enviar sin correo electrónico aparece un error visual; al avanzar con Tab, este aviso no se transmite en el campo de correo electrónico». Añade el nombre del campo afectado y el entorno de pruebas. Así, el equipo de desarrollo puede investigar directamente la causa técnica.

Complementar tus pruebas con experiencia real

Una prueba inicial ayuda a tu equipo a detectar problemas y a verificar cambios. No sustituye ni una evaluación completa de las WCAG ni la experiencia de las personas que usan lectores de pantalla a diario. Para los procesos importantes, planifica pruebas con usuarias y usuarios adecuados. Tras la corrección, compara la misma tarea en el mismo entorno y anota qué combinaciones adicionales siguen pendientes.