T reba ll F ina l de G rau
Herramienta de análisis de accesibilidad WCAG 2.0
MARIANO FONTANA HUARTE
Tutor
Jaume Jaume Mayol
Escola Politècnica Superior
Universitat de les Illes Balears
S UMARI
Sumari i
1 Introducción 1
1.1 Estructura del documento . . . 2
1.2 Agradecimientos . . . 3
2 Presentación del proyecto 5 2.1 Contexto del proyecto . . . 5
2.2 Objetivos . . . 6
2.3 Alcance del proyecto . . . 6
2.4 Importancia del proyecto . . . 6
3 Conceptos teóricos 9 3.1 Accesibilidad Web . . . 9
3.2 WCAG 2.0 . . . 10
3.3 Javascript . . . 11
3.4 Node.js . . . 12
3.5 Reactjs . . . 12
3.6 Webpack . . . 12
3.7 Single Page application (SPA) . . . 12
3.8 Mocha . . . 13
3.9 Técnica divide and conquer . . . 13
3.10 Test driven development (TDD) . . . 14
3.11 Kanban . . . 15
4 Desarrollo del proyecto 17 4.1 Planificación . . . 17
4.2 Metodología . . . 19
4.3 Descripción . . . 21
4.3.1 Descripción del proyecto . . . 21
4.3.2 Proyectos anteriores . . . 21
4.3.3 Usuarios . . . 21
4.3.4 Análisis del sistema . . . 21
4.4 Interfaz de usuario . . . 25
4.5 Desarrollo . . . 28
4.5.1 Analizador WCAG 2.0 . . . 28
4.5.2 Aplicación frontal (Recogida y corrección del HTML) . . . 32
ii SUMARI
4.6 Solución y resultados . . . 35
4.6.1 Resultados obtenidos . . . 35
4.6.2 Ventajas e inconvenientes de la solución . . . 35
4.6.3 Proyectos y mejoras futuros . . . 36
5 Conclusiones 39
Bibliografia 41
C
APÍTOL1
I NTRODUCCIÓN
Se define la accesibilidad web como una característica de una página web que hace que se pueda utilizar por personas que padecen algún tipo de discapacidad, sea temporal o definitiva.
El concepto de accesibilidad surge para eliminar las dificultades de acceso para las personas con discapacidad (tanto sensoriales como físicas), pero además permite otras ventajas adicionales para los usuarios web sin discapacidad, como se verá a lo largo del proyecto.
Un organismo internacional, la W3C, definió en el año 2008 un conjunto de reglas de diseño a seguir para conseguir una web accesible.
Diversos estudios, estudios de los niveles de accesibilidad muestran que las reglas de diseño accesible no se cumplen.
En este sentido, se ha desarrollado una herramienta que automatiza el análisis de las reglas de diseño WCAG 2.0
La aplicación que se ha desarrollado es un analizador de código html que busca errores con las reglas WCAG 2.0 (Web Content Accessibility Guidelines 2.0). Esta aplicación consta de dos partes por separadas:
1. Por una parte, se ha desarrollado una librería de análisis de código html. Esta librería se ha desarrollado como un módulo completamente separado, con tal de poder utilizar esta librería en otros proyectos, en caso de que así se quisiera.
2. Por otra parte, se ha creado un sitio web que permite tanto recoger el html como para corregir los errores analizados. Esta aplicación conecta con la librería de análisis como una librería general de Javascript.
1. INTRODUCCIÓN
Esta aplicación sólo contemplará una muestra incompleta de las reglas de accesibilidad, las cuales se contemplan en las técnicas de diseño de nivel A. Se podría realizar en un segundo proyecto la implementación de todas las reglas restantes.
La motivación principal por la cual se ha realizado este proyecto es con la intención de crear una herramienta que ayude al desarrollo de sitios web accesibles para todo tipo de persona.
Aunque la herramienta que se presenta a continuación vendrá limitada debida a pro- blemas que se explicarán a continuación, esta debería ser fácilmente ampliable en un proyecto futuro, con tal de brindar la funcionalidad completa de las WCAG 2.0.
El proyecto comenzó siendo el proyecto de 2 alumnos (Mariano Fontana Huarte y Petar Boyanov). Después de cierto tiempo durante el cual el proyecto se quedó estancado, Petar decidió abandonarlo.
A partir de Septiembre de 2017, Mariano retomó el proyecto en el que realizar tanto la aplicación frontal como el analizador de reglas.
1.1 Estructura del documento
En este apartado se presentará la estructura que seguirá el documento:
1. Primero, se expondrán las motivaciones y el resumen del proyecto, con tal de presentar la idea general del proyecto y poner en contexto a todos los lectores.
2. Seguidamente, se expondrá con algo más de detalle el alcance, los objetivos y la importancia de este proyecto.
3. En tercer lugar, se hará una introducción a todos los conceptos teóricos que se utilizarán durante el desarrollo de la aplicación
4. En cuarto lugar, se expondrá con mucho detalle todos los puntos por los que se ha pasado a la hora de desarrollar el proyecto. En este apartado se tocarán, respectivamente, los siguientes temas:
a) Metodología de trabajo b) Proyectos anteriores
c) Usuarios que utilizarán la aplicación d) Análisis del sistema a desarrollar e) Interfaz de usuario
f ) Módulos desarrollados g) Solución y resultados
5. Para finalizar, en el último apartado, se presentarán las conclusiones a las que se ha llegado durante el desarrollo de la aplicación
2
1.2. Agradecimientos
1.2 Agradecimientos
En este apartado se mencionarán las personas que han ayudado en el desarrollo del proyecto:
• Jaume Jaume Mayol: por toda la ayuda en el desarrollo.
• Petar Boyanov: por la ayuda para reutilizar el código que se había escrito en un principio.
C
APÍTOL2
P RESENTACIÓN DEL PROYECTO
En este apartado se expondrán tanto el alcance como el objetivo que pretende cumplir el proyecto, con tal de explicitar la importancia de este.
2.1 Contexto del proyecto
Como se expone en la tesis doctoral del tutor del TFG [1], el nivel de accesibilidad que se presenta en las páginas web turísticas impide hablar de un verdadero turismo de calidad en las Islas Baleares. Esto puede ser extrapolado a la web en general.
La situación actual de la accesibilidad es que ésta va mejorando, sobretodo debido a la globalización de la web en diferentes dispositivos y con diferentes limitaciones. [2] Por ejemplo, la necesidad de adaptar páginas web a diferentes dispositivos y resoluciones puede compararse con el uso de magnificación para gente con visión impedida.
Debido a esto, la accesibilidad en la web en general ha ido incrementando.
Aun así, el objectivo para la accesibilidad de laW3C (World Wide Web Consortium)con la iniciativaWAI (Web Accessibility Initiative)es conseguir que la web sea accessible para todo el mundo [3], objetivo para el cual sigue siendo necesario un gran esfuerzo generalizado por todo el sector.
2. PRESENTACIÓN DEL PROYECTO
2.2 Objetivos
El objetivo principal de este proyecto es ampliar sobre el marco de trabajo que define el tutor Jaume Jaume Mayol en su doctorado [1], creando una aplicación informática que realice el análisis de las reglas y ofrezca una interfaz de usuario para su uso.
Este obetivo se puede separar en 2 bloques
• Obtener un analizador automático de html que ayude a cualquier desarrollador web a reconocer los errores que sus páginas web están cometiendo (en cuanto a accesibilidad) de manera automática, ofreciendo soluciones en la medida de lo posible.
• Obtener un analizador automático de html fácilmente extensible, con la posibili- dad de modificar y ampliar las reglas a analizar con sencillez.
2.3 Alcance del proyecto
El proyecto se trata de realizar el desarrollo de un analizador de accesibilidad, siguiendo las reglas del WCAG 2.0.
En este proyecto específicamente se desarrollarán:
• Una interfaz de usuario cuyo uso sea simple e intuitivo.
• Una primera implementación del analizador de accesibilidad. A efectos de cum- plir con la carga de trabajo de un TFG, se ha procedido a considerar un subocon- junto de las reglas para la accesibilidad ’A’, dejando para posteriores ampliaciones el resto de reglas. Este módulo debería ser independiente a la interfaz de usuario, con tal de que pueda ser reutilizado.
Esta aplicación será fácilmente ampliable para proyectos posteriores, con tal de poder mantener las reglas actualizadas y poder agregar nuevas en el caso de que nuevas sean desarrolladas en las siguientes versiones de lasWCAG 2.0.
2.4 Importancia del proyecto
Este proyecto pretende contribuir con la construcción de una web universal accessible.
Esta herramienta tendría relevancia debido a dos factores:
• Una herramienta con estas características, por una parte, ayudará en los esfuerzos de diferentes compañías alrededor de la mejora de accesibilidad de sus páginas web.
6
2.4. Importancia del proyecto
• Por otra parte, si se permite la mejora continua de esta herramienta, esta puede ir desarrollándose junto al sector, con tal de intentar incorporar la accessibilidad en el diseño web.
Por otra parte, la herramienta se servirá como una aplicación web, sin ningún tipo de registro, con tal de ofrecerla libremente por la web.
Además, debido a la separación de la librería de análisis de la aplicación web, sería posible crear nuevas herramientas en base a esta librería, pudiendo así conseguir herramientas completamente nuevas que puedan ser utilizados en casos que no se tengan en cuenta, como se explica en el apartado 4.6.3
C
APÍTOL3
C ONCEPTOS TEÓRICOS
En este capítulo se exponen los conceptos teóricos necesarios para comprender el contexto del desarrollo del TFG. Se describen las bases teóricas, como la normativa WCAG, así como un conjunto de técnicas, tecnologías y metodologías utilizadas en el desarrollo del TFG.
3.1 Accesibilidad Web
La accessibilidad web se define como la práctica inclusiva que se encarga de eliminar las barreras que previenen la interacción o el acceso para personas con discapacidades a páginas web. [4]
Cuando una página web es accesible, todo los usuarios tienen el mismo acceso a información y funcionalidades. Esto puede ser beneficioso tanto a usuarios con alguna discapacidad como para usuarios sin discapacidades.
Las principales ventajas que presenta la accesibilidad web son: [5]
• Evitar discriminacion y complicaciones legales.
• Mejorar usabilidad para todo tipo de usuario, tanto usuarios con alguna discapa- cidad como usuarios sin discapacidades.
• Mejorar reputación, pudiendo demostrar la preocuación social y contribuyendo con el objetivo de una web universal accesible.
• Aumentar el mercado de la página web.
• La accesibilidad web mejora el posicionamiento SEO, debido a que ciertas reglas agregan metainformación que los buscadores utilizan para indexar.
3. CONCEPTOS TEÓRICOS
3.2 WCAG 2.0
LasWeb Content Accessibility Guidelines (WCAG) 2.0 son un seguido de guías que cu- bren un amplio rango de recomendaciones para crear contenido web mas accesible.[6]
Seguir estas guías creará contenido web más accesible a un amplio rango de gente con discapacidades, incluyendo discapacidades físicas e intelectuales. Además, seguir estas guías creará contenido web más usable en general.[6]
Estas guías son el sucesor a lasWeb Content Accessibility Guidelines (WCAG) 1.0, las cuales fueron creadas en el año 1999.[6]
Las WCAG 2.0 dividen la accessibilidad en 3 niveles. Las guías se clasifican en cada uno de los niveles de conformidad teniendo en cuenta que tan esenciales son para el usuario final al mismo tiempo que comprobando cuales implican las menores limitaciones para los creadores de contenido.[6]
Los niveles son los siguientes:
1. A: Cumplimiento mínimo.
2. AA: Cumplimiento moderado.
3. AAA: Cumplimiento total.
Cada uno requiere la conformidad de los niveles anteriores para su conformidad.[6]
La conformidad se define por la siguiente serie de requisitos:[6]
1. Nivel de conformidad: Se debe cumplir con uno de los niveles de conformidad definidos anteriormente, cumpliendo también sus niveles inferiores.
2. Páginas completas: La conformidad no puede cumplirse únicamente en una parte de la página.
3. Proceso completo: Cuando una página es una serie de páginas que conforman un proceso, todas las páginas que forman parte de este proceso tienen que cumplir conformidad.
4. Sólo métodos soportados por accesibilidad para usar tecnologías: Únicamente se aceptan métodos que tengan soporte de manera generalizada en herramientas de soporte para cumplir conformidad. En la figura 3.1 podemos ver un esquema que explica las áreas y métodos que se pueden utilizar en las herramientas de asistencia.
5. Sin interferencia: En el caso de que alguna tecnología es usada de una manera que no soportada (como se explica en el punto anterior), o sin ofrecer conformidad, esto no debe bloquear la habilidad de los usuarios a acceder al resto de la página.
10
3.3. Javascript
Figura 3.1: Áreas y métodos de asistencia [7]
Por otra parte, WCAG 2.0 clasifica sus guías por área de actuación:[6]
1. Percibible: La información y componentes deben ser presentados de maneras que los usuarios puedan percibir.
2. Operable: Los componentes de la interfaz de usuario y la navegación debe ser operable.
3. Entendible: La información y las operaciones que se pueden realizar desde la interfaz de usuario deben ser comprensibles.
4. Robusto: El contenido tiene que ser lo bastante robusto como para que pueda ser utilizado de manera confiable por una amplia variedad de agentes de usuario, incluyendo tecnologías asistivas.
Para concluir, las correcciones de las técnicas que presenta las WCAG 2.0 pueden ser:[6]
• Automáticas: En el caso de que su corrección se pueda automatizar. Por ejemplo, la regla H37 requiere la introducción de elementos alt en todas las imágenes.
Esto se puede automatizar, para agregar el atributo en cada imágen y luego simplemente pedir el valor deseado al usuario.
• Manuales: En el caso de que su corrección no se pueda automatizar. Por ejemplo, la regla H69 requiere de la identificación de secciones mediante una cabecera (<h>). El problema está en que no hay ninguna marca que defina como es una sección y requiere de comprobación humana.
3.3 Javascript
Javascript es un lenguaje de programación interpretado, dialecto del estandar Ecmas- cript. [8]
3. CONCEPTOS TEÓRICOS
Se usa principalmente en el lado del cliente, ya que esta implementado en la mayoría de navegadores web modernos.
En este momento, Javascript se ha convertido en el lenguaje principal de programación web, el cual se utiliza en toda empresa que se dedique al desarrollo web.
3.4 Node.js
Node.js es un runtime de Javascript creado sobre el motor V8 de Google Chrome.[9]
Fue desarrollado originalmente por Ryan Dahl en 2009, y desde entonces se ha conver- tido en un importante método para el desarrollo de servidores web.
Algunas de las empresas que lo utilizan son GoDaddy, Groupon, IBM, LinkedIn, Micro- soft, Netflix, PayPal, Rakuten, SAP, Tuenti, Voxer, Walmart, and Yahoo!.[10]
En la página de npm (El contenedor de librerías de Node) hay miles de librerías des- arrolladas y accesibles con la intención de ser utilizadas de manera abierta por la comunidad.[11]
3.5 Reactjs
Reactjs es una librería de JS utilizada para crear interfaces de usuario de manera sencilla.
Este librería intenta separar los diferentes componentes de una interfaz, de manera que cada uno de estos funcione de manera autónoma, sin necesidad (O con mínima ne- cesidad) de dependencias externas, pudiendo así separar en componentes reutilizables de manera simple.[12]
Esta librería se mantiene por el trabajo de, entre otros, Facebook e Instagram, además de una gran cantidad de desarrolladores independientes.[13]
Una gran ventaja que otorga esta librería es que permite trabajar con diferentes fra- meworks MVC con relativa sencillez, tales como AngularJS o Django, entre otros.
3.6 Webpack
Webpack es un empaquetador de módulos para aplicaciones de JS. Esto quiere decir que empaqueta módulos de JS y sus dependencias en ficheros sin dependencias[14]
La utilidad de empaquetar módulos de JS es para tanto evitar que fallas de dependencias por separado como para poder comprimir los estáticos resultantes más fácilmente.
3.7 Single Page application (SPA)
Una aplicación web SPA es una aplicación web que interactúa con el usuario de manera dinámica, reescribiendo la página actual en vez de cargando páginas nuevas.
12
3.8. Mocha
Esta metodología de programación de páginas web busca minimizar las interrupciones de la experiencia de usuario, interrupciones que un cambio de página provocaría.[15]
Con tal de conseguir esta funcionalidad, en vez de realizar llamadas de cambios de páginas, se utilizan otros métodos para conseguir actualizar la página:[16]
• Por una parte, siendo esta la manera más usual de realizar la conexión con el servidor, se pueden realizar llamadas AJAX contra el servidor, recogiendo en cada una de estas, la información necesaria para realizar el cambio en la página.
• Por otra parte, un método que está empezando a surgir son los websockets. Estos son conexiones bidireccionales entre Cliente y servidor.
• Adicionalmente, una manera menos utilizada es mediante eventos de servidor.
Para ello, es necesario que el cliente abra una conexión con el servidor, mediante el cual, este servidor le enviará eventos con los datos necesarios para actualizar la pantalla.
Esta metodología es extremadamente útil para experiencias de usuarios que pueden considerarse como una única experiencia.
3.8 Mocha
Mocha es un framework de js utilizado para construir suites de tests.[17]
Una de las mayores ventajas que presenta este framework es la simpleza mediante la cual se pueden crear tests, además de una construcción y ejecución de los tests que no requiere de un setup inicial.
3.9 Técnica divide and conquer
La técnica de desarrollo divide and conquer es una técnica mediante la cual, para resolver el problema en cuestión, se realizan sucesivas divisiones del problema en problemas más pequeños.
1. Este proceso se repite hasta que los problemas resultantes son lo bastante evi- dentes para ser resueltos sin necesidad de un esfuerzo demasiado costoso.
2. Una vez se ha llegado a este punto, se resuelven los subproblemas más pequeños.
3. Una vez resueltos, la combinación de los subproblemas debería dar lugar a la resolución del problema en cuestión.
Esta Técnica es extremadamente útil cuando el problema puede ser fácilmente separa- do en tareas más pequeñas.
3. CONCEPTOS TEÓRICOS
Una de las mayores ventajas es que el código resultante suele ser más modular, cosa que permite un testeo más simple de la aplicación.[18][19]
En la figura 3.2 se puede apreciar una representación del proceso que se ha explicado anteriormente
Figura 3.2: Esquema representativo de la técnica divide and conquer [18]
3.10 Test driven development (TDD)
El test driven development es un proceso del desarrollo de software que consiste en repetir un ciclo muy simple en el cual los requisitos se convierten en casos de test y el código se mejora para pasar exclusivamente estos tests:[20]
En la figura 3.3 se puede observar el ciclo mencionado anteriormente.
Este ciclo se repite constantemente hasta acabar con el desarrollo. Debido a esto, el código resultante cumple con los requisitos, ya que estos han sido utilizados para moldear los tests que se ejecutan.
Al acabar el desarrollo, también queda la batería de tests utilizada para implementar el código, batería que puede utilizarse para probar la funcionalidad en el caso de que esta vuelva a cambiarse[21][22]
14
3.11. Kanban
Figura 3.3: Ciclo de trabajo utilizado en TDD[21]
3.11 Kanban
Kanban es un sistema de planificación de tareas para lean y JIT manufacturing. Este sistema de planificación se utiliza para mejorar la eficiencia de procesos. [23]
En el mundo de la informática, Kanban puede ser utilizado para organizar las planificar las tareas que van a ser implementadas en las siguientes iteraciones y priorizarlas según los criterios que los stakeholders vean convenientes.[24]
En la figura 3.4 se puede observar un ejemplo de estructura de una pizarra Kanban.
3. CONCEPTOS TEÓRICOS
Figura 3.4: Estructura de una pizarra kanban[25]
16
C
APÍTOL4
D ESARROLLO DEL PROYECTO
En este capítulo se presentará el desarrollo del proyecto que se ha llevado a cabo.
4.1 Planificación
En este apartado se expondrá la planificación que se ha seguido para realizar el proyec- to.
Para la planificación se ha utilizado la metodología Kanban y su uso se explica en detalle en la sección 4.2.
Al comenzar el proyecto, se propuso el esquema que se muestra en la figura 4.1.
Figura 4.1: Esquema simplificado del proyecto a desarrollar
Una vez que se habían descompuesto las necesidades del proyecto en historias de usuario, estas se clasificaron en diferentes categorías:
1. Analizador de HTML: Se refiere a todos las historias de usuario que forman parte
4. DESARROLLO DEL PROYECTO
del análisis de HTML.
2. Corrector de HTML: Se refiere a todas las historias de usuario que forman parte de la corrección del HTML.
3. Algoritmo de diferenciación: Se refiere a la funcionalidad de diferenciación que se utilizaría en la página web
4. Sitio web: Se refiere a todas las historias de usuario que se refieren a la creación de la página web.
Donde los dos primeros puntos se iban a desarrollar en otro proyecto.
La planificación inicial definió el siguiente orden:
1. Algoritmo de diferenciación: En primer lugar, se define el algoritmo principal con el que se iban a mostrar las diferencias.
2. Sitio Web: En segundo lugar se crea el sitio web que va a utilizar el algoritmo de diferenciación y los datos del proyecto de análisis de accesibilidad.
En un principio, el trabajo simplemente se componía de estas tareas, hasta que, debido a la partida de uno de los componentes del equipo se tomaron las siguientes decisiones:
1. Construir el algoritmo de diferenciación sale del alcance del proyecto.
2. Se construirá una versión reducida del analizador de HTML para funcionar con el sitio web.
La planificación después de este cambio definió el siguiente orden para el desarrollo de las historias de usuario:
1. Analizador: Este componente se desarrolló primero debido a que no depende de ningún otro.
2. Corrector: A continuación, debido a que ya tenemos una programa que pue- de informarnos correctamente de los errores de accesibilidad, se comienza el desarrollo de este componente.
3. Sitio Web: Como ya tenemos la librería de análisis y corrección, ya se puede comenzar a desarrollar con datos y funcionalidades reales el sitio web.
Al comenzar el proyecto, se definió el calendario que podemos observar en la figura 4.2.
18
4.2. Metodología
Figura 4.2: Calendario Inicial
4.2 Metodología
En este apartado se expondrán los temas de la metodología de trabajo que se ha utilizado para realizar el desarrollo de este trabajo.
Durante el desarrollo del proyecto, se ha utilizado la metodología Kanban.
Esta metodología se ha utilizado debido a la sencillez con la que permite reorganizar prioridades ante cambios que pueda presentar el trabajo.
Para este proyecto, se decidió utilizar un panel Kanban bastante simple, el cual simple- mente mantuviera los siguientes estados:
• To do: Para todas las tareas que aun están por hacerse
• Doing: Para todas las tareas que ahora mismo están en proceso
• Done: Para todas las tareas que han sido acabadas
• Discarded: Para todas las tareas que no formarán parte del producto final
En la figura 4.3 podemos observar el estado inicial de la pizarra Kanban utilizada en el proyecto (habiendo comenzado sólo con el algoritmo de diferenciación).
Debido a algunos análisis que se hicieron al empezar el proyecto y que cambiaron a lo largo de este, se tomaron algunas decisiones de arquitectura que más adelante fueron descartadas.
En la figura 4.4 se puede ver el estado de la pizarra después de estas decisiones.
Además, debido a que uno de los componentes del equipo que realizaba este trabajo decidió dejar el proyecto, esto agregó bastante trabajo a las prioridades.
En la figura 4.5 se puede ver el estado de la pizarra después de agregar el trabajo del analizador.
4. DESARROLLO DEL PROYECTO
Figura 4.3: Kanban Inicial
Figura 4.4: Kanban con descartes
Figura 4.5: Kanban extendido
Gracias a la metodología Kanban, fue extremadamente sencillo descartar el trabajo que se había analizado (dejándolo para quizás una segunda versión) y reorganizar las prioridades acordemente, incluyendo también las tareas que se agregaron más adelante.
20
4.3. Descripción
4.3 Descripción
4.3.1 Descripción del proyecto
En este apartado se expondrá la descripción del proyecto.
El proyecto tiene como objetivo crear una herramienta que analice los errores de accesibilidad que tenga un código HTML, enseñarlos al usuario y, si fuera posible, corregirlos o ayudar al usuario a corregirlos.
El análisis del HTML se hará en base a las reglas de accesibilidad expuestas en el WCAG 2.0.
4.3.2 Proyectos anteriores
Anteriormente a este proyecto, el tutor del TFG, Jaume Jaume Mayol, había desarrollado un un entorno de trabajo (framework) y un software de mejora de la accesibilidad web, con el objetivo de mejorar los niveles de accesibilidad web de la páginas web turísticas y con ello avanzar hacia un turismo de calidad.[1]
4.3.3 Usuarios
En este apartado se expondrán los diferentes tipos de usuarios que interactuarán con el sistema.
Debido a que la aplicación es una herramienta, esta no requiere de especiales man- tenimientos, motivo por el cual, no requiere de usuarios especializados que tengan mayores accesos que otros.
Como, al menos por el momento, no hay intención lucrativa detrás de este proyecto, no será necesario un usuario registrado que tenga mayores accesos.
Para esta aplicación se espera un único tipo de usuario: Anónimo.
Todo usuario que entre en la aplicación se considerará como usuario anónimo. Este usuario tiene acceso completo a la funcionalidad de la aplicación.
4.3.4 Análisis del sistema
En este apartado se mostrará un extracto del análisis del problema que se ha seguido para desarrollar la aplicación.
En dicho apartado se representan las decisiones y suposiciones realizadas, con las restricciones del sistema. Asimismo, se presentan los principales requisitos funcionales y no funcionales.
Decisiones y restricciones
Las decisiones y restricciones que se han considerado son las siguientes:
4. DESARROLLO DEL PROYECTO
• El lenguaje de programación utilizado será Javascript. Se utilizará Javascript porque permite reutilizar el código tanto en una aplicación frontal como en lógica de servidor. Esta fácil portabilidad puede utilizarse para mejorar eficiencia en un proyecto futuro, como se hablará en el apartado 4.6.3.
• Para el desarrollo de la interfaz de usuario se utilizará REACT, un framework de Javascript que permite crear esta Interfaz con sencillez.
• Debido al aumento de trabajo que acompañó la falta de uno de los miembros del equipo, se ha decidido que las únicas reglas que se aplicarán serán un sub- conjunto de las reglas de necesarias para cumplir con la accessibilidad de nivel
’A’.
Suposiciones y dependencias
Las suposiciones que se han hecho para este desarrollo han sido:
• Se ha supuesto que el HTML que un usuario suministre a la aplicación es correcto, con tal de facilitar el desarrollo.
Esto provoca que el sistema tenga una dependencia con el código HTML suministrado, ya que podría no funcionar correctamente si este no es correcto
Requisitos funcionales
Debido a que podemos encontrarnos dos tipos de requisitos diferenciados, se ha deci- dido que estos se listarán por separado.
Por una parte, nos encontramos con los requisitos funcionales de usuario. Estos, se listarán en forma de historias de usuario:
1.
Yo como usuario
Quiero poder suministrar un HTML
Para que el sistema pueda realizar un análisis en busca de errores de accesibilidad
2.
Yo como usuario
Quiero poder corregir los errores que no han sido del todo corregidos por el analizador Para poder completar la corrección de accesibilidad del HTML.
3.
Yo como usuario
Quiero poder ver en todo momento los cambios que se están realizando en mi HTML Para evitar resultados no deseados con la corrección.
4.
Yo como usuario
Quiero poder recoger el HTML completamente corregido Para poder utilizarlo según mis necesidades.
22
4.3. Descripción
Por otra parte, el sistema como tal, tiene requisitos funcionales que se expresarán de una manera más técnica, con tal de que no sea tan confuso:
1. Dado un string de HTML, el sistema tiene que convertirlo a un formato más manejable para poder facilitar el análisis.
2. El sistema tiene que mantener un fichero con las funciones de análisis de los errores de accesibilidad y los mapeos de estas funciones con sus respectivos errores.
3. Dado un HTML en un formato manejable, el sistema tiene que realizar un análisis en cada nodo para detectar los errores de accesibilidad que éste pueda contener.
4. El sistema tiene que mantener un fichero con las funciones de corrección de los errores de accesibilidad y los mapeos de estas funciones con sus respectivos errores.
5.
Dado un nodo de HTML con errores, el sistema tiene que intentar corregir estos errores, corrigiendo los errores automáticos y preparando los nodos de HTML para la corrección manual del usuario.
6. El sistema, una vez acabado el análisis y corrección del HTML, debe devolver el HTML analizado de manera que pueda ser fácilmente manejado.
Requisitos no funcionales
Los requisitos no funcionales que esta aplicación necesita se pueden separar en tres categorías: extensibilidad, rendimiento y usabilidad.
• Por una parte, se encuentran los requisitos deExtensibilidad, que serán aquellos que se tendrán en cuenta para simplificar el mantenimiento y evolución de la aplicación. Estas se pondrán en forma de historias de usuario, siendo el usuario el programador de la aplicación:
1.
Yo como programador de la aplicación
Quiero que las funciones de análisis de cada regla utilizadas en el análisis del HTML sean simples de añadir
Para facilitar el mantenimiento de esta aplicación.
2.
Yo como programador de la aplicación
Quiero que las funciones de corrección para cada error analizado sean simples de añadir
Para facilitar el mantenimiento de la aplicación.
• Por otra parte, se encuentran los requisitos deRendimiento, que son los requisitos que el sistema debe cumplir en cuanto a tiempo de respuesta.
1. El sistema debe tener cierta eficiencia en devolver una respuesta (Tiempos de carga inferiores a 3 seg).
• Por último, se encuentran con los requisitos deUsabilidad, que marcan las guías que debe seguir la aplicación en cuanto a como deben desarrollarse las interfaces gráficas.
1. La aplicación debe ser intuitiva y simple de utilizar para usuarios inexpertos.
4. DESARROLLO DEL PROYECTO
Plataforma
La plataforma elegida ha sido la web, con tal de facilitar la compatibilidad con diferentes sistemas operativos.
Esto se ha conseguido creando la aplicación como una aplicación web, utilizando Javascript y React.
La aplicación no requerirá de conexiones adicionales después de que se haya cargado la página.
En la figura 4.6 podemos ver como interacciona el servidor y el cliente.
Figura 4.6: Esquema de interacción cliente servidor
Metodología de trabajo
Para el analizador de accesibilidad, se decidió utilizar la metodología de trabajo TDD (Test Driven Development). Mediante esta metodología, los tests unitarios se escriben como casos de uso sobre los cuales se realiza el desarrollo.
Esta metodología fue utilizada debido a que se necesitaba tener una batería de tests con la cual poder confirmar que las reglas del analizador se comprobaban correctamente.
Teniendo esta confirmación, fue mucho más sencillo continuar el desarrollo cuan- do fue necesario hacer cambios sobre el analizador para arreglar errores y agregar funcionalidades.
24
4.4. Interfaz de usuario
4.4 Interfaz de usuario
En este apartado se mostrará el diseño que se ha seguido para crear la interfaz de usuario que utiliza la aplicación.
Se ha intentado simplificar al máximo la interfaz, con la intención de mantener esta intuitiva y simple de utilizar.
En la figura 4.7 se muestra el manejo de la aplicación.
Figura 4.7: Esquema de manejo de la aplicación
4. DESARROLLO DEL PROYECTO
Tal y como podemos observar, tiene 2 acciones:
1. Introducir el HTML a analizar: Se introduce el HTML a analizar, y, al hacer click en "Analizar", se accede al segundo paso. En las figuras 4.8 y 4.9 se muestra la pantalla que se utilizará para la recogida del html
Figura 4.8: Recogida de HTML
Figura 4.9: Recogida de HTML rellenada
2. Arreglar los errores: Una vez analizado el HTML introducido, los errores de este aparecerán listados en la parte inferior de la pantalla. En este momento, se puede ver que aparecen 2 áreas de texto. En el área de texto de la izquierda se encuentra 26
4.4. Interfaz de usuario
el HTML original, en el de la derecha, se encuentra el HTML con los arreglos realizados hasta el momento. En las figuras 4.10 y 4.11 se muestra la pantalla que se utilizará para la corrección de los errores del html.
Figura 4.10: Área de diferenciación
Figura 4.11: Errores a corregir
En todo momento, se puede ver en la parte inferior de la pantalla un listado que muestra cada uno de los cambios a tener en cuenta. Todos ellos muestran el estado original del HTML y la corrección por la que se ha optado.
4. DESARROLLO DEL PROYECTO
4.5 Desarrollo
4.5.1 Analizador WCAG 2.0
En este apartado se definirá la solución por la que se ha optado para realizar el desarrollo del analizador de reglas de WCAG 2.0.
Este apartado se dividirá en 5 partes:
1. Primero se explicará el WCAG 2.0, sirviendo de introducción para lectores que no lo conozcan de antemano.
2. Seguidamente, se definirá el framework que se ha desarrollado para poder crear reglas y correcciones con sencillez.
3. Después, se expondrá la solución que se ha utilizado para realizar el análisis de las reglas.
4. También se expondrá la solución que se ha utilizado para realizar las correcciones de los errores.
5. Para terminar, también se presentará el framework de test y parte de las baterias de test creadas con este framework.
WCAG 2.0
En este apartado se explicarán las guías de WCAG 2.0.
Web Content Accessibility Guidelines (WCAG) 2.0 son un conjunto de guías que cu- bren un amplio rango de recomendaciones para hacer que el contenido web sea más accesible.
Para desarrollar el analizador, se han utilizado estas guías debido a que fueron diseñadas por el W3C, una comunidad dedicada a la creación de estándares gratuitos con la intención de asegurar el crecimiento de la web a largo plazo.
Framework del analizador
En este apartado, se hablará del framework que se ha creado con tal de crear el analiza- dor y corrector de errores de WCAG 2.0.
Este framework utiliza la estrategia de Divide and conquer.
Este framework permite la definición de reglas de análisis y de correcciones, las cuales se combinarán en cada una de las posibilidades.
Por una parte, para el análisis, para cada una de los nodos, se definen las normas que tiene que pasar.
28
4.5. Desarrollo
1 let H T M L T a g R u l e s = {
2 H T M L : A r r a y ({ c o d e : ’ H57 ’, r u l e _ f u n c t i o n : H57 }) , 3
4 i n p u t : A r r a y ({ c o d e : ’ H36 ’, r u l e _ f u n c t i o n : H36 } ,
5 { c o d e : ’ H44 ’, r u l e _ f u n c t i o n : H44 } ,
6 { c o d e : ’ H65 ’, r u l e _ f u n c t i o n : H65 }) ,
7
8 a p p l e t : A r r a y ({ c o d e : ’ H35 ’, r u l e _ f u n c t i o n : H35 }) , 9
10 a r e a : A r r a y ({ c o d e : ’ H24 ’, r u l e _ f u n c t i o n : H 2 4 _ H 3 7 }) , 11
12 img : A r r a y ({ c o d e : ’ H37 ’, r u l e _ f u n c t i o n : H 2 4 _ H 3 7 }) , 13
14 a : A r r a y ({ c o d e : ’ H30 ’, r u l e _ f u n c t i o n : H30 }) , 15
16 s e l e c t : A r r a y ({ c o d e : ’ H44 ’, r u l e _ f u n c t i o n : H44 } ,
17 { c o d e : ’ H65 ’, r u l e _ f u n c t i o n : H65 }) ,
18
19 t e x t a r e a : A r r a y ({ c o d e : ’ H44 ’, r u l e _ f u n c t i o n : H44 } ,
20 { c o d e : ’ H65 ’, r u l e _ f u n c t i o n : H65 }) ,
21
22 e m b e d : A r r a y ({ c o d e : ’ H46 ’, r u l e _ f u n c t i o n : H46 }) , 23
24 o b j e c t : A r r a y ({ c o d e : ’ H53 ’, r u l e _ f u n c t i o n : H53 }) , 25
26 f i e l d s e t : A r r a y ({ c o d e : ’ H71 ’, r u l e _ f u n c t i o n : H71 }) , 27
28 f r a m e : A r r a y ({ c o d e : ’ H64 ’, r u l e _ f u n c t i o n : H64 }) , 29
30 i f r a m e : A r r a y ({ c o d e : ’ H64 ’, r u l e _ f u n c t i o n : H64 }) ,
31 }
Listing 4.1: Mapeo de funciones de análisis
Por otra parte, en el corrector de errores, se define la función que lo arregla (si se puede)
1 c o n s t w 3 c E r r o r F i x M a p p i n g = { 2
3 ’ H24 ’: H24_H37 ,
4 ’ H30 ’: H30 ,
5 ’ H35 ’: H35 ,
6 ’ H36 ’: H36 ,
7 ’ H37 ’: H24_H37 ,
8 ’ H44 ’: H44 ,
9 ’ H57 ’: H57 ,
10 ’ H64 ’: H64_H65 ,
11 ’ H65 ’: H64_H65 ,
12 ’ H71 ’: H71 ,
13 ’ H77 ’: H77 ,
14 15 }
Listing 4.2: Mapeo de funciones de corrección El flujo del framework es el siguiente:
4. DESARROLLO DEL PROYECTO
1. Se analiza cada nodo en busca de errores en contra del WCAG 2.0
2. Para cada error encontrado, este se intenta corregir el error automáticamente 3. Se devuelve el listado de errores, con las correcciones que han sido posible aplicar.
El framework en el que se ha trabajado se ha hecho lo bastante modular como para poder utilizarlo con cualquier otra aplicación, necesitando sólo importar la librería en la que se necesite.
Una vez acabado el análisis de un nodo, de este se guarda una estructura con las siguientes características:
1 {
2 " o r i g i n a l N o d e ": M a n t i e n e el n o d o o r i g i n a l que se ha a n a l i z a d o , 3
4 " c o r r e c t e d N o d e ": M a n t i e n e el n o d o con t o d a s las c o r r e c c i o n e s que
5 han s i d o r e a l i z a d a s ,
6
7 " t a g E r r o r s ": M a n t i e n e un l i s t a d o con t o d o s los e r r o r e s que se han
8 d e t e c t a d o
9 }
A partir de los siguientes apartados, se comenzará a analizar en detalle cada uno de los componentes desarrollados para cada punto del flujo.
Analizador
En este apartado se especificará la definición que se ha hecho del analizador al desarro- llarlo.
Como ya se ha dicho en el apartado anterior, el analizador mantiene un diccionario en el que se mapea cada uno de los nodos de HTML con las reglas que tiene que analizarse para saber que este nodo es accesible.
Las funciones que se crean para analizar los nodos HTML siempre siguen las mismas características:
• Todas siguen la misma interfaz, es decir, tienen los mismos parámetros de entra- da, que es el nodo HTML a analizar.
• Todos tienen el mismo retorno, un booleano indicando si la regla se cumple satisfactoriamente.
Si una regla no se cumple correctamente, la regla que ha fallado se registra, con tal de mantener en todo momento los errores para mostrarlos más adelante.
30
4.5. Desarrollo
1 f u n c t i o n a n a l y z e T a g ( h t m l T a g ) {
2 let e r r o r s = [];
3
4 if ( h t m l T a g R u l e s . h a s O w n P r o p e r t y ( h t m l T a g . n a m e . t o L o w e r C a s e () ) ) { 5 for ( let r u l e of h t m l T a g R u l e s [ h t m l T a g . n a m e . t o L o w e r C a s e () ]) { 6 if (! r u l e . r u l e _ f u n c t i o n ( h t m l T a g ) ) {
7 e r r o r s . p u s h ( r u l e . c o d e ) ;
8 }
9 }
10 }
11
12 r e t u r n e r r o r s ; 13 }
Listing 4.3: Función principal de análisis
Corrector
En este apartado se especificará el funcionamiento desarrollado para el corrector de HTML.
Después de realizar el análisis de un nodo, para cada uno de los errores resultantes se intenta realizar una corrección en este nodo, en el caso de que se pueda.
Una vez se ha intentado arreglar todos los errores que se detectaron en el nodo, el nodo resultante tiene todas las correcciones aplicables y está listo para ser mostrado y recoger el input de usuario, en caso de que sea pertinente.
1 f u n c t i o n c o r r e c t T a g ( htmlTag , e r r o r C o d e ) { 2 let c o r r e c t e d N o d e = c o p y N o d e ( h t m l T a g ) ;
3 if ( w 3 c E r r o r F i x M a p p i n g . h a s O w n P r o p e r t y ( e r r o r C o d e ) ) {
4 c o r r e c t e d N o d e = w 3 c E r r o r F i x M a p p i n g [ e r r o r C o d e ]( c o r r e c t e d N o d e )
;
5 }
6 r e t u r n c o r r e c t e d N o d e ; 7
8 }
Listing 4.4: Función principal de corrección
Tests
En este apartado se hablará tanto del framework utilizado para realizar las baterías de pruebas como las pruebas en si que confirman la funcionalidad de las reglas.
El framework utilizado para la creación de las baterías de pruebas ha sido Mocha. Este framework ha permitido crear suites de tests con relativa sencillez.
Gracias a haber realizado estas suites de tests, los cambios para mejorar ciertos proble- mas que fueron surgiendo pudieron ser arreglados sabiendo con cierta certeza de que nada había dejado de funcionar.
Las pruebas que se han realizado han sido varias por cada una de las reglas a analizar.
4. DESARROLLO DEL PROYECTO
Debido a ello, la estructura que se ha seguido es la siguiente:
• Por cada regla, se crea un bloque de tests, con tal de agrupar los tests que son para cada regla.
• Se crean los tests. Todos los tests son unitarios, no deberían necesitar de ninguna librería fuera de la que se está testeando.
De esta manera, se ha generado una batería de tests automática, donde cada bloque de tests tiene la siguiente estructura:
1 d e s c r i b e (’ H24 ’, f u n c t i o n() {
2 let H 2 4 _ H 3 7 = r e q u i r e (’ ../ h t m l _ w 3 c _ a n a l y s i s . js ’) . H 2 4 _ H 3 7 ; 3 it (’ s h o u l d r e t u r n t r u e if an a r e a has a non - e m p t y a t t r i b alt
’, f u n c t i o n() { 4
5 let H 2 4 H t m l = ’ < a r e a alt =" s o m e t h i n g " > </ area > ’ 6 p a r s e r . p a r s e r . p a r s e C o m p l e t e ( H 2 4 H t m l ) ;
7 a s s e r t . i s T r u e ( H 2 4 _ H 3 7 ( p a r s e r . h a n d l e r . dom [ 0 ] ) ) ;
8 }) ;
9
10 it (’ s h o u l d r e t u r n f a l s e if an a r e a d o e s not h a v e an a t t r i b alt ’, f u n c t i o n() {
11
12 let H 2 4 H t m l = ’ < a r e a > </ area > ’
13 p a r s e r . p a r s e r . p a r s e C o m p l e t e ( H 2 4 H t m l ) ;
14 a s s e r t . i s F a l s e ( H 2 4 _ H 3 7 ( p a r s e r . h a n d l e r . dom [ 0 ] ) ) ;
15 }) ;
16
17 it (’ s h o u l d r e t u r n f a l s e if an a r e a has an e m p t y a t t r i b alt ’, f u n c t i o n() {
18
19 let H 2 4 H t m l = ’ < a r e a alt ="" > </ area > ’; 20 p a r s e r . p a r s e r . p a r s e C o m p l e t e ( H 2 4 H t m l ) ;
21 a s s e r t . i s F a l s e ( H 2 4 _ H 3 7 ( p a r s e r . h a n d l e r . dom [ 0 ] ) ) ;
22 }) ;
23 }) ;
Listing 4.5: Bloque de tests para la técnica "H24"
4.5.2 Aplicación frontal (Recogida y corrección del HTML)
En el siguiente apartado se hablará de la aplicación frontal que se utiliza para recoger el HTML, corregir y devolver el HTML corregido.
La estructura de este apartado se separará en tres diferentes espacios:
1. Primero, se explicará el framework utilizado para el desarrollo, React.
2. Seguidamente, se explicará el flujo que sigue la aplicación completa.
3. Para terminar, se mostrarán las estructuras de datos utilizadas para este desarro- llo.
32
4.5. Desarrollo
Framework de desarrollo, React
En este apartado se definirá el uso que se le ha dado al framework REACT, así como los componentes que se han definido con este con tal de construir la aplicación.
El framework utilizado para la aplicación frontal ha sido React. Este se ha elegido debido a la sencillez con la que permite montar una aplicación y prepararla para despliegue.
Se ha utilizado React para construir diferentes partes de la aplicación como componen- tes separados.
De esta manera, se pueden discernir los siguientes componentes que forman parte de la aplicación:
• Área de recogida del HTML: En esta primera pantalla se recoge el HTML que va a ser analizado. Se trata de una simple área de texto en la que se deja el HTML. 4.8
• Área de diferenciación: Uno de los componentes más esenciales de la aplicación es el área de diferenciación, que es el área en el que se pueden ver las versiones anterior y posterior a la corrección del HTML. 4.10
• Área de corrección: Otro de los componentes esenciales es el área de corrección.
Este área está compuesto por un listado de errores, en el que se muestran las versiones de antes y después de la corrección automática. 4.11
Flujo de la aplicación
En este apartado se explicará el flujo de la aplicación desarrollada, donde se incluye también el uso de la librería de análisis del HTML que se ha explicado en apartados anteriores.
Como podemos ver en el diagrama 4.12, los pasos de este analizador son los siguientes:
1. Recoger HTML (Retrieve HTML): En este paso, el usuario deja el HTML que quiere que sea analizado.
2. Análisis de errores WCAG 2.0 (WCAG 2.0 Error Analysis): Usando el HTML recogi- do en el paso anterior, este se transfiere a la librería de análisis de errores WCAG 2.0, donde se analizan los errores que contiene este HTML.
3. Corrección automática de errores WCAG 2.0 (WCAG 2.0 Automatic correction):
Según los errores analizados en el paso anterior, se realizan las correcciones automáticas necesarias. Se realizan 2 tipos de correcciones, las correcciones que no requieren de input de usuario y las que requieren de input manual de usuario.
4. Corrección manual de errores (Correct manual errors): Los errores que no han podido ser arreglados automáticamente por la librería son enviados al usuario para que el realice la corrección manual.
4. DESARROLLO DEL PROYECTO
5. Recuperar el HTML corregido (Recover corrected HTML): Una vez corregido el HTML, este se devuelve al usuario final.
Figura 4.12: Diagrama de interacción
Estructuras de datos
En este apartado se expondrá la estructura utilizada para el diferenciador de correccio- nes y para el listado de errores.
La estructura utilizada es una lista compuesta por objetos que mantienen el estado anterior y el posterior a los cambios.
Estos se utilizan con la finalidad de mostrar al usuario en todo momento como ha cambiado el código que ha introducido.
34
4.6. Solución y resultados
4.6 Solución y resultados
En este apartado se hará una conclusión, en la cual se expondrán los puntos vistos an- teriormente y se detectarán tanto ventajas como desventajas de la solución propuesta.
4.6.1 Resultados obtenidos
Primero que nada, se comenzará haciendo un resumen de la funcionalidad del desar- rollo recién analizado:
• La aplicación tiene 2 partes claramente diferenciadas. Por un lado, nos encon- tramos con el analizador de WCAG2.0 y por el otro, la aplicación frontal que envuelve este funcionamiento y lo presenta al usuario.
• El analizador de WCAG 2.0 se ha formado como una librería separada. Esto se ha hecho con tal de conseguir separar responsabilidades, y así, aislar ambas partes, impidiendo que los cambios a la parte frontal afecten al analizador.
• Por otro lado, se ha desarrollado una aplicación frontal que envuelve la librería del analizador. Esta aplicación sirve de interfaz entre el usuario y la librería, facilitando su uso por usuarios no técnicos que no puedan utilizar esta librería.
• En esta aplicación frontal, el objetivo es mostrar en todo momento como ha cambiado el HTML entre antes del análisis y después. Esto se consigue en es- ta aplicación mostrando las 2 versiones en todo momento. Además, todos los cambios que se realizan en el HTML, son mostrados en el mismo momento en el que el usuario los está aplicando, pudiendo ver en todo momento como queda el HTML final.
4.6.2 Ventajas e inconvenientes de la solución
En este apartado se hablarán de las diferentes ventajas e inconvenientes que presenta la solución que se ha presentado.
Por una parte, las ventajas que presenta la solución son las siguiente:
• La aplicación está hecha completamente en Javascript, cosa que permite que la aplicación no necesite de funciones de servidor, cosa que permite un crecimiento en el número de usuarios concurrentes. Esto se puede conseguir debido a que la aplicación no necesita de base de datos.
• La separación de la librería de análisis y la interfaz hace que sea simple crear nuevos tests de la librería. Por otra parte, esto también permite que sea simple crear otras herramientas basadas en la librería, ya que esta no tiene necesidades de la aplicación frontal.
• Debido a que la aplicación no necesita de base de datos, el despliegue de la aplicación se vuelve muy sencillo, ya que lo único necesario es la actualización de los estáticos.
4. DESARROLLO DEL PROYECTO
• Por otra parte, ya que la aplicación está creada en JS, si fuera necesario mayor poder de procesamiento, la librería puede ser portada completamente al servidor usando Nodejs.
• Debido a que la aplicación realiza el análisis directamente en el cliente, la infor- mación resultante no tiene que enviarse mediante una conexión, cosa que en muchos casos reporta una mejora de eficiencia.
Asimismo, la solución optada tiene los siguientes inconvenientes:
• En contraste con el hecho de que la aplicación no necesita enviar tantos datos mediante una conexión, como la aplicación se ejecuta directamente en el nave- gador del cliente, el desempeño de la misma depende del ordenador del usuario que la utilice.
• La aplicación no guarda ningún tipo de registro de las peticiones que se hacen ni de los errores que se han analizado. Debido a esto, en este momento, esta aplicación no permite estudios estadísticos.
4.6.3 Proyectos y mejoras futuros
En este apartado se discutirán diferentes posibilidades de evolución de la aplicación.
Viendo las desventajas de las que hemos hablado en el apartado anterior, podemos discernir varias posibilidades para evolucionar la aplicación:
1. Por una parte, haciendo un estudio previo, se podría intentar mejorar el tema de la eficiencia del usuario creando un servicio de servidor que hiciera el análisis del HTML, el cual, al enviar este HTML, devuelva los errores encontrados y corregidos.
Para ello, una de las posibilidades más simples es simplemente utilizar node para reutilizar la librería y simplemente programar la conexión entre ambas partes.
2. Por otro lado, ya como un proyecto más grande y posterior, se podría desarrollar todo un sistema de logging alrededor de la aplicación, con tal de empezar a recoger diversos tipos de datos que puedan ser útiles para estudios posteriores.
Por ejemplo, un tipo de dato interesante que se podría recoger para realizar estudios son las listas de errores que se analizan. Esto requeriría: Además, debido a la separación de la librería de análisis de la aplicación web, sería posible crear nuevas herramientas en base a esta librería, pudiendo así conseguir herramientas completamente nuevas que puedan ser utilizados en casos que no se tengan en cuentai
a) Por una parte, se necesitaría construir un sistema de logs.
b) Haría falta conectar todos los eventos que se quisieran registrar con el sistema de logs, enviando los datos que sean necesarios para cada evento.
36
4.6. Solución y resultados
3. Además, gracias a la separación de la librería de análisis de HTML, se podría desarrollar un plugin que fuera comprobando la accesibilidad en archivos HTML para diferentesIDEde programación.
C
APÍTOL5
C ONCLUSIONES
En este apartado se presentarán las conclusiones a las que se ha llegado durante el desarrollo de este proyecto.
En primer lugar, se puede considerar que la aplicación desarrollada cumple con el ob- jetivo y alcance propuesto en el apartado 2, además de los requisitos tanto funcionales como no funcionales definidos en la subsección 4.3.4, debido a que:
• Se ha desarrollado una aplicación que permite de manera simple recoger el html que se necesita analizar.
• La herramienta detecta un conjunto de las reglas de la WCAG 2.0, automatizando su análisis y así facilitando el trabajo a los desarrolladores de cualquier aplicación para poder corregirlas
• Además, el mismo analizador ofrece una corrección para todas las reglas propu- estas, pidiendo el feedback del desarrollador en caso de que sea necesario.
• Debido a que se ha conseguido que el sitio web vea cada error como independi- ente, los cambios que realiza el usuario en los errores propuestos se pueden ver inmediatamente en el html corregido
• El análisis del html, aunque se puede intentar mejorar aún más la eficiencia del algoritmo, tiene un tiempo de respuesta decente, acabando el análisis completo, en casos generales, en menos de 3s
• La aplicación no requiere de ningún entrenamiento especial, ya que se basa en sólo 3 acciones del usuario:
1. Facilitar el html.
2. Hacer click en "analizar"
5. CONCLUSIONES
3. Corregir los errores que se le ofrecen por pantalla
• En cuanto a la mantenibilidad del código, si un programador continuara con este proyecto con la intención de agregar todas las reglas de la WCAG 2.0 o cambiar algunas de las presentes, no necesitaría de grandes esfuerzos, ya que cada regla se define por separado, sin dependencias entre ellas.
Además de los objetivos específicos de la aplicación, cabe mencionar que a nivel perso- nal se han obtenido los siguientes conocimientos:
• Se ha adquirido práctica en la metodología de trabajo Kanban, la cual ha per- mitido tanto trabajar pudiendo tener visible en todo momento todo el trabajo a realizar.
• Se ha utilizado la técnica dedivide and conquerpara la resolución de cada una de las reglas por separado, consolidando así el conocimiento de la misma.
• Se ha aprendido a utilizar el framework de desarrollo React, el cual ha facilitado el desarrollo de la aplicación.
• Se ha aprendido a utilizar el framework de testing Mocha, el cual ha facilitado la creación de los tests que aseguran la funcionalidad de las reglas de WCAG 2.0.
• Se ha ampliado el conocimiento en el lenguaje de programación Javascript, debi- do principalmente a la necesidad de crear todo un framework para agregar reglas y correcciones de la WCAG 2.0 de manera simple.
Para concluir, cabe destacar que, a nivel personal, el desarrollo de esta aplicación ha resultado una experiencia enriquecedora, debido principalmente a que ha permitido trabajar en un problema que ha dado la posibilidad a desarrollar una solución que requiere de un conocimiento de programación avanzado, el cual será imprescindible a la hora de enfrentarse al mundo real y a sus problemáticas, abriendo el camino a una mejora y un aprendizaje continuos.
40
B IBLIOGRAFIA
[1] J. J. Mayol, “Análisis y mejora de la accesibilidad web como parámetro de calidad del turismo,” 2015. [Online]. Available:
http://estudis.uib.es/es/doctorat/Tesis-doctorals/Detall/
Hacia-la-mejora-de-la-accesibilidad-de-las-webs.cid3947502.1, 2.2, 4.3.2 [2] S. A.-Z. Henry, Shawn Lawton and J. Brewer, “The role of accessibility in a
universal web,” 2018. [Online]. Available:http://hdl.handle.net/1721.1/880132.1 [3] “Accessibility.” [Online]. Available:
https://www.w3.org/standards/webdesign/accessibility2.1 [4] “Web accessibility.” [Online]. Available:
https://en.wikipedia.org/wiki/Web_accessibility3.1
[5] T. whole brain group, “Top 5 benefits of an accessible website.” [Online]. Available:
https://blog.thewholebraingroup.com/5-benefits-accessible-website3.1 [6] L. G. R. G. V. W. C. J. S. J. W. Ben Caldwell, Michael Cooper,Web Content
Accessibility Guidelines (WCAG) 2.0, 2008. [Online]. Available:
https://www.w3.org/TR/WCAG20/3.2, 3.2, 3.2, 3.2
[7] “Free or low cost assistive technology for everyone.” [Online]. Available:
http://www.augsburg.edu/class/groves/assistive-technology/everyone/3.1 [8] “Javascript.” [Online]. Available:https://es.wikipedia.org/wiki/JavaScript3.3 [9] “Nodejs site.” [Online]. Available:https://nodejs.org/en/3.4
[10] “Node.js.” [Online]. Available:https://en.wikipedia.org/wiki/Node.js3.4 [11] “Npmjs site.” [Online]. Available:https://www.npmjs.com/3.4
[12] “Reactjs site.” [Online]. Available:https://reactjs.org/ 3.5 [13] “Reactjs.” [Online]. Available:
https://en.wikipedia.org/wiki/React_(JavaScript_library)3.5
[14] “Webpack site.” [Online]. Available:https://webpack.js.org/concepts/3.6 [15] “Single page application.” [Online]. Available:
https://en.wikipedia.org/wiki/Single-page_application3.7
BIBLIOGRAFIA
[16] M. Wasson, “Asp.net - single-page applications: Build modern, responsive web apps with asp.net,” vol. 28, no. 11, 2013. [Online]. Available:
https://msdn.microsoft.com/en-us/magazine/dn463786.aspx3.7 [17] “Mochajs.” [Online]. Available:https://mochajs.org/3.8
[18] D. B. Thomas Cormen, “Divide and conquer algorithms.” [Online]. Available:
https://www.khanacademy.org/computing/computer-science/algorithms/
merge-sort/a/divide-and-conquer-algorithms 3.9, 3.2
[19] Anonymous, “Divide and conquer | set 1 (introduction).” [Online]. Available:
https://www.geeksforgeeks.org/divide-and-conquer-introduction/3.9 [20] “Test driven development.” [Online]. Available:
https://en.wikipedia.org/wiki/Test-driven_development 3.10
[21] S. W. Ambler, “Introduction to test driven development (tdd).” [Online]. Available:
http://agiledata.org/essays/tdd.html3.10, 3.3 [22] Anonymous, “Tdd.” [Online]. Available:
https://www.agilealliance.org/glossary/tdd/3.10
[23] “Kanban.” [Online]. Available:https://en.wikipedia.org/wiki/Kanban3.11 [24] D. Radigan, “Kanban.” [Online]. Available:
https://www.atlassian.com/agile/kanban 3.11 [25] “What is kanban?” [Online]. Available:
https://leankit.com/learn/kanban/what-is-kanban/3.4
42
