Press "Enter" to skip to content

Pruebas de Accesibilidad: Técnicas de filtrado y evaluación con herramientas automáticas

¿Cómo podemos evaluar la accesibilidad a través de las técnicas de filtrado (revisión manual) y las herramientas automatizadas que nos permiten evaluar la interfaz y el código?

Estaremos dando respuesta a esta pregunta en este post 🙂 Comencemos!

Técnicas de Filtrado (revisión manual)

A través de las técnicas de filtrado o revisiones manuales podemos comprobar varios de los criterios que se plantean en la WCAG 2.1.

Checklist

Estos criterios pueden ser evaluados en formato checklist y si buscás en internet podrás encontrar varias formas de comenzar a evaluarlos como por ejemplo: The Checklist, Easy Checks – A First Review , Accessibility Checklist, desde estos sitios se tiene disponible esta información que nos ayuda en la guía de las pruebas de accesibilidad que estemos realizando.

Desde Abstracta hemos elaborado una plantilla de excel que contiene los criterios definidos en la WCAG 2.1, desde la planilla se puede tener una rápida visión de los resultados obtenidos. Les comparto el link para que puedan acceder al contenido, descargarla y comenzar a utilizarla en sus evaluaciones.

Checklist de Accesibilidad (Idioma: English)

Revisión del contraste de colores en la aplicación

La comprobación del contraste de colores entre el primer plano y fondo en nuestras aplicaciones no se realiza de forma subjetiva, por más que podamos identificar a simple vista lo difícil que resulta leer un texto por su contraste, para la comprobación del contraste de colores podemos apoyarnos en herramientas como Color Contrast Analyzer, sobre esta herramienta estuvimos conversando en este post y también con otras herramientas como Contrast Checker, que nos ayudan a comprobar con mayor facilidad el contraste de colores en nuestras aplicaciones.

Zoom

Debemos llevar nuestra aplicación a un 200% o más. Para activar la opción de Zoom desde nuestros dispositivos móviles podemos dirigirnos a la sección de Accesibilidad en Settings o Configuraciones y desde ahí podemos activarlo. Desde un navegador podemos activarlo desde el menú de opciones desde la opción de Zoom.

Debemos comprobar si se activa un scroll horizontal, si se pierde texto, si la navegación a través del teclado varía o queda inconsistente, si la aplicación no es responsive.

Navegar en la aplicación con el solo uso del teclado

¿Has intentado navegar al menos por un día o unas horas con solo el teclado de tu computadora? Si aún no has tenido esta experiencia te invito a que lo puedas probar y después compartas tu experiencia 🙂

Muchas personas hoy en día dependen del teclado para interactuar con una aplicación web. Para la navegación a través del teclado se debe contar con acceso a todas las funciones , incluyendo controles de formularios, entrada de datos y otros componentes principales de la interfaz del usuario.

Debemos identificar en nuestras evaluaciones si todas las funcionalidades que están disponibles a través del ratón (mouse) también siguen estando disponibles a través del teclado, comprobar que el foco del teclado no quede atrapado en el contenido.

Prueba con lectores de pantalla

Hace poco estuve participando en una charla sobre accesibilidad donde se hacía énfasis en que los lectores de pantalla no son herramientas de evaluación y en realidad no lo son, las mismas son un producto de apoyo o tecnología asistiva para los usuarios en situación de discapacidad visual o baja visión, pero no las obviaría en nuestras pruebas de filtrado.

Considero que es muy difícil llegar a contar con la destreza en el uso de este tipo de tecnología como lo tiene un usuario que hace uso a diario de un lector de pantalla y lo pude presenciar en el curso de pruebas de accesibilidad que estuvimos realizando desde Abstracta para testers del equipo NahualIT en Argentina en situación de discapacidad en este caso visual.

Me sorprendí de sus habilidades al usar los lectores de pantalla y me percaté que en mis primeras pruebas de accesibilidad muchas veces asumí que era un error de la aplicación cuando hacía uso del lector de pantalla pero en realidad era porque no estaba haciendo un correcto uso del producto de apoyo.

Debemos intentar especializarnos y conocer cómo funcionan los lectores de pantalla, es importante tener presente que no todos tienen el mismo funcionamiento por lo que se hace indispensable aprender el comportamiento del lector de pantalla que consideremos utilizar para nuestra evaluación y así nos evitamos falsos positivos.

Comprobación del foco

Debemos comprobar si el foco del teclado es visible y el orden del foco sigue una secuencia significativa.

Puede ser que al diseñar o desarrollar una aplicación web nos ha pasado que hemos notado que el foco no hace juego con los colores seleccionados para la interfaz y la solución es ocultarlo. Debemos evitar ocultar el indicador de enfoque en la página ya que este nos permite conocer en todo momento donde estamos ubicados en la aplicación.

Debemos mantener el indicador de enfoque visible en nuestra aplicación, como alternativa podemos sustituirlo por un color que se complemente con el diseño de nuestra página.

Orden de tabulación

Debemos comprobar si el orden de tabulación al usar el tab tiene sentido y es intuitivo para el usuario.

Para realizar la comprobación de forma manual y validar que los elementos en nuestra aplicación presentan un orden correcto en la tabulación y que se navega correctamente a través del teclado debemos considerar lo siguiente:

  • TAB – movemos el foco adelante.
  • SHIFT+TAB – movemos el foco hacia atrás.
  • Flechas del teclado – movemos el foco dentro de un componente.
  • OPTION + TAB – cambiamos el foco en otros navegadores como Safari.
  • Espacio – nos permite seleccionar un checkbox.
  • Flecha derecha del teclado – nos permite seleccionar un radio button.

Podemos apoyarnos para este tipo de evaluación en herramientas como ARCToolkit donde se realiza la comprobación automática del orden de tabulación:

Revisión automatizada

Para la revisión automatizada podemos apoyarnos en varias herramientas que nos permiten comprobar rápidamente la accesibilidad de nuestras aplicaciones, muchas de ellas son automáticas y nos generan un reporte del estado de nuestra aplicación, podemos mencionar a: WAVE, aXe, Total Validator, ARC Toolkit, Pa11y. Podrás acceder a más aplicaciones en el siguiente link que comparto a continuación: Web Accessibility Evaluation Tools List.

Conclusiones

Debemos tener presente que:

El testing automatizado no puede sustituir a las pruebas manuales y el feedback real de los usuarios.

Podemos revisar la accesibilidad en nuestras aplicaciones con las herramientas automáticas antes mencionadas, podemos simular algún tipo de discapacidad a través de las técnicas de filtrado pero nada de esto sustituye el poder obtener feedback real cuando realizamos pruebas de accesibilidad con un grupo de usuarios en situación de discapacidad.

Las evaluaciones de accesibilidad a través de las técnicas de filtrado y uso de herramientas automáticas son recomendables realizarlas antes de coordinar las Pruebas con Usuarios ya que nos permiten conocer rápidamente las primeras barreras de accesibilidad con las que se pueden encontrar. Realizar este tipo de evaluaciones desde etapas muy tempranas del desarrollo del producto, nos permite reducir costos y esfuerzos en nuestros proyectos.

¿Has aplicado técnicas de filtrado en tus proyectos o solo hacen uso de herramientas de evaluación automática?

Déjanos tus comentarios!

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Close Bitnami banner
Bitnami