Hoy retomo los post de testing repasando los últimos puntos de accesibilidad en WCGA AA. Como es costumbre, explicaré brevemente en qué impacta la normativa y a continuación, como podemos testearla. Los puntos a tratar son un popurri de elementos a tener en cuenta, que no podemos pasar por alto al validar que tan accesible es nuestra web o app en dispositivo móvil.
Índice de contenidos
2.1.4 Atajos con teclas de caracteres
Con esta norma queremos asegurarnos de que si existen atajos de teclado para realizar acciones, donde solo se utilizan letras, elementos de puntuación, números o símbolos, estos se puedan apagar, reasignar o activar solo en caso de foco. ¿Cuál es el objetivo que se busca? Son tres. El primero es que los usuarios que utilicen comandos de voz de una sola tecla, no puedan ejecutar varias acciones involuntarias en lote. En segundo lugar, los usuarios más «torpones», que pulsan las teclas sin querer, no se volverán locos con acciones ejecutadas sin intención. Y en último lugar, para las personas con problemas cognitivos, tendrán la posibilidad de asignar los mismos atajos a las mismas acciones.
¿Cómo se valida?
Pues para validar esta norma, se deben probar los atajos de teclado y comprobar que ninguno es de una sola tecla. Además, validaremos que si existe, se puede desactivar. Adicionalmente, cambiaremos las asignaciones de los teclados a nuestra medida y nos aseguraremos que ninguno de los atajos se puede ejecutar si no tenemos el foco en ese componente.
2.4.3 Orden del foco (En cambios dinámicos)
Se debe asegurar que al navegar por una pantalla, bien con el teclado, o con el lector de pantalla (usando la tecla de teclado «tab») se debe poder acceder a todos los elementos visibles, sin acceder a los elementos ocultos. Se hace hincapié en este último punto, pues al haber cambios dinámicos, se puede dar la circunstancia de elementos que «ya no son visibles» puede seguir siendo focusables. Además, el orden de foco debe tener sentido.
¿Cómo se valida?
Cuando nos encontramos en una página que cambia dinámicamente, bien porque son formularios que cambian con la respuesta, o elementos de visualización avanzada. Por ejemplo, contenidos presentados en modo acordeón, o solapas de carpetas, etc, en ningún caso se debe poder acceder a los elementos ocultos ni con teclado, ni con lector de pantalla hasta que ese contenido esté activo.
Usamos el teclado y la vista.
2.4.4 Propósito de los enlaces (en contexto)
Esta norma tiene como objetivo asegurarse de que los enlaces presentes dentro de un contexto, sean comprensibles por todos los usuarios (sin discriminación). Para ello, nos debemos asegurar de que la descripción del mismo sea lo suficiente para comprender su objetivo, o pueda ser comprendido con el texto de apoyo programáticamente. Pero en todos los casos, no hay una situación de desventaja para un conjunto de usuarios.
¿Cómo se valida?
La validación de esta norma es manual. Tenemos que revisar visualmente y con lector de pantalla, los enlaces en contexto presentes en la página y asegurarnos que:
- El texto descriptivo que lo precede es suficientemente explicativo.
- Se entiende por el contexto el objetivo de ese enlace. Por ejemplo, el «leer más».
2.5.1 Gestos del puntero
Con esta norma, se pretende asegurar que los usuarios que no pueden usar con precisión gestos con el punto basados en rutas (ordenador), o gestos con múltiples punteros (en pantalla táctil) dispongan de una alternativa sencilla para realizar la operación.
¿Cómo podemos traducir esto? Hay que ponerse en la situación en la que un usuario no pueda interaccionar con una pantalla táctil con varios dedos, sino solo con un «palito» (de forma transitoria o permanente) o con usuarios que manejen el ratón con dificultades o alguna herramienta de soporte de interpretación del ratón, que no les permite trazar trayectorias.
¿Qué se considera una alternativa sencilla? Pulsar, hacer clic, pulsar dos veces, hacer doble clic, mantener pulsado o hacer clic y mantener pulsado. Cabe destacar, que cuando el sistema permite realizar la interacción con una de estas opciones sencillas, no hay ningún inconveniente de que la acción también se pueda realizar de forma compleja.
¿Cómo se valida?
Para validar que se cumple la accesibilidad en WCGA AA, debemos de explorar todas las interacciones de la aplicación web o móvil y asegurarnos que se pueden realizar con las interacciones sencillas.
- Pulsar
- Pulsar dos veces
- Mantener pulsado
- Hacer clic
- Hacer doble clic
- Hacer clic y mantener pulsado
2.5.2 Cancelación del puntero
Esta norma ayuda a los usuarios que no necesitan realizar una acción, revertirla antes de finalizar. ¿Quién puede necesitarla? Usuario cuyo manejo del ratón no sea con un «pulso firme», usuarios con dificultades de comprensión, cualquiera que sean es necesario que la acción de clic o de tap se pueda cancelar de forma alguna. De forma más técnica es necesario que:
- El evento down del puntero(clic o tap sin soltar) no se emplea para ejecutar ninguna parte de la funcionalidad (hacer una acción).
- La función se completa con el evento up del puntero(soltar clic o tap) y existe un mecanismo para cancelar la función antes de que se complete o para deshacerla una vez completada (por ejemplo, soltar el clic fuera del área).
- El evento up del puntero deshace cualquier consecuencia del evento down previo.
- Completar la función con el evento down es esencial.
¿Cómo se valida?
Para realizar la validación de esta norma es necesaria una comprobación manual. En primer lugar, se deben localizar todos los elementos de interacción y acceder a ellos utilizando todos los medios disponibles. En otras palabras, se debe tener que acceder mediante el ratón, o haciendo «tap» con una pantalla táctil. A continuación, se debe comprobar que al pulsar en el elemento de interacción (sólo pulsar, pero no soltar) no se activa ninguna funcionalidad. Adicionalmente, al deslizar y levantar el puntero fuera del área de interacción y comprobar que no se ha activado ninguna funcionalidad.
2.5.4 Operación mediante movimiento
En esta ocasión, la WCGA, nos exige que las operaciones que se realizan mediante el movimiento y la interacción gestual también se puedan realizar mediante un método alternativo a través de una interfaz de usuario. Existen distintas aplicaciones que permite realizar acciones moviendo la pantalla de un dispositivo móvil, o con gestos faciales. Si hay una persona con el dispositivo fijo a un soporte o con la incapacidad de hacer gestos, debe de disponer de un método alternativo para realizar dicha acción. Cabe destacar, que quedan exentas algunas aplicaciones como son las del podómetro (cuenta pasos), que requieren de forma implícita de esa funcionalidad.
¿Cómo se valida?
Para validar que se cumple esta norma, se debe hacer de forma manual. Primeramente, se debe localizar si existen funcionalidades que puedan ser activadas mediante el movimiento del dispositivo. Para ello, debemos probar distintas acciones con el dispositivo. Por ejemplo, agitar el dispositivo, avanzar entre páginas al inclinar el dispositivo. En segundo lugar, se debe garantizar que existe un método alternativo que no dependa del movimiento. Por ejemplo, enlaces, un botón, etc.
Para comprobar las acciones que se pueden realizar mediante gestos, puedes utilizar la herramienta «Switch access». Para más información: Switch Access una app de accesibilidad para Android
Referencias
Agradecimientos a Melanie Caballero, que como auditora de accesibilidad, me ha ayudado a comprender la mayoría de las pautas de accesibilidad. Para más información, tienes su web: https://mel-caballero.github.io/
Conclusión: Con estos puntos compruebas la accesibilidad en WCGA AA
Gracias a estos últimos puntos puedo concluir que hemos datos una vuelta por todo los puntos de accesibilidad en WCGA AA. Si haces clic en este enlace, se puede WCGA, puedes revisar cada una de las normas. Te invito a que aprendas conmigo a hacer testing de accesibilidad, de forma fácil y cercana.
Recuerda que te puedes suscribir para estar al tanto de las novedades. Su tienes alguna duda, o algo que añadir, no dudes en dejar un comentario.
Quizás te puede interesar
