Hasta ahora, en este curso, aprendiste sobre los aspectos individuales, comerciales 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 programación inclusivos, como cuándo usar ARIA en lugar de HTML, cómo medir el contraste de color y cuándo JavaScript es esencial, entre otros temas.
En los módulos restantes, pasaremos de diseñar y crear a probar la accesibilidad. Compartimos un proceso de prueba de tres pasos que incluye 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, ya sea automatizada, manual o de tecnología de asistencia, es fundamental para lograr el producto más accesible posible. Nuestras pruebas se basan en los niveles de cumplimiento A y AA de los Lineamientos de Accesibilidad para el Contenido Web (WCAG) 2.1 como nuestros estándares.
Recuerda que tu sector, el tipo de producto, las leyes y políticas locales y nacionales, o los objetivos generales de accesibilidad determinan qué lineamientos debes seguir y qué niveles debes cumplir. Si no necesitas un estándar específico para tu proyecto, te recomendamos que sigas la versión más reciente 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 principio POUR.
Como ya sabes, el cumplimiento de la accesibilidad no es todo lo que se necesita para 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 las siguientes acciones, además de las pruebas de cumplimiento, para ayudarte a crear productos más inclusivos:
- Ejecuta pruebas de usabilidad con personas con discapacidad.
- Contrata personas con discapacidades para que trabajen en tu equipo.
- Consulta a una persona o empresa con experiencia en accesibilidad digital.
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 los estándares de cumplimiento de accesibilidad predefinidos.
Ventajas de las pruebas de accesibilidad automatizadas:
- Repite rápidamente las pruebas en diferentes etapas del ciclo de vida del producto.
- Solo requiere unos pocos pasos y los resultados son muy rápidos.
- No se requiere mucho conocimiento sobre accesibilidad para ejecutar las pruebas o comprender los resultados.
Desventajas de las pruebas de accesibilidad automatizadas:
- Las herramientas automatizadas no detectan todos los errores de accesibilidad en tu producto.
- Falsos positivos denunciados (se denuncia un problema que no es un incumplimiento real de las 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 aplicación, pero no todas las verificaciones se pueden automatizar. En el módulo de pruebas de accesibilidad manuales, analizaremos con más detalle cómo verificar la accesibilidad de los elementos que no se pueden automatizar.
Tipos de herramientas automatizadas
Una de las primeras herramientas de prueba de accesibilidad automatizadas en línea fue desarrollada en 1996 por el Center for Applied Special Technology (CAST) y se llamó "The Bobby Report". Actualmente, hay más de 100 herramientas de prueba automatizadas para elegir.
La implementación de herramientas automatizadas varía desde extensiones de accesibilidad para navegadores hasta verificadores de código, aplicaciones para computadoras y dispositivos móviles, paneles en línea y hasta APIs de código abierto que puedes usar para crear 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 conformidad realizas las pruebas? Esto puede incluir los WCAG 2.2, los WCAG 2.1, el artículo 508 de EE.UU. o una lista modificada de reglas de accesibilidad.
- ¿Qué tipo de producto digital estás probando? Puede ser un sitio web, una aplicación web, una aplicación nativa para dispositivos móviles, un PDF, un kiosco o cualquier otro producto.
- ¿En qué parte del ciclo de vida del 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 realiza la prueba: diseñadores, desarrolladores, QA o alguien más?
- ¿Con qué frecuencia quieres que se verifique la accesibilidad? ¿Qué detalles deben incluirse en el informe? ¿Los problemas deben vincularse directamente a un sistema de tickets?
- ¿Qué herramientas funcionan mejor en tu entorno? ¿Para tu equipo?
También hay muchos factores adicionales que debes tener en cuenta. Consulta el artículo de la 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 las de rendimiento, SEO y accesibilidad.
Nuestra demostración es un sitio web creado para una organización ficticia, el Club de Misterios Médicos. Este sitio se hizo inaccesible de forma intencional para la demostración. Es posible que veas algunas de estas inaccesibilidades, y otras (pero no todas) se detectarán en nuestra prueba automática.
Paso 1
Con el navegador Chrome, instala la 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 demostración en CodePen.
Míralo 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. Borra todas las opciones de categorías, excepto "Accesibilidad". Mantén el modo predeterminado y elige el tipo de dispositivo en el que ejecutarás las pruebas.
Paso 4
Haz clic en Analizar la carga de la página y espera a que Lighthouse ejecute sus pruebas.
Una vez que se completan las pruebas, Lighthouse muestra una puntuación que mide el nivel de 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 que no son 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 detectó y corrige los estilos y el lenguaje de marcado pertinentes.
Problema 1: Roles de ARIA
El primer problema indica lo siguiente: "Los elementos con un atributo [role] de ARIA que requieren que los elementos secundarios contengan un atributo [role] específico carecen de 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, falla el botón de suscripción al boletín informativo:
<button role="list" type="submit" tabindex="1">Subscribe</button>
Vamos a solucionarlo.
El botón "Suscribirse" junto al campo de entrada tiene aplicado un rol de 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 "[aria-hidden="true"] contienen elementos secundarios enfocables. Los elementos descendientes 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>
El campo de entrada tenía aplicado un atributo aria-hidden="true". Si agregas este atributo, se oculta el elemento (y todo lo que esté anidado debajo de él) 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 asistencia accedan al campo del formulario y puedan ingresar información en él.
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>
Cuando quitas el rol ARIA impreciso del elemento de botón en el problema 1, la palabra "Suscribirse" se convierte en el nombre accesible del botón. Esta funcionalidad está integrada en el elemento de botón HTML semántico. Existen otras opciones de patrones que puedes considerar para situaciones más complejas.
<button type="submit" tabindex="1">Subscribe</button>
Problema 4: Atributos alt de imágenes
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 usando un atributo alt vacío. Obtén más información sobre las reglas del 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, sabes por el módulo de imagen que se denomina imagen procesable y requiere información de texto alternativo 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 los usuarios de TA lo sabrán, y puedes decidir no agregar esta información contextual adicional 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. Usar textos de vínculo (y textos alternativos para las imágenes, si estas se usan como vínculos) que sean reconocibles y únicos, y que se puedan enfocar mejora la experiencia de navegación de los usuarios de lectores de pantalla. Obtén más información sobre las reglas de texto de vínculos.
<a href="#!"><svg><path>...</path></svg></a>
Todas las imágenes en las que se puede hacer clic de la página deben incluir información sobre el destino al que dirigen los vínculos. 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. 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 alternativa diferente para segmentar los SVG, agregar la información entre las etiquetas <a> y <svg> y, luego, ocultarla visualmente a los usuarios, agregar un ARIA compatible o usar otras opciones. Según tu entorno y las restricciones de código, un método podría ser preferible a otro.
Usa la opción de patrón más simple con la mayor cobertura de tecnología de asistencia, que consiste en agregar un role="img" a la etiqueta <svg> y, luego, 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 adecuada. 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 denunciaron dos ejemplos.
#01aa9d y un valor hexadecimal de fondo de #ffffff.
La relación de contraste de color es de 2.9:1. 
#7c7c7c, mientras que el color hexadecimal del fondo es #ffffff. La relación de contraste de color es de 4.2:1.
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 de color azul verdoso debe cumplir con el requisito de contraste de color de 3:1, ya que se trata de texto de gran tamaño a 24 px. Sin embargo, los botones verde azulado se consideran texto de tamaño normal con 16 px en negrita, por lo que deben cumplir con el requisito de contraste de color de 4.5:1.
En este caso, podríamos encontrar un color azul verdoso lo suficientemente oscuro como para cumplir con la proporción 4.5:1 o aumentar el tamaño del texto del botón a 18.5 px en negrita y cambiar ligeramente el valor del color azul verdoso. Cualquiera de los métodos se mantiene en línea con la estética del diseño.
Todo el texto gris sobre el fondo blanco también falla en cuanto al contraste de color, excepto los dos encabezados más grandes de la página. Este texto debe oscurecerse para cumplir con los requisitos de contraste de color de 4.5:1.
#008576 y el fondo permanece #ffffff. La relación de contraste de color actualizada es de 4.5:1. Haz clic en la imagen para verla en tamaño original.
#767676 y el
fondo sigue siendo #ffffff. La relación de contraste de color es de 4.5:1.
Problema 7: Estructura de la lista
Los elementos de lista (<li>) no se encuentran dentro de elementos principales <ul> o <ol>.
Los lectores de pantalla requieren que los elementos de lista (<li>) se incluyan en un elemento <ul> o <ol> principal 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 CSS para simular la lista desordenada en lugar de usar una etiqueta <ul>. Cuando escribimos este código de forma incorrecta, quitamos las funciones semánticas inherentes de HTML integradas en esta etiqueta. Si reemplazamos la clase por una etiqueta <ul> real y modificamos el CSS relacionado, resolvemos 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. Si el valor es superior a 0, el orden de navegación es 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>
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 solucionaste todos los problemas de accesibilidad automatizados, 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 nuevo CodePen.
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 de accesibilidad manuales.