Cuando abordamos proyectos de desarrollo web, independientemente de su naturaleza, centramos nuestra atención en la planificación, recursos, evaluación de tecnologías, herramientas, metodología y estrategia de calidad, fundamentales para concebir un producto o servicio digital que cumpla con los estándares que promueve la industria, entre otros aspectos esenciales como: la usabilidad, rendimiento, SEO, y la accesibilidad que reflejan la calidad del desarrollo.
En la práctica, cuando hacemos una evaluación del resultado final, es posible evidenciar métricas que reflejan el no cumplimiento de prácticas web recomendadas, quizá por desconocimiento o falta de inclusión de estos indicadores como parte de la estrategia de calidad y su alcance en etapas tempranas del desarrollo.
En un análisis reciente (2024) realizado por WebAIM, mostró un aumento notable en los errores de accesibilidad web detectados, también se evidenció una pequeña disminución en los sitios con fallos de conformidad WCAG y a pesar del aumento de errores, hubo tendencias positivas y mejoras en sitios web, lo cual sugiere la adopción de un mayor enfoque en la accesibilidad web.
En este artículo refrescaremos la accesibilidad web, centrando la estrategia de calidad durante el desarrollo, pruebas recomendadas (híbridas, manuales y automatizadas) y algunas herramientas que podemos incorporar a nuestro arsenal de QA.
Antes de entrar en materia, os comparto el contenido a tratar:
1. Entendiendo la Accesibilidad Web
Para entender mejor la accesibilidad es útil conocer los problemas de accesibilidad que pueden enfrentar los diferentes usuarios, en términos generales, podemos dividirla en cuatro amplias categorías:
- Problemas visuales: Las deficiencias visuales varían desde la visión limitada hasta la ceguera completa. Los usuarios con visión reducida pueden necesitar herramientas como la ampliación de pantalla, temas de alto contraste y texto a voz. Algunos usan lectores de pantalla o pantallas braille para navegar por páginas, interactuar con los controles y leer descripciones de contenido.
- Problema de movilidad (motricidad o destreza): Las discapacidades motrices y de destreza pueden dificultar el uso de un mouse, pantalla táctil u otros dispositivos apuntadores. Los usuarios con estas discapacidades pueden recurrir a dispositivos de entrada alternativos, como teclados, software de seguimiento de cabeza u ojos, dispositivos de conmutación, dispositivos de presión y sonido, o comandos de voz para acceder al contenido.
- Problemas de audición: Las discapacidades auditivas pueden ir desde dificultades para oír ciertas frecuencias hasta la sordera completa. Las personas con problemas auditivos suelen depender de subtítulos o transcripciones para acceder al contenido sonoro en una interfaz.
- Problemas cognitivos: El deterioro cognitivo incluye condiciones como el TDAH (Trastorno por Déficit de Atención e Hiperactividad), dislexia y autismo. Las adaptaciones para estos usuarios son variadas. Generalmente, intentan reducir distracciones, evitar animaciones parpadeantes y cambios inesperados en el contexto de la página. También se pueden personalizar colores y estilos para mejorar la legibilidad y evitar dolores de cabeza.
Ahora lo tenemos claro, cuando hablamos de accesibilidad Web, nos referimos al contenido, la navegación e interacción con las aplicaciones y sitios web, cuyo propósito es ofrecer una experiencia digital más inclusiva que funcione para más usuarios, sin importar su discapacidad.
Estándares de Accesibilidad Web W3C
El World Wide Web Consortium (W3C) es una organización internacional sin fines de lucro, de interés público que desarrolla estándares web. La Iniciativa de Accesibilidad Web (WAI) es clave en el trabajo de W3C, y en ella se enmarcan las pautas de accesibilidad web.
Pautas esenciales de Accesibilidad Web
Es importante destacar que las pautas de accesibilidad dependen de varios componentes que interactúan entre sí en el ecosistema de desarrollo web, ellos son: ATAG, WCAG, y UAAG.
Ilustración: https://www.w3.org/WAI/standards-guidelines/es
- Pautas de accesibilidad para las herramientas de creación de contenido (ATAG: Authoring Tool Accessibility Guidelines): Orientada a los desarrolladores, diseñadores, redactores, y perfiles afines que utilizan herramientas para la creación de contenido web, Por ejemplo: editores de HTML, sistemas de gestión de contenidos (CMS) y sitios web que permiten a los usuarios añadir contenido tales como blogs y redes sociales. Estas pautas aseguran que las herramientas usadas para crear contenido web sean accesibles y que permitan la creación de contenido accesible.
- Pautas de accesibilidad para el contenido web (WCAG: Web Content Accessibility Guidelines): Dirigida a creadores de contenido web, y proporcionan pautas para hacer que el contenido web sea accesible para personas con diversas discapacidades. Por contenido web se refiere a toda la información de una página o aplicación web, como: contenido dinámico, multimedia, textos, imágenes, código que define la estructura, presentación, etc.
- Pautas de accesibilidad para el agente de usuario UAAG (User Agent Accessibility Guidelines): Con enfoque a desarrolladores de navegadores web, extensiones y/ complementos de los navegadores, reproductores multimedia, lectores y otras aplicaciones que presentan contenido web. Estas pautas aseguran que los usuarios puedan acceder al contenido web de manera efectiva, incluyendo a aquellos con discapacidades.
En este punto, tenemos claro cuáles son los componentes fundamentales que intervienen en la accesibilidad en el ecosistema web, en el resto del camino nos enfocaremos en el estándar WCAG de acuerdo con el objetivo general de este artículo.
Evolución del estándar WCAG
- WCAG 1.0: Publicado el 5 de mayo de 1999.
- WCAG 2.0: Publicado el 11 de diciembre del 2008. El 15 de octubre de 2012 fue aprobado como estándar internacional ISO/IEC 40500:2012.
- WCAG 2.1: Publicado el 5 de junio del 2018 y actualizado el 21 de septiembre de 2023.
- WCAG 2.2: Publicado el 5 de octubre del 2023.
- WCAG 3.0: Es un borrador en progreso del 28 de mayo de 2024, incluye una lista actualizada de lo posibles resultados potenciales en revisión (a modo informativo).
Importante considerar:
- Las WCAG 2.0, 2.1 y 2.2 están diseñadas para ser compatibles con versiones anteriores, lo cual quiere decir que si se cumple con WCAG 2.2 también se cumple con WCAG 2.1 y WCAG 2.0. Si se quiere cumplir con todas las versiones, usar de referencia los recursos de WCAG 2.2
- Las WCAG 2.0, WCAG 2.1 y WCAG 2.2 son estándares actuales. WCAG 2.2 no elimina ni deja sin efecto WCAG 2.1, de la misma forma que WCAG 2.1 no deja sin efecto WCAG 2.0. El W3C recomienda usar la última versión de las WCAG.
Prioridades de las pautas de WCAG
Cada punto de verificación en las pautas tiene un nivel de prioridad asignado por el Grupo de Trabajo y fundamentado en su impacto en la accesibilidad web:
- Prioridad 1: Se tiene que satisfacer este punto de verificación. De otra forma, uno o más grupos de usuarios encontrarán imposible acceder a la información del documento. Satisfacer este punto de verificación es un requerimiento básico para que algunos grupos puedan usar los documentos Web.
- Prioridad 2: Se debería satisfacer este punto de verificación. De otra forma, uno o más grupos encontrarán dificultades en el acceso a la información del documento. Satisfacer este punto de verificación eliminará importantes barreras de acceso a los documentos Web.
- Prioridad 3: Se puede satisfacer este punto de verificación. De otra forma, uno o más grupos de usuarios encontrarán alguna dificultad para acceder a la información del documento. Satisfacer este punto de verificación mejorará la accesibilidad de los documentos Web.
Niveles de conformidad del estándar
Hay tres niveles de cumplimiento de accesibilidad en las WCAG en función del número de puntos incluidos en las pautas de verificación que reflejan la prioridad:
- Nivel A (A): Se satisfacen todos los puntos de verificación de prioridad 1.
- Nivel Doble A (AA): Se satisfacen todos los puntos de verificación de prioridad 1 y 2.
- Nivel Triple A (AAA): Se satisfacen todos los puntos de verificación de prioridad 1, 2 y 3.
Ventajas de la Accesibilidad Web
Cuando nos solicitan que un proyecto cumpla con los criterios de “accesibilidad web”, esto sin duda puede suponer muchos retos y quizá no tengamos claro cuáles son las bondades que representa o por qué es un requisito que tiene mucha demanda en proyectos web. Por esta razón vamos a destacar algunas de las ventajas en los siguientes segmentos:
Mercado:
- Mejora el acceso al contenido web para que sea más accesible a personas con discapacidades, además de las personas mayores con capacidades cambiantes debido a la edad y para todos los usuarios en general
- Permite fidelizar clientes, por ofrecer una solución que se adapta a las necesidades de todos los usuarios, lo cual crea un factor diferenciador ante la competencia.
Eficiencia:
- Una implementación temprana reduce el coste de desarrollo y mantenimiento.
- Ayuda a mejorar el rendimiento del sitio y ancho de banda del servidor (hojas de estilo, vínculos mejor definidos, alternativas textuales, etc.).
- Mejora el SEO a nivel de resultados en navegadores web y permite reutilizar contenidos en múltiples formatos o dispositivos.
Responsabilidad - Permite reforzar la imagen corporativa y el sentido de responsabilidad social.
- Reducción de la brecha digital, ayudando a llegar a una proporción influyente de la población (3,5 millones de personas en España demandan servicios y entornos accesibles).
Legislación:
• Ayuda a evidenciar el cumplimiento de la legislación en materia de accesibilidad digital
• Promueve el uso de buenas prácticas, estándares internacionales e iniciativas europeas.
Existen muchos más beneficios sobre este tema, te invitamos a seguir explorando y adoptar esta iniciativa para llevar tú proyecto web al siguiente nivel.
2. Estrategia de calidad para asegurar la Accesibilidad web
El primer paso en la estrategia es establecer un enfoque compartido en el equipo sobre la accesibilidad web y su integración en el proyecto (incluyendo los roles clave involucrados en el desarrollo), tener claro que no es una actividad separada u opcional, implica pensar y actuar alineada como si se tratara de un objetivo o requerimiento más del proyecto.
Algunas acciones que aportan valor en etapas tempranas son:
- Definir objetivos y metas “alcanzables” entorno a la Accesibilidad web y de acuerdo con las necesidades del proyecto. Todo el equipo debe compartir la visión y apoyar en la definición de objetivos estratégicos (SMART), alineado al estándar WCAG y/o grado de conformidad que se desea adoptar (recomendado WCAG 2.2 y aspirar a niveles de cumplimiento entre AA o AAA). Esta evaluación preliminar es fundamental para orientar otros aspectos de la estrategia que iremos abordando más adelante.
- Capacitar al equipo, se deben proveer los recursos y las formaciones necesarias de acuerdo con el rol y/o responsabilidades que desempeñen dentro del equipo.
- Documentar es fundamental, el ámbito de accesibilidad web es muy amplio y siempre está en constante evolución, por lo que es recomendable contar con documentación actualizada de referencia, donde podamos refinar y acotar los aspectos clave considerados en la estrategia, como el enfoque de calidad, las herramientas, los recursos y flujos que intervienen en el proceso, etc, básicamente consiste en crear un marco de referencia sobre este ámbito para uso del equipo y el proyecto en general.
Documentación y trazabilidad de las pruebas de Accesibilidad web
Hemos visto que las pruebas de accesibilidad pueden realizarse mediante varios métodos y herramientas, manuales o automatizadas, sin embargo, es fundamental establecer una estrategia que nos brinde trazabilidad y cobertura, tras cada iteración es importante tener visibilidad de las validaciones que se realizan y no precisamente en el “código” de las pruebas automatizadas o casos manuales, sino a nivel de la normativa WCAG y grado de conformidad alcanzado, estos indicadores son los que realmente nos permiten reflejar cumplimiento.
Documentar los requerimientos de accesibilidad en el proyecto, en este caso las “pautas” de cada estándar WCAG (2.0 y 2.1, en 2.2 se extienden recomendaciones recientemente añadidas a finales del año 2023, y 3.0 aún continua en revisión). Para esta actividad es posible crear un “checklist”, permite organizar los criterios y verificar cumplimiento (modo auditoría), o si se trata de un proyecto “ágil” que emplea Scrum o Kanban, pensar en ellos como requerimientos con historias de usuario y criterios de aceptación. El propósito de esta iniciativa es “volcar” la misma información como requisitos del desarrollo de manera clara y concisa.
Veamos un ejemplo sencillo para una pauta del WCAG 2.1 (referencia del checklist provisto por el equipo WebAIM para ilustrar la idea en este ejercicio):
Un ejemplo de cómo enfocar la historia de usuario a esta pauta sería:
Quiero poder navegar por el sitio web usando solo el teclado
Para acceder a todo el contenido y funcionalidad sin necesidad de usar un ratón.
En términos generales, el caso de prueba podría ser una definición alto nivel (para poder asociar todos los escenarios de prueba comprendidos en la pauta 2.1) o ir bajando de nivel hasta especificar la norma correspondiente (ejemplo: 2.1.1, 2.1.2, 2.1.3, etc), esto dependerá de la estrategia que se desee adoptar para organizar el conjunto de pruebas.
Un ejemplo para definir el título del caso de prueba sería:
En el cuerpo podemos usar lenguaje “Gherkin” (recomendado) o bien una definición con un formato o plantilla tradicional, esto se debe convenir con el equipo y el soporte de la herramienta de gestión de pruebas.
Un ejemplo para definir el cuerpo del caso de prueba usando “Gherkin” sería un enfoque similar al siguiente:
Cuando el usuario presiona la tecla «Tab» desde el inicio de la página
Entonces el foco debe moverse secuencialmente a través de todos los elementos interactivos de la página
Y el foco debe ser claramente visible en cada elemento interactivo
Y el usuario debe poder activar elementos interactivos usando la tecla «Enter» o «Espacio»
Y el usuario debe poder navegar a cualquier subpágina o sección principal usando solo el teclado
Posteriormente, es posible vincular las pruebas manuales o aplicar una etiqueta específica a las pruebas automatizadas para tener trazabilidad por cada iteración, agregar claridad al reporte de resultados (más allá de reflejar un “Pass” o “Fail”), poder vincular incidencias, entender que partes de la normativa se cumplen o no, facilitar el mantenimiento del conjunto de pruebas, obtener métricas confiables y de fácil comprensión. Ciertamente, es un enfoque general, se entiende que el nivel de implementación dependerá de los recursos y herramientas del proyecto.
Pruebas de accesibilidad web
En puntos anteriores hemos visto que las pruebas de accesibilidad pueden cubrir varios aspectos: contenido, la navegación y la interacción. Antes de empezar las pruebas de accesibilidad, es importante asegurar la existencia de los criterios del estándar WCAG estén definidos en la herramienta de gestión de pruebas (en ausencia de estos se recomienda usar por defecto los requisitos de las pautas).
Creación de casos de pruebas de Accesibilidad web
Una vez que tenemos todo listo para avanzar, debemos abordar una estrategia para crear los casos de pruebas, debemos ser prácticos en su organización, de otro puede impactar negativamente la estrategia de calidad, al perder visibilidad del estado del proyecto debido a la falta de trazabilidad entre pruebas y requisitos, problemas para llevar a cabo tareas de mantenimiento y actualización del conjunto de pruebas, inexactitud en los resultados de los reportes, entre otras afectaciones. En este punto conviene tener en cuenta algunas de las siguientes recomendaciones:
- Añadir un título claro y alineado al requisito descrito en la pauta, colocar en el detalle o descripción los aspectos más relevantes tal y como se describen en cada pauta del estándar, y en un lenguaje alineado al proyecto (español o inglés según la convención).
- Establecer la prioridad (Bloqueante, crítico, alto, bajo, trivial, etc.) de acuerdo con el nivel de conformidad que indique el estándar (prioridad 1, 2 y 3).
- Añadir alguna “etiqueta” que resulte útil para actividades de organización, mantenimiento y actualización.
- El resultado esperado según corresponda, la información que necesitemos añadir al caso de prueba debe estar contenida en las pautas del estándar (no reinventar la rueda).
- Dependiendo del proyecto, en el caso de “pruebas manuales asistidas con herramientas” (ejemplo: un complemento o extensión del navegador), recordar añadir precondiciones/postcondiciones según apliquen (para evitar reportar falsos/positivos al momento de interpretar los resultados).
Importante considerar:
Independientemente del caso de prueba (manual o automatizado), es recomendable crear el caso de prueba (base) para cada requisito en la herramienta de gestión de pruebas del proyecto, lo cual nos va a permitir asociarlos a ejecuciones en Planes de Prueba con una mayor trazabilidad en relación a los requisitos del estándar WCAG, que luego podemos aprovechar para algún informe de resultados y dar visibilidad del cumplimiento a las partes interesadas, también es muy útil para vincular los hallazgos o incidencias proveniente de casos manuales o automatizados y como referencia para las iteraciones resultantes de ejecuciones automatizadas en entornos de integración y entrega continua (CI/CD).
Pruebas Manuales de Accesibilidad web
Son fundamentales porque nos ayudan a detectar los problemas que las herramientas automatizadas no pueden encontrar (no cubren todos los criterios de éxito de las WCAG). Aunque la tecnología evolucionará para abarcar más pruebas automatizadas, es necesario combinar pruebas manuales y usar tecnologías de asistencia para cumplir con las pautas aplicables que establece el estándar WCAG.
Ventajas:
Sencillas para un probador con experiencia, permiten detectar un porcentaje mayor de errores que las pruebas automatizadas.
Desventajas:
Si no tienes experiencia son complejas de ejecutar sobre todo al momento de interpretar los resultados, requieren más tiempo que las pruebas automatizadas por lo que ejecutar varias iteraciones resulta una actividad difícil de estimar y repetir a gran escala.
El equipo de desarrolladores de Chrome (Web.dev) en su sitio web tienen buenos recursos sobre accesibilidad web, que sin duda facilitarán el aprendizaje en este ámbito. En uno de sus cursos ellos presentan una tabla comparativa, lo cual me parece interesante citar en este artículo para dar mayor comprensión de los elementos de accesibilidad que pueden ser detectados en la actualidad por herramientas automatizadas y aquellos que necesariamente requieren pruebas manuales:
Se puede automatizar | No se puede automatizar |
---|---|
Contraste de color del texto sobre fondos sólidos | Contraste de color del texto en gradientes o imágenes |
Existe texto de imagen alternativo | El texto alternativo de la imagen es preciso y está asignado de forma correcta |
Existen encabezados, listas y puntos de referencia | Los encabezados, listas y puntos de referencia están marcados correctamente y se incluyen todos los elementos. |
ARIA está presente | ARIA se usa de manera adecuada y se aplica a los elementos correctos. |
Cómo identificar elementos que se pueden enfocar en el teclado | A qué elementos les falta el enfoque del teclado, el orden del enfoque tiene sentido lógico y el indicador de enfoque es visible |
Detección de títulos 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 del video debe incluir medios alternativos apropiados (como subtítulos y transcripciones). |
Podemos resumir que hay tres (3) áreas fundamentales donde debemos aplicar un enfoque manual en las pruebas, sobre todo en aquellas funcionalidades relacionadas con el uso del teclado, las revisiones centradas en aspectos visuales y las verificaciones de contenido general. Sobre los tipos de pruebas manuales de accesibilidad web hay mucha documentación de referencia en la web, no obstante, si te encuentras planteando una estrategia de pruebas híbrida o combinada (manuales y automatizadas), es recomendable que en el conjunto de pruebas manuales no olvides contemplar los siguientes enfoques como parte de la cobertura:
- Validaciones Visuales: Se enfocan en los elementos visuales del sitio web, utilizan herramientas como la ampliación (zoom) del navegador para revisar aspectos claves como: Contraste de color de un texto sobre una imagen, codificación adecuada de encabezados, listas y elementos estructurales de la página, existencia de vínculos de navegación y entradas a formulario, que las animaciones no excedan las recomendaciones, espacios adecuados en el contenido (letras, palabras, líneas y párrafos), visualizar el contenido correctamente con funciones de ampliación y reducción del navegado, etc.
- Validaciones de Contenido: Se enfocan en el contenido de la página: títulos de las páginas, los encabezados, las etiquetas de formularios, las alternativas de imágenes, los vínculos, idioma de la página, el texto y contexto tienen sentido para todos los usuarios, se diferencian de las pruebas visuales, las cuales están más orientadas al diseño, movimiento y colores, etc.
- Validaciones de Teclado: Este enfoque requiere un procedimiento de pruebas bastante simple: Validar que se pueda usar el sitio web haciendo uso del teclado únicamente, y determinar si alguna parte del sitio web requiere el uso de un “ratón” para funcionar correctamente. Aunque hay herramientas o complementos que pueden agilizar esta actividad, requieren supervisión humana para asegurarnos de dar cobertura a todas las partes y funcionalidades del sitio web, además de aspectos como: tabulación lógica entre los elementos, enfoque del teclado siempre visible, existencia de elementos no navegables o sin enfoque, entre otros aspectos relacionados con la falta de compatibilidad con el teclado.
Hay muchas herramientas de accesibilidad que pueden complementar cualquier proceso de pruebas manuales, por ejemplo, las extensiones de navegador o acceso online que proveen AxeDevTool o WAVE, no solo nos permiten ejecutar las pruebas de manera ágil, sino también a brindar cobertura en la detección de problemas comunes, lo cual nos permite aprovechar el tiempo en otros aspectos de accesibilidad que si demandan mayor atención. Más adelante estaremos abordando el punto de las herramientas con más detenimiento.
¡Por el momento lo tienes claro! si contemplas estos tipos de pruebas manuales en el plan de pruebas del proyecto… vas por buen camino.
Pruebas automatizadas de Accesibilidad web
El enfoque de estas pruebas se basa en usar herramientas de software para complementar las verificaciones de accesibilidad del sitio web y facilitar su ejecución en función de los estándares de cumplimiento de accesibilidad predefinidos.
Ventajas:
- Fácil ejecución e iteración en diferentes etapas del ciclo de desarrollo del proyecto web, permitiendo integrarse en ciclos de regresión automatizadas (herramientas como axe-core incluyen una librería para este propósito, la cual es el mismo motor en el cual está basada la extensión AxeDevTool).
- Permite aprovecha herramientas automatizadas de accesibilidad que se incluyen en algunos frameworks, por ejemplo: protractor-accessibility-plugin para Angular.
- Resultados rápidos que facilitan la aplicación de correctivos y visibilidad en el cumplimiento de las pautas del estándar.
Desventajas:
- Las herramientas automatizadas no pueden detectar todos los problemas de accesibilidad.
- En los resultados de cada análisis es posible detectar muchas “Falsos/positivos” (un problema que no es un verdadero incumplimiento de las WCAG).
- Puede que se necesiten varias herramientas para aumentar la cobertura de accesibilidad, lo cual dependerá de la naturaleza del proyecto y sus funciones.
Tipos de herramientas automatizadas
Ahora que conoces el enfoque de las pruebas automatizadas de accesibilidad, sus ventajas y desventajas, hablaremos de los tipos de herramientas, varían desde complementos o extensiones de navegador, aplicaciones para computadoras y dispositivos móviles, hasta librerías y APIs de código abierto que pueden ser usadas para compilar otras herramientas e integrarlas en flujos de integración y entrega continua en el proyecto.
Como hemos comentado anteriormente, el tipo de herramienta automatizada dependerá de las necesidades del proyecto, entre ellas:
- Estándares y niveles de cumplimiento requeridos, los cuales pueden incluir los estándares WCAG 2.1, las WCAG 2.0 o una lista modificada de reglas de accesibilidad; antes de seleccionar cualquier herramienta debes asegurar esta especificación.
- Selección herramientas, donde la naturaleza del proyecto web es clave para determinar cuáles herramientas funcionan mejor en el entorno web objetivo, puede ser una página web, una aplicación web o nativa para dispositivos móviles, etc.
- Hitos del proyecto, se deben considerar las fechas de entrega para planificar en qué punto del ciclo de vida del desarrollo, se iniciará la fase de pruebas de accesibilidad, si es obligatorio para el proyecto o no, si es un proyecto nuevo (donde la fase de desarrollo no ha iniciado) o uno estable (en uso), donde lo recomendable sería realizar previamente una auditoría de accesibilidad completa para estimar el esfuerzo de desarrollo y pruebas para aplicar los correctivos.
- Evaluar implementación de las herramientas de accesibilidad, teniendo en cuenta las herramientas a utilizar (en cualquier de sus formas) es importante tener en cuenta algunos factores: Complejidad de instalación y/o configuración, por ejemplo: Si debe integrarse en un flujo CI/CD o responde a un complemento o extensión del navegador de fácil instalación, pero se necesita un periodo de entrenamiento para aprender a usar las funcionalidades que ofrece), si es requerido para una persona o todos los miembros del equipo de proyecto (Dev & QA), si la herramienta es código abierto y es libre de usar o es necesario adquirir licencias para su uso en la organización.
- La estrategia de ejecución de pruebas de accesibilidad, para determinar los roles y responsabilidad de ejecución de las pruebas (diseñadores, desarrolladores, QA, usuarios finales con discapacidades, etc). En este punto también se debe conocer la frecuencia de ejecución, la dinámica propuesta para gestionar los hallazgos y aplicación de correctivos, como reflejar el cumplimiento en el informe de resultados.
Ejecución de pruebas de accesibilidad
En la creación de planes de prueba, se suelen asociar distintos tipos de pruebas para asegurar la calidad de nuestros entregables, las pruebas de accesibilidad no son la excepción, debe ser un proceso continuo e iterativo, parte integral del plan de pruebas, en el que se describa el alcance, los objetivos, los métodos, las herramientas, los criterios y el cronograma de las pruebas de accesibilidad, su ejecución debe ser periódica o frecuente dependiendo de las necesidades del proyecto.
A menudo se facilita su ejecución a través de complementos o extensiones integradas en el navegador, un análisis en línea, manuales o de forma automatizada en flujos de trabajo ágiles como parte del proceso de integración y entrega continua (CI/CD), el objetivo es claro “garantizar regresiones de accesibilidad web”, de igual manera, importante añadir las actividades de revisión y actualización de estos escenarios.
Informes de resultado pruebas de accesibilidad web
Los informes de resultado es un paso fundamental en la estrategia, permite comunicar y realizar un seguimiento de los resultados de las pruebas de accesibilidad de manera eficiente, deben resumir los hallazgos, incidencias y recomendaciones resultantes en cada iteración. Por lo general, en procesos de integración y entrega continua (CI/CD) este reporte se genera automáticamente con cada ejecución, sin embargo, periódicamente es recomendable generar informe del tipo “ejecutivo” que refleje el estado general del proyecto, cumplimiento de la normativa y el grado de conformidad alcanzado, entre otros aspectos relevantes.
3. Herramientas para evaluar la accesibilidad web.
Existen programas de software y servicios que ayudan a los equipos de desarrollo (DEV&QA) a identificar y corregir los problemas de accesibilidad, permiten identificar barreras de accesibilidad ahorrando tiempo y esfuerzo en pruebas, no obstante, las herramientas tienen algunas limitaciones, no todo se pueden automatizar y se deben realizar algunas comprobaciones de forma manual “asistida por la herramienta”, algunas requieren el uso de licencia (de pago), y otras son de libre uso, su escogencia dependerá de la necesidad del entorno web, sus y sus características.
En general, la mayoría se integran en diferentes entornos de trabajo, bien mediante el uso de librerías, hasta un complemento o extensión ejecutada desde el navegador web, algunas pueden escanear sitios buscando problemas de accesibilidad, otras solo escanean la página, pero hay que aclarar que, sin importar la herramienta usada, algunos resultados pueden ser inexactos (falsos/positivos) por lo que hay que verificarlo más.
A continuación, se mencionan algunas recomendaciones de las herramientas para la evaluación de accesibilidad web y aspectos más relevantes:
- Axe DevTools Extension: Es una herramienta desarrollada por el equipo de Deque Systems,Inc., se instala como complemento o extensión en el navegador para pruebas de accesibilidad, combina pruebas automatizadas como guiadas y cuenta con una interfaz fácil de usar. Su enfoque de ejecución combinada permite detectar el 80% de los problemas más comunes de accesibilidad.
El proyecto axe-core facilita que las pruebas de accesibilidad se pueden ejecutar como parte integral del ciclo de pruebas en CI/CD del proyecto, permitiendo encontrar un promedio del 57% de los problemas WCAG automáticamente, el resto de los elementos que no puede identificar los devolverá como «incompletos» para aplicar revisiones manuales. También permite realizar escaneos en todo el sitio web o parciales, aprendizaje automático, generar y compartir enlaces con los resultados, guardar y exportar resultados en diferentes formatos.
- WAVE Evaluation Tool: Es una herramienta web desarrollada por WebAIM.org se instala a través de una extensión en el navegador y proporciona información visual mediante la inyección de iconos e indicadores en la página auditada lo que la hace una opción bastante intuitiva y educa sobre problemas de accesibilidad. Como otras herramientas de ejecución automatizada ayuda a encontrar problemas de accesibilidad, pero con cierto grado de cobertura y precisión, lo cual hace necesaria la intervención humana. El análisis se realiza íntegramente dentro del navegador Chrome, lo que permite una valoración segura de las páginas web de intranet, locales, protegidas con contraseña y otras páginas web confidenciales.Para ejecutar un informe WAVE, simplemente haga clic en el ícono WAVE a la derecha de la barra de direcciones de su navegador, o seleccione «WAVE esta página» en el menú contextual. La interfaz facilita la evaluación humana de muchos otros aspectos de la accesibilidad y los problemas encontrados con esta herramienta se alinean con las pautas del estándar de WCAG 2.2.
También ofrece la posibilidad de realizar una auditoría en línea, cuyo reporte también es
bastante intuitivo para hacer evaluaciones rápidas, para ello se debe acceder a través del siguiente enlace: https://wave.webaim.org/ y ejecutar la auditoría.
- PageSpeed Insights: Es una herramienta de Google que ayuda a analizar el rendimiento de una página web, está disponible en pagespeed.web.dev y permite ejecutar análisis bajo demanda con solo indicar la URL del sitio web, tanto para dispositivos móviles como de escritorio. Entre las métricas generadas se incluyen una enfocada a “Accesibilidad web”, muestra las auditorías y el detalle correspondiente para ayudar a corregir los problemas encontrados.
- Lighthouse: Es una herramienta de código abierto desarrollada por Google para auditar el rendimiento y la accesibilidad de las páginas web. Está incluida en el navegador de Google Chrome por lo que no es necesario instalar ninguna extensión, su ejecución es sencilla, solo se abre el Chrome y se navega a la página que deseas auditar, luego se habilita las opciones Chrome DevTools (en Windows “F12”), se configuran las opciones de auditoría (Accesibilidad), se selecciona el modo del dispositivo (Mobile/Desktop) y clic en «Analyze page load» para generar el reporte.
Al finalizar la ejecución podemos ver el detalle de la auditoría realizada, los problemas encontrados y recomendaciones para para ayudar a corregirlos, el enfoque de esta herramienta permite hacer auditorias más completas que “PageSpeed Insights”, además de facilitar las herramientas de desarrollador del Chrome DevTools para análisis y/o correcciones propuestas al cierre de la auditoria.
El equipo de W3 dispone de un espacio donde están documentadas un listado de herramientas de evaluación de accesibilidad web, este sitio contiene filtros que permiten encontrar la herramienta que más se adecue a las necesidades del proyecto.
Herramientas, recursos y referencias de interés
• Selecting Web Accessibility Evaluation Tools
• Lista de tareas de accesibilidad manual
• WebAIM’s WCAG 2 Checklist
• A guide to understanding and implementing Web Content Accessibility Guidelines 2.0
• Check List for WCAG Compliance
• Legislación nacional e internacional
• Guía para crear sitios web accesibles
• Web Accessibility Evaluation Tools List
• Learn Accessibility