Pruebas manuales de accesibilidad

Conceptos básicos de las pruebas manuales

Las pruebas de accesibilidad manuales utilizan pruebas, herramientas y técnicas visuales, cognitivas 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 fundamental que ejecutes pruebas de accesibilidad automatizadas y que sigas realizando pruebas.

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

Beneficios de las pruebas de accesibilidad manuales:

  • Es bastante sencillo y rápido de ejecutar.
  • Detectar un mayor porcentaje de problemas que las pruebas automatizadas por sí solas
  • Se necesitan pocas herramientas y experiencia para tener éxito

Desventajas de las pruebas de accesibilidad manuales:

  • Más complejas y requieren más 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.

Compara los elementos y detalles de accesibilidad que puede detectar una herramienta automatizada con los que no se detectarán.

Se puede automatizar No se puede automatizar
Contraste de color del texto sobre fondos sólidos Contraste de color del texto sobre degradados e 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 marcados correctamente y se tienen en cuenta todos los elementos.
ARIA está presente Se usa ARIA de forma adecuada y se aplica a los elementos correctos.
Cómo identificar elementos enfocables con el teclado Qué elementos no tienen enfoque de teclado, si el orden de enfoque tiene sentido lógico y si el indicador de enfoque es visible
Detección del título del 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 de video tiene medios alternativos adecuados presentes (como subtítulos y transcripciones).


Tipos de pruebas manuales

Existen muchas herramientas y técnicas manuales que debes tener en cuenta cuando revises la accesibilidad digital de tu página web o aplicación. 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 generales del contenido.

En este módulo, abordamos cada uno de estos temas de forma general, pero las siguientes pruebas no pretenden ser una lista exhaustiva de todas las pruebas manuales que puedes o debes ejecutar. Te recomendamos que comiences con una lista de verificación de accesibilidad manual de una fuente confiable y que desarrolles tu propia lista de verificación de pruebas manuales enfocada en 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 se relacionan con 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 que solo usan el teclado y tienen visión, los usuarios de lectores de pantalla con visión reducida o ciegos, y las personas que usan software de reconocimiento de voz que también se basa en que el contenido sea accesible con el teclado.

Las pruebas de teclado responden 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 siempre está visible?
  • ¿Puedes quedarte atascado en un elemento que no debería atrapar el enfoque?
  • ¿Puedes navegar detrás o alrededor de un elemento que debería atrapar el enfoque?
  • Cuando se cierra un elemento que recibió el enfoque, ¿el indicador de enfoque regresó 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 dejar de usar el mouse o instalar un paquete pequeño de JavaScript y probar tu sitio web solo con el teclado. Los siguientes comandos son esenciales para probar el teclado.

Clave Resultado
Pestaña Avanza un elemento activo a otro.
Mayúsculas + Tab Se mueve hacia atrás de un elemento activo a otro.
Flechas Cómo desplazarse por los controles relacionados
Barra espaciadora Alterna estados y se desplaza hacia abajo en la página
Mayúsculas + barra espaciadora Se desplaza 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 enfocan 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 pudo detectar, como texto sobre un gradiente o una imagen?
  • ¿Hay elementos que parecen encabezados, listas y otros elementos estructurales, pero no están codificados como tales?
  • ¿Los vínculos de navegación y las entradas de formularios son coherentes en todo el sitio web o la aplicación?
  • ¿Hay algún parpadeo, destello o animación que supere las recomendaciones?
  • ¿El contenido tiene el espaciado adecuado? ¿Para letras, palabras, líneas y párrafos?
  • ¿Puedes ver todo el contenido con una lupa de pantalla o el zoom del navegador?

Verificaciones de contenido

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

Las verificaciones de contenido responden preguntas como las siguientes:

  • ¿Los títulos, los encabezados y las etiquetas de los formularios de la página son claros y descriptivos?
  • ¿Las alternativas de imágenes son concisas, precisas y útiles?
  • ¿Se usa el color como la única forma de transmitir significado o información?
  • ¿Los vínculos son descriptivos o usas 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 un lenguaje sencillo y se explican todas las siglas cuando se mencionan por primera vez?

Algunas verificaciones de contenido se pueden automatizar, al menos en parte. Por ejemplo, podrías escribir un verificador de JavaScript que busque "Haz clic aquí" y te sugiera que realices un cambio. Sin embargo, estas soluciones personalizadas a menudo requieren que una persona cambie el texto por algo contextual.

Demostración: Prueba manual

Hasta el momento, ejecutamos pruebas automatizadas en nuestra página web de demostración, y encontramos y corregimos ocho tipos de problemas diferentes. Ahora, podemos ejecutar verificaciones manuales para ver si podemos descubrir aún más problemas de accesibilidad.

Paso 1

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

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 2

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

Problema 1: Indicador de enfoque visible

Deberías ver el primer problema del teclado de inmediato (o, mejor dicho, no deberías verlo), ya que se quitó el indicador de enfoque visible. Cuando analices 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 sobre el 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 el estilo adecuado para cumplir con 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 este sea visible, asegúrate de presionar la tecla Tab para recorrer la página. Mientras lo haces, deberías notar que el campo de entrada del formulario que se usa para suscribirse al boletín informativo no recibe el enfoque. Se quitó del orden de enfoque natural con un tabindex negativo.

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

Como queremos 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 vuelva a ser enfocable con 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, pasamos a las verificaciones visuales y de contenido.

Mientras realizabas las pruebas de teclado con la tecla Tab para subir y bajar por la página de demostración, probablemente notaste que el teclado se enfocaba en tres vínculos ocultos visualmente en los párrafos sobre las diferentes afecciones médicas.

Para que nuestra página sea accesible, los vínculos deben destacarse del texto circundante y deben incluir un cambio de estilo que no sea de color cuando se coloque el cursor sobre ellos y cuando se enfoquen con el teclado.

Vamos a solucionarlo.

Una solución rápida es agregar un subrayado a los vínculos dentro de los párrafos para que se destaquen. Esto resolvería el problema de accesibilidad, pero podría no adaptarse a la estética general del diseño que deseas lograr.

Si decides no agregar un subrayado, deberás modificar los colores de manera tal que cumplan con los requisitos tanto para el fondo como para el texto.

Cuando mires la demostración con una herramienta de verificación del 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 sin subrayar también deben cumplir con un requisito de contraste de color de 3:1 con respecto al texto circundante.

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, también se debe modificar el cuerpo del texto para cumplir con los requisitos generales de contraste de color entre los tres elementos: vínculos, fondo y texto circundante.

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 vínculo y el texto del cuerpo son iguales, la prueba falla.
La captura de pantalla de WebAIM muestra que todas las pruebas se aprueban 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 del ícono

Otro problema de contraste de color que se pasó por alto son los íconos de redes sociales. En el módulo sobre color y contraste, aprendiste que los íconos esenciales deben cumplir con una relación de contraste de color de 3:1 con respecto al fondo. Sin embargo, en la demostración, los íconos de redes sociales tienen una relación de contraste de 1.3:1.

Vamos a solucionarlo.

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

Una captura de pantalla de la demostración con el analizador de color que muestra un contraste de color incorrecto del ícono.

Problema 5: Diseño del contenido

Si observas el diseño del contenido del párrafo, el texto está completamente justificado. Como aprendiste en el módulo de Tipografía, esto crea "ríos de espacio", lo que puede dificultar la lectura del texto 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 los navegadores es a 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 de Medical Mysteries Club.
Todos los problemas manuales 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 que se describen 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 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 pruebas automatizadas y manuales. Puedes ver nuestro CodePen actualizado, en el que se aplicaron todas las correcciones de accesibilidad automáticas y manuales.

Ahora, dirígete al último módulo de pruebas, que se enfoca en las pruebas de tecnología de asistencia.