Hoy retomo los post de explicación de cómo hacer testing en las criterios de accesibilidad de la WCGA 2.2. En concreto, voy a repasar los criterios de A y AA que fueron incorporados en su última versión y que no estaban presentes en la 2.1. Posteriormente, en otros post podrás ver los de AAA.
Comenzamos.
Índice de contenidos
2.4.11 - Foco no obstruido (mínimo) [AA]
El objetivo de esta norma es impedir que el foco de los elementos interaccionables quede oculto para su visualización. Hay usuarios que necesitan utilizar la navegación por teclado, siendo videntes; cuando se da la situación de que un elementos iteraccionable queda oculto pueden estar confusos en cómo proceder a continuación. Es importante que el foco de esos elementos no quede oculto, al menos de forma parcial. ¿Cuángo puede ocurrir esto? Con los avisos de cookies en el footer, con modales que aparecen, en otras palabras: cuando hay un contenido adicional que no desplaza el contenido existente o el foco no se restringe al último elemento aparecido.
¿Cómo se valida?
La forma de probar este criterios de accesibilidad de la WCGA 2.2 es de forma manual. Se debe navegar en la página web buscando que aparezcan esos elementos emergentes y validando que en níngún caso quede totalmente oculto el foco de navegación. Para ello, debes iniciar la navegación de teclado usando “tab”, y flechas cuando procede, haciendo una “vuelta completa”.
A nivel de desarrollo, la técnica utilizada para su implementación es la “C43: Uso de CSS scroll-padding para despejar el contenido”, de forma que cuando aparezcan nuevos elementos, que no deban restringir el foco, este nuevo elemento de incluya en la web desplazando el contenido ya existente y no llegando a ocultar ningún foco.
2.5.7 - Movimientos de arrastre [A]
En este criterio se trata solo: el movimiento de arrastre realizado por un ratón. Aclarar que es distinto al criterio de exito 2.5.1 “Gestos con el puntero”. En este, se trata la situación en la que necesitamos hacer clic en un punto de partida, y sin soltar desplazarnos hasta un punto final en el que liberamos el puntero. Esta acción es compleja de realizar para usuarios que no pueden usar el ratón para arrastrar elementos, sino que utilizan dispositivos de entrada especializados como son: sistema de seguimiento ocular, un puntero de cabella, un trackball o un emulador de ratón controlado por voz.
Para cumplir con ese criterio es necesario garantizar de que exista una alternativa para realizar esa funcionalidad con un solo puntero. Este criterio se debe cumplir independientemente de los criterios de teclado.
¿Cómo se valida?
Para probar esa funcionalidad, es de forma manual. Se debe navegar por la funcionalidad deseada y poder alcanzar el objetivo sin tener que hacer una acción de arrastrar el teclado. Por ejemplo, si tenemos un panel con un listado de columnas que representas estados de tareas. Dentro de cada columna tenemos un conjunto de tareas (tipo kanban). El sistema permite actualizar el estado de una tarea al desplazar una tarea de una columna a otra. Para cumplir con ese criterio, se debe permite la opción de entrar en un menú contextual de dicha tarea donde exista una acción “Mover a columna”, donde exista un seleccionador de las columnas existentes.
2.5.8 - Tamaño del objetivo (mínimo) [AA]
Este criterio exige un tamaño minimo de 24×24 pixeles a los elementos intereaccionables, salvo algunas excepciones. Con este criterio se quiere evitar errores al accionar acciones por aquellas personas que tienen dificultades de destreza o en la motricidad fina. Por ejemplo, cuadruplejia, temblores en las manos o espasticidad.
Tenemos las excepciones de:
- Espaciado, cuando hay poco espacio, dos elementos interaccionables tienen que tener una circunferencia concentrica de 24 pixeles y no interseccionar.
- Equivalente, si existe otro control que pueda permitir realizar la función subyacente.
- En línea, para los enlaces de texto donde el interlineado sea inferior a 24px.
- Control de agente de usuario: Cuando existe otra función que no dependa del desarrollador, como los input tipo date, que despliegan un calendario interaccionable.
- Esencial, cuando por al propia funcionalidad no se puede modificar. Ejemplo, un conjunto de puntos en un mapa a escala. Cuando está ampliado, los puntos estan separados; cuando está más alejado, los puntos están muy cerca unos de otros.
¿Cómo se valida?
Para validar este criterios de accesibilidad de la WCGA 2.2, la forma de prueba es manual. Se dee garantizar que se cumpla la técnica suficiente de min-height y min-width en el contenedor del mismo.
3.3.7 - Entrada redundante [A]
Este criterio quiere ayudar a las personas con discapacidades cognitivas a las cuales les es díficil recordar la información que introdujeron previamente. Este cirterio abarca el proporcional al usuario la información que han completado previamente cuando se encuentran en un proceso de varios pasos. En este criterio, no hace referencia a la función autocompletar de los inputs, sino que debe almacenar en la sesión actual de la página los datos que ha completado el usuario previamente. T, a continuación, el sistema debe ofrecer la información bien en un resumen de datos o bien, con la opción de “seleccionar respuesta anterior”, o con un simple “copiar respuesta previa”. Cabe destacar la importancia de cuidar esos datos en sesión y borrarlos al finalizar (aunque eso no es algo que competa a este criterio).
Hay algunas excepciones a este criterio: datos caducados, juegos de memoria, sistemas de seguridad.
¿Cómo se valida?
Para validar el criterio 3.3.7 se debe probar de forma manual, completando el flujo que estamos validando y asegurando que los datos que vuelven a solicitar estén visibles para volver a completar. La técnica suficiente es la G221.
Ejemplo: En una tienda online, completamos los datos de la dirección de envío. Al llegar a la información de facturación hay un checkbox que indica “utilizar los mismos datos que en dirección de envío”.
3.3.8 - Autenticación accesible (mínimo) [AA]
Con este criterio se desea eliminar la barrera de que sea necesaria una prueba de función cognitiva compleja para un proceso de autenticación. En otras palabras, hay usuarios con discapacidades cognitivas que no les es fácil recordar una contraseña o resolver un rompecabezas. Por ello necesitan una alternativa accesible, segura y fácil de usar. Existen varias excepciones:
- Que se ofrezca una alternativa,
- Que exista un mecanismo disponible que ayude al usuario a completar dicha función cognitiva.
- Que la prueba cognitiva consista en el reconocimiento de objetos.
- Que se reconozca un contenido no textual que el usuario proporcionó previamente.
Se debe tener el cuenta, que para un acceso multifactor, este criterio se debe cumplir para todos los pasos. Y además, para las opciones de recuperar o cambiar correo-electrónico y contraseña, también se debe cumplir. Cuando nos encontramos con métodos de autenticación que permitan que los agentes de usuario completen automáticamente los credenciales, también se cumple a normal (para ello es imprescindible que se cumplan los criterios de propósito de la entrada (1.35) y nombre, valor, función (4.1.2).
¿Cómo se valida?
Para validar este criterio, se requiere de prueba manual. No es válida una única solución, pero se debe asegurar que en todo momento el inicio de sesión no depende de sus capacidades cognitivas. Ejemplo, un usuario para iniciar sesión escanea un código QR con un aplicación de su móvil. Otro ejemplo, el navegador autocompleta los credenciales de inicio de sesión en una tienda online.
Conclusión: Hacer testing es esencial para cumplir con los criterios de accesibilidad de la WCGA 2.2
Hoy conoces un poco más de los criterios de accesibilidad de la WCGA 2.2. En este conjunto de criterios hemos podido ver que hay mucha prueba manual, pero no muy compleja.
Si amplias información de como válidar criterios de accesibilidad y de como construir soluciones más accesibles, estarás aportanto tu grano de arena para un entorno dígital apto para todos.
