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, pasamos de diseñar y desarrollar a probar para mejorar la 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. Más tarde usar la misma demostración en estos módulos de prueba para hacer avanzar la página web desde inaccesible para la accesibilidad.
Cada prueba (tecnología automatizada, manual y de asistencia) es fundamental para lograr el sea el producto más accesible posible.
Nuestras pruebas se basan en las Pautas de accesibilidad de contenido web (WCAG) 2.1 nivel de conformidad A y AA como nuestro con los estándares necesarios. Recuerda que tu industria, el tipo de producto, las leyes locales o nacionales y las políticas o los objetivos de accesibilidad generales dictarán 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 auditorías de accesibilidad, tipos/niveles de cumplimiento, WCAG y PULIR.
Como saben ahora, el cumplimiento de accesibilidad no es la historia completa cuando se trata de ayudar a las personas con discapacidad. Pero 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 cumplimiento de accesibilidad, como realizar pruebas de usabilidad con personas con discapacidad, contratar personas con discapacidades para trabajar en tu equipo o consultar a una persona o empresa con experiencia en accesibilidad digital para ayudarte a crear productos más inclusivos.
Conceptos básicos de las pruebas automatizadas
Las pruebas automatizadas de accesibilidad usan software para escanear tu producto digital en busca de problemas de accesibilidad en función de estándares de cumplimiento de accesibilidad predefinidos.
Ventajas de las pruebas automatizadas de accesibilidad:
- Es fácil repetir pruebas en diferentes etapas del ciclo de vida del producto.
- Solo unos pasos para ejecutar 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.
- Se informaron falsos positivos (se informa un problema que no es un verdadero incumplimiento de las WCAG)
- Es posible que se necesiten varias herramientas para diferentes tipos de productos y funciones.
Las pruebas automatizadas son un excelente primer paso para verificar si tu sitio web o aplicación accesibilidad, pero no todas las comprobaciones se pueden automatizar. Veremos en detalle sobre cómo comprobar la accesibilidad de los elementos que no se pueden automatizar en el manual de pruebas de accesibilidad.
Tipos de herramientas automatizadas
Una de las primeras herramientas de prueba de accesibilidad automatizadas y en línea se desarrolló en 1996 por el Centro de Tecnología Especial Aplicada (CAST), llamado "El informe de Bobby". Hoy en día Más de 100 herramientas de pruebas automatizadas para elegir de!
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 utilizar puede depender de muchos factores, entre los que se incluyen los siguientes:
- ¿Con qué estándares y niveles de cumplimiento realizas las pruebas? Esto puede incluyen WCAG 2.1, WCAG 2.0 y EE.UU. el artículo 508 o una lista modificada de las 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.
- ¿Qué parte del ciclo de vida del desarrollo de software estás probando tu producto?
- ¿Cuánto tiempo lleva configurar y usar la herramienta? Para un individuo, equipo o empresa?
- ¿Quién realiza la prueba: diseñadores, desarrolladores, QA, etc.?
- ¿Con qué frecuencia quieres que se revise 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 se deben considerar. Consultar el artículo de WAI en “Cómo seleccionar las 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 la API de Chrome Faro. Lighthouse es una herramienta automatizada de código abierto creada para mejorar la calidad de a través de diferentes tipos de auditorías, como de rendimiento, SEO 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.
Hay muchas maneras de integrar Lighthouse en tu flujo de trabajo de prueba. Usaremos la extensión de Chrome para esta demostración.
Paso 2
Compilamos una demostración 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
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 3
Abre las Herramientas para desarrolladores de Chrome y navega hasta la pestaña Lighthouse. Desmarca todas las opciones de categorías, excepto "Accesibilidad". Mantén el modo predeterminado y elige el tipo de dispositivo que estés ejecutaste las pruebas.
Paso 4
Haz clic en el botón "Analizar carga de página" y darle tiempo a Lighthouse para que ejecute sus pruebas.
Una vez que se completan las pruebas, Lighthouse muestra una puntuación que mide cuánto accesible el producto que estás probando. El Puntuación de Lighthouse se calcula a partir de la cantidad de problemas, los tipos de problemas y el impacto en los usuarios 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, veamos un ejemplo de cada problema de accesibilidad automatizado y corregir los estilos y el lenguaje de marcado relevantes.
Problema 1: Roles de ARIA
El primer problema dice lo siguiente: “Hay elementos con un [rol] ARIA que requieren que los niños contienen un [role] específico, y les faltan algunos o todos los niños necesarios. Algunos roles superiores de ARIA deben contener roles secundarios específicos para realizar sus funciones de accesibilidad previstas". Obtén más información sobre las reglas de los 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>
Solucionémoslo.
El botón para suscribirse El botón junto al campo de entrada tiene un rol de ARIA incorrecto que se le aplicaron. 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. Enfocable
elementos subordinados dentro de un elemento [aria-hidden="true"] impiden que
elementos estén disponibles para los usuarios de tecnologías de asistencia, como la pantalla
lectores. 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>
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. Cuando un botón no tiene un elemento nombre accesible, los lectores de pantalla lo leerán en voz alta como "botón", lo que la hace inutilizable para los usuarios que dependen de los 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>
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. Hay son opciones de patrones adicionales que se deben considerar en 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]. Los elementos informativos deben apuntar
texto alternativo breve y descriptivo. Los elementos decorativos se pueden ignorar con
un atributo alt vacío Más información sobre el texto alternativo de la imagen
reglas.
<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, módulo de imagen, que se denomina módulo 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>
Todas las imágenes prácticas de la página deben incluir información sobre dónde
el vínculo enviará a los usuarios. Un método para solucionar este problema es agregar
texto a la imagen sobre el propósito, como lo hiciste en la imagen del logotipo en la
ejemplo anterior. 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
en tu entorno y restricciones de código, puede ser preferible usar un método en lugar
con el otro. Usemos 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 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 relación de contraste de color es de 2.9:1.
Ver captura de pantalla en tamaño original
.
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 4.2:1.
Ver captura de pantalla en tamaño original
Solucionémoslo.
Se detectaron muchos problemas de contraste de color en la página web. Como aprendiste en el módulo color and contraste El texto de tamaño normal (menos de 18 pt / 24 px) exige que el contraste de color sea de 4.5:1, mientras 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 están se considera texto de tamaño normal y tiene 16 px en negrita, por lo que debe cumplir con el color de 4.5:1. requisito de contraste.
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 mantendrá 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.
.
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 original
.
Mermaid syndrome ahora tiene un valor de color de #767676 y el fondo sigue siendo #ffffff. La relación de contraste de color es 4.5:1.
Ver captura de pantalla en tamaño original
Problema n.o 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>) estén incluidos en un elemento superior
<ul> o <ol> para anunciar correctamente.
Obtén más información sobre las reglas de 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 desordenada, en lugar de
con 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 n.o 8: tabindex
Algunos elementos tienen un valor [tabindex] superior a 0. Un valor superior a 0 implica un orden de navegación explícito. Aunque técnicamente es válido, esto a menudo crea experiencias frustrantes para los usuarios que dependen de las tecnologías de asistencia. Obtén más información sobre las reglas de tabindex.
<button type="submit" tabindex="1">Subscribe</button>
A menos que haya una razón específica para interrumpir el orden natural de tabulación en una Web
no es necesario tener un número entero positivo en un atributo tabindex. Para
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 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.
Ya aplicamos todas estas actualizaciones automáticas de accesibilidad a una nueva CodePen.
Próximo paso
Buen trabajo. Ya lograste mucho, pero aún no lo has terminado. Luego, pasaremos a las verificaciones manuales, como se detalla en manual de pruebas de accesibilidad.
Verifica tus conocimientos
Pon a prueba tus conocimientos sobre las pruebas automatizadas de accesibilidad
¿Qué tipo de prueba deberías realizar para garantizar que tu sitio sea accesible?
¿Qué errores se detectan en las pruebas automatizadas?