Hasta ahora, en este curso, aprendiste sobre los aspectos individuales, empresariales y legales de la accesibilidad digital, y los conceptos básicos del cumplimiento de la accesibilidad digital. Exploraste temas específicos relacionados con el diseño y la codificación inclusivos, por ejemplo, cuándo usar ARIA en comparación con HTML, cómo medir el contraste de color y cuándo JavaScript es esencial, entre otros temas.
En los módulos restantes, pasaremos del diseño y la compilación a las pruebas de accesibilidad. Utilizaremos un proceso de prueba de tres pasos que incluye herramientas y técnicas de prueba de tecnología automatizada, manual y de asistencia. Usaremos la misma demostración en 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.
Nuestras pruebas se basan en los niveles de cumplimiento A y AA de las Pautas de accesibilidad de contenido web (WCAG) 2.1. Recuerda que tu industria, tipo de producto, leyes y políticas locales o nacionales, o los objetivos de accesibilidad generales determinarán los lineamientos que debes seguir y los niveles que debes cumplir. Si no necesitas un estándar específico para tu proyecto, la recomendación es seguir la última versión de WCAG. Consulta la sección "¿Cómo se mide la accesibilidad digital?" para obtener información general sobre las auditorías de accesibilidad, los tipos y niveles de conformidad, WCAG y Pour.
Como sabes, el cumplimiento de la accesibilidad no es la historia completa cuando se trata de brindar asistencia a las personas con discapacidades. Sin embargo, es un buen punto de partida, ya que proporciona una métrica con la que puedes realizar pruebas. Te recomendamos que realices acciones adicionales fuera de las pruebas de conformidad de accesibilidad, como realizar pruebas de usabilidad con personas con discapacidades, contratar a personas con discapacidades para trabajar en tu equipo o consultar a una persona o empresa con experiencia en accesibilidad digital a fin de ayudarte a crear productos más inclusivos.
Conceptos básicos de las pruebas automatizadas
Las pruebas automatizadas de accesibilidad usan software para analizar tu producto digital en busca de problemas de accesibilidad en función de los estándares de cumplimiento de accesibilidad predefinidos.
Ventajas de las pruebas automatizadas de accesibilidad:
- Pruebas fáciles de repetir en diferentes etapas del ciclo de vida del producto
- Solo unos pasos para ejecutarse y resultados muy rápidos
- Se requieren pocos conocimientos sobre accesibilidad para ejecutar las pruebas o comprender los resultados.
Desventajas de las pruebas de accesibilidad automatizadas:
- Las herramientas automáticas no detectan todos los errores de accesibilidad en tu producto.
- Falsos positivos informados (se informa un problema que no es un verdadero incumplimiento de las WCAG)
- Es posible que se necesiten varias herramientas para los distintos tipos de productos y funciones.
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. Profundizaremos en 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
Una de las primeras herramientas de prueba de accesibilidad automatizada en línea fue desarrollada en 1996 por el Center for Applied Special Technology (CAST), llamada "The Bobby Report" (El informe de Bobby). Hoy en día, puedes elegir entre más de 100 herramientas de prueba automatizadas.
La implementación automatizada de herramientas varía desde las extensiones de accesibilidad del navegador hasta los linters de código, las aplicaciones para computadoras y dispositivos móviles, los paneles en línea y las APIs de código abierto que puedes usar para compilar tus propias herramientas automatizadas.
La herramienta automatizada que decidas utilizar puede depender de muchos factores, entre los que se incluyen los siguientes:
- ¿Qué estándares y niveles de cumplimiento estás probando? Esto puede incluir las WCAG 2.1, las 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, una aplicación web, una aplicación nativa para dispositivos móviles, un PDF, un kiosco o algún otro producto.
- ¿En qué parte del ciclo de vida del desarrollo de software estás probando el producto?
- ¿Cuánto tiempo lleva configurar y usar la herramienta? ¿Para una persona, un equipo o una empresa?
- Quién realiza la prueba: diseñadores, desarrolladores, QA, etc.
- ¿Con qué frecuencia quieres que se revise la accesibilidad? ¿Qué detalles se deben incluir en el informe? ¿Los problemas deberían vincularse directamente a un sistema de tickets?
- ¿Qué herramientas funcionan mejor en tu entorno? ¿Para tu equipo?
También hay muchos factores adicionales que se deben tener en cuenta. 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 seleccionar la mejor herramienta para ti y tu equipo.
Demostración: Prueba automatizada
Para la demostración de la prueba automatizada de accesibilidad, usaremos Lighthouse de Chrome. Lighthouse es una herramienta automatizada de código abierto creada para mejorar la calidad de las páginas web mediante diferentes tipos de auditorías, como el rendimiento, la SEO y la accesibilidad.
Nuestra demostración es un sitio web creado para una organización ficticia, Medical Mysteries Club. Este sitio se hizo inaccesible de manera intencional para la demostración. Es posible que puedas ver una parte de esta inaccesibilidad y otra parte (pero no todos) se capturará en nuestra prueba automatizada.
Paso 1
En el navegador Chrome, instala la extensión de Lighthouse.
Hay muchas maneras de integrar Lighthouse en tu flujo de trabajo de pruebas. En esta demostración, usaremos la extensión de Chrome.
Paso 2
Creamos una demostración en CodePen.
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 3
Abre las Herramientas para desarrolladores de Chrome y navega a la pestaña Lighthouse. Desmarca todas las opciones de categorías, excepto "Accesibilidad". Mantén el modo como predeterminado y elige el tipo de dispositivo en el que realizarás las pruebas.
Paso 4
Haz clic en el botón "Analizar la carga de la página" y espera a Lighthouse para que ejecute sus pruebas.
Una vez que se completan las pruebas, Lighthouse muestra una puntuación que mide la accesibilidad del producto que estás probando. La puntuación de Lighthouse se calcula según la cantidad de problemas, los tipos de problemas y el impacto que tienen los problemas detectados en los usuarios.
Además de una puntuación, el informe de Lighthouse incluye información detallada sobre los problemas que detectó y vínculos a recursos para obtener más información sobre cómo solucionarlos. El informe también incluye las pruebas que se aprobaron o no y una lista de elementos adicionales que se deben verificar de forma manual.
Paso 5
Ahora, veamos un ejemplo de cada problema de accesibilidad automatizada descubierto y corrijamos los estilos y el lenguaje de marcado relevantes.
Problema 1: roles de ARIA
El primer problema indica lo siguiente: "A los elementos con un [rol] ARIA que requieren elementos secundarios que contengan un [role] específico les faltan algunos o todos los elementos secundarios obligatorios. Algunos roles principales de ARIA deben contener roles secundarios específicos para realizar las funciones de accesibilidad previstas. 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 "Suscribirse" junto al campo de entrada tiene una función de ARIA incorrecta aplicada. En este caso, el rol se puede quitar por completo.
<button type="submit" tabindex="1">Subscribe</button>
Problema 2: ARIA oculto
Los elementos "[aria-hidden="true"] contienen elementos subordinados enfocables. Los elementos subordinados 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 de aria-hidden.
<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>
Se aplicó un atributo aria-hidden="true" al campo de entrada. Cuando agregas este atributo, se oculta el elemento (y todo lo que está anidado debajo) de la tecnología de asistencia.
<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 que usan tecnología de accesibilidad tengan acceso a la información y la ingresen 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 accesible, 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 para asignar nombres a los botones.
<button role="list" type="submit" tabindex="1">Subscribe</button>
Cuando quitas la función de ARIA incorrecta del elemento del botón en el problema 1, la palabra "Suscribirse" se convierte en el nombre del botón al que se puede acceder. Esta funcionalidad está integrada en el elemento de botón HTML semántico. Existen opciones de patrones adicionales para tener en cuenta en situaciones más complejas.
<button type="submit" tabindex="1">Subscribe</button>
Problema 4: Atributos alt de imagen
A los elementos de imagen les faltan atributos [alt]. El texto alternativo de los elementos informativos
debe ser corto 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>
Dado que la imagen del logotipo también es un vínculo, en el módulo de imágenes sabes que se denomina imagen procesable y requiere información de texto alternativa sobre el propósito de la imagen. Por lo general, la primera imagen de la página es un logotipo, por lo que puedes suponer razonablemente que tus usuarios de AT lo sabrán y puedes decidir no agregar esta información contextual adicional a la descripción de tu 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 vínculo (y el texto alternativo para las imágenes, cuando se usa como vínculos) que sea reconocible, único y enfocable mejora la experiencia de navegación para los 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>
Todas las imágenes prácticas de la página deben incluir información sobre el destino al que dirigirá 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 hiciste en la imagen del logotipo del ejemplo anterior. Esto funciona muy bien para una imagen que usa una etiqueta <img>, pero las etiquetas <svg> no pueden usar este método.
En el caso de los íconos de redes sociales, que usan etiquetas <svg>, puedes usar un patrón de descripción alternativo diferente orientado a SVG, agregar la información entre las etiquetas <a> y <svg>, y, luego, ocultarla visualmente para los usuarios, agregar un ARIA compatible y otras opciones. Según tu entorno y las restricciones de código, es posible que sea preferible usar un método en lugar de otro. Usemos la opción de patrón más simple con la mayor cobertura de tecnología de accesibilidad, que es agregar un role="img" a la etiqueta <svg> e incluir 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 colores.
Se informaron dos ejemplos.
Medical Mysteries Club , tiene un valor hexadecimal de color de #01aa9d y el valor hexadecimal de fondo es #ffffff. La proporción de contraste de color es de 2.9:1.
Ver captura de pantalla en tamaño completo.
Mermaid syndrome tiene un valor hexadecimal de texto de #7c7c7c, mientras que el color hexadecimal del fondo es #ffffff. La proporción de contraste de color es de 4.2:1.
Ver captura de pantalla en tamaño completo.
Solucionaremos el problema.
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 de color verde azulado debe cumplir con el requisito de contraste de color de 3:1, ya que es texto de tamaño grande de 24 px. 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 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 ligeramente el valor del color verde azulado. Cualquiera de los dos métodos se mantendrá en línea con la estética de diseño.
Tampoco se produce el contraste de color en ningún texto gris sobre fondo blanco, excepto en los dos encabezados más grandes de la página. Este texto se debe oscurecer para cumplir con los requisitos de contraste de color de 4.5:1.
Medical Mysteries Club, se le asignó un valor de color de #008576, y el fondo sigue siendo #ffffff. La relación de contraste de color actualizada es de 4.5:1.
Ver captura de pantalla en tamaño completo.
Mermaid syndrome ahora tiene un valor de color de #767676, y el fondo sigue siendo #ffffff. La proporción de contraste de color es de 4.5:1.
Ver captura de pantalla en tamaño completo.
Problema 7: Estructura de la lista
Los elementos de lista (<li>) no se encuentran dentro de los elementos principales <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>
En esta demostración, usamos una clase de CSS para simular la lista no ordenada en lugar de usar una etiqueta <ul>. Cuando escribimos este código de forma incorrecta, quitamos las funciones semánticas de HTML inherentes a esta etiqueta. Para resolver este problema de accesibilidad, reemplazas la clase por una etiqueta <ul> real y modificas el CSS relacionado.
<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 n.o 8: tabindex
Algunos elementos tienen un valor [tabindex] superior a 0. Un valor mayor que 0 implica un orden de navegación explícito. Aunque técnicamente es válida, esto suele crear experiencias frustrantes para los usuarios que dependen de las tecnologías de accesibilidad. Obtén más información sobre las reglas de tabindex.
<button type="submit" tabindex="1">Subscribe</button>
A menos que haya un motivo específico para interrumpir el orden natural de tabulación en una página web, no es necesario tener un número entero positivo en un atributo tabindex. Para mantener el orden natural de tabulación, podemos cambiar el tabindex a 0 o quitar el atributo por completo.
<button type="submit">Subscribe</button>
Paso 6
Ahora que corregiste todos los problemas de accesibilidad automatizada, abre una nueva 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 automatizadas a un CodePen nuevo.
Próximo paso
Buen trabajo. Ya lograste mucho, pero aún no terminamos. A continuación, pasaremos a las verificaciones manuales, como se detalla en el módulo de pruebas manuales de accesibilidad.
Verifica tus conocimientos
Pon a prueba tus conocimientos sobre las pruebas automatizadas de accesibilidad
¿Qué tipo de pruebas debes realizar para asegurarte de que tu sitio sea accesible?
¿Qué errores se detectan en las pruebas automatizadas?