Este módulo se enfoca en el uso de la tecnología de asistencia (AT) para las pruebas de accesibilidad. Una persona con discapacidad puede utilizar la AT para ayudar a aumentar, mantener o mejorar las capacidades de realizar una tarea.
En el espacio digital, las AT pueden ser:
- Sin tecnología o con tecnología baja: palillos para la cabeza y la boca, lupas de mano y dispositivos con botones grandes
- Tecnología: dispositivos activados por voz, dispositivos de seguimiento ocular, teclados/mouse adaptables
- Hardware: botones de interruptor, teclados ergonómicos, dispositivo braille de actualización automática
- Software: programas de texto a voz, subtitulado instantáneo, lectores de pantalla
Te recomendamos utilizar varios tipos de AT en tu flujo de trabajo general de las pruebas.
Conceptos básicos de las pruebas de lectores de pantalla
En este módulo, nos enfocamos en una de las AT digitales más populares: los lectores de pantalla. Un lector de pantalla es un software que lee el código subyacente de un sitio web o una app y convierte esa información en voz o texto braille para el usuario.
Los lectores de pantalla son esenciales para las personas ciegas o sordociegas, pero también pueden beneficiar a las personas con visión reducida, trastornos de la lectura o discapacidades cognitivas.
Compatibilidad del navegador
Hay varias opciones de lectores de pantalla disponibles. En la actualidad, los lectores de pantalla más populares son JAWS, NVDA y VoiceOver para computadoras de escritorio, y VoiceOver y TalkBack para dispositivos móviles.
Según el sistema operativo (SO), el navegador favorito y el dispositivo que utilices, un lector de pantalla puede destacarse como la mejor opción. La mayoría de los lectores de pantalla se crean teniendo en cuenta hardware y navegadores web específicos. Cuando usas un lector de pantalla con un navegador para el que no se calibró, es posible que encuentres más "errores" o comportamientos inesperados. Los lectores de pantalla funcionan mejor cuando se usan en las siguientes combinaciones.
Comandos de los lectores de pantalla
Una vez que hayas configurado correctamente el software del lector de pantalla para tu computadora de escritorio o dispositivo móvil, debes consultar la documentación del lector de pantalla (que se incluye en la tabla anterior) y ejecutar algunos comandos esenciales del lector de pantalla para familiarizarte con la tecnología. Si ya usaste un lector de pantalla, considera probar uno nuevo.
Cuando usas un lector de pantalla para pruebas de accesibilidad, tu objetivo es detectar problemas en el código que interfieren con el uso de tu sitio web o aplicación, no emular la experiencia de un usuario de lector de pantalla. Por lo tanto, puedes hacer muchas cosas con conocimientos básicos, algunos comandos de los lectores de pantalla y un poco (o mucha) práctica.
Si necesitas comprender mejor la experiencia del usuario de las personas que utilizan lectores de pantalla y otras AT, puedes interactuar con muchas organizaciones y personas para obtener esta valiosa información. Recuerda que usar una AT para probar el código con un conjunto de reglas y preguntar a los usuarios acerca de su experiencia a menudo produce resultados diferentes. Ambos son aspectos importantes para crear productos completamente inclusivos.
Comandos clave para lectores de pantalla de computadoras de escritorio
Comandos clave para lectores de pantalla de dispositivos móviles
Demostración de prueba del lector de pantalla
Para probar la demostración, usamos Safari en una laptop con MacOS y capturamos sonido. Puedes realizar estos pasos con cualquier lector de pantalla, pero la forma en que encuentras algunos errores puede ser diferente de la que se describe en este módulo.
Paso 1
Visita el CodePen actualizado, que tiene aplicadas todas las actualizaciones de accesibilidad automáticas y manuales.
Obsérvalo en modo de depuración para continuar con las siguientes pruebas. Esto es importante, ya que quita el <iframe> que rodea la página web de demostración, lo que puede interferir con algunas herramientas de prueba. Obtén más información sobre el modo de depuración de CodePen.
Paso 2
Activa el lector de pantalla que prefieras y ve a la página de demostración. Te recomendamos que navegues por toda la página de arriba abajo antes de centrarte en problemas específicos.
Grabamos nuestro lector de pantalla para cada problema, antes y después de aplicar las correcciones a la demostración. Te recomendamos que realices la demostración con tu propio lector de pantalla.
Problema 1: estructura del contenido
Los encabezados y los puntos de referencia son una de las formas principales en que las personas navegan cuando usan los lectores de pantalla. Si no están presentes, el usuario de lector de pantalla deberá leer toda la página para comprender el contexto. Esto puede llevar mucho tiempo y causar frustración. Si intentas navegar por cualquiera de los elementos de la demostración, descubrirás rápidamente que no existen.
- Ejemplo de punto de referencia:
<div class="main">...</div> - Ejemplo de encabezado:
<p class="h1">Join the Club</p>
Si actualizaste todo correctamente, no debería haber cambios visuales, pero la experiencia de tu lector de pantalla habrá mejorado significativamente.
Vamos a solucionarlo.
Algunos elementos inaccesibles no son visibles solo con mirar el sitio. Es posible que recuerdes la importancia de los niveles de encabezados y el código HTML semántico del módulo Estructura del contenido. Un elemento de contenido puede parecer un encabezado, pero en realidad está envuelto en un <div> estilizado.
Para solucionar el problema con los encabezados y los puntos de referencia, primero debes identificar cada elemento que se debe marcar como tal y actualizar el código HTML relacionado. Asegúrate de actualizar también el CSS relacionado.
Ejemplo de punto de referencia: <main>...</main>
Ejemplo de encabezado: <h1>Join the Club</h1>
Si actualizaste todo correctamente, no debería haber cambios visuales, pero la experiencia de tu lector de pantalla habrá mejorado significativamente.
Problema 2: contexto del vínculo
Es importante brindarles a los usuarios de lectores de pantalla contenido sobre el propósito de un vínculo y si el vínculo los redirecciona a una ubicación nueva fuera del sitio web o la aplicación.
En nuestra demostración, corregimos la mayoría de los vínculos cuando actualizamos el texto alternativo de la imagen activa, pero hay algunos vínculos adicionales sobre las diversas enfermedades poco frecuentes que podrían beneficiarse del contexto adicional, especialmente porque redireccionan a una nueva ubicación.
<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease">
Maple syrup urine disease (MSUD)
</a>
A fin de solucionar este problema para los usuarios de lectores de pantalla, actualizamos el código para agregar más información sin afectar los elementos visuales. O bien, para ayudar a más personas, como aquellas con trastornos de la lectura y de la cognición, podríamos optar por agregar más texto visual.
Existen muchos patrones diferentes que podemos considerar para agregar información adicional sobre los vínculos. Según nuestro entorno simple que admite solo un lenguaje, una etiqueta ARIA es una opción directa en esta situación. Es posible que notes que la etiqueta ARIA anula el texto del vínculo original, así que asegúrate de incluir esa información en tu actualización.
<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease"
aria-label="Learn more about Maple syrup urine disease on the Rare Diseases website.">
Maple syrup urine disease (MSUD)
</a>
Problema 3: imagen decorativa
En nuestro módulo de pruebas automatizadas, Lighthouse no pudo captar el SVG intercalado que actúa como imagen de presentación principal en nuestra página de demostración, pero el lector de pantalla lo encuentra y lo anuncia como "imagen" sin información adicional. Esto es así, incluso sin agregar explícitamente el atributo role="img" al SVG.
<div class="section-right">
<svg>...</svg>
</div>
Para solucionar este problema, primero debemos decidir si la imagen es informativa o decorada. En función de esa decisión, debemos agregar el texto alternativo de imagen adecuado (imagen informativa) u ocultar la imagen a los usuarios de lectores de pantalla (decoración).
Analizamos los pros y los contras de la mejor manera de categorizar la imagen y decidimos que era decorativa, lo que significa que queremos agregar o modificar el código para ocultar la imagen. Un método rápido es agregar un role="presentation" directamente a la imagen SVG. Esto envía una señal al lector de pantalla para omitir esta imagen y no incluirla en el grupo de imágenes.
<div class="section-right">
<svg role="presentation">...</svg>
</div>
Problema 4: Decoración de viñetas
Quizás hayas notado que el lector de pantalla lee la imagen de viñeta de CSS en las secciones de enfermedades poco frecuentes. Si bien no es el tipo tradicional de imagen que analizamos en el módulo Imágenes, la imagen debe modificarse de todos modos, ya que interrumpe el flujo del contenido y podría distraer o confundir al usuario de lector de pantalla.
<p class="bullet">...</p>
Al igual que en el ejemplo de la imagen decorativa que se analizó anteriormente, puedes agregar un elemento role="presentation" al HTML con la clase de viñetas para ocultarlo del lector de pantalla. Del mismo modo, un elemento role="none" funcionaría. Solo asegúrate de no usar aria-hidden: true. De lo contrario, ocultarás toda la información del párrafo a los usuarios de lectores de pantalla.
<p class="bullet" role="none">...</p>
Problema 5: campo del formulario
En el módulo Formularios, aprendimos que todos los campos del formulario también deben tener una etiqueta visual y programática. Esta etiqueta debe permanecer visible en todo momento.
En nuestra demostración, nos falta una etiqueta visual y programática en el campo de correo electrónico de suscripción al boletín informativo. Hay un elemento de marcador de posición de texto, pero este no reemplaza la etiqueta, ya que no es visualmente persistente y no es totalmente compatible con todos los lectores de pantalla.
<form>
<div class="form-group">
<input type="email" placeholder="Enter your e-mail address" required>
<button type="submit">Subscribe</button>
</div>
</form>
Para solucionar este problema, reemplaza el marcador de posición de texto por un elemento de etiqueta similar. Ese elemento de etiqueta está conectado de manera programática al campo de formulario y se agregó movimiento con JavaScript para mantener la etiqueta visible incluso cuando se agrega contenido al campo.
<form>
<div class="form-group">
<input type="email" required id="youremail" name="youremail" type="text">
<label for="youremail">Enter your e-mail address</label>
<button type="submit" aria-label="Subscribe to our newsletter">Subscribe</button>
</div>
</form>
Conclusión
¡Felicitaciones! Completaste todas las pruebas de esta demostración. Puedes ver todos estos cambios en la versión actualizada de Codepen para esta demostración.
Ahora, puedes usar lo que aprendiste para revisar la accesibilidad de tus propios sitios web y apps.
El objetivo de todas estas pruebas de accesibilidad es abordar la mayor cantidad de problemas posibles que pueda encontrar un usuario. Sin embargo, esto no significa que tu sitio web o app serán fácilmente accesibles cuando termines. Para tener éxito, diseña el sitio web o la app con accesibilidad durante todo el proceso y, luego, incorpora estas pruebas a las otras pruebas previas al lanzamiento.
Verifica tus conocimientos
Pon a prueba tus conocimientos sobre las pruebas automatizadas de accesibilidad
¿Cuál es el mejor lector de pantalla para probar la accesibilidad?
¿Cuál es el propósito de realizar pruebas con tecnología de asistencia?