Pruebas de tecnología de accesibilidad

Este módulo se centra en el uso de la 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:

• Sin tecnología 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 adaptables y mouse
• Hardware: botones de interruptores, teclados ergonómicos, dispositivo braille con actualización automática
• Software: programas de texto a voz, subtítulos en vivo y lectores de pantalla

Te recomendamos que uses varios tipos de AT en tu flujo de trabajo de pruebas general.

Conceptos básicos de las pruebas de lectores de pantalla

En este módulo, nos enfocamos 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 app. Luego, convierte esa información en salida de 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 y discapacidades cognitivas.

Compatibilidad del navegador

Hay varias opciones de lectores de pantalla disponibles. 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 uses, un lector de pantalla podría destacarse como la mejor opción. La mayoría de los lectores de pantalla se compilan 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 comportamientos inesperados. Los lectores de pantalla funcionan mejor cuando se usan en las siguientes combinaciones.

Comandos del lector de pantalla

Una vez que tengas la configuración adecuada del software del lector de pantalla para tu computadora 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 usas un lector de pantalla para realizar pruebas de accesibilidad, tu objetivo es detectar problemas en el código que interfieran con el uso de tu sitio web o app, no emular la experiencia de un usuario de lector de pantalla. Por lo tanto, hay mucho que puedes hacer con algunos conocimientos básicos, algunos comandos del lector de pantalla y un poco (o mucho) de práctica.

Si necesitas comprender mejor la experiencia del usuario de las personas que usan lectores de pantalla y otros AT, puedes interactuar con muchas organizaciones y personas para obtener esta valiosa información. Recuerda que usar una AT para probar el código en función de un conjunto de reglas y preguntarles a los usuarios sobre su experiencia suele generar resultados diferentes. Ambos son aspectos importantes para crear productos totalmente inclusivos.

Comandos de teclas para lectores de pantalla para computadoras

Comandos de teclas para lectores de pantalla para dispositivos móviles

Demostración de pruebas de lectores 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 encuentres 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.

Míralos en el 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 elijas y ve a la página de demostración. Te recomendamos que navegues por toda la página de arriba abajo antes de enfocarte en problemas 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 ejecutes 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 que las personas navegan en los lectores de pantalla. Si no están presentes, el usuario de un lector de pantalla tiene que leer toda la página para comprender el contexto. Esto puede demorar 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 del lector de pantalla mejorará de forma significativa.

Vamos a solucionarlo.

Algunos elementos inaccesibles no se pueden observar simplemente mirando el sitio. Es posible que recuerdes la importancia de los niveles de encabezados y el HTML semántico del módulo Estructura del contenido. Un contenido puede parecer un encabezado, pero en realidad está envuelto en un <div> estilizado.

Para solucionar el problema con los encabezados y los lugares de interés, primero debes identificar cada elemento que debe marcarse 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 del lector de pantalla mejorará de forma significativa.

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 las diversas enfermedades raras que podrían beneficiarse de contexto adicional, en especial, porque redireccionan a una ubicación nueva.

<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease">
  Maple syrup urine disease (MSUD)
</a>

Vamos a solucionarlo.

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 visual. O bien, para ayudar a aún más personas, como aquellas con trastornos cognitivos y de lectura, podemos optar por agregar texto visual adicional.

Hay muchos patrones diferentes que podemos considerar para agregar información adicional del vínculo. En nuestro entorno, que admite un solo idioma, una etiqueta ARIA es una opción sencilla 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 detectar el SVG intercalado que actúa como la imagen principal de la pantalla de presentación en nuestra página de demostración. Sin embargo, el lector de pantalla la encuentra y la 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>

Vamos a solucionarlo.

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 imagen adecuado (imagen informativa) o 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 de viñetas

Es posible que hayas notado que el lector de pantalla lee la imagen de viñeta de CSS en las secciones de enfermedades raras. Si bien no es el tipo tradicional de imagen que analizamos en el módulo Imágenes, la imagen se debe modificar de todos modos, ya que interrumpe el flujo del contenido y podría distraer o confundir al usuario de un lector de pantalla.

<p class="bullet">...</p>

Vamos a solucionarlo.

Al igual que en el ejemplo de imagen decorativa que se analizó antes, puedes agregar un role="presentation" al código HTML con la clase de viñeta para ocultarlo del lector de pantalla. Del mismo modo, funcionaría un role="none". Solo asegúrate de no usar aria-hidden: true, o bien 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 de formulario

En el módulo Forms, 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 faltan una etiqueta visual y una programática en el campo de correo electrónico de registro para el boletín informativo. Hay un elemento de marcador de posición de texto, pero 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>

Vamos a solucionarlo.

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 forma programática al campo del 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 el CodePen actualizado 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 posible de problemas que un usuario podría encontrar. Sin embargo, esto no significa que tu sitio web o aplicación estarán perfectamente accesibles una vez que termines. Para tener más éxito, diseña tu sitio web o aplicación con accesibilidad durante todo el proceso y, luego, incorpora estas pruebas con las demás pruebas previas al lanzamiento.

Verifica tus conocimientos

Pon a prueba tus conocimientos sobre las pruebas de accesibilidad automatizadas