Pruebas manuales de accesibilidad

Conceptos básicos de las pruebas manuales

Las pruebas manuales de accesibilidad usan pruebas, herramientas y técnicas cognitivas, visuales y de teclado para encontrar problemas que las herramientas automatizadas no pueden detectar. Como las herramientas automatizadas no abarcan todos los criterios de éxito identificados en las WCAG, es vital que no ejecutes pruebas de accesibilidad automatizadas y, luego, dejes de realizarlas.

A medida que avanza la tecnología, se podrían cubrir más pruebas solo con herramientas automatizadas. Sin embargo, hoy en día, es necesario agregar tanto verificaciones manuales como de tecnología de accesibilidad a tus protocolos de pruebas para abarcar todos los puntos de control de las WCAG aplicables.

Ventajas de las pruebas de accesibilidad manuales:

  • Razonablemente sencilla y rápida de ejecutar
  • Detectan un porcentaje mayor de problemas que las pruebas automatizadas solas.
  • Pocas herramientas y experiencia necesarias para el éxito

Desventajas de las pruebas de accesibilidad manuales:

  • Son más complejas y requieren mucho tiempo que las pruebas automatizadas.
  • Puede ser difícil de repetir a gran escala
  • Se requiere más experiencia en accesibilidad para ejecutar pruebas e interpretar los resultados.

Comparemos qué elementos y detalles de accesibilidad puede detectar actualmente una herramienta automatizada con aquellos que no lo harán.

Se puede automatizar No se puede automatizar
Contraste de color del texto sobre fondos sólidos Contraste de color del texto en gradientes o imágenes
Existe texto de imagen alternativo El texto alternativo de la imagen es preciso y está asignado de forma correcta
Existen encabezados, listas y puntos de referencia Los encabezados, listas y puntos de referencia están marcados correctamente y se incluyen todos los elementos.
ARIA está presente ARIA se usa de manera adecuada y se aplica a los elementos correctos.
Cómo identificar elementos que se pueden enfocar en el teclado A qué elementos les falta el enfoque del teclado, el orden del enfoque tiene sentido lógico y el indicador de enfoque es visible
Detección de títulos iFrame iFrame, el orden del enfoque tiene sentido lógico y el indicador de enfoque es visible
El elemento de video está presente El elemento del video debe incluir medios alternativos apropiados (como subtítulos y transcripciones).


Tipos de pruebas manuales

Hay muchas herramientas y técnicas manuales que debes tener en cuenta cuando buscas accesibilidad digital en tu página web o app. Las tres áreas de enfoque más importantes en las pruebas manuales son la funcionalidad del teclado, las revisiones centradas en lo visual y las verificaciones de contenido general.

Abordaremos cada uno de estos temas en un nivel general en este módulo, pero las siguientes pruebas no son una lista exhaustiva de todas las pruebas manuales que puedes o debes ejecutar. Te recomendamos que comiences con una lista de tareas de accesibilidad manual de una fuente confiable y que desarrolles tu propia lista de tareas de prueba manual enfocada para las necesidades específicas de tu equipo y producto digital.

Verificaciones del teclado

Se estima que alrededor del 25% de los problemas de accesibilidad digital están relacionados con la falta de compatibilidad con el teclado. Como aprendimos en el módulo de enfoque del teclado, esto afecta a todos los tipos de usuarios, incluidos los usuarios videntes que solo utilizan el teclado, los usuarios ciegos o con visión reducida y las personas que usan software de reconocimiento de voz que usa tecnología que también depende de que el contenido también esté accesible con el teclado.

Las pruebas de teclado permiten responder preguntas como las siguientes:

  • ¿La página web o la función requieren un mouse para funcionar?
  • ¿El orden de tabulación es lógico e intuitivo?
  • ¿El indicador de enfoque del teclado está siempre visible?
  • ¿Puedes atascarte en un elemento que no debería atrapar el enfoque?
  • ¿Puedes navegar detrás o alrededor de un elemento que debería estar atrapando el foco?
  • Al cerrar un elemento que recibió foco, ¿el indicador de enfoque volvió a un lugar lógico?

Si bien el impacto de la funcionalidad del teclado es enorme, el procedimiento de prueba es bastante simple. Lo único que debes hacer es apartar el mouse o instalar un paquete pequeño de JavaScript y probar tu sitio web usando solo el teclado. Los siguientes comandos son esenciales para las pruebas del teclado.

Clave Resultado
Pestaña Permite mover un elemento activo a otro
Mayúsculas + Tab Retroceder un elemento activo a otro
Flechas Desplazar por los controles relacionados
Barra espaciadora Activa o desactiva los estados y se mueve hacia abajo en la página
Mayúsculas + Barra espaciadora Mueve la página hacia arriba
Ingresar Activa controles específicos
Escape Descarta los objetos que se muestran de forma dinámica

Verificaciones visuales

Las verificaciones visuales se centran en los elementos visuales de la página y utilizan herramientas como la ampliación de pantalla o el zoom del navegador para revisar la accesibilidad del sitio web o la aplicación.

Las verificaciones visuales pueden indicarte lo siguiente:

  • ¿Hay problemas de contraste de color que una herramienta automatizada no podría detectar, como texto sobre un gradiente o una imagen?
  • ¿Hay elementos que parezcan encabezados, listas y otros elementos estructurales, pero que no estén codificados como tales?
  • ¿Los vínculos de navegación y las entradas del formulario son coherentes en todo el sitio web o la aplicación?
  • ¿Hay alguna luz parpadeante, estroboscópica o de animación que exceda las recomendaciones?
  • ¿El contenido tiene los espacios adecuados? ¿Para letras, palabras, líneas y párrafos?
  • ¿Puedes ver todo el contenido con una lupa o zoom del navegador?

Verificaciones de contenido

A diferencia de las pruebas visuales que se enfocan en diseños, movimiento y colores, las verificaciones de contenido se enfocan en las palabras de la página. No solo debes mirar el texto en sí, sino que debes revisar el contexto para asegurarte de que tenga sentido para los demás.

Las verificaciones de contenido permiten responder preguntas como las siguientes:

  • ¿Los títulos de las páginas, los encabezados y las etiquetas de formularios son claros y descriptivos?
  • ¿Las alternativas de imágenes son concisas, precisas y útiles?
  • ¿El color solamente se usa como la única forma de transmitir significado o información?
  • ¿Los vínculos son descriptivos o utilizan texto genérico, como “más información” o “haz clic aquí”?
  • ¿Hay algún cambio en el idioma de una página?
  • ¿Se usa lenguaje sencillo? ¿Todas las siglas se escriben cuando se hace referencia a ellas por primera vez?

Algunas verificaciones de contenido se pueden automatizar, en parte. Por ejemplo, podrías escribir un linter de JavaScript que verifique "Haz clic aquí" y te sugiera hacer un cambio. Sin embargo, estas soluciones personalizadas a menudo necesitan que una persona cambie el texto a algo contextual.

Demostración: Prueba manual

Hasta ahora, ejecutamos pruebas automatizadas en nuestra página web de demostración y encontramos y solucionamos ocho tipos de problemas diferentes. Ahora estamos listos para ejecutar comprobaciones manuales con el fin de ver si podemos descubrir aún más problemas de accesibilidad.

Paso 1

Nuestra demostración de CodePen actualizada tiene todas las actualizaciones de accesibilidad automáticas aplicadas.

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 2

Para iniciar el proceso de prueba manual, deja a un lado el mouse o el panel táctil, y navega hacia arriba y hacia abajo en el DOM con el teclado.

Problema 1: Indicador de enfoque visible

Deberías ver el primer problema del teclado de inmediato (o no deberías verlo), ya que se quitó el indicador de enfoque visible. Cuando escanees el CSS en la demostración, deberías encontrar el temido “outline: none” agregado a la base de código.

  :focus {
    outline: none;
  }
Vamos a solucionarlo.

Como aprendiste en el módulo de enfoque del teclado, debes quitar esta línea de código para permitir que los navegadores web agreguen un enfoque visible para los usuarios. Puedes ir un paso más allá y crear un indicador de enfoque diseñado para adaptarse a la estética de tu producto digital.

:focus {
  outline: 3px dotted #008576;
}

Problema 2: Orden de enfoque

Una vez que hayas modificado el indicador de enfoque y esté visible, asegúrate de recorrer la página con la tecla Tab. Mientras lo haces, notarás que el campo de entrada del formulario que se usa para suscribirte al boletín informativo no recibe el foco. Un tabindex negativo lo quitó del orden natural del foco.

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

Como nos gustaría que las personas usen este campo para registrarse en nuestro boletín informativo, lo único que debemos hacer es quitar el tabindex negativo o establecerlo en cero para permitir que la entrada se vuelva a enfocar en el teclado.

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

Paso 3

Una vez que se verifique el enfoque del teclado, pasaremos a las verificaciones visuales y de contenido.

A medida que realizabas las pruebas del teclado deslizando el tabulador hacia arriba y hacia abajo en la página de demostración, probablemente hayas notado que el teclado se enfocaba en tres vínculos visualmente ocultos en los párrafos sobre diferentes afecciones médicas.

Para que nuestra página sea accesible, los vínculos deben destacarse del texto circundante y, además, incluir un cambio de estilo sin color cuando se coloca el cursor del mouse y se enfoca el teclado.

Solucionaremos el problema.

Una solución rápida es subrayar los enlaces dentro de los párrafos para que se destaquen. Esto resolvería el problema de accesibilidad, pero es posible que no se adapte a la estética de diseño general que esperas lograr.

Si decides no subrayar, deberás modificar los colores de modo que cumplan con los requisitos del fondo y del texto.

Cuando mires la demostración con una herramienta de verificación de contraste de vínculos, verás que el color de los vínculos cumple con el requisito de contraste de color de 4.5:1 entre el texto de tamaño normal y el fondo. Sin embargo, los vínculos no subrayados también deben cumplir con un requisito de contraste de color de 3:1 con respecto al texto que los rodea.

Una opción es cambiar el color de los vínculos para que coincida con los demás elementos de la página. Pero si cambias el color del vínculo a verde, el texto del cuerpo también debe modificarse para que cumpla con los requisitos generales de contraste de color entre los tres elementos: enlaces, fondo y texto que lo rodea.

La captura de pantalla de WebAIM para el texto del vínculo muestra que el vínculo al texto del cuerpo no cumple con el nivel A de las WCAG.
Cuando el texto del vínculo y el cuerpo son iguales, la prueba falla.
La captura de pantalla de WebAIM muestra que todas las pruebas son exitosas cuando el color del vínculo es verde.
Si el texto del vínculo y del cuerpo son diferentes, la prueba se aprueba.

Problema 4: contraste de color del ícono

Otro problema de contraste de color omitido son los íconos de las redes sociales. En el módulo color y contraste, aprendiste que los íconos esenciales deben hacer coincidir un contraste de color de 3:1 con el fondo. Sin embargo, en la demostración, los íconos de las redes sociales tienen una relación de contraste de 1.3:1.

Solucionaremos el problema.

Para cumplir con los requisitos de contraste de color de 3:1, los íconos de las redes sociales se cambian a un gris más oscuro.

Captura de pantalla de la demostración con el analizador de color que muestra el contraste de color de los íconos con errores.

Problema 5: Diseño del contenido

Si observas el diseño del contenido del párrafo, el texto estará completamente justificado. Como aprendiste en el módulo de tipografía, esto crea "ríos del espacio", lo que puede hacer que el texto sea difícil de leer para algunos usuarios.

p.bullet {
   text-align: justify;
}
Vamos a solucionarlo.

Para restablecer la alineación del texto en la demostración, puedes actualizar el código a text-align: left; o quitar esa línea por completo del CSS, ya que la alineación predeterminada para navegadores es la izquierda. Asegúrate de probar el código, en caso de que otros estilos heredados quiten la alineación de texto predeterminada.

p.bullet {
   text-align: left;
}

Paso 4

Captura de pantalla del sitio de demostración del Medical Mysteries Club.
Todos los problemas manuales ya se solucionaron en la demostración, como se muestra en esta imagen.

Una vez que hayas identificado y corregido todos los problemas de accesibilidad manual descritos en los pasos anteriores, tu página debería verse como nuestra captura de pantalla.

Es posible que encuentres más problemas de accesibilidad en tus verificaciones manuales de los que abordamos en este módulo. Descubriremos muchos de estos problemas en el próximo módulo.

Próximo paso

¡Buen trabajo! Completaste los módulos de prueba automáticos y manuales. Puedes ver nuestro CodePen actualizado, que tiene aplicadas todas las correcciones de accesibilidad automáticas y manuales.

Ahora, dirígete al último módulo de prueba enfocado en las pruebas de tecnología de asistencia.

Verifica tus conocimientos

Pon a prueba tus conocimientos sobre las pruebas manuales de accesibilidad

¿Qué elementos deben cumplir con los estándares de contraste de color de las WCAG?

Íconos
Los íconos deben cumplir con los estándares de contraste de color, pero no son la única opción.
Encabezados
Los encabezados deben cumplir con los estándares de contraste de color, pero no son la única opción.
Cuerpo del texto
El texto del cuerpo debe cumplir con los estándares de contraste de color, pero esa no es la única opción.
Todas las opciones anteriores
Cada elemento debe cumplir con los estándares de contraste escritos por las WCAG.