Parafraseando a Tim Berners-Lee, creador de la WWW y director del W3C,»la potencia de la web se basa en su universalidad y un aspecto esencial es que cualquiera pueda acceder a la misma sin importar sus capacidades».
En este tutorial vamos a centrarnos en la accesibilidad web, por ello vamos a mostraros como poder analizar la accesibilidad de nuestras webs gracias a GoogleChrome Accessibility Developers Tools, y como automatizar el proceso con Jenkins.
Índice de contenidos
- 1. Introducción
- 2. Entorno
- 3. Instalación del entorno
- 4. Ejecución análisis
- 5. Automatización de análisis mediante Jenkins y Docker
- 6. Conclusiones
- 7. Referencias
1. Introducción
Entendemos por Accesibilidad Web la habilidad de hacer que una web sea usable por el máximo número de personas posible con independencia de sus conocimientos o capacidades personales.
En este sentido la W3C (World Wide Web Consortium) crea en 1997 la Web Accessibility Initiative (WAI), iniciativa que busca como principal objetivo eliminar las barreras que impiden a las personas que tengan dificultades de cualquier índole encontrar o consumir información en la web.
Para alcanzar esta meta, el W3C definió una serie de pautas o directivas que deben tenerse en cuenta a la hora de diseñar las páginas web para conseguir que estas sean accesibles. Hasta un total de 14 pautas se ven recogidas en el WCAG (Web Content Accessibility Guidelines).
Desde proveer de alternativas equivalentes del contenido en formato audio o visual, hasta asegurarnos de que los documentos que ofrecemos son claros y sencillos, cada pauta se ve definida por una serie de checkpoints que nos informaran del grado de cumplimiento de la misma.
Dichos checkpoints se pueden categorizar según distintas prioridades de importancia, del 1 al 3, y el cumplimiento de la totalidad de cada una de las prioridades nos dará una medida de cuán accesible es nuestra web.
Es a través del cumplimiento de los checkpoints como se definen los grados o niveles de conformidad:
- Nivel de conformidad «A»:Se cumple con la totalidad de los checkpoints de prioridad 1.
- Nivel de conformidad «AA»:Se cumple con la totalidad de los checkpoints de prioridad 1 y 2.
- Nivel de conformidad «AAA»:Se cumple con la totalidad de los checkpoints. Prioridades 1, 2 y 3 completas.
La propia WAI dispone de una herramienta que nos ayuda a generar informes, paso a paso, sobre el grado de accesibilidad de una determinada web, pero no realiza ningún análisis de manera automática.
Para este último proceso, los análisis automáticos, vamos a ayudarnos de GoogleChrome Accessibility Developer Tools, una suite de herramientas que, si bien no se basan en las 14 pautas de la W3C, si analizan el cumplimiento de algunos problemas más comunes en la accesibilidad web, como son:
- El cálculo del ratio de contraste y la sugerencia de colores.
- Obtención y validación de atributos y estados WAI-ARIA (Accesibile Rich Internet Applications).
- El cálculo de la accesibilidad de un nombre usando el algoritmo propuesto por la W3C.
En este tutorial vamos a mostraros como poder analizar la accesibilidad de nuestras webs gracias a GoogleChrome Accessibility Developers Tools, y como automatizar el proceso con Jenkins.
2. Entorno
El tutorial está escrito usando el siguiente entorno:
- Hardware: Portátil MacBook Pro Retina 15′ (2.5 Ghz Intel Core I7, 16GB DDR3).
- Sistema Operativo: macOS Sierra 10.12.3.
- Git v2.6.0
- NodeJS v6.3.0
- Npm v3.10.3
- Grunt v1.2.0
- PhantomJs v2.1.1
- Docker v1.12.2
- Docker Kitematic v0.12.0
3. Instalación del entorno
El primer punto a tener en cuenta es que asumiremos que ya se dispone de las dependencias declaradas en la sección anterior.
Continuaremos clonando el repositorio de las herramientas como se muestra a continuación:
$ git clone --recursive https://github.com/GoogleChrome/accessibility-developer-tools.git
Tras la descarga del proyecto desde Github, procederemos colocandonos en la carpeta base del proyecto y resolviendo todas las dependencias del mismo mediante:
$ npm install
Para finalizar volveremos a compilar el proyecto con las dependencias descargadas mediante grunt:
$ grunt
Mediante estos sencillos pasos habremos instalado el entorno necesario para proceder con los análisis de accesibilidad de la herramienta Accessibility Developer Tools (ADT).
4. Ejecución análisis
Para proceder con los análisis de accesibilidad tan solo necesitaremos ayudarnos de la herramienta PhatomJS procediendo según el siguiente comando:
$ phantomjs {ruta-de-instalacion-ADT}/tools/runner/audit.js {ruta-del-fichero-html}
En ese instante, la herramienta comenzará con el análisis del fichero html objetivo, ofreciendo como resultado la escritura por pantalla de aquellas problemas de accesibilidad que haya detectado.
A continuación se puede ver un ejemplo de resultado de ejecución del análisis.
*** Begin accessibility audit results *** An accessibility audit found Errors: Error: AX_TEXT_01 (Controls and media elements should have labels) failed on the following element: #s See https://github.com/GoogleChrome/accessibility-developer-tools/wiki/Audit-Rules#ax_text_01 for more information. Warnings: Warning: AX_FOCUS_01 (These elements are focusable but either invisible or obscured by another element) failed on the following elements (1 - 5 of 96): #topbar > .container > DIV:nth-of-type(2) > .social-icons.clearfix > UL > .social-twitter > A #topbar > .container > DIV:nth-of-type(2) > .social-icons.clearfix > UL > .social-facebook > A #topbar > .container > DIV:nth-of-type(2) > .social-icons.clearfix > UL > .social-linkedin > A #topbar > .container > DIV:nth-of-type(2) > .social-icons.clearfix > UL > .social-youtube > A #topbar > .container > DIV:nth-of-type(2) > .social-icons.clearfix > UL > .social-rss > A See https://github.com/GoogleChrome/accessibility-developer-tools/wiki/Audit-Rules#ax_focus_01 for more information. Warning: AX_TEXT_02 (Images should have a text alternative or presentational role) failed on the following elements (1 - 5 of 18): #content > .post.clearfix > .image-member > A > IMG #content > DIV:nth-of-type(3) > .image-member > A > IMG #content > DIV:nth-of-type(4) > .image-member > A > IMG #content > DIV:nth-of-type(5) > .image-member > A > IMG #content > DIV:nth-of-type(6) > .image-member > A > IMG See https://github.com/GoogleChrome/accessibility-developer-tools/wiki/Audit-Rules#ax_text_02 for more information. Warning: AX_TEXT_04 (The purpose of each link should be clear from the link text) failed on the following elements (1 - 5 of 20): #content > .post.clearfix > .image-member > A #content > DIV:nth-of-type(3) > .image-member > A #content > DIV:nth-of-type(4) > .image-member > A #content > DIV:nth-of-type(6) > .image-member > A #content > DIV:nth-of-type(7) > .image-member > A See https://github.com/GoogleChrome/accessibility-developer-tools/wiki/Audit-Rules#ax_text_04 for more information. Warning: AX_COLOR_01 (Text elements should have a reasonable contrast ratio) failed on the following elements (1 - 5 of 128): #topbar > .container > .eight.columns > .callus #topbar > .container > DIV:nth-of-type(2) > .social-icons.clearfix > UL > .social-twitter > A #topbar > .container > DIV:nth-of-type(2) > .social-icons.clearfix > UL > .social-facebook > A #topbar > .container > DIV:nth-of-type(2) > .social-icons.clearfix > UL > .social-linkedin > A #topbar > .container > DIV:nth-of-type(2) > .social-icons.clearfix > UL > .social-youtube > A See https://github.com/GoogleChrome/accessibility-developer-tools/wiki/Audit-Rules#ax_color_01 for more information. Warning: AX_IMAGE_01 (Meaningful images should not be used in element backgrounds) failed on the following elements (1 - 5 of 60): #content > .post.clearfix > .post-meta > .meta-date > .icon-calendar #content > .post.clearfix > .post-meta > .meta-author > .icon-user #content > .post.clearfix > .post-meta > .meta-comment > .icon-comment #content > .post.clearfix > .post-meta > SPAN:nth-of-type(5) > .icon-eye-open #content > DIV:nth-of-type(3) > .post-meta > .meta-date > .icon-calendar See https://github.com/GoogleChrome/accessibility-developer-tools/wiki/Audit-Rules#ax_image_01 for more information. *** End accessibility audit results ***
Una característica bastante interesante es que, para cada uno de los problemas que detecte durante el análisis, nos ofrece una URL del tipo See https://github.com/GoogleChrome/accessibility-developer-tools/wiki/Audit-Rules#
5. Automatización de análisis mediante Jenkins y Dockerización.
Vamos a proceder con la automatización del proceso de análisis con Jenkins, pero, dado que el proceso de instalación es bastante sencillo, consideramos oportuno automatizarlo asociándolo a una imagen dockerizada de Jenkins.
Procedemos con la generación de un fichero Dockerfile como el que se puede ver a continuación:
FROM jenkins:latest USER root RUN apt-get update RUN apt-get install -y nodejs RUN apt-get install -y npm RUN ln -s /usr/bin/nodejs /usr/bin/node RUN mkdir -m 777 /opt/adt RUN git clone https://github.com/jlrvilla/accessibility-developer-tools.git /opt/adt RUN npm install -g grunt-cli RUN npm install -g grunt RUN cd /opt/adt && npm install RUN cd /opt/adt && grunt --force RUN npm install -g phantomjs USER jenkins
Como vemos, no estamos haciendo uso del repositorio de GoogleChrome, sino que hemos realizado un fork del proyecto donde hemos modificado el runner audit.js adaptandolo para que nos devuelva códigos de error en caso de encontrar problemas de manera que Jenkins nos devuelva un mensaje adecuado dependiendo de la corrección o no del proceso de análisis.
A continuación procedemos con la construcción de la imagen mediante:
$ docker build -t "jenkins:adt" .
Y levantamos una instancia de la imagen:
$ docker run --name "ADT" jenkins:adt
Cuando el contenedor se encuentre en pleno funcionamiento procedemos con el mapeo de puertos al exterior, en nuestro caso lo hemos realizado a través de Kitematic, como se puede ver en la imagen a continuación:
Una vez mapeados los puertos procedemos con la configuración de Jenkins mediante el sencillo asistente paso a paso que nos ofrece la imagen dockerizada.
Cuando hayamos acabado procedemos con la configuración de una nueva tarea de jenkins. En nuestro caso simplemente procederemos con la evaluación de un fichero html que vamos a alojar en la carpeta temporal.
En las imágenes anteriores podemos ver cómo proceder con el análisis, simplemente estableciendo la ejecución de un nuevo paso
de tipo «Ejecutar línea de comandos (Shell)» en el que estableceremos la ejecución del análisis:
phantomjs /opt/adt/tools/runner/audit.js /tmp/prueba.html
En este caso tan solo mantenemos un fichero html sobre el que realizar la prueba mientras en nuestras páginas web, probablemente, existan más páginas. ¿Qué hacer en estos casos? Tendremos que modificar este paso para introducir un poco de programación shell script realizando una búsqueda de aquellos fuentes html en la ruta donde se disponga de los ficheros a analizar y proceder con un bucle FOR.
El resultado que nos devuelve la ejecución de la tarea de Jenkins, en nuestro caso, será similar a la que se muestra a continuación:
6. Conclusiones
La accesibilidad web debería ser uno de los pilares básicos en la generación de webs, tanto más si la web que estamos creando está pensada para el público en general.
En este tutorial hemos visto que existe un estándar WCAG que nos ayuda en la búsqueda de conseguir que nuestra web sea accesible, hemos visto que a través de herramientas como las Accessibility Developer Tools de GoogleChrome podemos realizar análisis que nos permitan verificar si vamos por el buen camino.
Por último hemos visto que es una tarea fácilmente automatizable dentro de procesos de integración continua, mediante la generación de una imagen de Docker de Jenkins un poco personalizada.
¡Espero que este tutorial os sirva de ayuda en la búsqueda de una web más accesible!