Full text
Herramienta de apoyo a la navegación web para personas con discapacidad MEMORIA TRABAJO DE FIN DE GRADO Realizado por: Lorena Jiménez Corta Dirigido por: Raquel Hervás Ballesteros Susana Bautista Blasco Departamento de Ingeniería del Software e Inteligencia Articial Facultad de Informática Universidad Complutense de Madrid Junio 2018
Documento maquetado con TEX i S v.1.0.
Herramienta de apoyo a la navegación web para personas con discapacidad Departamento de Ingeniería del Software e Inteligencia Articial Facultad de Informática Universidad Complutense de Madrid Junio 2018
Agradecimientos Agradezco al colegio Estudio 3 AFANIAS, en especial a los docentes que participaron, su colaboración y aportación con este proyecto. A los alumnos del colegio Estudio 3 AFANIAS, por su participación, alegría, agradecimiento y buena acogida de este proyecto. Por enseñarme una visión del mundo totalmente diferente. A mis tutoras, Raquel Hervás y Susana Bautista, por hacer posible que este proyecto sea de utilidad en un colegio de enseñanza. Por regalarme la experiencia de poder participar en un proyecto real. v
Frases Lo que sabemos es una gota de agua lo que ignoramos es el océano. Isaac Newton Nuestros sentidos nos permiten percibir solo una pequeña porción del mundo exterior. Nikola Tesla Solo una vida dedicada a los demás merece ser vivida. Albert Einstein Creo que muchos niños se sienten solos y aislados en su propio mundo. Tim Burton Las cosas que haces son las que te hacen, así que haz lo que sabes y sabrás lo que vales. Mientras veas sólo con tus ojos serás siempre ciego. El Chojin Todo el mundo tiene el derecho a una vida digna y el deber de ayudar a los otros a tenerla cuando lo consigue. Juancho Marqués vii
Resumen En la actualidad, cada vez más personas acceden a internet diariamente por diversos motivos. Sin embargo, no todos los usuarios poseen las mismas capacidades para navegar a través de internet. En el caso de los colectivos que presentan discapacidad o avanzada edad, entre otros, es habitual que encuentren diversas barreras que les dicultan el acceso, encontrándose con problemas para leer, escribir o entender textos a la hora de navegar por internet. Por ello, surge la necesidad de adaptar la web a estos colectivos, haciéndola accesible para todo tipo de usuarios. Una página web es accesible cuando sus contenidos están disponibles para todo tipo de usuario, permitiendo así interactuar de forma total e independiente con la página web. Existen determinadas pautas para hacer la web más accesible, por ejemplo, escoger un tipo de letra clara y de tamaño grande para facilitar la lectura del texto a personas con dicultad lectora, sin embargo, estas pautas no se cumplen en la mayoría de los casos. Como proyecto de n de grado se ha realizado el análisis, diseño e implementación de una herramienta de apoyo a la navegación web para colectivos de personas que presentan algún tipo de dicultad a la hora de comprender el lenguaje escrito. En todo el desarrollo del proyecto se ha llevado a cabo una aproximación centrada en el usuario nal, con la colaboración del colegio Estudio 3 AFANIAS. Considerando las características de los usuarios que pueden tener problemas a la hora de leer o interpretar un texto, este proyecto se ha desarrollado con el n de facilitar a dichos usuarios la navegación en internet, facilitándoles de manera sencilla un conjunto de herramientas que les ayuden a comprender los textos cuando estén navegando. La aplicación, ReadIt, es una extensión desarrollada en Google Chrome, ya que es uno de los navegadores web más utilizados por la mayoría de los usuarios. A través del uso de servicios externos, permite a los usuarios comprender mejor el texto al que se enfrentan, por ejemplo, pudiendo buscar las distintas acepciones de una palabra que no entienden o mostrando un resumen del texto que proporciona la página web. ix
Índice Agradecimientos v Frases vii Resumen ix Abstract xi Palabras Clave xiii Keywords xv 1. Introducción 1 1.1. Objetivos ............................. 2 1.2. Motivación ............................ 2 1.3. Estructura del documento . . . . . . . . . . . . . . . . . . . . 3 1.4. Gestión del proyecto . . . . . . . . . . . . . . . . . . . . . . . 4 2. Preamble 5 2.1. Goals ............................... 6 2.2. Motivation............................. 6 2.3. Document structure . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Project management . . . . . . . . . . . . . . . . . . . . . . . 7 3. Estado del arte 9 3.1. El concepto de la accesibilidad web . . . . . . . . . . . . . . . 9 3.1.1. ¾Qué es la Accesibilidad Web? . . . . . . . . . . . . . 9 3.1.2. Pautas de Accesibilidad al Contenido en la Web . . . . 10 3.1.3. ¾Por qué la Accesibilidad Web es importante? . . . . . 14 3.2. ¾Qué es la Lectura Fácil? . . . . . . . . . . . . . . . . . . . . 14 3.2.1. Directrices internacionales de la IFLA . . . . . . . . . 14 3.2.2. ¾Por qué la lectura fácil es necesaria? . . . . . . . . . . 17 3.3. Proyectos relacionados . . . . . . . . . . . . . . . . . . . . . . 17 xvii
xviii Índice 3.3.1. inSuit ........................... 17 3.3.2. NavegaFácil........................ 18 3.3.3. ATbar........................... 20 3.3.4. Extensión WAVE Evaluation Tool . . . . . . . . . . . 23 3.3.5. OpenDyslexic y OpenDyslexic Font-Helperbird-Free . 23 4. Tecnología 27 4.1. Orígenes de Google Chrome . . . . . . . . . . . . . . . . . . . 27 4.1.1. Versiones ......................... 28 4.2. ¾Qué es una extensión? . . . . . . . . . . . . . . . . . . . . . 29 4.2.1. ¾Por qué una extensión para Chrome? . . . . . . . . . 30 4.2.2. Características básicas de Google Chrome . . . . . . . 31 4.3. Estructura general de las extensiones en Google Chrome . . . 32 4.3.1. Arquitectura de la ventana emergente . . . . . . . . . 34 4.4. Mundos aislados en las extensiones de Google Chrome . . . . 35 5. Diseño centrado en el usuario 39 5.1. Colegio Estudio 3 AFANIAS . . . . . . . . . . . . . . . . . . 40 5.2. Colegio Estudio 3 AFANIAS: Primera reunión . . . . . . . . . 40 5.2.1. Mockup ejemplo 1: Click con el botón derecho. . . . . 41 5.2.2. Mockup ejemplo 2: Barra de menú. . . . . . . . . . . . 42 5.2.3. Menú guardar. . . . . . . . . . . . . . . . . . . . . . . 45 5.2.4. Marcas de guardado en el documento. . . . . . . . . . 45 5.2.5. Colegio Estudio 3 AFANIAS: Primeras conclusiones . 45 5.3. Colegio Estudio 3 AFANIAS: Segunda reunión . . . . . . . . 47 5.4. Colegio Estudio 3 AFANIAS: Tercera reunión . . . . . . . . . 48 5.4.1. Colegio Estudio 3 AFANIAS: Cuestionarios sobre la aplicación......................... 48 5.4.2. Colegio Estudio 3 AFANIAS: Resultados tras la tercerareunión......................... 50 6. Descripción de la aplicación 55 6.1. Barra de menú de la aplicación . . . . . . . . . . . . . . . . . 55 6.1.1. Barra de búsqueda . . . . . . . . . . . . . . . . . . . . 55 6.1.2. Blog............................ 56 6.1.3. Deniciones........................ 56 6.1.4. Palabras parecidas . . . . . . . . . . . . . . . . . . . . 56 6.1.5. Palabras contrarias . . . . . . . . . . . . . . . . . . . . 57 6.1.6. Pictogramas........................ 57 6.1.7. Youtube.......................... 57 6.1.8. Wikipedia......................... 58 6.1.9. Resumen ......................... 58
Índice xix 6.1.10. Lectura en voz alta . . . . . . . . . . . . . . . . . . . . 58 6.1.11. Icono de los engranajes . . . . . . . . . . . . . . . . . 58 6.2. Conguración de la barra de menú de la aplicación . . . . . . 59 6.3. Guardar los datos del usuario . . . . . . . . . . . . . . . . . . 60 6.4. Exportar los datos del usuario . . . . . . . . . . . . . . . . . . 61 7. Arquitectura de la aplicación 65 7.1. Introducción............................ 65 7.2. Arquitectura ........................... 66 7.2.1. Archivos principales . . . . . . . . . . . . . . . . . . . 66 7.2.2. SelectionServicesMenu . . . . . . . . . . . . . . . . . . 67 7.2.3. Services .......................... 68 7.2.4. Toolbar .......................... 71 7.2.5. Modals .......................... 71 7.2.6. Storage .......................... 72 7.3. Instalación del plugin . . . . . . . . . . . . . . . . . . . . . . . 73 7.4. Extensibilidad del plugin . . . . . . . . . . . . . . . . . . . . . 74 8. Conclusiones y trabajo futuro 79 8.1. Conclusiones ........................... 79 8.2. Trabajofuturo .......................... 80 9. Conclusions and future work 83 9.1. Conclusions............................ 83 9.2. Futurework............................ 84 Bibliografía 85
Índice de guras 3.1. Diseño de NavegaFácil . . . . . . . . . . . . . . . . . . . . . . 19 3.2. Diseño de la barra de herramientas . . . . . . . . . . . . . . . 21 3.3. Resultados tras ejecutar WAVE . . . . . . . . . . . . . . . . . 24 3.4. Plugins OpenDyslexic y OpenDyslexic Font-Helperbird-Free . 25 3.5. Aplicando los plugins OpenDyslexic . . . . . . . . . . . . . . 26 4.1. Versiones de Chrome ordenadas de menor a mayor estabilidad 28 4.2. Uso de distintos tipos navegadores . . . . . . . . . . . . . . . 30 4.3. Estructura general de una extensión para Chrome . . . . . . . 32 4.4. Page Action vs Browser Action . . . . . . . . . . . . . . . . . 34 4.5. Arquitectura de la ventana emergente . . . . . . . . . . . . . 35 4.6. Ejemplo de una estructura DOM . . . . . . . . . . . . . . . . 36 4.7. DOMcompartido......................... 36 4.8. DOM compartido con mundos aislados . . . . . . . . . . . . . 37 4.9. Arquitectura que muestra el intercambio de información . . . 37 5.1. Selección de palabras pulsando botón derecho . . . . . . . . . 42 5.2. Selección de palabras a través de una barra de menú . . . . . 43 5.3. Selección de palabras a través de una barra de menú escribiendotexto............................ 44 5.4. Obteniendo los valores guardados por el usuario . . . . . . . . 46 5.5. Ejemplo de marcas de guardado . . . . . . . . . . . . . . . . . 47 5.6. Respuestas en forma de semáforo . . . . . . . . . . . . . . . . 49 6.1. Barra principal de la aplicación . . . . . . . . . . . . . . . . . 55 6.2. Deniciones de la palabra casa . . . . . . . . . . . . . . . . . 56 6.3. Resultado de una palabra que no presenta deniciones . . . . 57 6.4. Pictogramas de la palabra casa . . . . . . . . . . . . . . . . . 58 6.5. Ejemplo usando la opción de resumen . . . . . . . . . . . . . 59 6.6. Ejemplo de los datos guardados por el usuario . . . . . . . . . 60 6.7. Resultado de ltrar los servicios adecuados para el usuario . . 61 6.8. Guardando los datos del usuario . . . . . . . . . . . . . . . . 62 xxi
xxii Índice de figuras 6.9. Ejemplo de los datos guardados por el usuario . . . . . . . . . 63 6.10. Guardando los datos del usuario . . . . . . . . . . . . . . . . 64 7.1. Estructura del proyecto . . . . . . . . . . . . . . . . . . . . . 66 7.2. Ruta para acceder a la pestaña Extensiones del navegador . . 74 7.3. Opciones que aparecen tras habilitar el Modo desarrollador . 74
Índice de Tablas 5.1. Respuestas del cuestionarios de los alumnos . . . . . . . . . . 52 5.2. Respuestas del cuestionarios de los profesores . . . . . . . . . 53 xxiii
Capítulo 1 Introducción La tecnología está cada día más arraigada en la sociedad actual de manera muy signicativa. Con el paso del tiempo, cada vez existen más usuarios que acceden a internet a diario por diversos motivos. Cabe suponer que no todos poseen las mismas capacidades para navegar en la web. Para muchos usuarios existe una gran barrera que les diculta o incluso impide el uso parcial o total de la red. Esta barrera puede ser causada por distintos motivos: edad avanzada, personas extranjeras que no conocen el idioma, distintos tipos de discapacidades: visuales, motoras, sonoras, físicas, cognitivas... Este proyecto nace con la idea de facilitar el acceso web a aquellos colectivos de personas que presentan algún tipo de dicultad a la hora de comprender el lenguaje escrito. Sin embargo, no todas las dicultades pueden tratarse de la misma forma, por lo que resulta realmente difícil abarcar todas en una sola aplicación. Por tanto, el objetivo principal de este proyecto consiste en hacer la información web más accesible a aquellos colectivos de personas con discapacidades como Trastornos del Espectro Autista (TEA) o trastornos del lenguaje como afasia 1 o dislexia 2 , que tienen problemas con la lectura de los contenidos que se presentan en la web. Además, decidimos orientarlo a que cada usuario pudiera escoger la ayuda que necesita acorde a sus necesidades. 1 Trastorno del lenguaje que se caracteriza por la incapacidad o la dicultad de comunicarse mediante el habla, la escritura o la mímica y se debe a lesiones cerebrales. 2 Alteración de la capacidad de leer por la que se confunden o se altera el orden de letras, sílabas o palabras. 1
8 Capítulo 2. Preamble − TeXstudio was used for the development of the memory. TeXstudio is an editor of LaTeX 4 open source and cross-platform, working on the TeXiS 5 . − GitNIL 6 , a repository within the organization of the UCM's NIL 7 research group in Github, was used for code change management and control. 4 It is a text composition system, aimed at the creation of written documents with a high typographic quality. 5 Further information about TeXiS at http://gaia.fdi.ucm.es/research/texis 6 We can nd the repository at https://github.com/NILGroup/ TFG-1718-AccesibilidadWeb 7 More information about NIL can be found at http://nil.fdi.ucm.es/
Capítulo 3 Estado del arte En este capítulo trataremos el tema de la accesibilidad web y la lectura fácil, así cómo las aplicaciones que existen en la actualidad para conseguir que los sitios web sean más accesibles para todos aquellos usuarios que lo necesiten. 3.1. El concepto de la accesibilidad web El objetivo de esta sección es explicar el concepto de la Accesibilidad web y presentar las pautas de Accesibilidad de Contenido desarrolladas por el W3C 1 (W3C, 2018) y por qué son importantes. 3.1.1. ¾Qué es la Accesibilidad Web? La Accesibilidad Web (Mora, 2018) tiene como objetivo lograr que las páginas web sean utilizables por el máximo número de personas, independientemente de sus conocimientos o capacidades personales. Concretamente, ofrece la posibilidad de que la información web pueda ser comprendida y consultada por personas con discapacidad, cuyo objetivo es garantizar la igualdad de oportunidades, evitando así todo tipo de discriminación. Cuando hablamos de accesibilidad web se hace referencia a un diseño web que permitirá que estas personas puedan percibir, entender, navegar e interactuar con la web. Existen otros colectivos, como personas de avanzada edad a las que también benecia la accesibilidad web. La Accesibilidad Web engloba muchos tipos de discapacidades, incluyendo problemas visuales, auditivos, físicos, cognitivos, neurológicos y del 1 El Consorcio World Wide Web (World Wide Web Consortium, en inglés) es una comunidad internacional donde diversas organizaciones y personas trabajan conjuntamente para desarrollar estándares web. 9
10 Capítulo 3. Estado del arte habla. Hoy en día, existen muchas personas con distintas discapacidades que no pueden utilizar la web, ya que actualmente la gran mayoría de los sitios web presentan grandes barreras de accesibilidad. Para que el acceso a la información sea posible existen determinadas normas y requisitos que las páginas web deben cumplir, tal como indica la Ley de Accesibilidad de la Información en las Páginas Web (Ley N ◦ 26.653). El cumplimiento de estas pautas contribuye a que el contenido sea más accesible para todas las personas, con o sin discapacidad, incluyendo a aquellos usuarios que para acceder a la web utilicen herramientas de apoyo (visuales, auditivas, motrices...). 3.1.2. Pautas de Accesibilidad al Contenido en la Web Una de las principales iniciativas del W3C es el desarrollo de normas de accesibilidad. El objetivo de la Iniciativa para la Accesibilidad Web (Web Accessibility Initiative, WAI (Henry, 2018)) es desarrollar los estándares de accesibilidad. Los grupos de trabajo del WAI desarrollan las normas de accesibilidad para los navegadores web, para las herramientas de autor, de evaluación y para el contenido web. Las normas del Grupo de Trabajo para el Contenido Web se llaman Pautas de Accesibilidad al Contenido en la Web (Web Content Accessibility Guidelines, WCAG). Actualmente, existen dos versiones para las Pautas de Accesibilidad al Contenido en la Web. 3.1.2.1. Pautas de Accesibilidad al Contenido en la Web 1.0 La versión 1.0 de las Pautas de Accesibilidad al Contenido en la Web (Web Content Accessibility Guidelines 1.0, WCAG 1.0 (Chisholm et al., 1999)) fue un avance importante para lograr que Internet sea más accesible para las personas con discapacidad. Estas pautas fueron escritas en 1999, creando 14 directrices y numerosos puntos de control que podían utilizarse para determinar la accesibilidad de una página web. Proporcionaban tres prioridades, niveles de cumplimiento o niveles de adecuación, es decir, la medida en que una página web cumple las directrices. − Prioridad 1 o Nivel de adecuación A. Se trata de un requisito básico para que algunos grupos de usuarios pudieran usar el contenido web. − Prioridad 2 o Nivel de adecuación AA. Indicaba una mejor
3.1. El concepto de la accesibilidad web 11 accesibilidad y la eliminación de importantes barreras de acceso al contenido. − Prioridad 3 o Nivel de adecuación AAA. Proporcionaba mejoras a la accesibilidad del contenido web. A continuación, desarrollamos las pautas de accesibilidad al contenido en la Web 1.0(Chisholm et al., 1999): − Proporcionar alternativas equivalentes para el contenido visual y auditivo. • Los textos alternativos al contenido visual o auditivo benecian a personas ciegas y/o sordas y a aquellos usuarios que deciden anular la descarga de imágenes y/o sonidos, por ejemplo, por motivos de velocidad de acceso a Internet. • Los equivalentes no textuales, como pueden ser dibujos o vídeos, benecian a personas analfabetas o con dicultades en la lectura. − No basarse únicamente en el color. Los textos y grácos deben comprenderse sin necesidad de ver los colores. El cumplimiento de esta pauta benecia a personas con dicultades para ver los colores y a usuarios que utilizan pantallas monocromáticas. − Utilizar marcadores y hojas de estilo apropiadamente. La presentación de los contenidos se debe realizar con hojas de estilo. Con el uso de marcadores de presentación los usuarios que utilizan software especializado tendrán dicultades para entender la estructura de la página. − Identicar el idioma que se usa. Esta pauta implica usar marcadores que faciliten la pronunciación o interpretación de texto abreviado. Se debe indicar el idioma predominante en cada página y marcar aquellas expresiones que se encuentren en otra lengua. Así, los sintetizadores de voz son capaces de cambiar su pronunciación en función del idioma siempre y cuando se usen los marcadores apropiados. − Crear tablas que se transformen correctamente. Las tablas sólo se deben utilizar para marcar información tabular (tablas de datos). El uso de tablas con otros nes crea dicultades para los usuarios que usan lectores de pantalla. De la misma forma, las tablas mal estructuradas (por ejemplo, sin encabezados <th>) dicultan la lectura a usuarios que no pueden visualizar la información de forma global: ciegos con lectores de pantalla y/o dispositivos braille , decientes visuales que utilizan magnicadores de pantalla o usuarios con dispositivos de pantalla pequeña.
12 Capítulo 3. Estado del arte − Asegurar que las páginas que incorporen nuevas tecnologías se transformen correctamente. Una página basada en tecnologías modernas tiene que ser accesible al desconectarla o al visualizarla con navegadores antiguos. El usuario puede desconectar las tecnologías más modernas para ganar en rapidez de descarga. Sin embargo, los contenidos deben permanecer accesibles. − Garantizar el control sobre los cambios de contenido sensibles en el tiempo. Es importante pausar o detener el movimiento, el parpadeo, el desplazamiento o la actualización automática de objetos o páginas. Algunas personas con discapacidades cognitivas o visuales no pueden leer el texto en movimiento. Además, los lectores de pantalla no pueden leer texto en movimiento. − Garantizar el acceso directo a las interfaces de usuario integradas. Se debe asegurar que la interfaz de usuario siga los principios del diseño accesible: acceso independiente del dispositivo a la funcionalidad, la operabilidad del teclado, la voz propia, etc. Cuando un objeto incrustado tiene su propia interfaz, ésta debe ser accesible. Si la interfaz del objeto incrustado no puede ser accesible, se debe proporcionar una solución accesible alternativa. − El diseño debe garantizar la independencia del dispositivo. Usar funciones que permitan la activación de elementos de página a través de una variedad de dispositivos de entrada. − Usar soluciones provisionales de accesibilidad para que las tecnologías de asistencia y los navegadores antiguos funcionen correctamente. − Utilizar las tecnologías W3C (según las especicaciones) y seguir las pautas de accesibilidad. Cuando no sea posible utilizar una tecnología W3C, o si al hacerlo el material no se transforma correctamente, proporcionar una versión alternativa del contenido que sea accesible. − Proporcionar información de contexto y orientación para ayudar a los usuarios a comprender páginas o elementos complejos. Las relaciones complejas entre partes de una página pueden ser difíciles de interpretar para las personas con discapacidades cognitivas y las personas con discapacidades visuales. − Proporcionar mecanismos de navegación claros y consistentes (información de orientación, barras de navegación, un mapa del sitio, etc.) para aumentar la probabilidad de que una persona encuentre lo que busca en un sitio. − Asegurar que los documentos sean claros y sencillos para que se puedan entender más fácilmente. Un diseño de página consistente, con grácos
3.1. El concepto de la accesibilidad web 13 reconocibles y un lenguaje fácil de entender, benecian en particular a las personas con discapacidades cognitivas o que tienen dicultades para leer. 3.1.2.2. Pautas de Accesibilidad al Contenido en la Web 2.0 Con el paso del tiempo, las WCAG 1.0 comenzaron a quedarse obsoletas, ya que debido al avance de las tecnologías web resultaba más difícil vericar sus pautas. Por ello, aparecen Las Pautas de Accesibilidad al Contenido en la Web 2.0 (Web Content Accessibility Guidelines 2.0, WCAG 2.0 (Chisholm et al., 2008)), que se fundamentan en WCAG 1.0, introduciendo algunos cambios signicativos. A un nivel práctico, algunos de los cambios se muestran igual que las WCAG 1.0. Por ejemplo, los formularios todavía requieren etiquetas, las tablas de datos deben contener cabeceras y las imágenes todavía requieren un texto alternativo, por lo que los desarrolladores web que ya diseñan sitios web accesibles no tendrán que cambiar demasiado sus hábitos. Por otro lado, las WCAG 2.0 representan un cambio en su losofía. Los cambios importantes implican que las pautas están centradas en principios más que en técnicas, permitiendo que las pautas sigan siendo relevantes incluso cuando la tecnología cambie. Además, están diseñadas para que su adecuación se pueda vericar de forma able. El cambio de pautas centradas en las técnicas a pautas centradas en principios dio lugar a un número reducido de ideas de nivel superior o principios. Las WCAG 1.0 tenían catorce principios en el nivel superior. En cambio, las WCAG 2.0 presenta únicamente cuatro principios en el nivel superior. Cada uno de estos cuatro principios se indica con una sola palabra: − Principio 1: Perceptible. La información y los componentes de la interfaz de usuario deben estar presentables para los usuarios de maneras que puedan percibir. − Principio 2: Operable. Los componentes de la interfaz de usuario y la navegación deben ser operables. − Principio 3: Comprensible. La información y el funcionamiento de la interfaz de usuario deben ser comprensibles. − Principio 4: Robusto. El contenido debe ser lo sucientemente robusto como para que pueda ser interpretado de manera conable por
14 Capítulo 3. Estado del arte una amplia variedad de agentes de usuario, incluidas las tecnologías de asistencia. 3.1.3. ¾Por qué la Accesibilidad Web es importante? Hoy en día, usamos internet para muchos aspectos de nuestra vida: educación, empleo, sanidad, entretenimiento... Por ello, es importante que la web sea accesible para poder proporcionar acceso equitativo y en igualdad de oportunidades para todas personas. El hecho de que una página web sea accesible permite ayudar a que personas con discapacidad participen más activamente en la sociedad, integrándose en ésta en mayor medida, brindándoles así una oportunidad de acceder a la información y de interactuar. 3.2. ¾Qué es la Lectura Fácil? Podemos encontrar dos deniciones ligeramente distintas para este término: − Adaptación lingüística de un texto que facilita más la lectura de un contenido, aunque no su comprensión. − Adaptación que hace más fácil tanto la lectura como la comprensión. La Lectura Fácil no sólo abarca el texto, sino también se reere a las ilustraciones y maquetación. Se dirige a todas las personas, en especial a aquellas que tienen dicultades lectoras transitorias (inmigración, incorporación tardía a la lectura, escolarización deciente...) o permanentes (trastornos del aprendizaje, diversidad funcional, senilidad...). 3.2.1. Directrices internacionales de la IFLA En 1997 la IFLA 2 (International Federation of Library Associations and Institutions) creó una serie de Directrices Internacionales que han sido traducidas a todos los idiomas de la Unión Europea, dentro de un proyecto que persigue hacer accesible a todos los ciudadanos los servicios y medios de comunicación. El objetivo que se pretende con estas directrices es determinar las pautas que debe seguir quien redacta un texto para que su lectura sea fácilmente 2 Para más información, consultar la página http://www.ia.org
3.2. ¾Qué es la Lectura Fácil? 15 comprensible por todos. Las Directrices de Lectura Fácil van dirigidas a todas las personas que tengan dicultades para leer y entender el idioma del país en el que residen. Por ejemplo, personas con discapacidad cognitiva, colectivos que padecen otro tipo de discapacidad que afecta también a su capacidad de lectura o comprensión, personas con un bajo nivel cultural, personas mayores... Para hacer un texto que sea comprensible para el mayor número de personas, existen una serie de normas de diseño y de redacción. 3.2.1.1. Normas de diseño El diseño de las publicaciones juega un papel importante en la facilidad de lectura. Las recomendaciones más importantes a tener en cuenta en lo que se reere al diseño son(Moreno y Franco, 2009): − Elegir letras claras, como Arial, Helvética, Verdana, Times New Roman o Sans Serif, entre otras. − Utilizar como máximo dos tipos de letras dentro del mismo documento. − El tamaño de la letra ha de ser grande o congurable si el formato es electrónico. − No utilizar mayúsculas ni cursivas. Usar la negrita o el subrayado para enfatizar palabras o frases. − No justicar el texto a la derecha. Lo más apropiado es usar una alineación a la izquierda. − No poner dibujos como fondo de un texto. − Intentar utilizar una sola línea para cada oración. − Evitar separar los elementos constitutivos de la oración, de modo que ésta quede siempre dentro de una misma página. − No incluir demasiada información en una página. − No usar nunca la impresión invertida. − Utilizar colores para los dibujos. − No usar guiones para separar palabras largas en el margen derecho del texto
16 Capítulo 3. Estado del arte 3.2.1.2. Normas de redacción El otro tipo de pautas a seguir son las relacionadas con el contenido del texto, que son fundamentales para que todos puedan entender la información que queremos transmitir. Sin embargo, el uso de estas pautas no implica caer en un lenguaje simplista e infantil. Las pautas relacionadas con el contenido son (Moreno y Franco, 2009): − Usar un lenguaje sencillo y claro. − Evitar conceptos abstractos. Si han de usarse, utilizar ejemplos concretos o aclaraciones. − Emplear vocablos cortos relativos al lenguaje cotidiano hablado. − Personicar el texto tanto como sea posible. Es mejor decir usted tiene derecho a... que los usuarios del servicio tienen derecho a... − Hacer uso de ejemplos prácticos. − Dirigirse a los lectores de manera respetuosa. − Incluir una sola idea principal en cada oración. − Utilizar un lenguaje positivo. − Emplear preferentemente la voz activa frente a la pasiva. − No dar por asumidos conocimientos previos sobre el tema en cuestión. − Ser sistemático al utilizar las palabras. − No emplear el subjuntivo. − Tener cuidado con el lenguaje gurativo o metafórico si son vocablos de uso poco común. − No emplear palabras de otro idioma. − Mencionar, siempre que sea posible, una dirección de contacto para solicitar más información. − Evitar el uso de jergas, abreviaturas e iniciales.
3.3. Proyectos relacionados 17 3.2.2. ¾Por qué la lectura fácil es necesaria? La lectura fácil es necesaria porque: − El acceso a la lectura y a la información es un derecho y una necesidad social. − Leer es un placer que permite compartir ideas, pensamientos y experiencias. − Muchos textos tienen un exceso de tecnicismos, una sintaxis compleja y una presentación poco clara. − Existe cierto porcentaje de la población que presenta dicultades lectoras. 3.3. Proyectos relacionados En esta sección comentaremos algunos de los proyectos que existen en la actualidad para afrontar el problema de la accesibilidad web. 3.3.1. inSuit InSuit 3 proporciona accesibilidad y usabilidad web de manera sencilla. Se trata de un producto de apoyo que añade a la página web una capa de información semántica, personalizada por expertos en accesibilidad y usabilidad. 3.3.1.1. ¾Qué nos permite inSuit? InSuit nos permite: − Mejorar de manera automática el cumplimiento de muchas de las recomendaciones del W3C en materia de accesibilidad web, haciendo que la web sea más accesible y usable. − Proporcionar desde la nube las ayudas técnicas para que cada persona pueda navegar de manera adaptada a sus necesidades y preferencias. 3.3.1.2. ¾Qué ofrece inSuit? Al proporcionar las ayudas desde la nube, inSuit está en continua evolución. Cada persona puede navegar de manera adaptada a sus necesidades y preferencias. Ofrece las siguientes ayudas técnicas: 3 Para más información, acceder a la página https://www.insuit.net/es/
24 Capítulo 3. Estado del arte Figura 3.3: Resultados tras ejecutar WAVE
3.3. Proyectos relacionados 25 (a) Plugin OpenDyslexic (b) Plugin OpenDyslexic Font-Helperbird-Free Figura 3.4: Plugins OpenDyslexic y OpenDyslexic Font-Helperbird-Free
26 Capítulo 3. Estado del arte (a) Antes de aplicar los cambios de los plugins (b) Despues de aplicar los cambios de los plugins Figura 3.5: Aplicando los plugins OpenDyslexic
Capítulo 4 Tecnología En este capítulo hablaremos sobre la tecnología escogida para desarrollar el proyecto, una extensión para Google Chrome. Describiremos los distintos motivos para seleccionarla frente a otras alternativas. Trazaremos nas pinceladas acerca de los orígenes de dicho navegador, las distintas versiones que existen en la actualidad y sus principales características. Describiremos algunos tipos de extensiones que nos podemos encontrar en internet, así como las más usadas según las necesidades de los usuarios. Explicaremos qué es una extensión web, deniendo su estructura y arquitectura generales. 4.1. Orígenes de Google Chrome Chrome (Leonardo, 2012) fue presentado por primera vez de manera o- cial el 2 de Septiembre de 2008 para Microsoft Windows (únicamente para XP y versiones posteriores) en 43 idiomas siendo una versión beta. Obtuvo en un breve periodo de tiempo el 1% del mercado de navegadores. Un tiempo después, el 11 de Diciembre de 2008 fue lanzado de manera ocial. Esta primera versión pasó las pruebas de Acid1 1 y Acid2 2 (esta última con un pequeño error). Obtuvo 79 puntos de 100 en la prueba de Acid3 3 , 1 Originalmente llamado Box Acid Test, es una página de prueba para los navegadores web. Se desarrolló en octubre de 1998 y fue importante para establecer una base de referencia para la interoperabilidad de los primeros navegadores web. 2 Es una página de prueba publicada para detectar fallos de renderización. Fue desarrollada en el espíritu de Acid1. Fue lanzada el 13 de abril de 2005. 3 Pone a prueba los navegadores con los estándares web. Desarrollo desde abril de 2007 y lanzado el 3 de marzo de 2008. 27
28 Capítulo 4. Tecnología siendo superior a Internet Explorer y Firefox, pero inferior a Opera. El 9 de diciembre de 2009, Google anunció la publicación de las versiones beta de Chrome para Mac OS X y Linux. A principios de 2010 ya cuenta con más de 1500 funciones disponibles. En marzo, surgen los controles de privacidad y el traductor de Google. El 25 de mayo de 2010 Google anunció la versión estable de su navegador Google Chrome versión 5 simultáneamente para todas las plataformas Microsoft Windows, Mac OS X y Linux. Al mes siguiente, se integra Flash a Chrome. En febrero de 2012 se lanza la versión beta para Android. En junio, surgen las versiones de Chrome para iPhone y iPad. Actualmente, el navegador está disponible para la plataforma Microsoft Windows en más de 50 idiomas. La versión para sistemas Mac OS X y Linux se encuentra actualmente en desarrollo, con disponibilidades de versiones beta en ambos sistemas operativos. 4.1.1. Versiones Google Chrome es el navegador web más utilizado en todo el mundo. Actualmente, existen cinco versiones (Velasco, 2017) de Google Chrome distintas, cada una de ellas pensadas para una nalidad en concreto. Figura 4.1: Versiones de Chrome ordenadas de menor a mayor estabilidad Google Chrome Stable Se trata de la más estable de Chrome y la más usada por los usuarios. Es la versión nal, libre de errores lista para funcionar, proporcionando la mejor experiencia, seguridad y rendimiento mientras navegamos en la web. Recibe las actualizaciones más importantes, siendo probadas antes por las demás versiones de desarrollo.
4.2. ¾Qué es una extensión? 29 Google Chrome Beta Es considerada como la versión más equilibrada que ofrece Google para dispositivos Android. Funciona igual que Google Chrome Stable y suele estar adelantada, ya que Google suele probar aquí todas las funciones que, con el tiempo, llegarán a la versión nal, por lo que existe la posibilidad de encontrar algunos errores. Chrome Beta es recomendada para aquellos usuarios que sufran problemas con la versión estable o para los que quieran disfrutar antes de las novedades. Esta versión se suele actualizar todas las semanas y suele recibir una actualización mayor cada seis semanas. Google Chrome Dev Es inferior de la versión Beta y Stable, por lo que es más inestable. Se trata de una variante pensada para desarrolladores, para detectar los errores, solucionarlos y desarrollar nuevas versiones. Su principal objetivo es que los administradores sean capaces de comprobar que sus páginas web funcionen bien con las nuevas extensiones y complementos instalados. Google Chrome Canary Es la versión más inestable de todas. Se genera automáticamente desde los servidores de Google con todos los cambios que se han realizado en el código sin ningún tipo de comprobación. Se caracteriza por continuas actualizaciones, errores y su función experimental. Esta variante está destinada a los desarrolladores, para poder comunicar los errores existentes. Puede recibir hasta siete actualizaciones a la semana. Google Chromiun Chromium es uno de los proyectos más interesantes de la compañía gracias a su diversidad. Su objetivo principal es proporcionar un navegador con mayor estabilidad, velocidad y seguridad además de incluir una interfaz de usuario sencilla y eciente. Chromium es el navegador base del que está construido Chrome y tiene sus mismas características de diseño, pero con un logotipo ligeramente diferente y sin el apoyo comercial y técnico de la compañía Google. 4.2. ¾Qué es una extensión? Las extensiones son pequeños programas que se instalan dentro del navegador (Google Chrome, Firefox, Opera, etc.) que permiten modicar y mejorar la funcionalidad del navegador, facilitando la experiencia de los usuarios una vez que son instaladas. Suelen tener un tamaño bastante pequeño (no más de 1MB). Se desarrollan utilizando tecnologías web tales como HTML,
30 Capítulo 4. Tecnología Javascript y CSS. Cada usuario puede seleccionar la extensión que quiera en función de sus necesidades e instalarla en su navegador. Hoy en día existe gran variedad de extensiones para cubrir las necesidades de los usuarios. Pueden ser gratis o de pago, pueden ser creadas por los desarrolladores de Google o por terceros. 4.2.1. ¾Por qué una extensión para Chrome? Uno de los principales motivos para desarrollar una extensión para Google Chrome es que es uno de los navegadores más utilizados a nivel mundial por los usuarios. En la gura 4.2 podemos comprobar en el diagrama de sectores 4 cómo el porcentaje de uso de los usuarios de dicho navegador es superior en casi un 40% respecto del resto. Figura 4.2: Uso de distintos tipos navegadores Escogiendo Chrome como navegador para el desarrollo del proyecto proporcionaríamos soporte a un amplio número de usuarios que usan internet a diario. Sin embargo, la navegación no es igual para todos. Cada usuario puede presentar distintos problemas a la hora de comprender un artículo, por ejemplo, que contenga palabras de las que desconoce su signicado. Desarrollando una extensión, podremos cubrir esta y otros tipos de problemática para un sector concreto de usuarios en todas las páginas a las que desee acceder. 4 Diagrama extraído del artículo https://www.muycomputer.com/2017/03/01/ navegadores-web-febrero/
4.2. ¾Qué es una extensión? 31 Otro motivo que impulsó al desarrollo de una extensión es aportar la capacidad de mejorar los servicios que nos proporciona el navegador para aquellas personas con mayor dicultad. Una característica importante a tener en cuenta, es que es muy sencillo habilitar un extensión de Chrome, como explicaremos en otra sección. 4.2.2. Características básicas de Google Chrome Google Chrome proporciona una serie de características que lo hacen diferente y completo. Presenta una interfaz simple y clara, cuenta con gran estabilidad y seguridad. La mejor característica que proporciona para los usuarios es la rapidez. Indicamos a continuación algunas características básicas (DKEN2302, 2015) (Chauvin, 2012): − Navegación segura: Para navegar de manera más segura, Google Chrome advierte al usuario cuando está a punto de visitar un sitio sospechoso o inseguro. Al realizar la navegación mediante pestañas independientes, que están incomunicadas, se impide el robo de la información. − Eficacia: Google Chrome está diseñado para soportar aplicaciones web complejas y es compatible con los lenguajes de programación actuales. − Soporta mejoras y actualizaciones: Está disponible para Windows, Mac y Linux, al igual que sus continuas mejoras, cuya nalidad es que el navegador sea más rápido, estable y funcional. − Velocidad: El objetivo principal de Chrome es la velocidad de navegación, desde su ejecución hasta la carga de aplicaciones web complejas. − Productividad: El usuario puede acceder a sus marcadores, pestañas abiertas e historial desde cualquier dispositivo que sea compatible con Chrome. − Compatibilidad: Google Chrome siempre se encuentra en constante crecimiento por parte de sus desarrolladores, lo que permite incluir nuevas extensiones para mejorar la compatibilidad con otras aplicaciones. − Interfaz sencilla y funcional: Está diseñado para ser lo más sencillo posible. − Administrador de tareas: Chrome contiene un administrador de tareas que nos indica qué recursos se están consumiendo y en qué páginas.
32 Capítulo 4. Tecnología − Privacidad: A través del modo de incógnito, Chrome permite controlar la información de privacidad y protegerla, navegando en la web sin guardar el historial de navegación ni las búsquedas, permitiendo así al usuario navegar de manera anónima. − Marcadores instantáneos: Si el usuario reconoce un sitio de interés, puede guardarlo como sitio preferido en los Marcadores de Google Chrome. Además, el navegador también permite generar carpetas para organizar nuestros marcadores. 4.3. Estructura general de las extensiones en Google Chrome Como ya hemos mencionado, las extensiones son pequeños programas software que pueden modicar y mejorar la funcionalidad del navegador Chrome. Por ello, es importante conocer su estructura general 5 . Para desarrollar una extensión, lo primero que hay que hacer es crear un chero llamado manifest.json . Se trata de un archivo que contiene toda la conguración, propiedades e información sobre la extensión. Se compone de datos formateados en JSON, que describen metadatos de la extensión, los permisos de los que dispone y los otros componentes de la extensión. En la gura 4.3 podemos ver cuáles son los elementos de los que se compone la estructura de la extensión y cuya conguración deberá estar reejada en el chero de maniesto. Figura 4.3: Estructura general de una extensión para Chrome 5 Más información en https://developer.chrome.com/extensions/overview
4.3. Estructura general de las extensiones en Google Chrome 33 A continuación, explicaremos brevemente qué es cada elemento del que se compone esta estructura: − Content script (Script de contenido) : se utilizan para tener acceso al DOM 6 de la página. Son cheros CSS y JavaScript que se inyectan en las páginas por las que los usuarios navegan. Se ejecutan después de que la página web en la que el usuario se encuentre se haya cargado. − Background script (Script de fondo) : son los controladores de nuestra aplicación. Se ejecuta cuando se inicia Chrome y siempre está escuchando todos los posibles eventos que genere la extensión en chrome. Cuánto más compleja sea la extensión, más necesario será el script de fondo. − Browser action (Acción del navegador) : es la parte más simple de la interfaz de usuario para extensiones. Una acción del navegador es un botón (el botón amarillo de la gura 4.3 ) que se agrega a la barra de herramientas principal a la derecha del omnibox 7 . La extensión puede cambiar el icono y mostrar popups emergentes, que se crean utilizando HTML y se dimensionan de forma dinámica en función de los contenidos. − Page action (Acción de página) : Son similares a las acciones del navegador, pero están en el onmibox y solo aparecen en determinadas páginas(el botón rojo de la gura 4.3 ). − Además, podemos añadir todos los archivos necesarios para desarrollar nuestra aplicación, como imágenes, bibliotecas de JavaScript... Todos los archivos deben estar contenidos en una sola carpeta. De esta manera, cuando se distribuye la extensión, el contenido de la carpeta se empaqueta en un archivo ZIP con sujo .crx, como explicaremos en otro capítulo más detalladamente. Además, se distinguen dos tipos de extensiones que podemos construir: − Acciones de página: acciones que dependen de la página. − Acciones de navegador: acciones que no son dependientes de la página. En la gura 4.4 mostramos un ejemplo de cada uno de los distintos tipos. Como podemos ver, el Page Action aparece únicamente cuando realizamos una búsqueda en una página determinada. Por otro lado, el Browser Action , en este caso la extensión AdBlock , se encuentra presente en todas las páginas. 6 Document Objet Model (modelo de objeto de documento) 7 La barra de direcciones combinada con el cuadro de búsqueda de Google.
40 Capítulo 5. Diseño centrado en el usuario − Antes de empezar a crear la aplicación, para detectar rápidamente los errores de diseño. − Durante el desarrollo de la aplicación, para no desviarnos y centrarnos en nuestros objetivos para conseguir la funcionalidad y usabilidad deseadas. − Una vez desarrollada y lanzada, para conocer los pasos de deberemos seguir para mejorar en una siguiente versión. Por tanto, gracias a esta aproximación, aseguramos que nuestra aplicación sea realmente útil, presente un alto nivel de usabilidad y funcionalidad para nuestros usuarios nales. 5.1. Colegio Estudio 3 AFANIAS El Colegio de Educación Especial Estudio 3 AFANIAS 1 es un centro concertado con La Consejería de Educación, Juventud y Deporte de la comunidad de Madrid. En el colegio Estudio 3 AFANIAS se escolariza alumnos entre los tres y los veintiún años con necesidades educativas especiales asociadas a discapacidad intelectual, plurideciencias y trastorno generalizado del desarrollo, en las etapas de Educación Infantil, Educación Básica Obligatoria y Programas para la Transición a la Vida Adulta. Gracias a Raquel Hervás y Susana Bautista, tutoras del proyecto, conseguimos concertar una reunión a principios de diciembre con el personal del colegio Estudio 3 AFANIAS para presentar una primera aproximación de la aplicación que íbamos a desarrollar. En nuestra primera visita al centro nos reunimos con Carlos Roldán (responsable TIC del colegio) que nos ayudaría a comprobar la utilidad y usabilidad de nuestra extensión, nos hizo una pequeña visita guiada por el colegio, presentándonos a los alumnos que participarían en el test de evaluación. 5.2. Colegio Estudio 3 AFANIAS: Primera reunión Una vez reunidos en el colegio con el responsable TIC del centro, expusimos que nuestra intención era desarrollar una extensión en Google Chrome para ayudar a sus alumnos (u otras personas que lo necesitaran) a navegar mejor en la red. 1 Podemos encontrar más información en: http://colegioestudio3.blogspot.com/
5.2. Colegio Estudio 3 AFANIAS: Primera reunión 41 Nuestro objetivo principal era conseguir información acerca de las necesidades básicas de los alumnos. Así, podríamos focalizar mejor el desarrollo de nuestra aplicación en mejorar su navegación en internet, evitando la posibilidad de desarrollar una herramienta que no cubriera las necesidades de los usuarios a los que está enfocada la aplicación. Nuestras propuestas pretendían resolver cuestiones relacionadas con la interfaz y funcionalidad de la aplicación. Por ello, nos planteamos las cuestiones siguientes: − Cuál era la manera más sencilla para obtener palabras que plantearan dicultades para los usuarios: seleccionando el texto de la página, escribiéndolo... − Cómo debíamos presentar la interfaz de nuestra herramienta: mostrando una barra de herramientas en todas las páginas, mostrar un menú tras seleccionar la palabra que les presenta dicultades... − Cuáles serían las herramientas más útiles para facilitar la lectura de los usuarios: sinónimos, antónimos, deniciones... − Qué opciones podrían resultar interesantes: guardar y exportar los datos que ellos buscaran, mostrar marcas de guardado en el documento... Ante esta problemática de no saber qué interfaz desarrollar, realizamos una serie de mockups 2 para presentárselos a los profesores del centro, quiénes podrían decidir cuál es el diseño y la utilidad más interesante o qué funcionalidad era la más apropiada para orientarnos a la hora de realizar la aplicación. A continuación, se explican los mockups y las conclusiones obtenidas tras la reunión. 5.2.1. Mockup ejemplo 1: Click con el botón derecho. Una vez activada la extensión, como mostramos en la gura 5.1, una de las ideas propuestas consistía en seleccionar la palabra o el texto que presente dicultades para el usuario pulsando click derecho posteriormente sobre ella. En el menú desplegado debemos seleccionar mi-plugin , correspondiente con la aplicación a desarrollar. Esto desplegaría un submenú que enumeraría los servicios prestados por el programa. El usuario podrá escoger la opción que necesite. En este ejemplo, clicando sobre deniciones podrá ver todas las acepciones de la palabra perros por medio de una ventana emergente. 2 Fotomontajes que permiten a los diseñadores grácos y web mostrar al cliente cómo quedaran sus diseños.
42 Capítulo 5. Diseño centrado en el usuario (a) Selección de los servicios que necesita el usuario (b) Ventana emergente resultante Figura 5.1: Selección de palabras pulsando botón derecho 5.2.2. Mockup ejemplo 2: Barra de menú. Como segunda propuesta, expusimos la posibilidad de diseñar una barra de menú con una serie de servicios que ofrecería la aplicación. Ante esta situación, distinguimos dos posibilidades:
5.2. Colegio Estudio 3 AFANIAS: Primera reunión 43 − Opción 1: Menú seleccionando la palabra. El usuario debe seleccionar el texto de la página web en la que se encuentra que le presente dicultades y escoger una de las opciones existente en la barra de menú personalizada como se muestra en la gura 5.2, clicando la opción deseada. Posteriormente, aparecerá una ventana emergente con todos los signicados de la palabra. (a) Escogiendo la palabra seleccionada por el usuario (b) Ventana emergente resultante Figura 5.2: Selección de palabras a través de una barra de menú
44 Capítulo 5. Diseño centrado en el usuario − Opción 2: Escribir en el menú la palabra. Otra característica consistía en incluir una barra de búsqueda en el menú personalizado. De esta manera, el usuario tendría la posibilidad de escribir una palabra o texto que le presente problemas. Una vez introducida la palabra, en el ejemplo de la gura 5.3 deberíamos clicar en la opción deniciones. Nos aparecerá una ventana emergente con todas las acepciones de la palabra perros. (a) Escribiendo la palabra deseada por el usuario (b) Ventana emergente resultante Figura 5.3: Selección de palabras a través de una barra de menú escribiendo texto
5.2. Colegio Estudio 3 AFANIAS: Primera reunión 45 5.2.3. Menú guardar. Una vez explicada la temática de la aplicación, también planteamos si podría resultar interesante poder almacenar los datos que los usuarios hayan buscado en algún momento, para que los puedan consultar siempre que quieran, como mostramos en la gura 5.4 5.2.4. Marcas de guardado en el documento. Como última aportación a la explicación, concluimos mostrando una idea extraída de la aplicación NavegaFácil , que como mostramos en la gura 5.5 consiste en añadir marcas de guardado en todas aquellas palabras que el usuario haya buscado cualquier tipo de información. 5.2.5. Colegio Estudio 3 AFANIAS: Primeras conclusiones Una vez terminada la exposición, fue momento de contrastar nuestras ideas con las de Carlos Roldán, el cual nos indicó las siguientes pautas que deberíamos tener en cuenta: − Algunos de los alumnos sí pueden seleccionar texto, pero no todos. − Recalcó la importancia de ampliar el texto. − Algunos de los alumnos sí que podrían querer obtener información textual. − Indicó que resultaría interesante poder marcar la información más importante a modo de resúmenes. − En cuanto al menú, deben entender las palabras. Por ejemplo, en lugar de mostrar la opción sinónimos sustituirla por palabras parecidas. Otra opción sería mostrar pictogramas 3 en lugar de palabras. − Sería buena idea poner los textos en mayúsculas. − Añadir la opción a navegar por Youtube o la Wikipedia sería una gran aportación. − Como cada alumno tiene distintos tipos de discapacidad, resulta interesante poder personalizar para cada usuario qué opciones tendrá disponibles en la extensión. 3 Dibujo o signo gráco que expresa un concepto relacionado materialmente con el objeto al que se reere.
46 Capítulo 5. Diseño centrado en el usuario (a) Seleccionar el servicio que queremos (b) Escoger la palabra que necesitamos (c) Ventana emergente resultante Figura 5.4: Obteniendo los valores guardados por el usuario
5.3. Colegio Estudio 3 AFANIAS: Segunda reunión 47 Figura 5.5: Ejemplo de marcas de guardado En cuanto a los mockups presentados, seleccionó como mejor idea desarrollar un menú personalizado con la opción de poder escribir texto en una barra de búsqueda. Descartó la idea de generar marcas de guardado, ya que podría causar confusión. Tras debatir la mejor manera de diseñar la aplicación, decidimos concertar una segunda reunión una vez realizado todo o casi todo el desarrollo de nuestra extensión para mostrárselo a los profesores de los alumnos para que vieran el funcionamiento de nuestra extensión y nos indicaran si cubría sus necesidades. Posteriormente, en una tercera visita al centro, los alumnos podrían utilizar la extensión y conocer sus opiniones. 5.3. Colegio Estudio 3 AFANIAS: Segunda reunión Tras la fase de desarrollo de la aplicación (ver capítulos 6 y 7), realizamos una segunda reunión con el centro la primera semana de mayo con Juan Miguel Fernández (tutor de los alumnos con los que íbamos a realizar la evaluación con usuarios nales).
48 Capítulo 5. Diseño centrado en el usuario Uno de los objetivos de la reunión consistía en exponer nuestra herramienta para conocer si la aplicación cubría las necesidades de sus alumnos. La respuesta de Juan Miguel Fernández resultó muy positiva, indicándonos que nuestro plugin reunía muchas funcionalidades que serían de gran ayuda para sus alumnos. Además, nos indicó también que incluir en las opciones de nuestra herramienta el blog del centro resultaría útil durante sus clases. Otro objetivo fue marcar la fecha para realizar la prueba con los alumnos del colegio, jada para la segunda semana de mayo. 5.4. Colegio Estudio 3 AFANIAS: Tercera reunión El objetivo de esta reunión consistió en probar nuestra aplicación con los usuarios nales, en este caso diez alumnos del colegio Estudio 3 AFANIAS. Esta visita se dividió en varias partes: − Mostrar la aplicación a José Ramón Díaz, profesor responsable de los alumnos en el aula de informática. − Realizar una presentación en el aula de los alumnos mostrándoles por primera vez la aplicación y enseñándoles cómo funciona. Para ello, preparamos una serie de actividades en las que cubríamos toda la funcionalidad de nuestra aplicación. Por ejemplo, para mostrar la funcionalidad de Youtube, como Juan Miguel Fernández nos indicó que en su viaje de n de curso irían a Port Aventura, les mostramos vídeos en Youtube sobre las atracciones del parque. − Probar nuestra herramienta en el aula de informática durante una hora siguiendo las pautas de su profesor. Allí, les indicó distintas actividades para probar la aplicación: buscar en internet sus películas favoritas para leer su sinapsis y posteriormente buscar la política de privacidad de WhatsApp , con el n de comprender sus contenidos. Finalmente, los alumnos y profesores rellenarían unos cuestionarios que preparamos para conocer cuáles eran sus opiniones sobre la aplicación. 5.4.1. Colegio Estudio 3 AFANIAS: Cuestionarios sobre la aplicación Como trabajo previo a la reunión, creamos una serie de cuestionarios orientados a los distintos perles de los usuarios con los que trabajaríamos: profesores y alumnos. Con estos cuestionarios queríamos conseguir las opiniones personales de todas las personas que usaron nuestra herramienta. De esta manera, conoceríamos como de útil y fácil les resultó nuestro plugin.
5.4. Colegio Estudio 3 AFANIAS: Tercera reunión 49 Para ello, creamos una estructura tipo test de preguntas y respuestas de tipo semáforo con emoticonos , como vemos en la gura 5.6, donde el verde representaba bien , el amarillo regular y el rojo mal . Además, en el caso de los alumnos dejamos una última pregunta donde pudieran expresar su opinión de manera escrita. En el caso del cuestionario de los profesores, formulamos una serie de cuestiones cuya respuesta pudieran desarrollar de manera escrita. Figura 5.6: Respuestas en forma de semáforo 5.4.1.1. Cuestionarios sobre la aplicación para los usuarios Las preguntas formuladas para los alumnos son: − ¾Te ha ayudado la opción de Deniciones? − ¾Te ha ayudado la opción de Palabras parecidas? − ¾Te ha ayudado la opción de Palabras distintas? − ¾Te ha ayudado la opción de Pictogramas? − ¾Te ha ayudado la opción de YouTube? − ¾Te ha ayudado la opción de Wikipedia? − ¾Te ha ayudado la opción de Resumen? − ¾Te ha ayudado la opción de Blog del cole? − ¾Te ha gustado? − ¾Te ha ayudado? − ¾Lo usarías para navegar por internet? − ¾Algo más que nos quieras decir?
56 Capítulo 6. Descripción de la aplicación 6.1.2. Blog A través de esta opción, podemos acceder al Blog del colegio Estudio 3 AFANIAS 1 , el cual se nos presentará en una ventana nueva. Incluimos el blog para el estudio en el centro con los usuarios nales, ya que aportaría ayuda a los docentes, sin embargo, esta opción es congurable. 6.1.3. Deniciones Esta opción nos ofrece las distintas acepciones de la palabra escogida por el usuario. Podemos encontrar casuísticas distintas. Por un lado, supongamos que el usuario ha buscado la palabra casa . El resultado sería el que muestra la gura 6.2 Figura 6.2: Deniciones de la palabra casa De otro modo, cabe la posibilidad de que el usuario haya escrito mal la palabra o dicha palabra no exista, por lo que el resultado será el que presenta la gura 6.3 6.1.4. Palabras parecidas Esta opción nos ofrece la posibilidad de mostrar al usuario los sinónimos de la palabra que ha seleccionado. Usamos la nomenclatura Palabras parecidas para facilitar a los usuarios su signicado. De nuevo, encontramos dos casuísticas, que el usuario haya buscado una palabra correcta o incorrecta. El resultado es el mismo que para las deniciones. 1 http://colegioestudio3.blogspot.com.es/
6.1. Barra de menú de la aplicación 57 Figura 6.3: Resultado de una palabra que no presenta deniciones 6.1.5. Palabras contrarias Esta opción nos ofrece la posibilidad de mostrar al usuario los antónimos de la palabra que ha seleccionado. Usamos la nomenclatura Palabras contrarias para facilitar a los usuarios su signicado. De nuevo, encontramos dos casuísticas, que el usuario haya buscado una palabra correcta o incorrecta. El resultado es el mismo que para las deniciones. 6.1.6. Pictogramas Por medio de esta opción, ofrecemos a los usuarios la posibilidad de ver el texto seleccionado en pictogramas. De esta manera, como vemos en la gura 6.4, mostramos los pictogramas asociados a la palabra casa . En caso de no existir un pictograma para la palabra o frase escogida, mostramos un mensaje de error. 6.1.7. Youtube A través de esta opción, podemos acceder a Youtube , abriéndose en una nueva pestaña. Cabe la posibilidad de abrir una nueva ventana de Youtube simple, es decir, sin ninguna búsqueda realizada. En el caso de que un usuario haya seleccionado algún texto, la ventana nueva se abrirá con la búsqueda de la palabra seleccionada.
58 Capítulo 6. Descripción de la aplicación Figura 6.4: Pictogramas de la palabra casa 6.1.8. Wikipedia A través de esta opción, podemos acceder a Wikipedia , abriéndose en una nueva pestaña. Cabe la posibilidad de abrir una nueva ventana de Wikipedia sin ninguna búsqueda realizada. Si el usuario ha seleccionado algún texto, la ventana nueva abrirá la Wikipedia con la búsqueda de la palabra seleccionada. 6.1.9. Resumen Gracias a esta opción el usuario podrá leer el resumen de un texto largo que le diculte su comprensión. Como mostramos en la gura 6.5, el usuario ha de seleccionar el texto que le cause problemas de comprensión y escoger la opción de Resumen . 6.1.10. Lectura en voz alta Usando esta opción, el usuario podrá escuchar en voz alta el texto que ha seleccionado o escrito en la barra de búsqueda. 6.1.11. Icono de los engranajes Como mostramos en la gura 6.6, seleccionando esta opción el usuario podrá ver todas y cada una de las búsquedas que ha realizado, así como los elementos que haya seleccionado en dicha búsqueda. Más adelante en la sección 6.3 explicaremos cómo podemos guardar los datos.
6.2. Conguración de la barra de menú de la aplicación 59 (a) Texto seleccionado que queremos resumir (b) Resumen del texto seleccionado Figura 6.5: Ejemplo usando la opción de resumen 6.2. Conguración de la barra de menú de la aplicación La barra horizontal presenta todos los servicios que nos ofrece la aplicación. Sin embargo, es posible que no todos sean de utilidad dependiendo del usuario que lo use. Por ello, implementamos una barra congurable en
60 Capítulo 6. Descripción de la aplicación Figura 6.6: Ejemplo de los datos guardados por el usuario la que un tutor del usuario podrá adaptarla acorde con sus necesidades. Supongamos que solo se precisa de los servicios Deniciones , Palabras parecidas , Youtube y Lectura en voz alta . El usuario podrá clicar en nuestro plugin, abriéndose un menú donde podrá seleccionar las opciones que desee, siendo el resultado que vemos en la gura 6.7. 6.3. Guardar los datos del usuario Otra funcionalidad que proporciona nuestra aplicación es la posibilidad de guardar los datos del usuario según las búsquedas que haya realizado. Para ello, el usuario ha de buscar las palabras que le presenten problemas. Por ejemplo, como vemos en la gura 6.8, suponemos que busca los sinónimos de árbol , selecciona la primera palabra y pulsa el botón Guardar . Además desea conocer cuáles son las deniciones de la palabra árbol y selecciona la primera acepción y pulsa el botón Guardar . Una vez realizadas las búsquedas pertinentes, el usuario podrá ver sus datos guardados pulsando en la opción de los engranajes, como explicamos la sección 6.1.11. El resultado será el de la gura 6.9, en la que podemos ver en color rojo los datos relativos a la búsqueda de las deniciones de la palabra casa con las dos acepciones que escogió el usuario y en color naranja la búsqueda del pictograma mosquito . Además, los datos guardados por el usuario se almacenan de manera persistente en el navegador. Es decir, si el usuario termina la sesión apagando el ordenador o saliendo del navegador, la próxima vez que navegue por las
6.4. Exportar los datos del usuario 61 páginas sus datos permanecerán guardados. 6.4. Exportar los datos del usuario Nuestra aplicación dispone de la posibilidad de exportar los datos que el usuario ha guardado. Resulta interesante poder tener en un chero todas las búsquedas que el usuario haya realizado, con la nalidad de repasar en casa los conceptos estudiados en clase o para saber cuáles son los términos que presentan mayor dicultad para el usuario. Para poder exportar los datos, debemos tener abierta la ventana con los datos guardados del usuario. Como vemos en la gura 6.10 debemos pulsar el botón exportar , lo que nos generará un archivo con el nombre misDatosGuardados.html donde se exportarán todos los elementos guardados del usuario (a) Escogiendo las opciones a mostrar en la barra de menú (b) Resultado de ltrar las opciones deseadas Figura 6.7: Resultado de ltrar los servicios adecuados para el usuario
62 Capítulo 6. Descripción de la aplicación con una apariencia sencilla. (a) Seleccionando los sinónimos de la palabra árbol (b) Buscando las acepciones de la palabra árbol Figura 6.8: Guardando los datos del usuario
6.4. Exportar los datos del usuario 63 Figura 6.9: Ejemplo de los datos guardados por el usuario
64 Capítulo 6. Descripción de la aplicación (a) Seleccionando la opción de exportar datos (b) Fichero html exportado con los datos guardados Figura 6.10: Guardando los datos del usuario
Capítulo 7 Arquitectura de la aplicación Este capítulo lo dedicaremos a estudiar la estructura y arquitectura de nuestra extensión para Chrome, a la que hemos dado el nombre de ReadIt. En primer lugar explicaremos a alto nivel cómo están ordenados los cheros que lo componen. De esta manera, en un segundo vistazo desarrollaremos en profundidad su contenido y funcionalidad. Además, explicaremos detalladamente como podemos hacer que nuestro proyecto sea extensible acorde a las nuevas necesidades que los usuarios puedan necesitar. 7.1. Introducción En el capítulo 4 desarrollamos en detalle cómo está formada la estructura de una extensión de Google Chrome. Dedicaremos esta sección en introducir brevemente la organización de los cheros que componen el diseño de nuestro plugin. Como vemos en la gura 7.1, podemos distinguir en la capa más alta: − El chero de conguración manifest.json . − El archivo popup.html , que representa la acción del navegador de nuestra extensión. − El chero style.css , que se corresponde con uno de los scripts de contenido , en el que guardamos los estilos que deseamos dar a la parte visual de nuestra extensión. − El archivo background.js , que representa el script de fondo de la aplicación. 65
72 Capítulo 7. Arquitectura de la aplicación − textModal.js: Este es el chero encargado de generar el modal de texto correspondiente a las opciones deniciones , sinónimos y antónimos . En la ventana emergente nos encontraremos con la posibilidad de seleccionar los elementos. Por ejemplo, si llamamos al servicio de de- niciones, el usuario podrá seleccionar las acepciones que desee guardar pulsando el botón Guardar . − imgModal.js: Este chero genera el modal correspondiente a la opción de los pictogramas . En la ventana emergente la aplicación mostrará una serie de imágenes haciendo referencia a la palabra escogida por el usuario, quién tendrá la posibilidad de guardar su búsqueda pulsando el botón Guardar . − summaryModal.js: Este chero genera el modal relacionado con la opción de resumen . En la ventana emergente la aplicación proporcionará al usuario el resumen del texto escogido por el usuario, quién podrá escoger guardarlo pulsando el botón Guardar . − saveChangesModal.js: Este chero genera el modal tras pulsar en la opción de los engranajes en la barra de menú. En la ventana emergente el usuario podrá ver todas sus búsquedas guardadas. Si lo desea, el usuario o el tutor podrán escoger la opción Exportar para descargar en un chero la información guardada. − errorModal.js: Este chero genera el modal tras pulsar la opción de deniciones , sinónimos , antónimos , pictogramas o resumen en el caso de que el usuario no haya seleccionado o buscado ninguna palabra o texto, mostrando al usuario el correspondiente mensaje informativo. − noResultsServiceModal.js: Este chero genera el modal tras pulsar la opción de deniciones , sinónimos , antónimos o pictogramas en caso de que la palabra buscada por el usuario no exista o el servicio correspondiente no ofrezca resultados, mostrando al usuario el correspondiente mensaje informativo. 7.2.6. Storage En esta carpeta almacenaremos los cheros relacionados con la gestión de los datos guardados por el usuario. En ella podemos encontrar dos cheros: − exportData.js: Se trata de un chero JavaScript encargado de exportar las búsquedas que el usuario ha realizado generando un archivo .html que el usuario se descargará. Para ello, obtenemos los datos guardados por el usuario a través de la función chrome.storage.sync.get proporcionada por la API de Chrome. Posteriormente, almacenaremos
7.3. Instalación del plugin 73 los datos guardados en un string con formato HTML. Finalmente, generaremos un chero con el nombre misDatosGuardados.html que contendrá las búsquedas guardadas del usuario, con la fecha y la hora. − saveChanges.js: Se trata de un chero JavaScript encargado de guardar los datos de las búsquedas realizadas por el usuario, haciendo uso de las funciones chrome.storage.sync.get y chrome.storage.sync.set que nos proporciona la API de Chrome. En primer lugar, guardaremos los datos que el usuario desea guardar en un array. Posteriormente, haremos uso de chrome.storage.sync.get para obtener datos guardados por el usuario anteriormente. En caso de ser la primera vez que el usuario guarda los datos, haremos uso chrome.storage.sync.set guardando los datos del array. Si el usuario ya tenía datos guardados, concatenaremos los datos de entrada almacenados en el array con los datos ya guardados, evitando sobreescribir los datos. Además, los datos guardados por el usuario son persistentes, es decir, los datos permanecerán guardados aunque el usuario haya cerrado el navegador. 7.3. Instalación del plugin El primer paso consiste en descargar la carpeta que contiene la funcionalidad de la extensión, ubicada en el siguiente enlace: https://github.com/NILGroup/TFG-1718-AccesibilidadWeb . Una vez descargada y descomprimida la carpeta es momento de cargar nuestra aplicación en local. Para ello, entramos en Google Chrome y en la parte de arriba a la derecha del navegador, pulsamos los tres puntos , seleccionamos la opción Más herramientas seguido de Extensiones , como se muestra en la gura 7.2. Una vez situados, es preciso habilitar la opción Modo desarrollador que el navegador de Google Chrome nos ofrece, que se encuentra en la parte superior derecha de la pantalla. Tras habilitar dicha opción, se mostrarán tres nuevas opciones como mostramos en la gura 7.3, de las cuales debemos seleccionar la opción Cargar descomprimida . A continuación, se nos abrirá un popup donde debemos añadir la ruta en la que se encuentra nuestra carpeta descargada. Añadimos la ruta y pulsamos Aceptar . Aparecerá en la pantalla nuestra aplicación cargada desde local en el ordenador del usuario.
74 Capítulo 7. Arquitectura de la aplicación Figura 7.2: Ruta para acceder a la pestaña Extensiones del navegador Figura 7.3: Opciones que aparecen tras habilitar el Modo desarrollador 7.4. Extensibilidad del plugin Una vez explicado el contenido y la funcionalidad de nuestra extensión para Google Chrome, vamos a continuar explicando cómo un programador puede añadir un nuevo servicio que precise siguiendo unos pasos. De esta manera, nuestra aplicación será extensible para aquellas personas que sigan estos pasos. Es importante destacar que sus cambios solo serán visibles desde local, es decir, desde el lugar donde carguen la extensión. Una vez cargada nuestra aplicación, debemos abrir en el entorno que deseemos el proyecto, Atom por ejemplo. Una vez abierto, localizamos los cheros que se deben modicar para añadir el nuevo servicio: − creatingServicesMenu.js
7.4. Extensibilidad del plugin 75 − toolbar.html − option-selected.js El primer chero que modicaremos será creatingServicesMenu.js , que encontraremos en la ruta readIt/js/selectionServicesMenu/. En él, podemos observar la variable features , que contiene todos los servicios de los que dispone el plugin. El desarrollador deberá añadir ahí el par [Clave, Valor] del servicio que quiere, donde la clave se corresponde con el identicador con el que se guardará el servicio en la barra de herramientas y valor representa el nombre con el que se mostrará el servicio en nuestra barra. Como mostramos en el siguiente ejemplo, el desarrollador deberá añadir el correspondiente [clave, valor] de su servicio descritos en la línea 10. 1 var features = { 2 "Definitions":"Definiciones", 3 "Synonyms":"Palabras parecidas", 4 "Antonyms":"Palabras contrarias", 5 "Youtube":"Youtube", 6 "Wikipedia":"Wikipedia", 7 "Pictograms":"Pictogramas", 8 "Summary":"Resumen", 9 "OutLoudReading":"Lectura en voz alta", 10 "Clave":"Valor" 11 }; El segundo archivo a retocar será toolbar.html , que encontramos en la ruta readIt/. El programador deberá añadir una linea de código para que su nuevo servicio se muestre en la barra de herramientas. Como mostramos a continuación, el desarrollador deberá añadir su [clave, valor] como se muestra en la línea 12 del ejemplo. 1 <ul> 2 <li><input id="searchText" type="text" placeholder="Buscar..." ></li> 3 <li id="Blog"><a href="#">Blog </a></li> 4 <li data-toggle="modal" data -target="#exampleModalLong" id=" Definitions" class="hidableItems"><a href="#">Definiciones </a></li> 5 <li data-toggle="modal" data -target="#exampleModalLong" id=" Synonyms" class="hidableItems"><a href="#">Palabras parecidas </a></li> 6 <li data-toggle="modal" data -target="#exampleModalLong" id=" Antonyms" class="hidableItems"><a href="#">Palabras contrarias </a></li> 7 <li data-toggle="modal" data -target="#exampleModalLong" id=" Pictograms" class="hidableItems"><a href="#">Pictogramas</a ></li> 8 <li id="Youtube" class="hidableItems"><a href="#">Youtube </a></ li>
76 Capítulo 7. Arquitectura de la aplicación 9 <li id="Wikipedia" class="hidableItems"><a href="#">Wikipedia</ a></li> 10 <li data-toggle="modal" data -target="#exampleModalLong" id=" Summary" class="hidableItems"><a href="#">Resumen </a></li> 11 <li id="OutLoudReading" class="hidableItems"><a href="#"> Lectura en voz alta </a></li> 12 <li id="Clave" class="hidableItems"><a href="#">Valor </a></li> 13 <li data-toggle="modal" data -target="#exampleModalLong" id=" getChangesId" style="float:right"><a href="#"><i class="fa fa-cogs"></i></a> </li> 14 </ul> El último chero que se debe modicar será option-selected.js , situado en la ruta readIt/js/services. En este chero se encuentran los pasos más importantes, ya que denirán el funcionamiento de su servicio. Para ello, es importante que el desarrollador disponga de: − Un servicio que a través de una llamada GET o POST sea capaz de obtener la información deseada así como el formato en la que la recibe. − Debe soportar https , ya que sino su servicio solo funcionará en páginas http . En primer lugar, el desarrollador deberá añadir la funcionalidad para que la aplicación reconozca cuando el usuario ha escogido su opción. Para ello, el desarrollador deberá añadir el código relativo a las líneas 9-17 en el siguiente ejemplo: 1 //Llamar al servicio de sinónimos 2 $("#Synonyms").click(function(){ 3 if (selectionableText == ""){ 4 getSearchText(); 5 } 6 var url = 'https://sesat.fdi.ucm.es/tfgapi/servicios/rest/ sinonimos/json/' + userText; 7 var serviceCalled = this.textContent; 8 callingGetWebService(url, userText , serviceCalled); 9 }); 10 //Llamar al servicio nuevo del desarrollador 11 $("#Clave").click(function(){ 12 if (selectionableText == ""){ 13 getSearchText(); 14 } 15 var url = url_servicioNuevo; 16 var serviceCalled = this.textContent; 17 callingDeveloperServiceWebService(url, userText, serviceCalled); 18 }); Destacamos:
7.4. Extensibilidad del plugin 77 − Línea 11. Con jQuery, comprobamos si el usuario ha escogido nuestro servicio. − Líneas 12-14. Comprobamos que el usuario haya seleccionado o buscado alguna palabra o texto. − Línea 15. Guardamos en la variable url la url del nuevo servicio que el desarrollador desea añadir. En caso de que necesite conocer el texto seleccionado por el usuario, lo encontrará en la variable global userText . − Línea 16. Almacenamos en la variable serviceCalled el nombre del nuevo servicio que el desarrollador quiere añadir. Esto servirá para guardar el título en el modal donde se mostrarán los datos generados por el nuevo servicio. − Línea 17. Llamamos a la función callingDeveloperServiceWebService , que el desarrollador deberá implementar para hacer la llamada a su servicio. Podrá escoger el nombre y los parámetros que sean necesarios. En la función callingDeveloperServiceWebService nombrada anteriormente, el desarrollador ha de implementar una función que parsee los datos generados por su servicio y llamar al modal correspondiente para mostrar los resultados. En caso de que ninguno de los modales ofrecidos por la aplicación situados en la ruta readIt/js/modals/ se adapte a la forma en la que el desarrollador quiere mostrar sus datos, deberá crear un nuevo chero, llamado por ejemplo developerModal.js en la ruta anteriormente nombrada que contendrá la función openDeveloperModal(...) . A continuación, mostramos un ejemplo del modal que muestra los resultados de los servicios deniciones , sinónimos y antónimos para explicar la estructura que ha de seguir: 1 function openDeveloperModal(array , serviceCalled , selectedText) { 2 jQuery('#modalTitleId').empty(); 3 jQuery('#modalTitleId').append(serviceCalled + ': ' + selectedText); 4 jQuery('#modalBodyId').empty(); 5 6 jQuery.each(array , function (index , value) { 7 jQuery('#modalBodyId').append('<label ><input type="checkbox" class="optionsSelected" id="' + index + '" value="' + value +'">' + value); 8 jQuery('#modalBodyId').append('</label ><br>'); 9 }); 10 11 jQuery('#saveChangesId').show();
78 Capítulo 7. Arquitectura de la aplicación 12 jQuery('#exportChangesId').hide(); 13 } Donde destacamos: − Línea 1. El desarrollador puede añadir los atributos que necesite en su función. En el ejemplo, la variable array guarda, por ejemplo, las acepciones de la palabra buscada por el usuario en caso de haber solicitado las deniciones . La variable serviceCalled indica el nombre del servicio que el usuario ha solicitado. La variable selectedText se corresponde con el texto que el usuario ha seleccionada. − Líneas 2 y 3. Se corresponden con el título que mostrará el modal. El desarrollador tiene libertad para generar ese formato u otro que desee para el título. En el ejemplo, mostraría el nombre del servicio solicitado seguido del texto seleccionado por el usuario. − Línea 4. El desarrollador debe escribir esta línea, ya que sirve para limpiar el cuerpo del modal y dejarlo preparado para los datos nuevos que introducirá. − Líneas 6-9. Se corresponden con la manera en la que se muestran los datos obtenidos del nuevo servicio. El desarrollador dispone de libertad para generar los datos de la manera que desee. − Línea 11. El desarrollador podrá escribir esta línea tal cual viene en el ejemplo en caso de querer permitir al usuario guardar su búsqueda. En caso contrario, deberá escribir .hide() en lugar de .show() − Línea 12. El desarrollador debe escribir esta línea, ya que no queremos mostrar el botón de exportar datos en este modal. Siguiendo estas pautas, el desarrollador podrá incluir en la aplicación todos los servicios que precise, pudiéndolo adaptar a las necesidades de los usuarios.
Capítulo 8 Conclusiones y trabajo futuro Una vez nalizado este proyecto llegamos a una serie de conclusiones y recapitulamos el trabajo que esperamos desarrollar en un futuro. 8.1. Conclusiones Al inicio del proyecto realizamos una etapa de aprendizaje acerca de las distintas necesidades que pueden presentar determinadas personas navegando en la web. Aprendimos que existen distintos colectivos, por ejemplo, personas que presentan discapacidad o avanzada edad, entre otros, que se enfrentan a una barrera que les diculta el acceso a internet, encontrándose con problemas para leer, escribir o entender textos a la hora de navegar por la web. Tras este proceso de aprendizaje descubrimos que las capacidades de comprensión lectora varían de unas personas a otras, por lo que comprendimos la necesidad y la importancia de desarrollar nuestra aplicación decidiendo cuáles serían las funcionalidades que más ayuda proporcionaría a dichos colectivos. Ante esta problemática, contamos con la ayuda de los profesionales del colegio Estudio 3 AFANIAS para escoger las funcionalidades que más se adaptaran a los usuarios. Para desarrollar nuestra aplicación, decidimos implementar una extensión para Google Chrome que, a través de servicios externos, ofrece distintas opciones que ayudan al usuario a comprender el texto al que se enfrenta. Además, ReadIt presenta grandes ventajas: − Permite congurar a los usuarios los servicios que necesiten, pudiendo descartar aquellos que no le ofrezcan ningún tipo de utilidad. − Al tratarse de una extensión, está disponible para todos los usuarios que quieran usarla. 79
80 Capítulo 8. Conclusiones y trabajo futuro − En caso de necesitarlo, se pueden añadir nuevos servicios que no contenga ReadIt. Un desarrollador podrá incluir en la aplicación un servicio nuevo que los usuarios precisen. Tras evaluar nuestra aplicación en el colegio Estudio 3 AFANIAS con profesores y diez alumnos del colegio, comprobamos que ReadIt no solo facilita la comprensión de los textos que ofrece internet, sino que también impulsa y anima a los usuarios a mejorar en su aprendizaje e independencia. Hemos querido denir ReadIt como una aplicación que se congura como apoyo o ayuda para colectivos de personas que presentan algún tipo de dicultad a la hora de comprender el lenguaje escrito. 8.2. Trabajo futuro ReadIt ofrece un amplio abanico de posibilidades para seguir ampliando sus funcionalidades: − Mejorar algunos de los servicios que ofrece ReadIt, ya que algunos de ellos no soportan las tildes o caracteres especiales. Además, el servicio de antónimos rara vez ofrece resultados. Otro ejemplo sería mostrar las acepciones de las deniciones de manera más sencilla. − Ofrecer más servicios que puedan ser de utilidad para los usuarios. Aumentar el abanico de posibilidades que ofrece ReadIt lo haría más completo y útil, ya que se podría abarcar un mayor número de problemas que presenten los usuarios a la hora de comprender el texto. − Durante la evaluación de ReadIt con los alumnos del colegio Estudio 3 AFANIAS, uno de los profesionales nos explicó que realizar un servicio que permitiera al usuario transmitir por voz y que la aplicación recogiera los datos resultaría interesante. − Durante esta evaluación, descubrimos que en el colegio algunos de los enlaces con los que estudian son PDF. Una propuesta interesante sería poder ofrecer los servicios que presenta nuestra aplicación en los documentos PDF. − Una vez que el usuario busca, por ejemplo, el resumen de un texto, resultaría interesante que pudiera seleccionar las palabras que le presenten dicultades en su lectura. Además, tras comprobar la ayuda que proporcionó nuestra aplicación en el colegio Estudio 3 AFANIAS, queremos que ReadIt llegue a más colegios
8.2. Trabajo futuro 81 u otros centros para poder así eliminar en medida de lo posible esta barrera a la que se enfrentan los usuarios. Para ello, se publicará en la Web store de Chrome.