Tag : accesibilidad

post image

¿Publicas fotos, textos y videos en internet? ¡Hazlo accesible!

La accesibilidad web ha sido un campo para los técnicos y tecnólogos, un espacio lleno de código html que debía cumplir unas normas que permitían que las páginas web fueran accesibles para cualquier persona independientemente de su discapacidad. Actualmente la evolución de las tecnologías de desarrollo ha hecho que la normativa de accesibilidad sea difícil de cumplir y por lo tanto no aplicable en la gran mayoría de las plataformas que utilizamos habitualmente. El desarrollo web accesible ha quedado relegado a páginas que deben cumplirla por exigencias propias.

Aunque ya no es una palabra de “moda” seguimos y seguiremos teniendo problemas de acceso al contenido y a las funcionalidades. En el mundo real hacer que un parque o edificio sea accesible depende exclusivamente de los arquitectos y constructores, sin embargo, en el mundo digital, toda persona que crea o publica contenido es responsable de que el mismo pueda ser interpretado independientemente de las capacidades del usuario. Del mismo modo que habitualmente cedemos nuestro asiento en el autobús, ayudamos a cruzar una calle o a leer una etiqueta, en internet podemos crear contenido apropiado para personas con discapacidad cognitiva, física o sensorial. Todo no está en nuestras manos, pero añadiendo información adicional y cuidando la maquetación de la página podemos conseguir un mejor acceso a la información. ¿Qué posibilidades tenemos? Entre otras cosas, podemos describir las fotos para una persona que no ve, transcribir los vídeos, hacer una redacción sencilla o un resumen de lectura fácil, elegir plantillas que se adapten a la pantalla, etc.

Actualmente creamos y publicamos más contenido que nunca, hagamos en la medida de lo posible que sea accesible, si quieres aprender a hacerlo puedes apuntarte al curso Iniciación a la Accesibilidad Digital nos pondremos en la piel de quien no ve, no comprende o no oye. Aprenderemos a hacer que ese contenido sea más fácil para todos.

post image

30 aniversario de Egokituz, ponencia en torno a la accesibilidad

El pasado 16 de diciembre EGOKITUZ, Laboratorio de Interacción Persona-Computador para Necesidades Especiales (UPV-EHU), organizó una jornada sobre accesibilidad para celebrar su 30 aniversario en la que participaron investigadores, colaboradores, empresas y organizaciones con las que ha trabajado. Bixente Monreal, diseñador de Lotura, tomó parte en la mesa redonda de empresas y centros técnológicos, presentado su visión sobre la accesibilidad en el desarrollo web.

“La accesibilidad web: de la fe a los hechos” por Bixente Monreal

16 Diciembre 2015 · 15:00h · Carlos Santamaria Zentroa

Hasta ahora hemos conocido dos versiones de pautas para definir contenido accesible en las web, la WCAG 1.0 y la WCAG 2.0.

La primera versión de las pautas de contenido web accesible de la WAI, la comparo con la Biblia. Es decir, describía las reglas mediante figuras retóricas, que daban pie a múltiples interpretaciones.

Por ejemplo,

“10.2 Hasta que las aplicaciones de usuario soporten explícitamente la asociación entre control de formulario y etiqueta, para todos los controles de formularios con etiquetas asociadas implícitamente, asegúrese de que la etiqueta está colocada adecuadamente.” En aquellos casos en que cada campo está formado únicamente por una etiqueta y un control de formulario no cabía la menor duda, rodeabamos el control con las etiquetas correspondientes. Pero cuando además había un texto adicional de ayuda, de poco nos servía la regla. Como solución los desarrolladores, como buenos “feligreses” nos inventábamos soluciones estrafalarias, no por imaginativas menos erróneas, como separar los campos mediante una lista.

El siguiente precepto es otro ejemplo,

“13.1 Identifique claramente el objetivo de cada vínculo.“. Supuestamente esa era la labor del atributo <title>, pero resulta que había lectores de pantalla que no lo interpretaban. Había que hacer malabarismos con etiquetas <span> que aportaban la explicación pertinente, pero que se escondían porque afeaban el diseño.

O este otro,

“9.5 Provea atajos de teclado a los enlaces importantes”. Es decir, la consideración de enlace importante recaía exclusivamente en los desarrolladores.

Y en el colmo de la ambigüedad,

“14.1 Utilice el lenguaje apropiado más claro y simple para el contenido de un sitio. “. ¿Cómo se mide ésto?

Para complicar las cosas, en aquel momento existían dos “evangelios”, el HML4 y el XHTML, y ambos prometían un desarrollo coherente para toda la eternidad.

Esta ambigüedad de la WCAG 1.0 tenía como consecuencia que la accesibilidad fuera una cuestión de fe. Me acuerdo de las amargas “discusiones teológicas” con los “sacerdotes auditores” (para los que no conozcáis esta figura aclararos que es muy similar a un inquisidor de la edad media) y cómo buscábamos la “absolución” de nuestras técnicas y no nos “excomulgaran” la subvención.

En uno de los proyectos, uno de los auditores me obligó a incluir los atributos “placeholder” en los formularios y después nos llamó el cliente diciéndonos que lo quitáramos porque los lectores de pantalla leían dos veces la misma información, el <label> y el “placeholder”.

Todos estos problemas provocaban paradojas como la que nos contó una persona invidente, que accedía mejor a una página de turismo estructurada mediante tablas, que a otra que supuestamente cumplía con los preceptos de la accesibilidad.

A pesar de todo, esta primera versión tuvo la virtud de obligarnos a estructurar las páginas de una manera correcta, mediante capas y encabezados, dotando de cierta lógica semántica a las mismas. En aquellos tiempos las etiquetas que aportaban valor semántico a la página eran unas pocas, e incluían a los encabezados <h1>, <h2>, <h3>…, las listas, y las tablas de datos.

En el “concilio” de diciembre de 2008 publicaron la segunda versión, la que, en un alarde de imaginación, definieron como WCAG 2.0. El susto fue mayúsculo. Ahora dividían los preceptos en cuatro principios: perceptible, operable, comprensible y robusto. Lo primero que pensé fue que eran los cuatro jinetes del Apocalipsis. Por aquella época, se publicó el “nuevo evangelio”, el HTML5, que sustituía a los dos precedentes. Nuevos protagonistas, como las etiquetas <section>, <article>, <nav>, <aside>, <header> y <footer>, hacían su aparición, que usándolos junto con los WAI-ARIA roles facilitaban el acceso a los lectores de pantalla, mejorando la accesibilidad notablemente. Además se eliminaban etiquetas redundantes como las <abbr> y <acronym> o las <caption> y <summary>.

Pero la principal virtud de las nuevas pautas era que eliminaban la ambigüedad de la primera versión. Además, definían claramente las técnicas que se podían utilizar para implementar la accesibilidad. Por fin, la accesibilidad no era una cuestión de fe.

Proyecto con Egokituz

Cuando ya se había publicado la segunda versión de las pautas, nos propusieron desarrollar junto con Egokituz uno de los proyectos más interesantes. El proyecto GureMintza necesitaba algo más que cumplir con las pautas de accesibilidad, ya que estaba dirigido a discapacitados cognitivos. Además de los habituales retos que la accesibilidad presenta, debimos resolver otros específicos del colectivo al que la web iba dirigido.

Los discapacitados intelectuales tienen problemas para recordar las claves, no comprenden el scroll, de modo que lo que no ven en la pantalla no existe, tienen problemas para entender los submenús y necesitan que los enlaces dispongan de iconos que refuercen el texto.

Futuro de la accesibilidad

Espero equivocarme, pero creo que la accesibilidad se va a implementar solo en aquellas webs que estén obligadas a cumplirla. Cuando Google decidió dar un empujón al lenguaje javascript y en concreto al ajax, marcó un camino que la mayoría de los desarrolladores hemos adoptado como modelo.

Si bien existe la posibilidad de construir de forma accesible una aplicación web que haga uso de la tecnología ajax, para que el contenido dinámico sea accesible, la aplicación debe alertar al usuario cuando ocurra un cambio y permitir el acceso directo al nuevo contenido, de modo que la aplicación web funcione de manera continua. Pero lograr este objetivo es complicado, especialmente para usuarios de lectores de pantalla, y, aunque se consiga, la aplicación resulta más cara. Un coste que la empresa privada no está dispuesta a asumir, sobre todo ahora que se han eliminado casi todas las subvenciones a la accesibilidad.

Como consecuencia, en Lotura hemos notado que la empresa privada prescinde de la accesibilidad y exige un diseño más dinámico y visual.

Los estándares web están definidos por una entidad, la W3C, que está al margen del mercado y no tiene el poder de influencia que sí tienen las grandes empresas como Google, Microsoft y Apple, que son las que, al fin y al cabo, definen las técnicas que se van a utilizar en la construcción de Internet. Así, la accesibilidad siempre va por detrás, a la espera de que estas empresas se dignen a implementarla.

post image

¿Es hora de adaptar tu web a móvil porque lo dice google?

SI y No

A partir del 21 de abril Google ha anunciado que no mostrará en sus búsquedas desde móvil las páginas que no tengan diseño responsivo. En su entrada  Finding more mobile-friendly search results explican que la razón de este cambio se debe a que cada vez más personas utilizan el móvil y tablets para navegar y es necesario dar una buena experiencia para el usuario. Según su comunicado “este cambio afectará a las búsqueda en todos los idiomas y tendrá un impacto significatio en nuestros resultados de búsqueda. Consecuentemente, los usuarios encontrarán más fácil conseguir resultados de búsqueda más relevantes y de mejor calidad optimizados para su dispositivo.”  Esto significa que el trabajo de SEO realizado en la página web debe contar con un diseño responsivo para obtener un buen posicionamiento tal y como comentamos en nuestra entrada Tú sitio web, SEO y los dispositivos

Esto de que Google ponga una fecha para decirnos algo así como “si tu web no está adaptada a móvil desapareces” nos pone nervioSEOS y nervioSEAS. Habrá que respirar hondo y poner un poco de lógica y sentido común en este asunto. Está claro que una web debe ser móvil y no hay mucha más opción teniendo en cuenta que hay webs que rondan el 50% de su tráfico desde el móvil. Para las empresas que no están familiarizadas con este lenguaje parece que puede acercarse el apocalipsis, sin embargo, puede que este cambio no afecte demasiado al tráfico de su web. Está claro que la adaptación de la web al móvil es más que necesaria, en Lotura tenemos clientes cuyo tráfico desde dispositivos móviles ronda el 40%, hay otros con un porcentaje mucho menor para los cuales la perdida de visitas puede llegar a ser insignificante. Por lo tanto, a cada empresa este cambio le va a afectar de una manera, lo mejor es revisar que implicación tiene y luego tomar decisiones, un rediseño en la página no se puede hacer a todo correr.

Te recomendamos:

1. Revisar el tráfico de tu página web desde móviles.

2. Revisar la adquisición: cómo llegan, con que palabras a tu página si se quedan y contactan o se van.

3. Tendencia del uso a móvil en tu página web.

4. Decidir si quieres rediseñar tu página web.

Google ha puesto una herramienta para comprobar si la web esta optimizada para móviles, añadiendo simplemente la URL puedes comprobarlo.

 

post image

Eventos en materia de derecho con diseño web para móviles

El proyecto se lanza en una primera fase con registro de usuario utilizando Facebook, Twitter, G+ y el propio registro de la web. Eventosjuridicos.com permite recibir alertas personalizadas, enviar sugerencias y publicar eventos. Además los gestores de Eventosjuridicos.com tienen un blog donde ofrecen información y resumenes de los eventos más importantes.

Los eventos celebrados se guardan en el repositorio donde se puede publicar toda la documentación generada: videos, fotos, presentaciones.

En esta nueva versión, se ha rediseñado teniendo en cuenta las pautas de accesibilidad, diseño responsive por lo que el interface se  adapta a todo tipo de resoluciones y dispositivos móviles (ipad, iphone, smartphones…).

Para dar solución a eventos que se publicaban desde otros países se ha puesto online Eventosjuridicos.com, donde se muestra un mapamundi de eventos y es el usuario el que elije el país que le interesa. En estos momentos Eventosjuridicos está en España, Mexico, Bolivia, Colombia, EEUU, México, Perú, Uruguay y Venezuela.

Eventosjuridicos.com tiene una gran cobertura en redes sociales y está presente en Twitter, Facebook y Linkedin. Se ha convertido en un referente en el sector.

En un futuro próximo Eventosjuridicos.com ofrecerá a los organizadores gestión completa de los eventos desde las inscripciones, gestión documental (videos, documentos, audio) y difusión en internet. Y para los asistentes a eventos una agenda personalizada para guardar la documentación, eventos a los que ha asistido, favoritos, etc.

 

post image

Hoy en “Así se hace”: Guremintza, red social para discapacidad cognitiva

Después de casi dos años desde la primera reunión, el proyecto Guremintza ha visto la luz. Esta iniciativa surgió de la unión de tres entidades: el Grupo Gureak, la Facultad de Informática de la UPV/EHU y Lotura, con el objetivo de desarrollar una red social adaptada a personas con discapacidad intelectual.

Definición de funcionalidades y necesidades especiales

Se analizaron diferentes redes sociales para hacer un listado de las funcionalidades que debía ofrecer la web y también distintos paquetes de software libre para la creación de redes sociales para usar como base de desarrollo.

Hubo que reducir y reestructurar las funcionalidades originales en más de una ocasión y finalmente se desechó la idea de usar software libre debido a la imposibilidad de personalizarlo con las necesidades especiales que debía cumplir una red social adaptada a este colectivo:

  • web accesible con un diseño simple, claro e intuitivo
  • opciones de accesibilidad: aumentar / disminuir el tamaño de letra y cambiar a alto contraste
  • colores diferentes para ayudar al usuario a diferenciar secciones y funcionalidades
  • imposibilidad de usar scrolls
  • imposibilidad de usar submenús ni otros elementos desplegables
  • uso de textos simples en el interfaz (nombres, explicaciones, ayudas, botones)
  • menús y botones con elementos gráficos de apoyo
  • textos de ayuda en cada pantalla y en los campos de los formularios
  • necesidad de pedir confirmación al usuario antes de realizar una acción
  • mostrar resultado de cada acción (confirmación de éxito o errores)
  • opción para que se locute (oir como audio) los textos de la web

 Desarrollo y primeras pruebas

Las funcionalidades a desarrollar han sido las siguientes:

  • Acceso al sistema, recordatorio de clave, solicitud de alta.
  • Cuenta de usuario: ver /modificar mis datos, ver /modificar mis aficiones, ver /añadir/borrar mis fotos, ver /añadir/borrar mis vídeos.
  • Novedades: ver listado de mensajes de mis amigos y mis grupos, escribir nuevo mensaje (visible para todos mis amigos), ver respuestas a un mensaje, responder a un mensaje, denunciar un mensaje, marcar como “me gusta” un mensaje, borrar un mensaje (solo si lo ha insertado el usuario).
  • Amigos: ver mis amigos, buscar nuevos amigos, añadir / eliminar amigo, aceptar / rechazar solicitudes de amistad, seleccionar un amigo, ver mensajes privados con un amigo, escribir nuevo mensaje privado al amigo, ver fotos úblicas del amigo, ver vídeos públicos del amigo, chatear con el amigo.
  • Grupos: ver mis grupos, seleccionar un grupo, listado de mensajes del grupo, escribir nuevo mensaje al grupo, ver listado de usuarios del grupo, ver listado de fotos del grupo, añadir nueva foto al grupo, ver listado de vídeos del grupo, añadir nuevo vídeo al grupo.

Desarrollar un proyecto con estas características no ha sido fácil: por una parte no hay muchos sitios web adaptados a este tipo de discapacidad en los que basarse, por otra ha sido necesario ir modificando y mejorando la red social con los problemas puntuales detectados en los tests de usuario realizados por un grupo de control durante el desarrollo del proyecto.

Guremintza

pantallazo de GuremintzaComo se puede apreciar en el pantallazo, se ha estructurado el sitio web de la siguiente manera:

  • Cabecera: cambio de idioma, aumentar / disminuir tamaño de letra, cambiar a alto contraste, activar / desactivar la locución de los textos.
  • Lateral, identificación del usuario y acceso a sus datos, menú principal de navegación: 3 secciones principales con colores personalizados que tienen a su vez un máximo de 3 subsecciones. Todos los nombres/botones se refuerzan con un elemento gráfico.
  • Área principal: ruta de navegación y contenido específico de cada pantalla, los listados siempre paginados con un diseño claro para evitar el scroll vertical.
  • Pie: sellos de accesibilidad, sin funcionalidad, sirve para cerrar la pantalla marcando su final.

En otras pantallas ha sido necesario añadir un submenú dependiendo de la sección para añadir las funcionalidades propias de la misma:

Control de uso y minería de datos

Por último se ha incorporado un sistema de control de uso de la red social que ayude a los gestores del sitio web a detectar tanto errores de uso por parte de los usuarios como errores de usabilidad de la red social.

Este sistema de control permite exportar los datos de uso de manera impersonal, es decir, sin información personal o privada, para que un grupo de investigación de la Facultad de Informática de la UPV/EHU pueda analizarlos y extraer información sobre los distintos perfiles de usuario y su nivel de integración en la red social mediante la técnica conocida como minería de datos.

Más información

Caso de estudio

Ficha del proyecto

Presentación de GureMintza por Antoni Heredia e Iban Lucas (Grupo Gureak) en “Iª Jornada Tecnología y Discapacidad Intelectual”, organizada por la Fundación Síndrome de Down de Madrid 22 de febrero 2013.

Diseño para todos no es posible” ponencia presentada en UXspain 2012, Encuentro de profesionales de la Experiencia de Usuario en España.

 

post image

Guremintza, red social para personas con discapacidad cognitiva, en la I jornada Tecnología y discapacidad intelectual

Cartel de la jornada tecnología y descapacidadEL pasado 22 de febrero se celebró la I Jornada de Tecnología y Discapacidad organizada por la Fundación Síndrome de Down de Madrid. Punto de encuentro alrededor de las tecnologías aplicadas al mundo de la discapacidad intelectual entre los profesionales de este ámbito, desarrolladores informáticos, mundo empresarial y familiares.

En lotura.com estamos especialmente contentos con la presentación que hizo GITEK de la mano de Toni Heredia e Iban Lucas de Guremintza la red social para personas con discapacidad cognitiva utilizada dentro del Grupo Gureak.

Mucho se habla de la discapacidad, diversidad funcional, accesibilidad, etc. Sin embargo muchas veces los desarrolladores web estamos al margen o desconocemos el uso de la tecnología que dan estas personas. Por eso el listado de ponencias que se presentaron en el congreso de Tecnología y discapacidad intelectual es una buena fuente de información que os invitamos a utilizar.

post image

Diseño responsivo, diseño para móviles

La navegación en Internet está cambiando rápidamente. Hasta ahora el acceso a la web se realizaba mayoritariamente mediante ordenadores personales. Los diseñadores web “solo” nos teníamos que preocupar de dar soporte a  los diferentes navegadores y resoluciones de pantalla de los PCs.

Pero hoy en día, con la irrupción de los dispositivos móviles, el escenario ha cambiado radicalmente. El usuario de internet navega cada vez más desde móviles y tabletas, y en breve veremos que el acceso a la web desde estos dispositivos superará a la navegación tradicional. (más…)

post image

Aplicación móvil o página web

Cuando queremos presentar los servicios de nuestra empresa , en ocasiones surgen  dudas a la hora de elegir una solución basada exclusivamente en tecnologías web  u otra que se fundamente en los lenguajes nativos de los móviles.

Las páginas web ofrecen muchas ventajas respecto a otras tecnologías:

Inmediatez. A diferencia de las aplicaciones que hay que descargar e instalar, el acceso a las páginas web es inmediato a través de un navegador.

Compatibilidad. Un único desarrollo es suficiente para que el contenido se visualice en todos los dispositivos. Por el contrario, en el caso de las aplicaciones móviles hay que desarrollar una versión para cada plataforma, con el consiguiente encarecimiento del desarrollo.

Actualización. El acceso a nuevas funcionalidades en una página web es inmediata, sin embargo en las aplicaciones hay que realizar una descarga y consiguiente instalación.

Facilidad para compartir. La web se puede fácilmente compartir mediante un enlace de la página enviado por mail, mensaje de texto, Facebook o Twitter. Una aplicación simplemente no se puede compartir.

Ciclo de vida. La página web no se puede borrar, no ocurre así con las aplicaciones que sí se pueden desinstalar.  Según un estudio, los usuarios no utilizan una misma aplicación más de 30 días.

El website móvil puede comportarse como una aplicación. Con el uso de Ajax, petición directa de datos sin realizar la carga de la página, la web replica el comportamiento de una aplicación nativa.

Coste de desarrollo. Al utilizar un único lenguaje de programación el coste de desarrollo se reduce drásticamente.

Hoy en día existen metodologías que adaptan un website de modo que en los dispositivos móviles la experiencia de usuario resulte similar a la que ofrece una aplicación.

Metodologías

1. Metodología RESS

La metodología RESS utiliza exclusivamente tecnología web y lo componen dos técnicas. Por un lado el cliente se diseña de modo responsivo, es decir, un diseño que reubica el contenido de la página dependiendo de la resolución de pantalla y por otro lado el servidor simplifica el contenido de la página, eliminando aquellas secciones que son irrelevantes y complican la usabilidad de la web en la navegación por móvil. En la mayoría de las webs esta solución resulta muy satisfactoria, evitando un sobrecoste importante en el desarrollo y mantenimiento.

2. HTML5 Y Ajax

En aquellos casos que el cliente necesite un comportamiento muy similar a una aplicación existen metodologías que resuelven el problema. A diferencia de la metodología RESS, hay un desarrollo personalizado, sobre todo en el diseño de la página, que tiene que realizar peticiones al servidor del mismo modo que lo hace una aplicación. Para ello se utiliza Ajax, que no es más que el lenguaje de programación javascript, que se ejecuta en el  dispositivo móvil. Esta programación adicional repercute en el coste de desarrollo, pero el resultado es muy similar al que ofrece una aplicación nativa.

3. Soluciones Híbridas

Si se quiere replicar el método de instalación de una aplicación nativa, de modo que se pueda descargar desde las respectivas tiendas de aplicaciones de Apple y Android, las dos metodologías precedentes no resuelven el problema. Pueden utilizarse técnicas híbridas, de modo que la aplicación se realice con tecnologías exclusivamente web, pero se compilen (empaqueten) del mismo modo que una aplicación nativa. De este modo el ciclo de vida de la aplicación así construida será idéntico a la de las aplicaciones.

Desarrollo de aplicaciones nativas

Si bien con estas tres técnicas nos podemos acercar a las funcionalidades que ofrecen las aplicaciones nativas, existen escenarios en los que solo una aplicación desarrollada en los lenguajes propios de los móviles puede dar una solución satisfactoria. Éstos son los casos concretos en los que será inevitable programar en los diferentes lenguajes de las diferentes plataformas móviles.

1. Juegos interactivos

Una aplicación nativa será la mejor opción para resolver las necesidades de rendimiento e interacción que requieren este tipo de programas .

2. Acceso a funcionalidades nativas

Si bien algunas funcionalidades propias del dispositivo móvil son también accesibles mediante tecnologías web, como es el caso del GPS, pulsar para llamar o SMS, otras son soportadas únicamente por la programación propia del dispositivo. Éste es el caso del acceso a la cámara de fotos. Si necesitamos esta funcionalidad estaremos obligados a prescindir del desarrollo web.

3. Aplicaciones que requieran potencia

Aquellas aplicaciones que por su naturaleza requieran de la máxima potencia deberán hacerse con programación nativa.

Conclusión

Las aplicaciones nativas para dispositivos móviles han tenido mucho éxito hasta ahora. No obstante, hoy en día existen metodologías web que replican el funcionamiento de las mismas aportando además muchas ventajas.

Solo en casos muy concretos deberemos decidirnos por el desarrollo de aplicaciones nativas, ya que presenta muchas desventajas frente al uso exclusivo de tecnologías web.

post image

“Diseño para todos no es posible” presentado en UXSpain 2012

Presentacion de la ponencia

Idoia Soto, "Diseño para todos no es posible". Fotos de @jruizjunquera

Fuimos al evento UXSpain con una ponencia sobre el proyecto que estamos desarrollando junto con el Grupo Gureak y la Universidad del País Vasco. Se trata de crear una red social para personas con discapacidad intelectual que les sirva y que la utilicen. Para que lleguen a utilizarla hay que construirla de forma que la entiendan, si la entienden y son capaces de utilizarla probalemente la usen. Esto es algo a lo que se ha dado muchas vueltas durante los dos días que ha durado el congreso y es que muchas veces llegamos a desarrollar proyectos que son muy bonitos, funcionales, accesibles y no se usan porque no despiertan el interés del usuario. (más…)