Hoy me han preguntado que cuáles serían las pruebas mínimas de accesibilidad en WEB necesarias para un proyecto y qué herramientas utilizaría. ¿Cuál ha sido mi respuesta? Pues qué: dependiendo del proyecto, si entendemos que debe cumplir una WCGA AA, todas las normas que apliquen a cada pantalla se deben cumplir. Aunque, si es necesario empezar por algunas, mi propuesta es la siguiente.
Índice de contenidos
Extensiones de navegador o herramientas automáticas
En primer lugar, utilizaría herramientas de detección automáticas como son ARC Toolkit o WAVE (Herramientas para validar Accesibilidad web) para que me liste los errores detectados y las advertencias. De esta forma, se podría dar un primer barrido y detectar temas de contrastes, mala estructuración, codificación incorrecta, etc. Tendremos dos puntos de partida: los errores, que en su mayoría hay que resolver; y las advertencias, que se debe analizar y corregirlas en caso de que aplique.
Tanto en estas extensiones de navegador, como en otras, suelen ir acompañadas de normas y referencias a documentación para su mejor comprensión. Sin embargo, ahora llega la pregunta del millón: ¿solo con estas herramientas, ya sabemos el estado de la accesibilidad de la página? La respuesta es NO. Es necesario validar otros puntos de forma manual.
Adecuada navegación con teclado
En segundo lugar, se debe hacer una navegación adecuada solo con teclado, de forma que se cumplan las pautas: 1.4.13 Contenido en Hover o Focus, 2.1.1 Mecanismos de entrada, 2.1.2 Sin trampas para el foco del teclado, 2.4.3 Orden del foco y 2.4.7 Foco visible.
Para ampliar más información, puedes consultar el post: Testing de 5 normas WCGA sobre la navegación por teclado.
Inicialmente, puede que te abrume un poco el listado de normas a cumplir, pero te debes enfocar en que una navegación con teclado (puede ser de dispositivos estándar o de conmutadores) que permita hacerse:
- de forma completa,
- visualmente perceptible,
- en un orden adecuado,
- sin que la navegación se bloqueen en algún punto,
- y sin que el foco pueda desencadenar una acción no esperada.
En este sentido, te aconsejo que prestes especial cuidado a los elementos secundarios que deben ser interaccionadles y a veces no llega el foco. Y en segundo lugar, al comportamiento del foco con las ventanas emergentes.
Navegación comprensible con lector de pantalla (NVDA)
A continuación, se debe prestar especial cuidado a la navegación con un lector de pantalla, como es «NVDA». En estas pruebas, se validan un conjunto de normas, entre ellas: 1.3.2 Secuencia significativa, 1.4.5 Imágenes de texto, 2.4.1 Evitar bloques, 2.4.2 Titulado de páginas, 2.4.6 Encabezados y etiquetas, 4.1.3 Mensaje de estado y Nombre, rol y valor. Además, nuevamente: 2.1.1 Mecanismos de entrada, 2.1.2 Sin trampas para el foco, 2.4.3 Orden del foco. Esta situación es igual o mucho peor que la anterior: nos encontramos con muchas normas que validar, de las cuales no podemos aprender rápidamente.
¿Qué se debe hacer entonces? Ejecuta el NVDA y navegar por la pantalla (con flechas y tabulador), y hacer el ejercicio de que realmente no podemos ver la pantalla. En todo momento, te debes hacer las siguientes preguntas: ¿puedo llegar a comprender la información que me está transmitiendo?, ¿tengo contexto completo de la situación? Lo correcto es que, en todo momento, el lector debe transcribir todo lo que percibimos con la vista: texto plano, iconos o imágenes (cuando sean informativas), elementos interaccionables (estado, rol, valor que tienen), notificaciones, contadores. Si en esta navegación hay puntos confusos o que no transmiten correctamente, el “contenido” es un KO (o una mejora).
Ajuste adecuado a cambios de tamaño
En este punto, se debe tener en cuenta si nuestra web se adapta sin perder información a 3 situaciones distintas: contenido responsive mínimo: 256 x 320px (puedes usar un emulador), aumento del zoom de pantalla hasta el 200% y espaciado determinado. En las 3 situaciones, se debe cumplir que no se oculte de forma parcial o total contenidos que aporten información. Solo debes aplicar la condición y observar que todo sea correcto. Presta especial cuidado a los contenidos que no están presentes a simple vista: mensajes de error, tooltip, ventanas emergentes, input completados, input desplegables, etc.
Las normas impactadas son: 1.4.4 Cambio del tamaño del texto, 1.4.10 Reflujo y 1.4.12 Espaciado del texto. Puedes tener más información en el post: 4 normas WCGA sobre el cambio de tamaño.
Pruebas mínimas de accesibilidad en WEB de audio, video y elementos en movimiento
En casos puntuales, puede que sea necesario revisar contenidos de audio, vídeo o elementos en movimiento. Para ello, si necesario que revises un poco más a fondo el testing de estas pautas de la WCGA. Aunque un buen resumen a alto nivel sería: para que cumpla con accesibilidad, los contenidos de audio, y video debe estar transcritos a textos, y a su vez los videos tienen que tener una locución de lo que sucede, convertida primero en audio y luego en texto. Por otro lado, para elementos en movimiento, deben existir controles que permitan interactuar para pausar o detener el movimiento.
Puedes ampliar la información en los post Testing de accesibilidad para audio y vídeo y Validar la accesibilidad de tiempos y movimientos.
Conclusión: Empieza por unas pruebas mínimas de accesibilidad en WEB
Recuerda siempre, que con estas indicaciones solo estamos empezando, pero para validar la accesibilidad web de una página es necesario comprobar cada una de las normas de la WCGA AA(que aplican). En general, las páginas web, para pasar una auditoría de accesibilidad, debe cumplir un porcentaje de normas cumplidas. Digamos que, todavía nuestro objetivo no es que sea adecuada con respecto a la accesibilidad al 100%, pero sí acercarnos lo más posible. Debes recordar que según aumente el porcentaje de accesibilidad de tu web, aumentará el porcentaje de usuarios que la pueden usar.
¿Te a gusto el post? Deja un comentario y hablamos de accesibilidad y si lo desea también puedes suscribirte al blog.
Quizás te puede interesar
