Pruebas manuales de accesibilidad

Conceptos básicos de las pruebas manuales

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

A medida que la tecnología avanza, se podrían incluir más pruebas solo con herramientas automatizadas, pero, hoy en día, es necesario agregar verificaciones manuales y de tecnología de accesibilidad a tus protocolos de prueba para abarcar todos los puntos de control de las WCAG correspondientes.

Ventajas de las pruebas manuales de accesibilidad:

  • Razonablemente sencillos y rápidos de ejecutar
  • Detecta un mayor porcentaje de problemas que las pruebas automatizadas solas.
  • Se necesitan pocas herramientas y experiencia para alcanzar el éxito

Desventajas de las pruebas de accesibilidad manuales:

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

Comparemos los elementos y detalles de accesibilidad que se pueden detectar en este momento por medio de una herramienta automatizada en comparación con los que no se detectarán.

Se puede automatizar No se pueden automatizar
El contraste de color del texto en fondos sólidos Contraste de color del texto en gradientes o imágenes
Existe texto alternativo de la imagen El texto alternativo de la imagen es preciso y está asignado correctamente
Existen encabezados, listas y puntos de referencia Los encabezados, las listas y los puntos de referencia están correctamente marcados y se consideran todos los elementos.
ARIA está presente ARIA se usa correctamente y se aplica a los elementos correctos.
Cómo identificar los elementos enfocables en el teclado Cuáles elementos no tienen 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 del enfoque es visible.
El elemento de video está presente El elemento de video incluye medios alternativos apropiados (como subtítulos y transcripciones)


Tipos de pruebas manuales

Hay muchas herramientas y técnicas manuales que debes considerar cuando analices página web o aplicación para accesibilidad digital. Las tres áreas de enfoque más grandes las pruebas manuales son la funcionalidad del teclado, las revisiones visuales y verificaciones generales del contenido.

Abordaremos cada uno de estos temas en términos generales en este módulo, pero Las siguientes pruebas no pretenden ser una lista exhaustiva de todas las pruebas manuales puedes o debes ejecutar. Te recomendamos que comiences con lista de tareas manual de accesibilidad de una fuente confiable y desarrollar tu propia lista de tareas enfocadas en pruebas manuales para las necesidades específicas de tu producto digital y equipo.

Verificaciones del teclado

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

Las pruebas con el teclado responden preguntas como las siguientes:

  • ¿La página web o la función requiere 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 foco?
  • ¿Puedes navegar detrás o alrededor de un elemento que debería capturar el foco?
  • Al cerrar un elemento que recibió el 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. Solo debes apartar el mouse o instalar un pequeño paquete de JavaScript y probar el sitio web solo con el teclado. Los siguientes comandos son esenciales para probar el teclado.

Clave Resultado
Tab Mueve un elemento activo hacia otro
Mayúsculas + Tab Mueve un elemento activo hacia otro en lugar de otro
Flechas Desplazarse por los controles relacionados
Barra espaciadora Cambia de estado y se mueve hacia abajo en la página
Mayúsculas + Barra espaciadora Mueve hacia arriba en la página
Intro 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 usan herramientas como la ampliación de la pantalla o el zoom del navegador para revisar la accesibilidad del sitio web o la aplicación.

Las verificaciones visuales te pueden decir lo siguiente:

  • ¿Hay problemas de contraste de color que una herramienta automatizada no podría detectar, como el texto sobre un gradiente o una imagen?
  • ¿Hay algún elemento que se parezca a encabezados, listas y otros elementos estructurales, pero que no esté codificado como tal?
  • ¿Los vínculos de navegación y las entradas de los formularios son coherentes en todo el sitio web o la aplicación?
  • ¿Hay imágenes intermitentes, estroboscópicas o animadas que superen las recomendaciones?
  • ¿El contenido tiene el espaciado adecuado? ¿Para letras, palabras, líneas y párrafos?
  • ¿Puedes ver todo el contenido con una lupa o el zoom del navegador?

Verificaciones de contenido

A diferencia de las pruebas visuales que se centran en diseños, movimientos y colores, las verificaciones de contenido se centran en las palabras de la página. No solo debes examinar la copia en sí, sino también revisar el contexto para asegurarte de que tenga sentido para los demás.

Las verificaciones de contenido responden preguntas como las siguientes:

  • ¿Los títulos de las páginas, los encabezados y las etiquetas de los formularios son claros y descriptivos?
  • ¿Las alternativas de imagen son concisas, precisas y útiles?
  • ¿Se usa solo el color como la única forma de transmitir significado o información?
  • ¿Los vínculos son descriptivos o usas texto genérico, como “obtén más información” o “haz clic aquí”?
  • ¿Hay algún cambio en el idioma de una página?
  • ¿Se usa lenguaje simple y se escriben todos los acrónimos cuando se hace referencia por primera vez?

Algunas verificaciones de contenido se pueden automatizar, en parte. Por ejemplo, puedes escribir un linter de JavaScript que compruebe la opción "Haz clic aquí" y te sugiere 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 verificaciones manuales y ver si podemos descubrir aún más problemas de accesibilidad.

Paso 1

Nuestra demostración de CodePen actualizada contiene de las actualizaciones automatizadas de accesibilidad aplicadas.

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 2

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

Problema 1: Indicador de enfoque visible

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

  :focus {
    outline: none;
  }
Solucionémoslo.

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 con un estilo que se adapte 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 presionar Tab a través de la página. Cuando lo hagas, verás que el campo de entrada del formulario que se usa para suscribirse al boletín informativo no es el foco. Se quitó del orden de enfoque natural por un tabindex negativo.

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

Como nos gustaría que las personas usen este campo para registrarse en nuestro boletín informativo, solo debemos quitar el tabindex negativo o configurarlo en cero para que la entrada pueda volver a enfocarse en el teclado.

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

Paso 3

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

A medida que revisabas las pruebas del teclado, deslizaba las pestañas hacia arriba y hacia abajo en la página de demostración, puedes notar que el teclado enfocado en tres enlaces visualmente ocultos párrafos sobre las diferentes afecciones.

Para que se pueda acceder a nuestra página, los vínculos deben destacarse del texto que los rodea e incluir un cambio de estilo sin color al colocar el cursor del mouse y al enfoque del teclado.

Solucionémoslo.

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 eliges no agregar un subrayado, deberás modificar los colores de modo que cumplan con los requisitos del fondo y la copia.

Cuando observes la demostración con una herramienta de verificación de contraste de vínculos, verás que el color del vínculo 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 que no estén subrayados también deben cumplir con un requisito de contraste de color de 3:1 con el texto que lo rodea.

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

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

Problema 4: Contraste de color de los íconos

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

Solucionémoslo.

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 colores que muestra el contraste de color del ícono con errores.

Problema 5: Diseño del contenido

Si observas el diseño del contenido del párrafo, el texto está justificado. Como aprendiste en el Módulo de tipografía, esto crea "ríos de espacio", lo que puede dificultar el texto para algunos que los usuarios la lean.

p.bullet {
   text-align: justify;
}
Solucionémoslo.

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

p.bullet {
   text-align: left;
}

Paso 4

Captura de pantalla del sitio de demostración de 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 manuales descritos en los pasos anteriores, tu página debería verse similar a nuestra captura de pantalla.

Es posible que encuentres más problemas de accesibilidad en tus verificaciones manuales que 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 pruebas automáticas y manuales. Puedes ver nuestro CodePen actualizado, que tiene aplicadas todas las correcciones automáticas y manuales de accesibilidad.

Ve al último módulo de pruebas centrado en pruebas de tecnología asistencial.

Verifica tus conocimientos

Pon a prueba tus conocimientos sobre las pruebas de accesibilidad manuales

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

Íconos
Los iconos 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.
Texto del cuerpo
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.