Treb

allF

inal

de

Gra

u Herramienta de análisis de accesibilidadWCAG 2.0

MARIANO FONTANA HUARTE

TutorJaume Jaume Mayol

Escola Politècnica SuperiorUniversitat de les Illes BalearsPalma, 10 de setembre de 2018

SUMARI

Sumari i

1 Introducción 11.1 Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Agradecimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Presentación del proyecto 52.1 Contexto del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Alcance del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Importancia del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Conceptos teóricos 93.1 Accesibilidad Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2 WCAG 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.3 Javascript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.4 Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.5 Reactjs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.6 Webpack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.7 Single Page application (SPA) . . . . . . . . . . . . . . . . . . . . . . . . . 123.8 Mocha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.9 Técnica divide and conquer . . . . . . . . . . . . . . . . . . . . . . . . . . 133.10 Test driven development (TDD) . . . . . . . . . . . . . . . . . . . . . . . . 143.11 Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Desarrollo del proyecto 174.1 Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2 Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.3 Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.3.1 Descripción del proyecto . . . . . . . . . . . . . . . . . . . . . . . 214.3.2 Proyectos anteriores . . . . . . . . . . . . . . . . . . . . . . . . . . 214.3.3 Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.3.4 Análisis del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.4 Interfaz de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.5 Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.5.1 Analizador WCAG 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . 284.5.2 Aplicación frontal (Recogida y corrección del HTML) . . . . . . 32

i

ii SUMARI

4.6 Solución y resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.6.1 Resultados obtenidos . . . . . . . . . . . . . . . . . . . . . . . . . 354.6.2 Ventajas e inconvenientes de la solución . . . . . . . . . . . . . . 354.6.3 Proyectos y mejoras futuros . . . . . . . . . . . . . . . . . . . . . 36

5 Conclusiones 39

Bibliografia 41

CA

PÍ

TO

L

1INTRODUCCIÓN

Se define la accesibilidad web como una característica de una página web que hace quese pueda utilizar por personas que padecen algún tipo de discapacidad, sea temporal odefinitiva.

El concepto de accesibilidad surge para eliminar las dificultades de acceso para laspersonas con discapacidad (tanto sensoriales como físicas), pero además permite otrasventajas adicionales para los usuarios web sin discapacidad, como se verá a lo largo delproyecto.

Un organismo internacional, la W3C, definió en el año 2008 un conjunto de reglas dediseño a seguir para conseguir una web accesible.

Diversos estudios, estudios de los niveles de accesibilidad muestran que las reglas dediseño accesible no se cumplen.

En este sentido, se ha desarrollado una herramienta que automatiza el análisis de lasreglas de diseño WCAG 2.0

La aplicación que se ha desarrollado es un analizador de código html que busca errorescon las reglas WCAG 2.0 (Web Content Accessibility Guidelines 2.0). Esta aplicaciónconsta de dos partes por separadas:

1. Por una parte, se ha desarrollado una librería de análisis de código html. Estalibrería se ha desarrollado como un módulo completamente separado, con tal depoder 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 comopara corregir los errores analizados. Esta aplicación conecta con la librería deanálisis como una librería general de Javascript.

1

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 unsegundo 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 decrear una herramienta que ayude al desarrollo de sitios web accesibles para todo tipode 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 unproyecto 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 PetarBoyanov). 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 laaplicació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 depresentar 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 laimportancia de este proyecto.

3. En tercer lugar, se hará una introducción a todos los conceptos teóricos que seutilizarán durante el desarrollo de la aplicación

4. En cuarto lugar, se expondrá con mucho detalle todos los puntos por los quese 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 seha 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 delproyecto:

• 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 unprincipio.

3

CA

PÍ

TO

L

2PRESENTACIÓN DEL PROYECTO

En este apartado se expondrán tanto el alcance como el objetivo que pretende cumplirel 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 quese presenta en las páginas web turísticas impide hablar de un verdadero turismo decalidad 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 laglobalización de la web en diferentes dispositivos y con diferentes limitaciones. [2] Porejemplo, la necesidad de adaptar páginas web a diferentes dispositivos y resolucionespuede 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 la W3C (World Wide Web Consortium) conla iniciativa WAI (Web Accessibility Initiative) es conseguir que la web sea accessiblepara todo el mundo [3], objetivo para el cual sigue siendo necesario un gran esfuerzogeneralizado por todo el sector.

5

2. PRESENTACIÓN DEL PROYECTO

2.2 Objetivos

El objetivo principal de este proyecto es ampliar sobre el marco de trabajo que defineel tutor Jaume Jaume Mayol en su doctorado [1], creando una aplicación informáticaque 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 desarrolladorweb a reconocer los errores que sus páginas web están cometiendo (en cuanto aaccesibilidad) de manera automática, ofreciendo soluciones en la medida de loposible.

• 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, siguiendolas 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 ampliacionesel 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 podermantener las reglas actualizadas y poder agregar nuevas en el caso de que nuevas seandesarrolladas en las siguientes versiones de las WCAG 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 esfuerzosde diferentes compañías alrededor de la mejora de accesibilidad de sus páginasweb.

6

2.4. Importancia del proyecto

• Por otra parte, si se permite la mejora continua de esta herramienta, esta puedeir desarrollándose junto al sector, con tal de intentar incorporar la accessibilidaden el diseño web.

Por otra parte, la herramienta se servirá como una aplicación web, sin ningún tipo deregistro, 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íaposible crear nuevas herramientas en base a esta librería, pudiendo así conseguirherramientas completamente nuevas que puedan ser utilizados en casos que no setengan en cuenta, como se explica en el apartado 4.6.3

7

CA

PÍ

TO

L

3CONCEPTOS TEÓRICOS

En este capítulo se exponen los conceptos teóricos necesarios para comprender elcontexto del desarrollo del TFG. Se describen las bases teóricas, como la normativaWCAG, así como un conjunto de técnicas, tecnologías y metodologías utilizadas en eldesarrollo del TFG.

3.1 Accesibilidad Web

La accessibilidad web se define como la práctica inclusiva que se encarga de eliminarlas barreras que previenen la interacción o el acceso para personas con discapacidadesa páginas web. [4]

Cuando una página web es accesible, todo los usuarios tienen el mismo acceso ainformación y funcionalidades. Esto puede ser beneficioso tanto a usuarios con algunadiscapacidad 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 contribuyendocon 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 reglasagregan metainformación que los buscadores utilizan para indexar.

9

3. CONCEPTOS TEÓRICOS

3.2 WCAG 2.0

Las Web 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 condiscapacidades, incluyendo discapacidades físicas e intelectuales. Además, seguir estasguías creará contenido web más usable en general.[6]

Estas guías son el sucesor a las Web Content Accessibility Guidelines (WCAG) 1.0, lascuales 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 unode los niveles de conformidad teniendo en cuenta que tan esenciales son para el usuariofinal al mismo tiempo que comprobando cuales implican las menores limitacionespara 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 conformidaddefinidos anteriormente, cumpliendo también sus niveles inferiores.

2. Páginas completas: La conformidad no puede cumplirse únicamente en unaparte de la página.

3. Proceso completo: Cuando una página es una serie de páginas que conforman unproceso, todas las páginas que forman parte de este proceso tienen que cumplirconformidad.

4. Sólo métodos soportados por accesibilidad para usar tecnologías: Únicamente seaceptan métodos que tengan soporte de manera generalizada en herramientasde soporte para cumplir conformidad. En la figura 3.1 podemos ver un esquemaque explica las áreas y métodos que se pueden utilizar en las herramientas deasistencia.

5. Sin interferencia: En el caso de que alguna tecnología es usada de una manera queno 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 manerasque los usuarios puedan percibir.

2. Operable: Los componentes de la interfaz de usuario y la navegación debe seroperable.

3. Entendible: La información y las operaciones que se pueden realizar desde lainterfaz de usuario deben ser comprensibles.

4. Robusto: El contenido tiene que ser lo bastante robusto como para que puedaser 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 luegosimplemente 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 unasección y requiere de comprobación humana.

3.3 Javascript

Javascript es un lenguaje de programación interpretado, dialecto del estandar Ecmas-cript. [8]

11

3. CONCEPTOS TEÓRICOS

Se usa principalmente en el lado del cliente, ya que esta implementado en la mayoríade navegadores web modernos.

En este momento, Javascript se ha convertido en el lenguaje principal de programaciónweb, 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 lacomunidad.[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 maneraque 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 reutilizablesde manera simple.[12]

Esta librería se mantiene por el trabajo de, entre otros, Facebook e Instagram, ademásde 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 decirque 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 dependenciaspor 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 maneradiná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 interrupcionesde 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 depá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 elservidor, se pueden realizar llamadas AJAX contra el servidor, recogiendo en cadauna 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. Estosson 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, medianteel cual, este servidor le enviará eventos con los datos necesarios para actualizarla pantalla.

Esta metodología es extremadamente útil para experiencias de usuarios que puedenconsiderarse 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 lacual se pueden crear tests, además de una construcción y ejecución de los tests que norequiere 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, pararesolver el problema en cuestión, se realizan sucesivas divisiones del problema enproblemas 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 laresolució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.

13

3. CONCEPTOS TEÓRICOS

Una de las mayores ventajas es que el código resultante suele ser más modular, cosaque 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 explicadoanteriormente

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 enrepetir un ciclo muy simple en el cual los requisitos se convierten en casos de test y elcó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, elcódigo resultante cumple con los requisitos, ya que estos han sido utilizados paramoldear los tests que se ejecutan.

Al acabar el desarrollo, también queda la batería de tests utilizada para implementar elcódigo, batería que puede utilizarse para probar la funcionalidad en el caso de que estavuelva 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. Estesistema 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 planificarlas tareas que van a ser implementadas en las siguientes iteraciones y priorizarlas segúnlos criterios que los stakeholders vean convenientes.[24]

En la figura 3.4 se puede observar un ejemplo de estructura de una pizarra Kanban.

15

3. CONCEPTOS TEÓRICOS

Figura 3.4: Estructura de una pizarra kanban[25]

16

CA

PÍ

TO

L

4DESARROLLO 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 endetalle 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 deusuario, estas se clasificaron en diferentes categorías:

1. Analizador de HTML: Se refiere a todos las historias de usuario que forman parte

17

4. DESARROLLO DEL PROYECTO

del análisis de HTML.

2. Corrector de HTML: Se refiere a todas las historias de usuario que forman partede la corrección del HTML.

3. Algoritmo de diferenciación: Se refiere a la funcionalidad de diferenciación quese utilizaría en la página web

4. Sitio web: Se refiere a todas las historias de usuario que se refieren a la creaciónde 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 principalcon 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 dediferenciació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, debidoa 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 conel sitio web.

La planificación después de este cambio definió el siguiente orden para el desarrollode las historias de usuario:

1. Analizador: Este componente se desarrolló primero debido a que no depende deningú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 eldesarrollo de este componente.

3. Sitio Web: Como ya tenemos la librería de análisis y corrección, ya se puedecomenzar 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 hautilizado 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 reorganizarprioridades 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 elproyecto (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 lolargo de este, se tomaron algunas decisiones de arquitectura que más adelante fuerondescartadas.

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 trabajodecidió 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 delanalizador.

19

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 trabajoque se había analizado (dejándolo para quizás una segunda versión) y reorganizarlas prioridades acordemente, incluyendo también las tareas que se agregaron másadelante.

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 deaccesibilidad 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 WCAG2.0.

4.3.2 Proyectos anteriores

Anteriormente a este proyecto, el tutor del TFG, Jaume Jaume Mayol, había desarrolladoun 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ísticasy 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 conel 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 tenganmayores 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. Esteusuario 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 seguidopara desarrollar la aplicación.

En dicho apartado se representan las decisiones y suposiciones realizadas, con lasrestricciones del sistema. Asimismo, se presentan los principales requisitos funcionalesy no funcionales.

Decisiones y restricciones

Las decisiones y restricciones que se han considerado son las siguientes:

21

4. DESARROLLO DEL PROYECTO

• El lenguaje de programación utilizado será Javascript. Se utilizará Javascriptporque permite reutilizar el código tanto en una aplicación frontal como enlógica de servidor. Esta fácil portabilidad puede utilizarse para mejorar eficienciaen 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 deJavascript que permite crear esta Interfaz con sencillez.

• Debido al aumento de trabajo que acompañó la falta de uno de los miembrosdel 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, selistarán en forma de historias de usuario:

1.

Yo como usuarioQuiero poder suministrar un HTMLPara que el sistema pueda realizar un análisis en busca de errores de accesibilidad

2.

Yo como usuarioQuiero poder corregir los errores que no han sido del todo corregidos por el analizadorPara poder completar la corrección de accesibilidad del HTML.

3.

Yo como usuarioQuiero poder ver en todo momento los cambios que se están realizando en mi HTMLPara evitar resultados no deseados con la corrección.

4.

Yo como usuarioQuiero poder recoger el HTML completamente corregidoPara 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 deuna 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 manejablepara poder facilitar el análisis.

2.El sistema tiene que mantener un fichero con las funciones de análisis de los erroresde 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 encada 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 erroresde 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ónmanual del usuario.

6.El sistema, una vez acabado el análisis y corrección del HTML, debe devolver el HTMLanalizado de manera que pueda ser fácilmente manejado.

Requisitos no funcionales

Los requisitos no funcionales que esta aplicación necesita se pueden separar en trescategorías: extensibilidad, rendimiento y usabilidad.

• Por una parte, se encuentran los requisitos de Extensibilidad, que serán aquellosque se tendrán en cuenta para simplificar el mantenimiento y evolución de laaplicación. Estas se pondrán en forma de historias de usuario, siendo el usuarioel programador de la aplicación:

1.

Yo como programador de la aplicaciónQuiero que las funciones de análisis de cada regla utilizadas en el análisis del HTMLsean simples de añadirPara facilitar el mantenimiento de esta aplicación.

2.

Yo como programador de la aplicaciónQuiero que las funciones de corrección para cada error analizado sean simples deañadirPara facilitar el mantenimiento de la aplicación.

• Por otra parte, se encuentran los requisitos de Rendimiento, que son los requisitosque el sistema debe cumplir en cuanto a tiempo de respuesta.

1.El sistema debe tener cierta eficiencia en devolver una respuesta (Tiempos de cargainferiores a 3 seg).

• Por último, se encuentran con los requisitos de Usabilidad, que marcan las guíasque debe seguir la aplicación en cuanto a como deben desarrollarse las interfacesgráficas.

1. La aplicación debe ser intuitiva y simple de utilizar para usuarios inexpertos.

23

4. DESARROLLO DEL PROYECTO

Plataforma

La plataforma elegida ha sido la web, con tal de facilitar la compatibilidad con diferentessistemas operativos.

Esto se ha conseguido creando la aplicación como una aplicación web, utilizandoJavascript y React.

La aplicación no requerirá de conexiones adicionales después de que se haya cargadola 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 escribencomo 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 conla 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 agregarfuncionalidades.

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 deusuario que utiliza la aplicación.

Se ha intentado simplificar al máximo la interfaz, con la intención de mantener estaintuitiva 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

25

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 clicken "Analizar", se accede al segundo paso. En las figuras 4.8 y 4.9 se muestra lapantalla 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 esteaparecerán listados en la parte inferior de la pantalla. En este momento, se puedever 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 arreglosrealizados hasta el momento. En las figuras 4.10 y 4.11 se muestra la pantalla quese 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 muestracada uno de los cambios a tener en cuenta. Todos ellos muestran el estado original delHTML y la corrección por la que se ha optado.

27

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 desarrollodel 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 queno lo conozcan de antemano.

2. Seguidamente, se definirá el framework que se ha desarrollado para poder crearreglas y correcciones con sencillez.

3. Después, se expondrá la solución que se ha utilizado para realizar el análisis delas reglas.

4. También se expondrá la solución que se ha utilizado para realizar las correccionesde los errores.

5. Para terminar, también se presentará el framework de test y parte de las bateriasde 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ásaccesible.

Para desarrollar el analizador, se han utilizado estas guías debido a que fueron diseñadaspor el W3C, una comunidad dedicada a la creación de estándares gratuitos con laintenció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 cualesse 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 quetiene que pasar.

28

4.5. Desarrollo

1 let HTMLTagRules = {2 HTML: Array ({ code: ’H57 ’, rule_function : H57 }),34 input: Array ({ code: ’H36 ’, rule_function : H36},5 {code: ’H44 ’, rule_function : H44},6 {code: ’H65 ’, rule_function : H65 }),78 applet : Array ({ code: ’H35 ’, rule_function : H35 }),9

10 area: Array ({ code: ’H24 ’, rule_function : H24_H37 }),1112 img: Array ({ code: ’H37 ’, rule_function : H24_H37 }),1314 a: Array ({ code: ’H30 ’, rule_function : H30 }),1516 select : Array ({ code: ’H44 ’, rule_function : H44},17 {code: ’H65 ’, rule_function : H65 }),1819 textarea : Array ({ code: ’H44 ’, rule_function : H44},20 {code: ’H65 ’, rule_function : H65 }),2122 embed: Array ({ code: ’H46 ’, rule_function : H46 }),2324 object : Array ({ code: ’H53 ’, rule_function : H53 }),2526 fieldset : Array ({ code: ’H71 ’, rule_function : H71 }),2728 frame: Array ({ code: ’H64 ’, rule_function : H64 }),2930 iframe : Array ({ code: ’H64 ’, rule_function : 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 const w3cErrorFixMapping = {23 ’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 ,1415 }

Listing 4.2: Mapeo de funciones de corrección

El flujo del framework es el siguiente:

29

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 parapoder utilizarlo con cualquier otra aplicación, necesitando sólo importar la librería enla que se necesite.

Una vez acabado el análisis de un nodo, de este se guarda una estructura con lassiguientes características:

1 {2 " originalNode ": Mantiene el nodo original que se ha analizado ,34 " correctedNode ": Mantiene el nodo con todas las correcciones que5 han sido realizadas ,67 " tagErrors ": Mantiene un listado con todos los errores que se han8 detectado9 }

A partir de los siguientes apartados, se comenzará a analizar en detalle cada uno de loscomponentes 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 enel que se mapea cada uno de los nodos de HTML con las reglas que tiene que analizarsepara saber que este nodo es accesible.

Las funciones que se crean para analizar los nodos HTML siempre siguen las mismascaracterí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 cumplesatisfactoriamente.

Si una regla no se cumple correctamente, la regla que ha fallado se registra, con tal demantener en todo momento los errores para mostrarlos más adelante.

30

4.5. Desarrollo

1 function analyzeTag ( htmlTag ) {2 let errors = [];34 if ( htmlTagRules . hasOwnProperty ( htmlTag .name. toLowerCase ())){5 for (let rule of htmlTagRules [ htmlTag .name. toLowerCase ()]){6 if (! rule. rule_function ( htmlTag )) {7 errors .push(rule.code);8 }9 }

10 }1112 return errors ;13 }

Listing 4.3: Función principal de análisis

Corrector

En este apartado se especificará el funcionamiento desarrollado para el corrector deHTML.

Después de realizar el análisis de un nodo, para cada uno de los errores resultantes seintenta 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, elnodo resultante tiene todas las correcciones aplicables y está listo para ser mostrado yrecoger el input de usuario, en caso de que sea pertinente.

1 function correctTag (htmlTag , errorCode ) {2 let correctedNode = copyNode ( htmlTag );3 if ( w3cErrorFixMapping . hasOwnProperty ( errorCode )){4 correctedNode = w3cErrorFixMapping [ errorCode ]( correctedNode )

;5 }6 return correctedNode ;78 }

Listing 4.4: Función principal de corrección

Tests

En este apartado se hablará tanto del framework utilizado para realizar las baterías depruebas 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. Esteframework 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 quenada había dejado de funcionar.

Las pruebas que se han realizado han sido varias por cada una de las reglas a analizar.

31

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 sonpara cada regla.

• Se crean los tests. Todos los tests son unitarios, no deberían necesitar de ningunalibrería fuera de la que se está testeando.

De esta manera, se ha generado una batería de tests automática, donde cada bloque detests tiene la siguiente estructura:

1 describe (’H24 ’, function () {2 let H24_H37 = require (’../ html_w3c_analysis .js’). H24_H37 ;3 it(’should return true if an area has a non -empty attrib alt

’, function () {45 let H24Html = ’<area alt =" something "></area >’6 parser . parser . parseComplete ( H24Html );7 assert . isTrue ( H24_H37 ( parser . handler .dom [0]));8 });9

10 it(’should return false if an area does not have an attribalt ’, function () {

1112 let H24Html = ’<area ></area >’13 parser . parser . parseComplete ( H24Html );14 assert . isFalse ( H24_H37 ( parser . handler .dom [0]));15 });1617 it(’should return false if an area has an empty attrib alt ’,

function () {1819 let H24Html = ’<area alt =""></area >’;20 parser . parser . parseComplete ( H24Html );21 assert . isFalse ( H24_H37 ( parser . handler .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 recogerel 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 loscomponentes 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 debidoa 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 dela aplicación:

• Área de recogida del HTML: En esta primera pantalla se recoge el HTML que va aser 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ónes el área de diferenciación, que es el área en el que se pueden ver las versionesanterior 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 lasversiones 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 incluyetambién el uso de la librería de análisis del HTML que se ha explicado en apartadosanteriores.

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 quiereque 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 WCAG2.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 correccionesautomáticas necesarias. Se realizan 2 tipos de correcciones, las correcciones queno 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 hanpodido ser arreglados automáticamente por la librería son enviados al usuariopara que el realice la corrección manual.

33

4. DESARROLLO DEL PROYECTO

5. Recuperar el HTML corregido (Recover corrected HTML): Una vez corregido elHTML, 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 estadoanterior y el posterior a los cambios.

Estos se utilizan con la finalidad de mostrar al usuario en todo momento como hacambiado 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 queenvuelve este funcionamiento y lo presenta al usuario.

• El analizador de WCAG 2.0 se ha formado como una librería separada. Esto se hahecho 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íadel 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 hacambiado 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 loscambios que se realizan en el HTML, son mostrados en el mismo momento en elque el usuario los está aplicando, pudiendo ver en todo momento como queda elHTML final.

4.6.2 Ventajas e inconvenientes de la solución

En este apartado se hablarán de las diferentes ventajas e inconvenientes que presentala 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 laaplicación no necesite de funciones de servidor, cosa que permite un crecimientoen el número de usuarios concurrentes. Esto se puede conseguir debido a que laaplicación no necesita de base de datos.

• La separación de la librería de análisis y la interfaz hace que sea simple crearnuevos tests de la librería. Por otra parte, esto también permite que sea simplecrear otras herramientas basadas en la librería, ya que esta no tiene necesidadesde la aplicación frontal.

• Debido a que la aplicación no necesita de base de datos, el despliegue de laaplicación se vuelve muy sencillo, ya que lo único necesario es la actualizaciónde los estáticos.

35

4. DESARROLLO DEL PROYECTO

• Por otra parte, ya que la aplicación está creada en JS, si fuera necesario mayorpoder de procesamiento, la librería puede ser portada completamente al servidorusando 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 enmuchos 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 datosmediante 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 usuarioque la utilice.

• La aplicación no guarda ningún tipo de registro de las peticiones que se hacenni de los errores que se han analizado. Debido a esto, en este momento, estaaplicació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, podemosdiscernir varias posibilidades para evolucionar la aplicación:

1. Por una parte, haciendo un estudio previo, se podría intentar mejorar el tema dela eficiencia del usuario creando un servicio de servidor que hiciera el análisis delHTML, 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 parareutilizar 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 desarrollartodo un sistema de logging alrededor de la aplicación, con tal de empezar arecoger diversos tipos de datos que puedan ser útiles para estudios posteriores.Por ejemplo, un tipo de dato interesante que se podría recoger para realizarestudios son las listas de errores que se analizan. Esto requeriría: Además, debidoa la separación de la librería de análisis de la aplicación web, sería posible crearnuevas herramientas en base a esta librería, pudiendo así conseguir herramientascompletamente nuevas que puedan ser utilizados en casos que no se tengan encuentai

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 elsistema 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íadesarrollar un plugin que fuera comprobando la accesibilidad en archivos HTMLpara diferentes IDE de programación.

37

CA

PÍ

TO

L

5CONCLUSIONES

En este apartado se presentarán las conclusiones a las que se ha llegado durante eldesarrollo 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 funcionalescomo 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 htmlque se necesita analizar.

• La herramienta detecta un conjunto de las reglas de la WCAG 2.0, automatizandosu análisis y así facilitando el trabajo a los desarrolladores de cualquier aplicaciónpara 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 verinmediatamente en el html corregido

• El análisis del html, aunque se puede intentar mejorar aún más la eficiencia delalgoritmo, 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 ensólo 3 acciones del usuario:

1. Facilitar el html.

2. Hacer click en "analizar"

39

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 esteproyecto con la intención de agregar todas las reglas de la WCAG 2.0 o cambiaralgunas de las presentes, no necesitaría de grandes esfuerzos, ya que cada reglase 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 arealizar.

• Se ha utilizado la técnica de divide and conquer para la resolución de cada unade las reglas por separado, consolidando así el conocimiento de la misma.

• Se ha aprendido a utilizar el framework de desarrollo React, el cual ha facilitadoel desarrollo de la aplicación.

• Se ha aprendido a utilizar el framework de testing Mocha, el cual ha facilitado lacreació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 reglasy correcciones de la WCAG 2.0 de manera simple.

Para concluir, cabe destacar que, a nivel personal, el desarrollo de esta aplicación haresultado una experiencia enriquecedora, debido principalmente a que ha permitidotrabajar en un problema que ha dado la posibilidad a desarrollar una solución querequiere de un conocimiento de programación avanzado, el cual será imprescindible ala hora de enfrentarse al mundo real y a sus problemáticas, abriendo el camino a unamejora y un aprendizaje continuos.

40

BIBLIOGRAFIA

[1] J. J. Mayol, “Análisis y mejora de la accesibilidad web como parámetro de calidaddel turismo,” 2015. [Online]. Available:http://estudis.uib.es/es/doctorat/Tesis-doctorals/Detall/Hacia-la-mejora-de-la-accesibilidad-de-las-webs.cid394750 2.1, 2.2, 4.3.2

[2] S. A.-Z. Henry, Shawn Lawton and J. Brewer, “The role of accessibility in auniversal web,” 2018. [Online]. Available: http://hdl.handle.net/1721.1/88013 2.1

[3] “Accessibility.” [Online]. Available:https://www.w3.org/standards/webdesign/accessibility 2.1

[4] “Web accessibility.” [Online]. Available:https://en.wikipedia.org/wiki/Web_accessibility 3.1

[5] T. whole brain group, “Top 5 benefits of an accessible website.” [Online]. Available:https://blog.thewholebraingroup.com/5-benefits-accessible-website 3.1

[6] L. G. R. G. V. W. C. J. S. J. W. Ben Caldwell, Michael Cooper, Web ContentAccessibility 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/JavaScript 3.3

[9] “Nodejs site.” [Online]. Available: https://nodejs.org/en/ 3.4

[10] “Node.js.” [Online]. Available: https://en.wikipedia.org/wiki/Node.js 3.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_application 3.7

41

BIBLIOGRAFIA

[16] M. Wasson, “Asp.net - single-page applications: Build modern, responsive webapps with asp.net,” vol. 28, no. 11, 2013. [Online]. Available:https://msdn.microsoft.com/en-us/magazine/dn463786.aspx 3.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.html 3.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/Kanban 3.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