Pruebas de accesibilidad automatizadas

Hasta ahora, en este curso aprendiste sobre el individuo, la empresa y aspectos legales de la accesibilidad digital y los conceptos básicos de la accesibilidad digital cumplimiento. Has explorado temas específicos relacionados con el diseño inclusivo y programación, incluido cuándo usar ARIA en lugar de HTML, cómo medir el contraste de color, cuando JavaScript es esencial, entre otros temas.

En los módulos restantes, cambiamos de diseño y compilación a pruebas de accesibilidad. Usaremos un proceso de prueba de tres pasos que incluirá herramientas y técnicas de prueba automatizadas, manuales y de tecnología de asistencia. Usaremos la misma demostración en todos estos módulos de prueba para que la página web pase de ser inaccesible a accesible.

Cada prueba (automatizada, manual y de tecnología de accesibilidad) es fundamental para lograr el producto más accesible posible.

Nuestros estándares se basan en los niveles de cumplimiento A y AA de los Lineamientos de Accesibilidad para el Contenido Web (WCAG) 2.1. Recuerda que la industria, el tipo de producto, las leyes locales y nacionales y las políticas o los objetivos de accesibilidad generales dictan qué lineamientos seguir y los niveles a cumplir. Si no necesitas un estándar específico para tu la recomendación es seguir la última versión de las WCAG. Consulta "¿Cómo se mide la accesibilidad digital?" para obtener información general sobre las auditorías de accesibilidad, los tipos o niveles de cumplimiento, los WCAG y el POUR.

Como saben ahora, el cumplimiento de accesibilidad no es la historia completa cuando se trata de ayudar a las personas con discapacidad. Sin embargo, es un buen punto de partida, ya que proporciona una métrica que puedes probar. Te recomendamos que realices acciones adicionales fuera de las pruebas de conformidad de accesibilidad, como ejecutar pruebas de usabilidad con personas con discapacidades, contratar a personas con discapacidades para que trabajen en tu equipo o consultar a una persona o empresa con experiencia en accesibilidad digital para que te ayude a crear productos más inclusivos.

Conceptos básicos de las pruebas automatizadas

Las pruebas de accesibilidad automatizadas usan software para analizar tu producto digital en busca de problemas de accesibilidad según estándares de cumplimiento de accesibilidad predefinidos.

Ventajas de las pruebas automatizadas de accesibilidad:

• Es fácil repetir las pruebas en diferentes etapas del ciclo de vida del producto.
• Solo unos pocos pasos para ejecutar y resultados muy rápidos.
• No se requieren muchos conocimientos de accesibilidad para ejecutar las pruebas ni comprender los resultados.

Desventajas de las pruebas automatizadas de accesibilidad:

• Las herramientas automáticas no detectan todos los errores de accesibilidad en tu producto.
• Se informaron falsos positivos (se informó un problema que no es un verdadero incumplimiento del WCAG)
• Es posible que se necesiten varias herramientas para diferentes tipos de productos y roles

Las pruebas automatizadas son un excelente primer paso para verificar la accesibilidad de tu sitio web o app, pero no todas las verificaciones se pueden automatizar. Analizaremos con más detalle cómo verificar la accesibilidad de los elementos que no se pueden automatizar en el módulo de pruebas de accesibilidad manuales.

Tipos de herramientas automatizadas

En 1996, el Centro de Tecnología Especial Aplicada (CAST) desarrolló una de las primeras herramientas de prueba de accesibilidad automatizada en línea, llamada “The Bobby Report”. Actualmente, hay más de 100 herramientas de pruebas automatizadas para elegir.

La implementación automática de herramientas varía de las extensiones de accesibilidad del navegador a linters de código, aplicaciones móviles y de escritorio, paneles en línea e incluso de código abierto que puedes usar para compilar tus propias herramientas automatizadas.

La herramienta automatizada que decidas usar puede depender de muchos factores, incluidos los siguientes:

• ¿Con qué estándares y niveles de cumplimiento realizas las pruebas? Esto puede incluir WCAG 2.1, WCAG 2.0, el artículo 508 de EE.UU. o una lista modificada de reglas de accesibilidad.
• ¿Qué tipo de producto digital estás probando? Podría ser un sitio web, app nativa para dispositivos móviles, PDF, kiosco o algún otro producto.
• ¿En qué parte del ciclo de vida de desarrollo de software estás probando tu producto?
• ¿Cuánto tiempo lleva configurar y usar la herramienta? ¿Es para una persona, un equipo o una empresa?
• ¿Quién realizará la prueba: diseñadores, desarrolladores, QA o alguien más?
• ¿Con qué frecuencia quieres que se verifique la accesibilidad? Qué detalles deben ser se incluyen en el informe? ¿Los problemas deberían estar directamente vinculados a la venta de entradas? un sistema de control de calidad?
• ¿Qué herramientas funcionan mejor en tu entorno? ¿Y para tu equipo?

También hay muchos factores adicionales que considerar. Consulta el artículo de WAI sobre "Cómo seleccionar herramientas de evaluación de accesibilidad web" para obtener más información sobre cómo elegir la mejor herramienta para ti y tu equipo.

Demostración: Prueba automatizada

Para la demostración de pruebas de accesibilidad automatizadas, usaremos Lighthouse de Chrome. Lighthouse es una herramienta automatizada de código abierto creada para mejorar la calidad de las páginas web a través de diferentes tipos de auditorías, como el rendimiento, el SEO y la accesibilidad.

Nuestra demostración es un sitio web creado para una organización ficticia, Medical Mysteries Club. Este sitio se ha vuelto inaccesible intencionalmente para la demostración. Parte de esto la inaccesibilidad puede ser visible para ti, y algunos (pero no todos) quedarán atrapados en nuestra prueba automatizada.

Paso 1

Con el navegador Chrome, instala el Extensión de Lighthouse.

Existen muchas formas de integrar Lighthouse en tu flujo de trabajo de pruebas. Usaremos la extensión de Chrome para esta demostración.

Paso 2

Creamos una demo en CodePen. 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 página web de demostración de Google Cloud, que puede interferir con algunas herramientas de prueba.

Obtén más información sobre Modo de depuración de CodePen

Paso 3

Abre las Herramientas para desarrolladores de Chrome y navega hasta la pestaña Lighthouse. Borra todas las opciones de categorías, excepto las "Accesibilidad". Mantén el modo como predeterminado y elige el tipo de dispositivo en el que ejecutas las pruebas.

Paso 4

Haz clic en Analizar la carga de la página y dale tiempo a Lighthouse para que ejecute sus pruebas.

Una vez que se completen las pruebas, Lighthouse mostrará una puntuación que mide cuán accesible es el producto que estás probando. La puntuación de Lighthouse se calcula en función de la cantidad de problemas, los tipos de problemas y el impacto en los usuarios de los problemas detectados.

Más allá de una puntuación, el informe de Lighthouse incluye información detallada sobre qué problemas que detectó y vínculos a recursos para obtener más información sobre cómo solucionarlos de ellos. El informe también incluye pruebas aprobadas o no aplicables y una lista de elementos adicionales que se deben verificar manualmente.

Paso 5

Ahora, revisa un ejemplo de cada problema de accesibilidad automatizado que se descubrió y corrige los estilos y el marcado relevantes.

Problema 1: Roles de ARIA

El primer problema indica lo siguiente: "Los elementos con un [role] ARIA que requieren que los elementos secundarios contengan un [role] específico no tienen algunos o todos esos elementos secundarios obligatorios. Algunos roles superiores de ARIA deben contener roles secundarios específicos para llevar a cabo las funciones de accesibilidad correspondientes". Obtén más información sobre las reglas de roles de ARIA.

En nuestra demostración, el botón de suscripción al boletín informativo falla:

<button role="list" type="submit" tabindex="1">Subscribe</button>

Vamos a solucionarlo.

El botón “subscribe” junto al campo de entrada tiene un rol ARIA incorrecto. En este caso, el rol se puede quitar por completo.

<button type="submit" tabindex="1">Subscribe</button>

Problema 2: ARIA oculto

Los elementos de "[aria-hidden="true"] contienen elementos subordinados que se pueden enfocar. Los objetos descendentes enfocables dentro de un elemento [aria-hidden="true"] impiden que esos elementos interactivos estén disponibles para los usuarios de tecnologías de accesibilidad, como los lectores de pantalla. Obtén más información sobre las reglas aria-hidden.

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>

Solucionemos el problema.

Al campo de entrada se le aplicó un atributo aria-hidden="true". Agregando este atributo oculta el elemento (y todo lo que se anida debajo) de tecnología de accesibilidad.

<input type="email" placeholder="Enter your e-mail address" tabindex="-1" required>

En este caso, debes quitar este atributo de la entrada para permitir que las personas usando tecnología de asistencia para acceder e ingresar información en el campo del formulario.

Problema 3: Nombre del botón

Los botones no tienen nombres accesibles. Si un botón no tiene un nombre de accesibilidad, los lectores de pantalla lo leerán en voz alta como "botón", por lo que resulta inservible para los usuarios que necesitan usar lectores de pantalla.

Obtén más información sobre las reglas de nombres de botones.

<button role="list" type="submit" tabindex="1">Subscribe</button>

Vamos a solucionarlo.

Si quitas el rol de ARIA incorrecto del elemento del botón en problema 1, la palabra "Suscribirse" se convierte en el botón accesible de la fuente de datos. Esta funcionalidad está integrada en el elemento del botón HTML semántico. Existen opciones de patrones adicionales que se deben tener en cuenta para situaciones más complejas.

<button type="submit" tabindex="1">Subscribe</button>

Problema 4: Atributos alt de las imágenes

A los elementos de imagen les faltan atributos [alt]. Los elementos informativos deben apuntar texto alternativo breve y descriptivo. Los elementos decorativos se pueden ignorar con un atributo alt vacío. Obtén más información sobre las reglas de texto alternativo de las imágenes.

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png">
</a>

Vamos a solucionarlo.

Dado que la imagen del logotipo también es un vínculo, módulo de imagen, que se denomina y requiere información de texto alternativo sobre el propósito de la imagen. Normalmente, la primera imagen de la página es un logotipo, así que puedes suponer razonablemente los usuarios de AT sabrán esto, y usted puede decidir no agregar este información contextual a la descripción de la imagen.

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png"
    alt="Go to the home page.">
</a>

Problema 5: Texto del vínculo

Los vínculos no tienen nombres reconocibles. El texto de los vínculos (y el texto alternativo para las imágenes, cuando se usan como vínculos) que sea reconocible, único y enfocable mejora la de navegación para usuarios de lectores de pantalla. Obtén más información sobre las reglas de texto de los vínculos.

<a href="#!"><svg><path>...</path></svg></a>

Vamos a solucionarlo.

Todas las imágenes interactivas de la página deben incluir información sobre adónde dirige el vínculo a los usuarios. Un método para solucionar este problema es agregar texto alternativo a la imagen sobre el propósito, como lo hiciste en la imagen del logotipo en el ejemplo. Esto funciona muy bien para una imagen que usa una etiqueta <img>, pero <svg> Las etiquetas no pueden usar este método.

Para los íconos de redes sociales, que usan etiquetas <svg>, puedes usar un diferente patrón de descripción alternativo segmentada para SVG, agrega la información entre las etiquetas <a> y <svg> y, luego, ocultarlo visualmente para los usuarios, agregar un ARIA compatible u otras opciones. Según tu entorno y las restricciones de código, es posible que un método sea preferible a otro.

Usa la opción de patrón más simple con el patrón más asistivo de cobertura tecnológica, que agrega un role="img" a la etiqueta <svg> y incluido un elemento <title>.

<a href="#!">
  <svg role="img">
    <title>Connect on our Twitter page.</title>
    <path>...</path>
  </svg>
</a>

Problema 6: Contraste de color

Los colores de fondo y de primer plano no tienen una relación de contraste suficiente. Los textos con poco contraste resultan difíciles o imposibles de leer para muchos usuarios. Obtén más información sobre las reglas de contraste de color.

Se informaron dos ejemplos.

Vamos a solucionarlo.

Se detectaron muchos problemas de contraste de color en la página web. Como aprendiste en el módulo Color y contraste, el texto de tamaño normal (menos de 18 pt/24 px) tiene un requisito de contraste de color de 4.5:1, mientras que el texto de tamaño grande (al menos 18 pt/24 px o 14 pt/18.5 px en negrita) y los íconos esenciales deben cumplir con el requisito de 3:1.

En el caso del título de la página, el texto verde azulado debe cumplir con el contraste de color de 3:1 ya que es un texto de 24 px de tamaño grande. Sin embargo, los botones verde azulado se consideran texto de tamaño normal en negrita de 16 px, por lo que deben cumplir con el requisito de contraste de color de 4.5:1.

En este caso, podríamos encontrar un color verde azulado que fuera lo suficientemente oscuro como para cumplir con 4.5:1, o podríamos aumentar el tamaño del texto del botón a 18.5 px en negrita y cambiar el el valor del color verde azulado ligeramente. Cualquiera de los métodos se mantiene en línea con el diseño estética.

Todo el texto gris sobre el fondo blanco también falla en el contraste de color, excepto para los dos títulos más grandes de la página. Este texto se debe oscurecer para cumplir los requisitos de contraste de color de 4.5:1.

Problema 7: Estructura de la lista

Los elementos de lista (<li>) no se encuentran dentro de elementos superiores <ul> o <ol>. Los lectores de pantalla requieren que los elementos de lista (<li>) se incluyan en un elemento <ul> o <ol> superior para leerlos correctamente.

Obtén más información sobre las reglas de las listas.

<div class="ul">
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</div>

Vamos a solucionarlo.

En esta demostración, usamos una clase de CSS para simular la lista desordenada en lugar de usar una etiqueta <ul>. Cuando escribimos este código de forma incorrecta, eliminamos la parte las funciones de HTML semánticas integradas en esta etiqueta. Si reemplazas la clase por un valor <ul> y modificamos el CSS relacionado, resolvimos este problema de accesibilidad.

<ul>
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</ul>

Problema 8: tabindex

Algunos elementos tienen un valor de tabindex superior a 0. Un valor superior a 0 implica un orden de navegación explícito. Aunque técnicamente esta es una posibilidad válida, suele producir experiencias frustrantes para los usuarios que necesitan usar las tecnologías de accesibilidad. Obtén más información sobre las reglas de tabindex.

<button type="submit" tabindex="1">Subscribe</button>

Vamos a solucionarlo.

A menos que haya un motivo específico para interrumpir el orden de tabulación natural en una página web, no es necesario tener un número entero positivo en un atributo tabindex. Para mantener el orden de tabulación natural, podemos cambiar el tabindex a 0 o quitar el atributo por completo.

<button type="submit">Subscribe</button>

Paso 6

Ahora que ya solucionaste todos los problemas de accesibilidad automatizada, abre una nueva ventana página del modo de depuración. Vuelve a ejecutar la auditoría de accesibilidad de Lighthouse. Tu puntuación debería ser mucho mejor que en la primera ejecución.

Aplicamos todas estas actualizaciones de accesibilidad automáticas a un nuevo CodePen.

Próximo paso

Buen trabajo. Ya lograste mucho, pero aún no lo has terminado. A continuación, pasaremos a las verificaciones manuales, como se detalla en manual de pruebas de accesibilidad.

Verifica tu comprensión

Pon a prueba tus conocimientos sobre las pruebas automatizadas de accesibilidad