no solo usabilidad: revista sobre personas, diseño y tecnología
menú
menú9 de Enero de 2015
Alcaraz Martínez, Rubén
Ribera Turró, Mireia
Resumen: Los mapas digitales y las aplicaciones basadas en la localización son unas de las tecnologías que más han avanzado en los últimos años. La aparición de diferentes APIs y servicios para la creación o integración de estas tecnologías en páginas web o aplicaciones, ha provocado una proliferación de productos basados en ellas. La accesibilidad de estos productos, enmarcados dentro de las denominadas Rich Internet Applications, supone un nuevo reto para los desarrolladores web. El objetivo de este artículo es el de proponer soluciones a los problemas de accesibilidad derivados del uso de estas tecnologías a través de un prototipo funcional.
Las personas ciegas son aquellas con una limitación muy elevada de la función visual (menos de un 5% de resto de visión). La pérdida de la percepción visual representa una reducción drástica en la autonomía dificultando tareas cotidianas (desplazamientos, acceso a la información...), o su inclusión y participación en la sociedad (educación, trabajo, ocio...). Según la ONCE (2014), el 80% de la información necesaria para nuestra vida cotidiana implica el órgano de la visión. Esto se debe a la predominancia de la información de carácter visual en la ejecución de la mayoría de las habilidades que poseemos, de los conocimientos que adquirimos y de las actividades que desarrollamos. El déficit visual es compensado por estas personas a través de patrones auditivos, olfativos, hápticos y térmicos que, a diferencia del resto de personas, ocupan un lugar predominante en su experiencia personal.
El usuario ciego accede al contenido web de una manera muy diferente a como lo hacen el resto de usuarios. Mientras que las personas que no tienen el órgano de la vista afectado por ninguna discapacidad exploran y toman decisiones en base a la organización visual del contenido, el ciego que accede mediante un lector de pantalla no es capaz de analizar la totalidad de la página con tanta inmediatez. Frente a contenidos organizados jerárquicamente o al uso de zonas destacadas visualmente para atraer la atención hacia los elementos más importantes de la página, el contenido al que acceden las personas con discapacidades visuales es lineal y basado en su totalidad en texto. El posicionamiento de los elementos en la página o el diseño gráfico, ni ayudan, ni dificultan de manera inherente el acceso de este colectivo a la información que contiene el sitio web. Simplemente resultan irrelevantes. Son otros factores, como el orden por programación, una sintaxis correcta, el uso de la semántica o la posibilidad de saltar bloques de información entre otros factores, los que realmente suponen una óptima experiencia de usuario para este colectivo.
Por lo que respecta a las ayudas técnicas, destacan el uso exclusivo del teclado frente al habitual binomio teclado/ratón y los lectores de pantalla. En menor medida, encontramos usuarios de líneas y anotadores braille.
El teclado estándar es para las personas ciegas el principal periférico de entrada de datos y medio de navegación en la web. En el contexto actual, pocas páginas resultan accesibles por completo mediante una interfaz de teclado. Esto se debe a diferentes razones, como por ejemplo a la dependencia del ratón para ejecutar determinados eventos de JavaScript o a la imposibilidad de acceder a determinados elementos de la página mediante el teclado. Es decir, elementos que jamás reciben el foco del teclado y que por tanto necesitan ser seleccionados con el ratón para poder interactuar con ellos. Recordemos que para una persona ciega los periféricos como el ratón o los joysticks que requieren de la coordinación de mano y vista representan una dificultad casi insuperable. Todos aquellos elementos que no reciban el foco del teclado quedarán fuera del alcance de este colectivo. De la misma manera, las funcionalidades del contenido que dependan del uso del ratón, no podrán ser activadas.
El lector de pantalla es un software que identifica e interpreta el contenido textual que se muestra en pantalla para representarlo posteriormente mediante un sintetizador de texto a voz (TTS, o text to speech) o una salida braille. Generalmente ofrecen atajos de teclado (keyboard shortcuts) y otras funcionalidades que permiten al usuario ciego acceder al contenido de las páginas web de forma ágil. Los lectores de pantalla permiten a sus usuarios navegar a través del contenido web de diferentes maneras. Según la situación o el tipo de web, es posible indicar al lector de pantalla que lea todo el contenido disponible, que vaya leyendo línea por línea, o incluso marcar el ritmo de lectura mediante alguna combinación de teclas, con la que es posible navegar entre elementos (enlaces, encabezados, listas...). Aunque suponen una ayuda indispensable para las personas ciegas, los lectores de pantalla presentan algunas limitaciones. Entre éstas destacan el acceso a las imágenes, así como al resto de contenidos no textuales, su capacidad para interpretar la organización de los contenidos en la página cuando depende del diseño visual, o el acceso a la información contenida en tablas complejas entre otras. Se trata, en su totalidad, de limitaciones que pueden ser compensadas siguiendo recomendaciones y estándares, como por ejemplo el uso del atributo "alt" para describir el contenido de las imágenes, pero que en ningún caso sustituyen la experiencia de ver la imagen.
El usuario que accede mediante un lector de pantalla escucha en primer lugar el título de la página y, a continuación, el resto de los elementos presentes en el nodo según su orden de aparición en el código fuente. Los programas más avanzados permiten a los usuarios saber dónde empiezan los diferentes elementos (listas, tablas, …), navegar por las tablas, acceder a los enlaces presentes en el contenido por orden alfabético, etc. De manera que la navegación, aunque lineal, presenta gracias a estas aplicaciones diferentes posibilidades de desplazamiento por el contenido. Una condición sine qua non para que los usuarios sean capaces de explotar al máximo las posibilidades de estas aplicaciones es la correcta utilización de los diferentes elementos, etiquetas y atributos de los lenguajes de marcas. Una característica común en todos los lectores de pantalla es su complejidad de uso, mayor cuantas más funcionalidades presenta el software. La mayoría de usuarios de lectores de pantalla sólo utilizan una pequeña parte de las funcionalidades, combinaciones de teclas o posibilidades que ofrecen estos programas.
Resulta complicado comprender lo que supone acceder al contenido web a través de un lector de pantalla si no se ha experimentado nunca. Sólo utilizando técnicas de screening, para simular las limitaciones derivadas de la ceguera, podemos comprender el alcance de esta discapacidad. Experimentar esa sensación nos advierte de lo tediosa que puede llegar a ser la consulta de un web que nos obliga a pasar página tras página por enormes menús de navegación que no ofrecen la posibilidad de ser saltados, de lo difícil que es en algunos sitios web diferenciar entre contenido y publicidad o de la gran cantidad de información y funcionalidades que pueden llegar a pasar completamente desapercibidas para este colectivo.
Los usuarios ciegos se caracterizan por ser el colectivo que mayor cantidad de estrategias diferentes utilizan al navegan por la web. Power, et al. (2013) destacan como estrategias preferentes la exploración y el descubrimiento, definidos por los autores como la extracción del significado o contexto de una pieza de contenido o de la funcionalidad de un componente interactivo y el intento de determinar la estructura general de una página web con el objetivo de localizar las secciones relevantes, respectivamente.
En líneas generales, saltan rápidamente y de manera secuencial a través de los contenidos de la página, escuchando sólo las primeras palabras de cada encabezado o etiqueta. En menor medida, dejan de lado la secuencia propia del contenido para navegar a través de los enlaces y encabezados detectados por el lector de pantalla, recorriendo la página de esta manera, de una forma más estructurada (Theofanos, Redish; 2003).
El uso intensivo de enlaces, de zonas de contenido diferenciadas y de encabezados tiene, en el caso de nuestra audiencia, importantes implicaciones en la creación de un sitio web o aplicación accesible. El uso mayoritario de las estrategias de exploración y de descubrimiento denota la necesidad que presentan estos usuarios de construir modelos mentales de cada una de las secciones de una página para, a continuación, integrarlos en un modelo global que define la estructura general de esa página. A pesar de que los lectores de pantalla apoyan, en cierta medida, ambas estrategias (exploración y descubrimiento), si la estructura de las páginas es pobre o incoherente, también lo será el resultado del análisis realizado por el usuario, haciendo total o parcialmente incomprensible el contenido para él.
En los últimos años hemos visto cómo todo tipo de mapas digitales iban adquiriendo cada vez mayor protagonismo en la red. Un gran número de ayuntamientos han creado sus propios callejeros con información de sus municipios, equipamientos y servicios. Muchas startups tienen en los mapas digitales y en los servicios basados en la localización su principal estrategia. Este es el caso de empresas de búsqueda de alojamientos turísticos, de transporte público, negocios locales, rutas museísticas y un largo etcétera. En este sentido, conviene destacar que muchos de estos sitios web, especialmente aquellos propiedad de la administración pública o que han sido subvencionados por ella, se encuentran obligados por ley a cumplir el nivel de accesibilidad establecido por el Real Decreto Legislativo 1/2013, de 29 de noviembre. Una ley que establece como grado de accesibilidad aplicable a los portales web de las administraciones públicas el nivel mínimo obligatorio de cumplimiento de las prioridades 1 y 2 de la Norma UNE 139803:2004: Aplicaciones informáticas para personas con discapacidad: requisitos de accesibilidad para contenidos en la Web, equivalentes al nivel doble A de las WCAG 2.0.
Los servicios basados en la localización (Location Based Services o LBS) son generalmente aplicaciones que ofrecen servicios personalizados en tiempo real al usuario basándose en la localización geográfica de su dispositivo. El éxito y la aparición de una gran cantidad de LBS no es casual, sino que, como manifiestan diversos autores (Asadi et al.; 2007), las búsquedas basadas en la localización son una de la funcionalidades que más expectativas despiertan entre los usuarios de Internet, especialmente entre los usuarios de dispositivos móviles.
La preponderancia de este tipo de aplicaciones y su uso en servicios de interés general y públicos implica la necesidad de diseñarlas o adaptarlas de manera que resulten accesibles para todo el mundo.
Las rich Internet applications, o RIA (en español aplicaciones de Internet enriquecidas) son aplicaciones web que presentan la mayoría de las características de las aplicaciones tradicionales de escritorio, pero pensadas para un medio distinto, generalmente un navegador web. Frente a las aplicaciones web tradicionales, en las que el usuario realiza una acción y debe esperar la respuesta correspondiente que llegará después de recargar el contenido, las RIA responden de manera inmediata a las acciones del usuario. Una de las tecnologías responsables de que esto pase es AJAX (Asynchronous JavaScript And XML), una técnica de desarrollo de RIA, gracias a la cual las aplicaciones se ejecutan en el cliente (el navegador) mientras se mantiene una comunicación asíncrona con el servidor de origen en segundo plano. De esta forma, los usuarios y la misma aplicación pueden realizar cambios en las páginas sin necesidad de recargar el contenido, mejorando así la interactividad y la velocidad de la aplicación. AJAX no es algo nuevo, sino que es una combinación de tecnologías ya existentes como HTML y CSS para el diseño de la información, el objeto XMLHttpRequest (XHR) para intercambiar datos de forma asíncrona con el servidor de origen, el Document Object Model (DOM) al que se accede mediante un lenguaje de programación (generalmente JavaScript) para mostrar e interactuar dinámicamente con la información que se presenta al usuario y XML o JSON como formatos preferentes para la transferencia de datos solicitados al servidor.
Las RIA plantean desafíos adicionales de accesibilidad a los diseñadores. Para las personas ciegas y para aquellos usuarios que sufren determinadas discapacidades cognitivas, usuarios típicos de los lectores de pantalla, cuando el contenido de una página web cambia como respuesta a sus acciones, al tiempo o a determinadas actualizaciones basadas en eventos, es posible que ese nuevo contenido pase desapercibido para ellos, siendo totalmente inaccesible. Los lectores de pantalla normalmente leen de forma lineal. En el momento en que se produce un cambio en la interfaz, el usuario de un lector de pantalla puede no darse cuenta del cambio y lo más probable es que ese nuevo contenido pase desapercibido y no se lea; o por el contrario que perciban el cambio como una nueva página y vuelvan a leer todo su contenido. La solución para que las interfaces dinámicas de las aplicaciones web enriquecidas sean accesibles pasa por alertar al usuario de los cambios acontecidos y proporcionar acceso directo a ese nuevo contenido, especificando la prioridad o importancia según el caso. Dos técnicas que se pueden implementar gracias a WAI-ARIA.
WAI-ARIA (WAI - Accessible Rich Internet Applications) es una especificación del W3C que se puede utilizar para mejorar la accesibilidad de los contenidos y aplicaciones web enriquecidas, gracias a que permite indicar la función de un elemento (por ejemplo, barra de deslizamiento), su estado (por ejemplo, activado o desactivado) y enriquecer su significado.
Entre las plataformas disponibles en el mercado para la creación de mapas digitales y servicios basados en la localización, actualmente destacan tres: Google Maps, Bing Maps y OpenStreetMaps.
Google Maps, además de ofrecer el conocido servicio homónimo a partir de un servidor de aplicaciones de mapas web desplazables (slippy map), liberó en 2005 su API basada en AJAX y JavaScript, permitiendo a terceros desarrolladores crear nuevos productos basados o incorporando parte de sus servicios. El uso de la API de Google Maps es gratuito, aunque presenta ciertos límites de uso “razonables”, excedidos los cuales, se debe adquirir una licencia de uso. Se trata, sin duda, de la más potente y actualizada plataforma de las tres que hemos destacado anteriormente. La última actualización de la plataforma data de finales de 2013, mucho más reciente que la del resto de alternativas. También destaca sobre el resto por su excelente servicio de obtención de rutas, menos desarrollado y con menos cobertura en el caso de OpenStreetMaps y Bing Maps respectivamente, así como por la existencia de otras bibliotecas, APIs o servicios ofrecidos que podemos combinar con Google Maps. Este es el caso de las APIs de Google Places, la de autocompletado de búsquedas, la de mapas estáticos, etc. Entre los servicios o recursos que ofrece, encontramos además de la posibilidad de utilizar su servicio de mapas digitales, el servicio de cálculo de rutas a pie, en vehículo privado, en transporte público o en bicicleta, el de geocodificación inversa encargado de traducir unas coordenadas conocidas a una dirección interpretable para las personas o las imágenes a pie de calle (Google Street View), entre otros.
El objetivo del artículo es el de explorar las posibilidades ofrecidas por las diferentes plataformas de cartografía digital, así como de otras herramientas y estándares actuales de la Web, para crear una aplicación accesible para personas ciegas que ofrezca servicios relacionados con información de carácter geográfico.
Aunque se trata de un trabajo esencialmente exploratorio, también se han querido ofrecer soluciones prácticas a los problemas de accesibilidad encontrados en las tecnologías involucradas, mediante un primer prototipo y la explicación de estas soluciones.
Este artículo tiene su origen en el marco de un proyecto final para el máster en Gestión de Contenidos Digitales de la Universidad de Barcelona y la Universidad Pompeu Fabra (Alcaraz; 2014).
Durante la primera fase del proyecto se evaluaron las diferentes plataformas para la creación de mapas digitales y servicios basados en la localización comentadas anteriormente, así como diferentes estándares como WAI-ARIA, que se antojaban necesarios para mejorar la accesibilidad del resultado final. Paralelamente, se procedió a la identificación de aquellas funcionalidades que podrían ser útiles para el usuario objetivo de este proyecto. Entre estas destacan:
También se realizó una primera validación de la accesibilidad de diferentes implementaciones de terceros, en vistas a identificar problemas derivados del uso de estas tecnologías. Entre los principales problemas detectados destacan:
Finalmente, se buscaron soluciones de terceros que, bien a través de algunas bibliotecas de JavaScript, bien a través de desarrollos propios, ya habían encontrado soluciones a algunos de los problemas de accesibilidad descritos. En este sentido, destaca un mapa creado por Vision Australia a partir de la API de Google Maps, en el que es posible acceder a los controles internos a través del teclado, las recomendaciones de Lauke (2008) en el mismo sentido o las de carácter general que promueve The Pennsylvania State University (2014). En nuestro territorio destaca el mapa disponible en el portal de Discapnet.
Los primeros modelos, así como el prototipo final se desarrollaron a partir de la versión 3 de la API de Google Maps. Además, se utilizó la biblioteca JQuery para facilitar las tareas de programación de la aplicación en JavaScript. El uso de estos dos productos se fundamenta en sus grandes posibilidades, escalabilidad y gran nivel de adopción entre los desarrolladores.
Entre las principales características y funcionalidades del prototipo encontramos todas aquellas que fueron identificadas en la fase de evaluación. Para su implementación se utilizó, además de la API de Google Maps que incluye un servicio de rutas o el de geocodificación inversa, la API de Geolocalización de HTML5 y la API de Google Places, para permitir al usuario realizar búsquedas de lugares de interés e implementar el servicio de autocompletado en las búsquedas.
Mediante la técnica del screening, se simuló el uso del prototipo por parte de usuarios ciegos. Para ello se intentaron realizar diferentes tareas en el prototipo con el monitor apagado y utilizando los dos principales lectores de pantalla del mercado, Jaws y NVDA y la extensión de navegador ChromeVox.
Como resultado se detectaron diferentes errores que fueron corregidos antes de realizar un test con un usuario real.
Una vez corregidos los errores detectados en el screening se realizó un test con un usuario ciego experto en el uso de lectores de pantalla y con amplia experiencia en el uso de Internet y de diferentes servicios de rutas.
Durante la sesión se propusieron diferentes tareas al usuario para que las realizase con distintos prototipos preparados para la ocasión. El conjunto de tareas propuestas fueron:
El usuario fue capaz de utilizar tanto los controles externos creados con elementos <button>, como los elementos internos modificados mediante JavaScript para recibir el foco. Es importante destacar que las acciones que permiten cambiar el tipo de mapa (satélite, callejero, híbrido, etc.), mover su centro o aumentar o disminuir el zoom, no son demasiado útiles para el usuario ciego si no tienen asociadas determinadas respuestas o funcionalidades como podría ser, por ejemplo, la actualización de los puntos de interés según el centro del mapa. El usuario no fue capaz, en cambio, de diferenciar las dos áreas de la interfaz (zona de botones y mapa). A partir de esta observación se diseñó la estructuración de la página en dos áreas diferenciadas mediante encabezados.
Una de las principales dudas con respecto a la búsqueda de lugares era la capacidad del lector de pantalla para acceder a la información que tradicionalmente se asocia a cada uno de los marcadores que ofrecen estos sistemas en forma de ventana emergente al pulsar sobre ellos. Evidentemente, el usuario no puede acceder a ellos de la manera tradicional, es decir, pulsando sobre el marcador para abrir la ventana emergente, al no ser capaz de ejecutar eventos de ratón. Como solución se preparó una interfaz que permitía activar la información mediante el teclado. El resultado fue positivo, permitiendo al usuario tanto abrir la ventana emergente, como acceder a su contenido mediante el lector de pantalla.
Figura 1. Interfaz del prototipo.
En referencia al servicio de rutas, las funciones de autocompletado en las búsquedas realizadas fueron muy bien valoradas por el usuario. Se trata de una funcionalidad que devuelve dinámicamente una lista de opciones de búsqueda que concuerdan con los términos que se van introduciendo en la ecuación de búsqueda. Esto permite al usuario evitar errores de tecleado, así como conocer la forma exacta con la que consta una dirección o lugar en el índice del sistema.
Figura 2. Detalle del servicio de autocompletado de la API de Google Places
El usuario fue capaz de utilizar el servicio de rutas para obtener las indicaciones entre el punto de origen y el punto de destino seleccionado. No obstante, el sistema no informó al usuario del nuevo elemento generado en la interfaz con las indicaciones correspondientes. Su bagaje y experiencia con interfaces similares y en el uso de Jaws, le permitió recurrir a la función de cursor virtual para actualizar la pantalla y detectar los cambios. A pesar de que el mismo usuario confesó que en otras ocasiones Jaws sí le había anunciado ese tipo de cambios, y que quizá en este caso se debió a problemas con la versión instalada en el PC en el que se realizó el test, resultaba necesario utilizar algún tipo de tecnología que permitiera a cualquier usuario, con independencia del lector de pantalla que utilice o de su nivel de conocimientos sobre este tipo de software, comprender los cambios producidos en la interfaz. En este sentido, la solución que se implementó en siguientes versiones del prototipo fue la definición de "zonas vivas" mediante WAI-ARIA para anunciar los cambios generados por la aplicación. En posteriores pruebas, el usuario sí fue avisado por el lector de pantalla cuando la aplicación añadía nuevos contenidos a la interfaz.
Figura 3. Indicaciones para la ruta proporcionadas por la API de Google Maps.
Con respecto a las diferentes opciones disponibles como medio de transporte, el usuario valoró positivamente la posibilidad de seleccionar no sólo recorridos a pie, sino también en transporte público, o incluso en transporte privado (coche, etc.), este último para planificar por ejemplo, rutas para la familia. Estas preferencias deben ser tenidas en cuenta para los desarrolladores que a menudo obvian la función social de algunas funcionalidades creyendo que no son necesarias para ciertos tipos de usuario; como ejemplo paradigmático algunos desarrolladores creen innecesario hacer accesible para ciegos una interfaz de un cine. Las teclas de acceso rápido o atajos también fueron valoradas positivamente por el usuario, aunque no las consideró como una funcionalidad totalmente necesaria. Se trata de una funcionalidad mediante la cual podemos asociar a una tecla o conjunto de teclas una acción definida previamente. En este sentido, el usuario destacó la necesidad de que no se solaparan con otras combinaciones de teclas ya utilizadas por los lectores de pantalla o el navegador. En cambio, sí valoró positivamente la posibilidad de saltar bloques de contenido y la correcta estructuración de los contenidos en secciones.
Con respecto al orden de navegación el usuario también destacó la molestia que suponen los enlaces generados automáticamente por las APIs de estos servicios, ubicados generalmente en la parte inferior del mapa. En el caso de Google Maps estos incluyen el logotipo de Google, Informar de un error, Términos de uso y Datos del mapa. Estos enlaces no aportan ningún valor añadido a la aplicación, pero obligan al usuario a detenerse en ellos. La licencia de uso de la API de Google Maps no permite eliminarlos.
El prototipo final se encuentra formado por cinco secciones diferenciadas: detalle de ruta, detalle de ubicaciones, buscador de lugares, buscador de rutas y mapa digital. El detalle de ruta y el detalle de ubicación son regiones dinámicas y sólo aparecen en pantalla cuando el usuario realiza determinadas acciones como la búsqueda de un negocio o lugar, o solicita una ruta entre dos puntos, tras lo cual muestran la información correspondiente.
Los atributos ARIA utilizados en el prototipo para identificar las zonas vivas y definir la manera en cómo se anunciarán los cambios que se produzcan en éstas son:
WAI-ARIA también se utiliza en el prototipo para marcar el mensaje de error que aparece en pantalla cuando el usuario tiene desactivada la autorización para que la aplicación realice el seguimiento de su posición. En este caso se utiliza el rol “alertdialog” para crear la notificación, junto con los atributos ARIA comentados anteriormente y un “aria-labelledby” para dar un nombre accesible a este contenido (que se corresponde con el id de su encabezado) y un “aria-describedby” que toma como valor el id del elemento que contiene el texto con el mensaje de alerta, creando así una referencia hacia él.
Para conseguir que los controles internos del mapa sean operables a través del teclado debemos manipular el DOM. El DOM (Document Object Model) es una API definida por el W3C que permite a los desarrolladores acceder y modificar dinámicamente el contenido, estructura y estilo de los documentos HTML.
Un ejemplo de modificación del DOM son los controles del mapa. Para que estos puedan recibir el foco de teclado deben ser elementos interactivos, en cambio por defecto, los controles del mapa en Google Maps se encapsulan en elementos <div>, incapaces de recibir el foco del teclado. La modificación del DOM consistirá en crear elementos <button>, que sí pueden recibir el foco del teclado, dentro de cada <div>. Ello nos permitirá además añadir nuevos atributos al elemento como “value” (que recogerá la información del “title” de sus respectivos <div>), “id“ para identificarlo, “tabindex” para su navegación en orden, etc.
El resultado provisional del prototipo, aún sin algunas de las funcionalidades implementadas se puede consultar en: http://www.rubenalcaraz.es/tfm/prototipo/
No todos los portales requieren una aplicación tan compleja como la expuesta en los apartados anteriores. En la mayoría de casos, los sitios web que incorporan un mapa digital lo hacen simplemente para mostrar la localización y datos de contacto a sus usuarios o clientes. En estos casos, se suele utilizar un mapa incrustado que incorpora un marcador sobre el mismo, indicando la localización exacta del sitio.
La solución para muchos de esos portales podría estar en la API de Mapas estáticos de Google. Se trata de un servicio que permite insertar imágenes de Google Maps en una página web sin utilizar JavaScript ni ningún otro sistema de carga dinámica. Su uso es muy sencillo, basta con definir un URL con una serie de parámetros como el centro del mapa, el nivel del zoom, su tamaño, posición de los marcadores, etc. Este URL se debe utilizar como valor del atributo “src” de un elemento <img>. Cuando carga la página, el servicio de Google Static Maps, crea el mapa a partir de los parámetros que le hemos proporcionado, enviados a través de una solicitud HTTP estándar. A efectos prácticos, sería equivalente a tener una imagen en nuestra página que se encuentra alojada en el servidor de Google.
<img src="http://maps.googleapis.com/maps/api/staticmap?center=Barcelona&zoom=13&size=600x300&maptype=roadmap
&markers=color:red%7C41.3846241973006,2.1716089115143404&sensor=false">
Una vez insertada la imagen, debemos simplemente complementarla con un texto alternativo suficientemente descriptivo o con un pie de imagen (en HTML5 <figcaption>). Se puede observar un ejemplo con ambas alternativas a continuación:
<figure>
<img src="codigo_de_la_api" alt="texto_alternativo">
<figcaption>Pie de imagen</figcaption>
</figure>
Los mapas digitales y los servicios basados en la localización ofrecen un sinfín de posibilidades en un mundo que, a pesar de ser cada vez más global, gracias a los dispositivos móviles y a su capacidad para localizar la posición del usuario ha recuperado el interés por lo local. El transporte público, el privado, el marketing y las estrategias SoLoMo, redes sociales como Foursquare o incluso juegos como el Geocaching, son sólo algunos ejemplos del uso de estas tecnologías aplicadas a diferentes ámbitos. El éxito de estos servicios o aplicaciones puede mejorar la vida de las personas en ciertos aspectos e incluso facilitarle el acceso a determinados servicios públicos. En este sentido, para que cualquier persona pueda acceder a ellos con independencia de las discapacidades que presente, resulta imprescindible diseñarlos prestando especial atención a su accesibilidad.
Conseguir que aplicaciones complejas y dinámicas como las RIA sean totalmente accesibles es un trabajo complicado. No obstante, como hemos podido ver en este artículo, actualmente existen suficientes alternativas como para solucionar una buena parte de los problemas de accesibilidad que presentan.
Entre las principales dificultades y aspectos no solucionados destaca, más allá de algunas funcionalidades propuestas y todavía no implementadas en el prototipo, el contraste entre las indicaciones para una ruta a pie y una ruta en transporte público ofrecidas por la API de Google Maps. Mientras que la primera se antoja suficientemente clara y completa para un usuario ciego, en la segunda, se resumen demasiado las indicaciones a pie que corresponden a los tramos que el usuario ha de realizar para llegar del punto de origen a la estación correspondiente y de la estación correspondiente al punto de destino. Lo mismo pasa cuando la ruta en transporte público implica realizar uno o varios transbordos entre diferentes líneas de autobús o metro.
Figura 4. Diferencias entre las explicaciones para una misma ruta a pie y en transporte público.
Otra de las dificultades, común a la mayoría de proyectos web, tiene que ver con la variedad de navegadores y lectores de pantalla que pueden utilizar nuestros usuarios y en el mayor o menor soporte que éstos pueden ofrecer a estándares como WAI-ARIA.
Tras esta primera aproximación a la accesibilidad de los mapas digitales y, en concreto, de los generados a partir de la API de Google Maps, resulta evidente que la mejor manera de contribuir a la mejora de su accesibilidad es mediante la creación de una biblioteca o plugin que permita añadir a los proyectos creados con este servicio de Google, las diferentes funcionalidades expuestas en este artículo. No nos referimos tanto a una biblioteca al estilo de gmaps.js que permita simplificar la tarea de programación de estas aplicaciones, como a una biblioteca que junto al código de una aplicación creada mediante la API de Google Maps, permite facilitar la creación de controles accesibles, listas de marcadores que proporcionen acceso al contenido que contienen sus pop-ups, etc. Es en esta línea en la que se puede trabajar a partir de ahora.
En cualquier caso, las recomendaciones expuestas en el artículo también son válidas y dependen, asimismo, de que el diseñador piense la aplicación en el contexto de una página más amplia, bien codificada.
Alcaraz Martínez, Rubén (2014). Análisis de requerimientos y prototipado de una aplicación web accesible para personas ciegas basadas en la API de Google Maps. Proyecto final del Máster en Gestión de Contenidos Digitales. Universidad de Barcelona. Disponible en: http://hdl.handle.net/2445/58427.
Asadi, Saeid, et al. (2007). "Location-based search engines tasks and capabilities: a comparative study". Webology. Vol. 4, no. 4.
Lauke, Patrick H. (2008). “Keyboard-accessible Google Maps”. Dev.Opera. Disponible en: https://dev.opera.com/articles/keyboard-accessible-google-maps/
ONCE (2014). "Discapacidad visual: aspectos generales". En: ONCE. Disponible en: http://www.once.es/new/servicios-especializados-en-discapacidad-visual/discapacidad-visual-aspectos-generales
Power, Christopher (2013). "Navigating, discovering and exploring the web: strategies used by people with print disabilities on interactive websites". En: Kotzé, Paula, et al. (ed.). Human-Computer Interaction, INTERACT 2013. (Lecture notes in computer science; vol. 8117), p.667-684.
The Pennsylvania State University (2014). "Maps". En: AccessAbility: accessibility and usability at Penn State. The Pennsylvania State University. Disponible en: http://accessibility.psu.edu/maps
Theofanos, M.F., Redish, J. (2003). "Bridging the gap: between accessibility and usability".Interactions. Vol. 10, issue 6 (Nov./Dec. 2003), p. 36-51.
W3C (2008). "ARIA Techniques for WCAG 2.0". En: Techniques for WCAG 2.0. 2008. Disponible en: http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/aria.html
W3C (2012). "Client-side scripting techniques for WCAG 2.0". En: Techniques for WCAG 2.0. Disponible en: http://www.w3.org/TR/WCAG20-TECHS/client-side-script
Compartir:
Rubén Alcaraz Martínez es Diplomado en Biblioteconomía y Documentación por la Universidad de Barcelona y Máster Interuniversitario en Gestión de Contenidos Digitales (UB-UPF). Trabaja en la Biblioteca del Ateneu Barcelonès y en EINA, Centre Universitari de Disseny i Art. También es profesor colaborador del Máster en buscadores y el Máster en documentación digital de la Universitat Pompeu Fabra, además de miembro del Grupo de Trabajo de Software Libre del Col·legi Oficial de Bibliotecaris-Documentalistes de Catalunya.
Mireia Ribera Turró es doctora en Documentación por la Universidad de Barcelona e Ingeniera Informática por la UPC. Trabaja en la Universidad de Barcelona como docente e investigadora en el ámbito de la accesibilidad digital. Mireia Ribera ha coordinado la traducción de las normativas WCAG al catalán, ha editado las guías de contenido digital accesible para documentos ofimáticos y para vídeo y realiza un trabajo de divulgación de la accesibilidad digital para público no especializado.
Citación recomendada:
Alcaraz Martínez, Rubén; Ribera Turró, Mireia (2015). Mapas digitales y aplicaciones basadas en la localización: mejoras en su accesibilidad para las personas ciegas. En: No Solo Usabilidad, nš 14, 2015. <nosolousabilidad.com>. ISSN 1886-8592
No Solo Usabilidad - ISSN 1886-8592. Todos los derechos reservados, 2003-2023
email: info (arroba) nosolousabilidad.com
