Este módulo se centra en el uso de tecnología de accesibilidad (AT) para las pruebas de accesibilidad. Una persona con discapacidades puede usar la AT para ayudar a aumentar, mantener o mejorar las capacidades al realizar una tarea.
En el espacio digital, las AT pueden ser:
- No o de baja tecnología: palitos para la cabeza y la boca, lupas de mano, dispositivos con botones grandes
- Alta tecnología: dispositivos activados por voz, dispositivos de seguimiento ocular, teclados/mouses 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 usar varios tipos de AT en tu flujo de trabajo general de pruebas.
Aspectos básicos de las pruebas de lectores de pantalla
En este módulo, nos enfocaremos en uno de los 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 aplicación. Luego, convierte esa información en voz o braille para el usuario.
Los lectores de pantalla son esenciales para las personas ciegas y sordas, pero también pueden beneficiar a las personas con visión reducida, trastornos de 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 tu sistema operativo (SO), tu navegador favorito y el dispositivo que utilices, un lector de pantalla podría 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 en el que no se calibró, es posible que encuentres más “errores” o un comportamiento inesperado. Los lectores de pantalla funcionan mejor cuando se usan en las siguientes combinaciones.
Comandos del lector de pantalla
Una vez que hayas configurado correctamente el software de lector de pantalla para tu computadora de escritorio o dispositivo móvil, debes consultar la documentación del lector de pantalla (vinculada 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 se usa un lector de pantalla para las pruebas de accesibilidad, el objetivo es detectar problemas en el código que interfieran con el uso de tu sitio web o aplicación, no emular la experiencia de un usuario de lector de pantalla. Como tal, hay muchas cosas que puedes hacer con algunos conocimientos básicos, algunos comandos del lector de pantalla y algo, 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 preguntarles a los usuarios sobre su experiencia a menudo arroja resultados diferentes. Ambos son aspectos importantes para crear productos completamente inclusivos.
Comandos clave para los lectores de pantalla de escritorio
Comandos clave para los lectores de pantalla de dispositivos móviles
Demostración de la prueba del lector de pantalla
Para probar nuestra demostración, usamos Safari en una laptop con MacOS y capturamos sonido. Puedes seguir 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 todas las actualizaciones de accesibilidad automáticas y manuales aplicadas.
Mírala en modo de depuración para continuar con la
las próximas pruebas. Esto es importante, ya que quita el <iframe>
que rodea la
una página web de demostración que puede interferir con algunas herramientas de prueba. Obtén más información sobre
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 revises la página completa de arriba abajo antes de enfocarte en temas específicos.
Grabamos el lector de pantalla para cada problema, antes y después de que se apliquen 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 principales formas en las que las personas navegan por medio de lectores de pantalla. Si no están presentes, el usuario de un lector de pantalla debe 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 en 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 has actualizado todo correctamente, no debería haber cambios visuales, pero la experiencia de tu lector de pantalla habrá mejorado drásticamente.
Algunos elementos inaccesibles no se pueden observar simplemente mirando el sitio. Tal vez recuerdes la importancia de los niveles de encabezado y del código HTML semántico en el módulo Estructura del contenido. Es posible que un contenido se vea como 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 debe marcarse como tal y actualizar el código HTML relacionado. Además, asegúrate de actualizar el CSS relacionado.
Ejemplo de punto de referencia: <main>...</main>
Ejemplo de encabezado: <h1>Join the Club</h1>
Si has actualizado todo correctamente, no debería haber cambios visuales, pero la experiencia de tu lector de pantalla habrá mejorado drásticamente.
Problema 2: Contexto del vínculo
Es importante brindarles contenido a los usuarios de lectores de pantalla sobre el propósito de un vínculo y si este los redirecciona a una ubicación nueva fuera del sitio web o la app.
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 diversas enfermedades poco frecuentes que podrían beneficiarse si se agrega contexto adicional, especialmente porque se redireccionan a una ubicación nueva.
<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease">
Maple syrup urine disease (MSUD)
</a>
Para solucionar este problema para los usuarios de lectores de pantalla, actualizamos el código para agregar más información sin afectar el elemento de las imágenes. O bien, para ayudar a más personas, como las que padecen trastornos cognitivos y de lectura, es posible que agreguemos texto visual adicional en su lugar.
Existen muchos patrones diferentes que podemos considerar para agregar información adicional sobre vínculos. Debido a nuestro entorno simple que admite solo un idioma, 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 la 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 detectar el SVG intercalado que actúa como la 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 de forma explícita 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 decorativa. En función de esa decisión, debemos agregar el texto alternativo de la imagen adecuado (imagen informativa) u ocultar la imagen para los usuarios de lectores de pantalla (decorativa).
Analizamos las ventajas y desventajas de clasificar mejor la imagen y decidimos que era decorativa, lo que significa que queremos agregar o modificar el código para ocultarla. 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 que omita esta imagen y no la incluya en el grupo de imágenes.
<div class="section-right">
<svg role="presentation">...</svg>
</div>
Problema 4: Decoración con viñetas
Tal vez 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 como se explicó en el módulo Imágenes, la imagen aún debe modificarse, ya que interrumpe el flujo del contenido y podrían distraer o confundir al usuario de un lector de pantalla.
<p class="bullet">...</p>
De manera muy similar al ejemplo de imagen decorativa que se analizó antes, puedes agregar un elemento role="presentation"
al HTML con la clase de viñeta para ocultarlo del lector de pantalla. Del mismo modo, un role="none"
funcionaría. Solo asegúrate de no usar aria-hidden: true
o 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 formularios 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 registro al boletín informativo. Hay un elemento marcador de posición de texto, pero esto 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 se conecta de manera programática al campo del formulario y se agregó el 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 el Codepen actualizado para esta demostración.
Ahora, puedes usar lo que has aprendido para revisar la accesibilidad de tus propios sitios web y aplicaciones.
El objetivo de todas estas pruebas de accesibilidad es abordar problemas que un usuario puede encontrar. Sin embargo, esto no significa que tu sitio web o aplicación será perfectamente accesible cuando hayas terminado. Entenderás a los más exitosos diseñar tu sitio web o aplicación con accesibilidad durante todo el proceso, y incorporando estas pruebas a las demás 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 accesibilidad?