Todo tipo de información sobre accesibilidad en la Web: errores de accesibilidad, ejemplos de páginas inaccesibles, noticias, software, hardware, productos de apoyo, consejos, pautas y guías de accesibilidad, WAI, WCAG, Norma EN 301 549, legislación, etc.
Estoy mirando varias páginas para la actividad voluntaria de accesibilidad web, pero me están surgiendo algunas dudas con las etiquetas. Por ejemplo, después de leer los apuntes me ha quedado claro que cuando se pone una imagen, se debe incluir la etiqueta (alt=" "), sin embargo, estoy viendo una web en la que aparece de la siguiente forma:
En este caso concreto, ¿la etiqueta (title= " ") cumple la misma función?
La alumna no me ha dicho en su mensaje dónde ha encontrado este ejemplo, pero uno que es "perro viejo" lo ha encontrado fácilmente: se trata de la web oficial de la Junta de Extremadura.
La respuesta es NO, no cumple la misma función. Si leemos la recomendación del W3C sobre HTML podemos sacar las siguientes conclusiones:
El atributo alt se emplea como representación alternativa, es decir, como sustituto de la imagen. Por ejemplo, cuando se decide no cargar las imágenes de una página (por ejemplo, porque la conexión a Internet es lenta o nos cobran mucho dinero por ello, como puede ser desde un teléfono) o cuando alguien no puede ver las imágenes (por ejemplo, un ciego). Este atributo es obligatorio.
El atributo title se emplea para proporcionar información adicional, no para proporcionar información que sustituya al elemento al que se aplica (en este caso a una imagen). Por ejemplo, se puede emplear para indicar el autor de una fotografía, la fecha de realización de una fotografía o el origen de una imagen, pero siempre como información complementaria. Este atributo es opcional.
Por tanto, en este caso concreto, está mal utilizado el atributo title. Se emplea para proporcionar exactamente la misma información que con el atributo alt, lo cual, más que ayudar, es una barrera (a nadie le gusta leer o escuchar dos veces lo mismo). Si vemos el código de la página de la Junta de Extremadura, comprobaremos que esta forma de actuar se repite en más sitios.
Esta página es el típico caso de accesibilidad web mal entendida: el desarrollador de la página lee alguna guía, lee algún artículo, consulta algún ejemplo, pero en realidad no entiende lo que está haciendo, simplemente lo repite como un loro.
La guinda de esta página web la podemos encontrar en su pie. Por un lado, podemos encontrar el mensaje "Resolución Óptima 1024x768 px.", que ya comenté un caso parecido hace unos días en Tonterías, las justas. Por otro lado, podemos encontrar las medallas de "XHTML 1.0" válido (pero no es así, a mí me han salido 3 errores de validación) y "WAI-AA" (hay algunas cosas básicas que se deberían corregir, como esta del atributo title).
[Actualización 04/03/2011]
En realidad, en este ejemplo, la imagen en cuestión sólo realiza una función decorativa, por lo que lo mejor, lo más accesible es emplear un texto alternativo nulo (simplemente alt=""), y por supuesto, no utilizar el atributo title.
A los alumnos de la asignatura Experiencia de usuario del Curso de especialista en diseño web que estoy impartiendo les propuse hace casi dos semanas un ejercicio complementario: ¿Cómo mejorará la accesibilidad web HTML 5? Para guiar un poco más el ejercicio, les comentaba que en este blog he escrito varias entradas sobre ello, y además les incluía tres preguntas para centrar aún más el tema:
¿Cómo mejorará la accesibilidad web HTML 5?
¿A quién crees que beneficiará más?
¿Alguna de las características beneficiará a la mayoría de la gente y no sólo a grupos reducidos?
Como el ejercicio es complementario, es decir, no se evalúa ni se va a hacer un examen sobre ello, ha ocurrido lo que esperaba: no ha contestado nadie, absolutamente nadie.
Hoy les he escrito el siguiente mensaje, para ver si alguien se anima de una vez:
Un nuevo elemento que ayuda a mejorar la accesibilidad es el nuevo elemento (etiqueta) <nav>. Esta etiqueta permite definir un elemento navegacional de la página web, como puede ser el menú principal o el menú secundario.
Se debe utilizar para marcar los elementos principales de navegación, no se deben marcar todos los elementos, como podemos leer en el apartado 4.4.3 The nav element de la especificación HTML5:
Not all groups of links on a page need to be in a nav element — only sections that consist of major navigation blocks are appropriate for the nav element. In particular, it is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases, without a nav element.
¿Por qué mejora la accesibilidad esta etiqueta? Porque permite identificar de una forma clara los elementos de navegación que tiene una página web, por lo que las tecnologías de apoyo como los lectores de pantalla lo pueden detectar y ofrecer al usuario cuando lo necesite.
Un compañero ha leído este mensaje y me ha preguntado: ¿hay alguna ventaja más? Por supuesto:
Proporciona un método explícito de especificar cuales son los elementos de navegación de un sitio web y de una página web.
Se puede (podrá) configurar el agente de usuario (navegador) para que inicialmente salte el menú de un sitio web, por lo que ya no es necesario escribir "saltar enlaces" o "saltar al contenido principal".
Un lector de pantalla puede tener un comando (atajo de teclado) para acceder directamente a los elementos de navegación de una página, igual que tiene un comando para mostrar la lista de enlaces o la lista de encabezados de una página.
Un agente de usuario en un dispositivo con una pantalla pequeña (por ejemplo, un teléfono), puede mostrar los elementos de navegación de forma independiente o cuando el usuario pulse una tecla del dispositivo.
El elemento <nav> puede funcionar como un <div> a todos los efectos. Ya no es necesario escribir <div id="menu"> o <div id="navigation">. <nav> tiene 3 letras como <div>, así que no se puede decir que haya que escribir más.
Y seguro que hay muchas más ventajas que yo desconozco. ¿Se te ocurre alguna ventaja más?
Evidentemente, todas estas ventajas dependerán de que los agentes de usuario y las tecnologías de apoyo soporten los nuevos elementos (etiquetas) de HTML5. Que no lo soporte ahora, no es razón para no usarlo ya: si ya lo usamos, nuestras páginas estarán preparadas para el futuro.
Si hubiese que elegir una regla o principio que resumiese toda las pautas, guías y consejos para hacer una página web accesible yo me quedaría con ofrece alternativas. No te limites a proporcionar la información en un solo formato, ya que estarás excluyendo a muchos usuarios.
Como suele ocurrir, la teoría es más sencilla que la práctica, y muchas veces es difícil encontrar buenos ejemplos que reflejen la teoría.
Pero acabo de encontrar un buen ejemplo. Un buen ejemplo de cómo hacer que un gráfico sea accesible. Tampoco es que haya descubierto algo sorprendente (lo que vamos a ver se lleva haciendo muchos años con el enlace D de información detallada), pero vale la pena recordarlo.
La página web WebKit SunPider ofrece los resultados de un test para medir el tiempo de ejecución de JavaScript en diferentes navegadores. Es decir, es un test para evaluar el rendimiento de los motores de JavaScript que llevan incorporados los navegadores. Sorprendentemente, el navegador más rápido de todos los probados es la versión candidata de Internet Explorer 9. Y también sorprende que no les importe reconocer que Internet Explorer 8 es el navegador más lento con diferencia (más de 10 veces más lento).
Volviendo al tema de la accesibilidad, como podemos ver en la siguiente imagen, los resultados se ofrecen mediante un gráfico de barras.
La forma correcta de ofrecer información adicional o alternativa sería mediante el atributo longdesc, pero desgraciadamente poca gente lo conoce y mucha menos gente lo usa.
Pero también se ofrece una versión textual en forma de tabla mediante el texto "A textual version of the results can be found here".
Para una persona que no pueda ver, la versión en forma de tabla, que está correctamente etiquetada porque emplea la etiqueta <th> para crear los encabezados de columna, le ofrece la misma información que el gráfico de barras. Pero es que además, la versión en forma de tabla beneficia a todo el mundo: ¿y si quiero hacer un trabajo con esos datos? No hay problema, los puedo copiar y pegar fácilmente a partir de la tabla, no tengo que escribir la tabla desde cero a partir del gráfico.
Según el artículo, lo más importante que falta por definir son las capacidades multimedia de HTML5 y el soporte de WebSocket, una tecnología que permitirá la comunicación en ambos sentidos (¿un AJAX mejorado?).
Otro tema crítico, la estandarización de los codecs de vídeo, parece que no se resuelve y por ahora no existe un consenso.
¿Puede una persona ciega hacer una página web? Pues claro, ¿por qué no? Todo depende de si la herramienta de autor empleada es accesible. En la página web Páginas webs hechas por ciegos 2011 podemos encontrar una recopilación de páginas web hechas por personas ciegas. Muy interesante visitar algunas de estas páginas y comprobar cómo están hechas.
Metadata and information structure design on websites – towards a web for all
A weighted-graph-based approach for diversifying search results
The role of web in launching and using radio communication for public safety
Mainstreaming accessibility? Multidisciplinary problems or technical solutions
Online diagnosis e-health system for all, based on advanced web accessible database technologies
Testing the accessibility of websites
El acceso a los artículos online está restringido a suscripciones (es de pago), sólo está accesible el editorial. Pero sí que se pueden leer los resúmenes de los artículos de forma gratuita. Los dos más interesantes son:
Metadata and information structure design on websites – towards a web for all
When we transmit information through the internet, we would usually like it to reach many people. Our aim is for people to read it, to utilise it as a source, and to make use of it in their studies, e.g., in postgraduate courses, or in other fields of life. This article seeks to identify what elementary criteria our information source has to fulfil in order for search engines to find it, for users to consider it relevant and appropriate, and for it to meet the demands of users with disabilities. Only if these criteria are fulfilled does our website become really accessible. To promote this possibility, the article deals with the theoretical and practical dimensions of screen structure, data structure and metadata.
Testing the accessibility of websites
The current development of the internet and its growing use makes it necessary to satisfy the needs of all users including those with disabilities having accessibility problems. We developed a new validator software (XValid) based on the WCAG 2.0. We tested 18 countries' sites in 15 categories approximately 500 sites, with XValid. We made a statistical analysis based on our test. We determined the most frequently occurring errors based on these statistics. We took into account these typical errors, when we determined our minimal guidelines in ten points. People with disabilities could reach the internet barrier free if the web designer would test his/her design using our recommendations. The problem will be more and more important because the population of Europe will become older and older. This population needs accessible internet. Therefore it is very important to be prepared to cope with this problem now!
Discapnet, el portal de las personas con discapacidad de la Fundación ONCE, contiene un par de páginas con numerosos informes sobre el estado de la accesibilidad web en España:
La mayoría de los informes se centran en la accesibilidad de los sitios web de las Administraciones Públicas (universidades, ministerios, comunidades autónomas, ayuntamientos), que recordemos que por diversas iniciativas legislativas como la Ley 56/2007 y el Real Decreto 1494/2007, deben satisfacer "el nivel medio de los criterios de accesibilidad al contenido generalmente reconocidos". Pero también podemos encontrar algunos informes dedicados a empresas privadas, como portales de viajes y transportes o portales de la banca.
Se hablaba sobre las condiciones de contratación de personal discapacitado en el Congreso y la portavoz popular en la materia, Celia Villalobos, se ha empeñado en referirse, en varias ocasiones, al asunto como "el tema de los tontitos".
A la segunda, el presidente del Congreso, José Bono, ha pedido a Celia Villalobos que cambiara de término y dejara de referirse a los afectados de deficiencias físicas o psíquicas como "tontitos".
Y aquí tenemos un vídeo con la explicación de José Bono, el presidente del Congreso de los Diputados.
Para el que no lo sepa, Celia Villalobos pertenece al Partido Popular, en la actualidad es Diputada por Málaga y anteriormente fue Ministra de Sanidad y Consumo y Alcaldesa de Málaga. Esto demuestra que cualquier 'listo' puede ser alguien en la vida y en especial en la política.
Sólo espero que los tontitos y todos los familiares de los tontitos a los que hacía referencia Celia Villalobos hagan un buen uso de su voto en las próximas elecciones.
De entrada, aclarar que hablar de "versión normal" y "versión accesible" es un error. No se tienen que crear varias versiones de un mismo sitio web, se tiene que crear una única versión que sea accesible por todos los usuarios. Sólo en el caso de que no haya otra solución, se puede optar por crear una versión alternativa accesible, tal como nos dice el W3C en el punto de verificación 11.4 de WCAG 1.0:
11.4 Si, después de los mayores esfuerzos, no puede crear una página accesible, proporcione un vínculo a una página alternativa que use tecnologías W3C, sea accesible, tenga información (o funcionalidad) equivalente y sea actualizada tan a menudo como la página (original) inaccesible.
Me acabo de encontrar con el sitio web del proyecto Tuning, financiado por la Unión Europea y mantenido por la Universidad de Deusto. En la imagen siguiente podemos ver la página principal visualizada en Mozilla Firefox:
En la parte central de la página destacan cuatro imágenes, prácticamente iguales, pero diferentes por una pequeña variación en el color:
Resulta que esas imágenes son enlaces que conducen a un documento PDF en inglés, francés, alemán e italiano. En la "versión normal", la versión visual, es imposible saber cuál es la función y el destino de cada enlace:
Las imágenes son muy pequeñas y no se puede leer nada.
La URL del enlace no aporta información útil para descubrir el destino del enlace: http://www.tuning.unideusto.org/tuningeu/index.php?option=com_docman&task=docclick&Itemid=59&bid=81&limitstart=5&limit=5
Sin embargo, como las imágenes sí que llevan el atributo alt, la "versión accesible", la versión de sólo texto que es equivalente a cómo percibe la página web un usuario ciego que utilice un lector de pantalla, sí que ofrece suficiente información para saber cuál es el destino de cada enlace. Por ejemplo, en la siguiente imagen podemos ver la página principal visualizada en WebbIE:
Los cuatro enlaces de las imágenes aparecen como:
Enlace: Tuning General Brochure in English
Enlace: Tuning General Brochure in French
Enlace: Tuning General Brochure in German
Enlace: Tuning General Brochure in Italian
La "versión accesible" proporciona suficiente información para saber cuál es la función y el destino de cada enlace.
Acertijo: está claro cuál es el error, ¿pero sabes por qué lo han cometido los creadores de este sito web? ¿Qué ha originado este error tan simple y evidente?
Para terminar, no he realizado un análisis de la accesibilidad de la página web principal, pero en 30 segundos se pueden encontrar los típicos errores:
La página no tiene título: la etiqueta <title> está vacía.
No se emplea el atributo lang para indicar el idioma principal ni los cambios de idioma.
La tabla está maquetada con tablas.
Se crean listas que en realidad no son listas.
Se emplean mapas de imagen cuando no son necesarios
¿Qué otros errores de accesibilidad tiene la página?
Ahora parece que la última llamada (last call) se producirá durante el segundo cuatrimestre de 2011 y se espera que la especificación completa sea publicada en el año 2014. El calendario completo lo podemos encontrar en HTML Working Group Charter:
Last Call Working Draft: 2011 Q2 (segundo cuatrimestre)
Mientras tanto, el W3C nos indica que debemos ser cuidadosos a la hora de utilizar HTML 5, pero también nos animan a utilizarlo cuando sea conveniente:
Although W3C officials have warned developers not to adopt the HTML5 capabilities prematurely, the standards body also is encouraging developers to implement HTML5 where appropriate.
Acabo de leer el artículo A World Wide Web that talks. El artículo habla del proyecto Spoken Web de IBM, que intenta recrear las características y funciones de la Web textual para personas con un nivel de alfabetización y de cultura digital bajo. El público objetivo de este sistema son las personas sin educación de regiones en desarrollo.
Sin embargo, este sistema me ha recordado otro que comenté hace un par de años en la entrada Navegación mediante un teléfono móvil, que tenía características similares, pero que en ese caso estaba destinado a ser usado por personas ciegas o con graves problemas de visión.
El artículo Printed Photos the Blind Can 'See' describe un programa que permite crear una imagen táctil a partir de una fotografía. De esta forma, una persona ciega puede "ver" una imagen. Por ahora el sistema esta desarrollado para fotografías de caras, pero es de esperar que se generalizará para cualquier tipo de imagen.
En la siguiente imagen podemos ver un ejemplo de este sistema: en primer lugar, la fotografía original; en segundo lugar, los trazos principales de la fotografía (los bordes); y en tercer y último lugar,
la impresión en relieve de los trazos principales de la fotografía para que una persona ciega los pueda sentir/ver.
He publicado en mi sitio web sobre accesibilidad los prerrequisitos de la clase presencial que tendré con los alumnos el próximo 1 de marzo. El objetivo de estos prerrequisitos es que los alumnos aprendan de forma autónoma una serie de conocimientos antes de la clase presencial, con el fin de que la clase presencial sea mucho más provechosa. No es una idea original, en el mundo anglosajón se emplea mucho el "pre-reading": lecturas que el alumno tiene que haber leído antes de asistir a la clase presencial.
Para motivar a los alumnos a leer y ver los vídeos que he preparado, les he pedido también que realicen un par de actividades.
En la primera actividad, los alumnos tienen que realizar una evaluación de la accesibilidad web de una página de alguna administración pública, para comprobar si cumple el REAL DECRETO 1494/2007.
En la segunda actividad, los alumnos tienen que realizar una propuesta de captcha accesible. Esta es una actividad difícil, no espero una solución perfecta, pero sí que propongan algo y evalúen los pros y contras de su propuesta.
Este tema duró 4 horas y el alumnado es mayoritariamente no técnico, sin experiencia en creación de páginas web, por lo que fue una clase totalmente introductoria.
¿Por qué hay gente que todavía se empeña en poner estas tonterias? En la Revista Dintel podemos leer en el pie de página:
Portal optimizado a una resolución de 1024x768 y Microsoft Internet Explorer
¿Cómo puede ser que aún se pongan estas tonterías en las páginas web? En sorprendente que una fundación y una revista, que tiene como objetivo la "Difusión de las ingenierías Informática y de Telecomunicación" (DINTEL) cometa este tipo de errores de principiante.
[Actualización 15/02/2011]
En un comentario, me preguntan por qué es una tontería o qué es exactamente la tontería. Creo que la pregunta es retórica, la persona que me hace la pregunta sabe cuál es el problema, simplemente está expresando sus pensamientos en forma de preguntas. De todas formas, una pequeña explicación para aquellos que lean esto y sí se pregunten por qué es una tontería:
"Portal optimizado a una resolución de 1024x768": con la diversidad de dispositivos que se emplean hoy en día para acceder a la Web (ordenadores de escritorio, portátiles, netbooks, teléfonos inteligentes, tabletas), cada uno con su resolución y su formato (4:3, 16:9), y cada usuario con su configuración de área de trabajo (barras de herramientas, barras de accesos rápidos) que limita el área de visualización disponible, es una tontería realizar esta afirmación. Porque en realidad, esta afirmación normalmente es falsa, ya que en realidad lo que quiere decir es "Portal diseñado para una resolución de 1024x768, para el resto de resoluciones no me he preocupado en comprobar cómo se visualiza".
"Microsoft Internet Explorer": con la diversidad de navegadores que emplea la gente, optimizar un sitio web para un solo navegador es una tontería (más bien, es una estupidez). Y es más tontería cuando se hace para Microsoft Internet Explorer, uno de los peores navegadores que ha existido y que ha hecho mucho daño al desarrollo web por su incumplimiento de los estándares, lo que ha obligado a los desarrolladores web a hacer "apaños" para que sus sitios web se pudieran visualizar en diferentes navegadores. Y es más tontería cuando las diferencias entre diferentes versiones de Microsoft Internet Explorer son tremendas. ¿Para qué versión de Microsoft Internet Explorer está optimizado el portal?
"DINTEL = Difusión de las ingenierías Informática y de Telecomunicación": es una tontería que una revista/fundación dedicada a la difusión de las ingenierías informática y telecomunicación cometa este error. Con este tipo de mensajes sólo difunde desconocimiento.
"Tonterías las justas": es un programa de humor que emiten por un canal de televisión en España y me vino a la cabeza en cuanto vi este pie de página tan tonto.
Y no he dicho directamente ni una sola palabra sobre la accesibilidad, aunque claro que esta tontería va en contra de la accesibilidad. Quien pone este tipo de mensajes no conoce la Web.
[Actualización 04/03/2011]
Otra razón más: la mayoría de los usuarios no comprende estos mensajes, la mayoría de los usuarios no saben o no entienden bien qué es la resolución de pantalla.
Acabo de leer la noticia Stephen Fry backs project to make Web more accessible, publicada en la web de la Universidad de Southampton. La noticia presenta el proyecto Fix the Web, que permite informar de los sitios web que son no accesibles. A continuación, un conjunto de voluntarios revisan los informes y se ponen en contacto con los propietarios de los sitios web y les informan de los problemas que tienen y de cómo resolverlos.
Los vídeos de la Fundación ONCE están subtitulados, pero no de la mejor forma, ya que los subtítulos están integrados en el propio vídeo. Al estar integrados los subtítulos en el vídeo, no se pueden desactivar ni se puede configurar su modo de presentación. Esto causa varios problemas, el más evidente es que no se puede ofrecer el vídeo con subtítulos en otros idiomas. Además, otro problema importante es que YouTube no tiene constancia de que los vídeos tienen subtítulos, por lo que no pueden ser encontrados por una persona sorda que realice una búsqueda de vídeos con subtítulos. Es sorprende que la Fundación ONCE cometa este error.
YouTube ofrece desde hace tiempo la posibilidad de subtitular los vídeos. Ya explicaré en otra entrada cómo se hace.
Cuando se realiza una búsqueda de un vídeo, se puede emplear "Opciones de búsqueda" para indicar en el apartado "Características" que se quiere buscar vídeos que tengan subtítulos. Para ello hay que seleccionar la opción "Subtítulos cerrados", traducción literal de closed captions, el término que se emplea en inglés. En la siguiente imagen podemos ver las "Opciones de búsqueda" de YouTube:
Los vídeos que tienen subtítulos aparecen en los resultados de una búsqueda con el marcador "cc" (de closed captions), como podemos ver en la siguiente imagen donde aparecen tres vídeos que tengo publicados en YouTube con subtítulos:
Como podemos ver en la siguiente imagen del vídeo Accesibilidad de la página web del Senado (1/2), los subtítulos aparecen sobreimpresos sobre el vídeo. En la barra del reproductor (player) aparece un botón en rojo con las letras "cc" cuando el vídeo tiene subtítulos.
Este botón permite activar y desactivar los subtítulos. Además, también permite configurar algunos parámetros de visualización de los subtítulos, como el tipo de letra, el tamaño de letra y el más importante, el idioma de los subtítulos.
YouTube permite añadir subtítulos en diferentes idiomas a un mismo vídeo. Además, también permite emplear un servicio de traducción automática de los subtítulos: podemos añadir los subtítulos en un único idioma, por ejemplo español, y YouTube se encarga de traducirlo a otros idiomas.
Por ejemplo, en la siguiente imagen aparecen los mismo subtítulos que en la imagen anterior, pero traducidos al alemán:
En conclusión: los subtítulos no se tienen que integrar en el propio vídeo, como lo hace la Fundación ONCE, sino que se tienen que publicar de forma separada. Además, hoy en día se pueden hacer vídeos que integren los subtítulos y la lengua de signos todo junto, permitiendo al usuario activar y desactivar lo que desea ver.
Jonathan Chacón es ciego desde hace más de 15 años. También es consultor de accesibilidad. Y ahora, con 31 años también es el primer desarrollador invidente en el mundo que ha conseguido vender en la tienda de aplicaciones de Apple el único juego para iPhone y iPad accesible. Una versión del popular buscaminas que permite jugar a discapacitados y no discapacitados. O lo que es lo mismo: un juego para todos.
La aplicación de este sevillano, aunque ya estaba disponible desde hace tiempo en las tiendas de Apple, ha sido presentada este lunes en 'The App Date', un espacio de conexión, ideas, investigación y creatividad sobre aplicaciones, impulsado por la empresa Wake App para servir de punto de encuentro a creadores y posibles inversores.
Con su buscaminas Chacón cumple su objetivo de desarrollar productos que todas las personas puedan usar. Una meta que nace y alimenta en su trabajo como consultor de accesibilidad en Technosite, perteneciente al grupo empresarial de la Fundación ONCE
Sus deseos de llegar a todos van por buen camino. De momento, el buscaminas de Chacón -disponible para iPhone, iPod e iPad- se puede encontrar en cinco idiomas: español, inglés, italiano, francés y sueco.
El proyecto EU4ALL (European Unified Approach for Assisted Lifelong Learning) tiene como finalidad que la formación universitaria esté al alcance de todo el mundo, independientemente de su diversidad funcional. Se trata de un proyecto multidisciplinar en el que participan 13 socios de diversos países y varias empresas.
El sistema permite adaptar de forma automática los contenidos educativos a los diferentes tipos de estudiantes en función de su diversidad funcional. Para ello, claro está, primero hay que conocer las necesidades de cada estudiante: cuando un estudiante trabaja con el sistema, tiene que identificar sus necesidades de interacción.
Guías clasificadas por tipo de trastorno: ofrece la información clasificada por el tipo de trastorno, como visual, motriz, auditivo, de aprendizaje, del lenguaje y dificultades de comunicación y de las personas mayores.
Dentro de cuatro días, el 31 de enero de 2011, empezará una nueva era para la página web del Senado: ¡la página web empezará a ser accesible! En realidad, no, tendremos que esperar unos meses más para verlo, pero será el principio del cambio.
El 22 de diciembre de 2010, el Senado publicó en el apartado de Contratación el "procedimiento abierto para la contratación del Suministro de software y hardware y de los servicios necesarios para el desarrollo del gestor de contenidos y el buscador para la página Web del Senado, que incluye licencias para su utilización en la Intranet, así como la conversión de los contenidos a XML, la realización de la página especializada para dispositivos móviles, la gestión de suscripciones, y las aplicaciones de sellado de tiempo, gestión de visitas y acreditaciones de prensa, representaciones gráficas y visita virtual". En pocas palabras, la renovación del sitio web del Senado.
1. Objeto
El objeto del presente pliego es la adquisición de los bienes y servicios necesarios para el desarrollo de la nueva web del Senado. Esto incluye la adquisición de las licencias de software necesarias, tanto del nuevo software ofertado como de cualquier otro que pudiera ya estar en uso en el Senado y que debiera actualizarse como consecuencia de la nueva implantación, su instalación y puesta en servicio, los nuevos equipos y sus servicios de instalación y puesta a punto, en caso de que la oferta los incluya por considerarlos
necesarios y, por último, el desarrollo de las funcionalidades de la nueva web
4. Lote 1: página web
4.1 Introducción
Se pretende que la página web del Senado se base en una solución integrada que incluya mecanismos de gestión de contenidos y gestión documental colaborativa, así como las funcionalidades necesarias para gestionar los distintos componentes de que constará la página web del Senado (portlets, etc.), y otros sites complementarios que se desee crear más adelante.
La página web finalmente obtenida deberá permitir que toda su funcionalidad esté disponible utilizando los principales navegadores del mercado, como Explorer, Firefox, Opera y Chrome.
4.10 Accesibilidad de los contenidos Se pretende que la nueva página web del Senado disponga del nivel de accesibilidad doble A, siempre que sea posible.
La solución proveerá herramientas que permitan controlar la accesibilidad de los contenidos en todo momento, con mecanismos de validación.
Se valorará la posibilidad de validación directa por parte del usuario editor de los
niveles de accesibilidad de los contenidos que introduce.
CLÁUSULA 6ª
1. El presupuesto máximo de licitación asciende a 500.000,00 euros, sin incluir IVA, que corresponde al importe total de bienes y servicios contemplados en el pliego de prescripciones técnicas, distribuido en los siguientes lotes:
Lote 1. Página web. Presupuesto máximo de licitación: 310.000,00 euros, sin IVA.
Lote 2. Buscador. Presupuesto máximo de licitación: 140.000,00 euros, sin IVA.
Lote 3. Páginas temáticas de niños y jóvenes y visita virtual. Presupuesto máximo de licitación: 50.000,00 euros, sin IVA.
CLÁUSULA 12ª
El plazo para la presentación de ofertas expira el día 31 de enero de 2011, a las catorce horas.
CLÁUSULA 20ª. Adjudicación.
La adjudicación, que se efectuará en el plazo máximo de tres meses a contar desde la apertura de las proposiciones, se notificará a los licitadores y se publicará simultáneamente en el perfil del contratante.
CLÁUSULA 24ª. Ejecución del contrato.
• Lote 1. Página web. Plazo de ejecución: 6 meses.
• Lote 2. Buscador. Plazo de ejecución: 3 meses.
• Lote 3. Páginas temáticas de niños y jóvenes y visita virtual. Plazo de ejecución: 3 meses.
Algunos datos interesantes que aparecen en este estudio:
3.1.1. Datos referidos a todas las personas con discapacidad
En total hay 3,8 millones de personas con discapacidad residiendo en los hogares españoles, de los que 2,3 millones son mujeres, que representan el 59,8% y 1,5 millones son hombres, el 40,2% del total de la población con discapacidad residente en hogares familiares.
Respecto los tipos de discapacidad, los totales por tipo de discapacidad son (medidos en miles de personas):
Visión: 979,2 (es decir, casi un millón de personas tiene algún problema de visión grave)
Audición: 1.064,6
Comunicación: 737,2
Aprendizaje y aplicación de conocimientos y desarrollo de tareas: 630,1
Movilidad: 2.544,1
Autocuidado: 1.834,6
Vida doméstica: 2.095,3
Interacciones y relaciones personales: 620,9
Las categorías de discapacidades no son disjuntas, es decir, una misma persona puede estar en varias categorías. Y una categoría engloba distintos grados de discapacidad. Por ejemplo, la discapacidad "visión" engloba los siguientes niveles (otra vez medido en miles de personas):
Percibir cualquier imagen: 58,3
Tareas visuales de detalle: 673,6
Tareas visuales de conjunto: 662,1
Otros problemas de visión: 357,4
Respecto las deficiencias, se definen los siguientes tipos (medidos en miles de personas):
Mentales: 724,8
Visuales: 797,6
De oído: 907,8
Del lenguaje, habla y voz: 86,5
Osteoarticulares: 1.486,5
Del sistema nervioso: 492,1
Viscerales: 576,6
Otras deficiencias: 322,6
Otra vez, una persona puede tener deficiencias de más de un grupo de deficiencias.
El informe completo ocupa 200 MB, así que ha sido dividido en varios archivos para facilitar su descarga:
[01_capitulo1.pdf] Capítulo 1. Estimaciones cuantitativas y perfil sociodemográfico según la Encuesta de Discapacidad, Autonomía personal y situaciones de Dependencia. (EDAD 2008)
[02_capitulo2.pdf] Capítulo 2. La Convención Internacional sobre los Derechos de las Personas con Discapacidad y su aplicación en España
[03_capitulo3.pdf] Capitulo 3. El empleo de las personas con discapacidad: retos y oportunidades
[04_capitulo4.pdf ] Capitulo 4. El desarrollo y aplicación de la Ley de promoción de la autonomía personal y atención a las personas en situación de dependencia
[06_indicadores.pdf] Selección de indicadores sobre la situación de las personas con discapacidad en España. Indicadores correspondientes a contratación, protección económica, Sistema para la Autonomía y Atención a la Dependencia y Accesibilidad, Prevención de dependencias y Educación
Estos días podemos leer la noticia de que el Senado de España se gastará 350.000 € cada año en traducciones para que los senadores puedan hablar en catalán, euskera, gallego o valenciano. Sin embargo, son incapaces o no tienen dinero para tener una página web en condiciones.
Para demostrarlo, he realizado un análisis rápido de la accesibilidad web de la página del Senado de España:
El análisis va acompañado de tres vídeos que explican paso a paso el análisis realizado. Desgraciadamente, el resultado es demoledor:
Empleo de un diseño fijo.
Utilización de imágenes animadas.
Imágenes sin texto alternativo.
Utilización de una versión de sólo texto.
Código HTML incorrecto y empleo de etiquetas desaconsejadas.
Ausencia de definición del juego de caracteres y del idioma principal de la página.
Empleo de marcos.
Maquetación con tablas.
Mecanismos de navegación incoherentes.
Es decir, la página web del Senado contiene los errores de accesibilidad más típicos y básicos.
Pero lo pero, lo más importante de todo esto no es que esté horriblemente mal hecha la página y tenga graves problemas de accesibilidad, sino que por ley, TIENEN LA OBLIGACIÓN DE HACERLO BIEN, tienen la obligación de proporcionar una página web accesible.
Desde el año 2002, en España se han desarrollado varias leyes que definen los niveles de accesibilidad web que deben cumplir las Administraciones Públicas.
Según estas leyes, desde el 31 de diciembre de 2008 la página web del Senado de España debería ser accesible. Sin embargo, estamos en enero de 2011, han pasado ya más de 2 años, y la página web tiene graves problemas de accesibilidad.
Si se aplicase la LEY 49/2007, que establece el régimen de infracciones y sanciones en materia de igualdad de oportunidades, no discriminación y accesibilidad universal de las personas con discapacidad, al Senado se le podría imponer una sanción máxima de 1.000.000 de euros si se considerase que comete una infracción muy grave.
Y yo me pregunto, ¿es necesario gastarse 350.000 euros al año para que menos de 300 personas puedan hablar en el idioma que quieran, cuando todos ellos conocen el castellano y podrían hablarlo sin problemas? ¿No sería mejor invertir una parte de ese dinero (tampoco hace falta mucho) para lograr que la página web del Senado fuera accesible, así cumplir con las leyes y no discriminar a millones de ciudadanos españoles?
En fin, una muestra más de la inteligencia de sus "señorías".
[Actualización 22/01/2011]
Según la noticia Los Premios Día de Internet se entregarán en el Senado (17/10/2005), el 25 de octubre de 2005 se entregaron en el Senado los Premios Día de Internet que contaban con las siguientes categorías:
1. Mejor evento del Día de Internet. 2. Mejor iniciativa para promover las TIC en los Centros educativos. 3. Web o iniciativa para mejorar la accesibilidad en los Webs de las AAPP. 4. Web o iniciativa para mejorar la accesibilidad en los Webs empresariales. 5. Mejor iniciativa para reducir la brecha digital en España. 6. Internet y yo: Mejor idea para contar que es Internet. 7. Mejor Webloger o Periodista digital.
Un poco cursioso que en el Senado entregasen un premio por mejorar la accesibilidad en las webs de las Administraciones Públicas. Ya se sabe, ya se sabe, "haz lo que digo, no lo que hago".
[Actualización 23/01/2011]
Según el documento La nueva intranet del Senado, presentado en TECNIMAP'2006, el equipo informático del Senado sabe que tienen que aplicar las pautas de accesibilidad y, al menos pasa la intranet del Senado sí que lo hacen (¿y el resto de los usuarios?):
En virtud de lo dispuesto en la disposición adicional quinta de la ley 34/2002, de 11 de julio, de servicios de la sociedad de la información y del comercio electrónico, y de la Resolución del Parlamento Europeo sobre la Comunicación de la Comisión “eEurope 2002: Accesibilidad de los sitios web públicos y de sus contenidos” (COM(2001 529-C5-0074/2002 . 2002/2032 (COS)), de abril de 2002, se aplicará, siempre que sea posible, las pautas de accesibilidad de la Web Accesibility Initiative (WAI) del World Wide Web Consortium (W3C).
1. Consistent Layout and Structure
2. Add Alternative Text to Images
3. Use Page Headings
4. Use Headings Properly
5. Skip Links
6. Link Content
7. Link Awareness
8. Be Careful With Title Attribute
9. Keep the Underline
10. Forms
11. Make All Links Accessible to Keyboard
12. Show Link Focus
13. Add ARIA Landmark Roles
14. Validate Mark-Up
15. The Three Tiers, and Progressive Enhancement
16. Use List Elements for Lists
17. Use More Than Color to Convey Meaning
18. Color Contrast
19. Mark Up Data Tables Correctly
20. Make Changes to Content Clear
21. Now, About That Flash…
22. Provide Transcriptions
23. Add Captions
24. Appropriate Language
25. Test Through Multiple Methods
El W3C ha preparado un documento, HTML5 differences from HTML4, en el que detalla las principales diferencias entre HTML4 (y su variante según XML, XHTML 1.0) y la nueva versión del lenguaje, HTML5.
Algunas de las principales diferencias son:
HTML5 define una sintaxis que es compatible con HTML4 y XHTML 1.0. Por tanto, un salto de línea se puede escribir como <br> (HTML4) o <br /> (XHTML 1.0).
Para definir el juego de caracteres se introduce un nuevo atributo para la etiqueta <meta>: <meta charset=”UTF-8″>
aunque todavía es posible utilizar el método tradicional: <meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″>
Se simplica el DOCTYPE: <!DOCTYPE html>
HTML5 permite incluir elementos de SVG y MathML.
Se introducen nuevos elementos, como: section, article, aside, header, footer, etc.
Se introducen nuevos atributos, como: media, charset, autofocus, placeholder, etc.
Algunos elementos cambian, como: a, b, i, menu, etc.
Algunos atributos cambian, como: type, name, summary, etc.
Algunos elementos desaparecen, como: basefont, big, center, etc.
Algunos atributos desaparecen, como: align, background, bgcolor, etc.
Mejora de las API, como: getElementsByClassName() y innerHTML.
An introduction to Web Accessibility, es un interesante vídeo introductorio a la accesibilidad web. Está en inglés, pero el presentador habla muy claro. No es muy técnico, no entra en muchos detalles de implementación, por lo que es adecuado para cualquier tipo de público.
La descripción del vídeo dice:
Paul Boag provides a simple introduction to web accessibility based on a presentation he has given at web design conferences. Ideal for beginners while challenging more experienced web developers to reconsider the way they approach accessibility.
OpenViBE permite crear Brain-Computer Interfaces (BCI), sistemas de comunicación que permiten transmitir al ordenador instrucciones simplemente con el pensamiento.
En el siguiente vídeo oficial se detallan las características de este sistema:
En esta segunda parte muestro algunos captcha que se proponen como accesibles, pero que siguen teniendo algunos problemas de accesibilidad importantes.
El vídeo es accesible: posee subtítulos en español, para que una persona sorda pueda seguirlo.
Además, también he publicado las transparencias empleadas en el vídeo.
Y a continuación incluyo la transcripción completa del vídeo.
1. Hola, soy Sergio Luján Mora, profesor de la Universidad de Alicante, y con este videotutorial vas a aprender los problemas de accesibilidad que presentan los captcha.
2. En la parte anterior de este videotutorial vimos los problemas de accesibilidad que presentan los captcha que se emplean normalmente.
En esta segunda parte del videotutorial vamos a ver que soluciones hay para que los captcha sean accesibles.
3. El World Wide Web Consortium, el consorcio internacional que desarrolla recomendaciones para la Web, como HTML o CSS, publicó en el año 2005 una nota donde analizaba el problema de los captcha y proponía seis posibles soluciones.
4. Desgraciadamente, estas soluciones tampoco son la panacea (por eso propone seis soluciones) y algunas son muy difíciles de conseguir.
5. Por otro lado, hay desarrolladores que han propuesto algunas alternativas a los captcha visuales.
Estas alternativas se basan en el uso de captcha textual en vez de visual.
Los desarrolladores que proponen estos captcha afirman que son accesibles, aunque esto no es del todo cierto, como veremos a continuación.
6. Por ejemplo, en el portal Discapnet dedicado a las personas con discapacidad, se emplea un captcha donde se debe introducir la respuesta a una operación matemática sencilla.
Este captcha presenta un problema de accesibilidad, ya que las personas con discapacidad cognitiva o intelectual pueden tener problemas.
Además, es una mala solución ya que es fácil de sortear: no es difícil hacer un programa que calcule el resultado de la operación matemática.
7. En la web manualdeusuario.es, se emplea un captcha donde hay que responder una pregunta sencilla como cuál es el color de la hierba o de qué color es la nieve.
Esta solución plantea otra vez varios problemas.
En primer lugar, otra vez las personas con discapacidad cognitiva o intelectual pueden tener problemas para resolver el captcha.
Además, como podemos ver en este mismo ejemplo, existe el problema de la barrera del idioma.
Y por último, ¿cuántas preguntas se pueden crear?
Un buen captcha debe tener un número ilimitado de preguntas, que deben ser fáciles de crear y a ser posible de un modo automático.
Este tipo de captcha sólo permite un conjunto limitado de preguntas.
8. Otro ejemplo de intento de captcha accesible lo podemos encontrar en el sitio web alzado.org, en el que se emplean varios tipos de captcha.
Por ejemplo, en este es necesario escribir la palabra que aparece en la tabla en las coordenadas indicadas.
En este caso, sería la palabra guisante.
9. Y en este otro tipo, se tiene que contestar la pregunta de cultura general que se realiza.
En este caso se pregunta “El monumento de la foto se encuentra en el país de…”.
Como la foto muestra la Torre Eiffel, hay que contestar Francia.
Algunos problemas que presenta esta solución son similares a los de las propuestas anteriores: puede haber problemas con el nivel de cultura, las personas con discapacidad cognitiva también pueden tener problemas y continúa existiendo el problema de la barrera del idioma.
10. Otra propuesta es el llamado Heyes Captcha, en la que el usuario tiene que pulsar una serie de teclas durante una serie de segundos para demostrar que es un ser humano.
Vamos a probarlo.
Nos vamos al navegador.
Aquí estamos en la página web de Heyes Captcha.
Y, las instrucciones nos dicen que tenemos que apretar la tecla E por 4 segundos.
Para ello, nos situamos en esta casilla y pulsamos la tecla E.
Vemos como el contador va avanzando y cuando llegue a 4, soltamos.
Ahora nos dice que tenemos que pulsar la tecla J por 5 segundos.
Así que repetimos la operación, pulsamos la tecla J durante 5 segundos.
Y ahora pulsamos la tecla E por 2 segundos, y vemos que hemos pasado el test.
Desgraciadamente, un sistema como este supone un problema de accesibilidad para aquellas personas que sufran algún tipo de discapacidad física que implique movilidad reducida, como puede ser la parálisis cerebral o la distrofia muscular, y que impida un control preciso de los interfaces de usuario.
11. La idea más original y, quizás, la que más futuro tiene, es la que encontramos en el llamado Honeypot Captcha, el “captcha del tarro de miel”.
En informática se denomina “honeypot” a un sistema que en realidad es una trampa, y cuya intención es atraer a los posibles atacantes de un sistema que se quiere proteger.
La idea del Honeypot Captcha es ofrecer a los “bots” un “tarro de miel”, para que acudan a él como las moscas a la miel.
Sin embargo, se supone que un ser humano no caerá en la trampa.
¿Cómo funciona el Honeypot Captcha?
12. Normalmente, una página web se compone al menos de dos partes: el código HTML y el código CSS.
El código HTML define la estructura y contenido de la página web, mientras que el código CSS define la presentación de la página web (los colores, los tipos de letra, las posiciones, etc.).
La clave del captcha del “tarro de miel” es explotar el hecho de que la mayoría de los “bots” actuales no interpretan el código CSS.
Veamos un ejemplo sencillo de esta trampa.
Por un lado, tenemos el código HTML de un formulario para dejar comentarios en un blog, que define un formulario similar a este.
Este formulario se compone de los siguientes campos: el nombre, el email, el comentario y un campo que hay que dejar vacío y que es el “tarro de miel”.
Por otro lado, tenemos el código CSS que oculta el campo del formulario que hace la función del “tarro de miel”.
13. Como he dicho antes, la clave de esta trampa es explotar el hecho de que la mayoría de los “bots” no interpretan el código CSS.
Un ser humano que utilice un navegador web normal verá la página web con la presentación definida en el CSS, y por tanto, el campo que hay que dejar vacío no lo verá y evidentemente, lo dejará vacío.
Sin embargo, un “bot” verá la página web sin el CSS, verá el campo que hay que dejar vacío, y lo rellenará.
14. Por tanto, cuando se reciba un comentario en el servidor, si se detecta información en el campo “Este campo hay que dejarlo vacío”, se supondrá que es un “bot” quien está enviado el comentario, y se rechazará.
15. Esta solución es muy simple y a su vez muy buena, ya que es muy fácil de implementar y es transparente para el usuario.
Y por ser transparente, es totalmente accesible.
Sin embargo, ¿qué ocurre cuando un usuario utiliza un navegador que no interpreta CSS?
Además, la clave de este captcha es explotar el hecho de que en la actualidad la mayoría de los “bots” no interpretan el código CSS, pero no es raro suponer que en un futuro cercano sí que lo harán, y entonces este captcha dejará de ser útil.
16. Otro captcha ingenioso es el que emplea WP Hashcash, un “plugin” para Wordpress, una de las plataformas de blog más extendida.
En este caso, la clave de este captcha es explotar el hecho de que la mayoría de los “bots” tampoco interpretan el código JavaScript.
17. Este “plugin” genera una función con valores aleatorios cada vez que se accede a una página con un formulario para dejar un comentario.
Cuando se envía un comentario, también se envía el resultado de esta función.
Si quien intenta enviar un comentario es un “bot”, no ejecutará el código JavaScript, no enviará el resultado de esta función, y el comentario será rechazado.
Esta solución tiene el mismo punto débil que el captcha del “tarro de miel”: los “bots” actuales no ejecutan JavaScript, pero no es raro suponer que en un futuro cercano sí que lo harán y entonces, este captcha dejará de ser útil.
Sin embargo, este captcha tiene una característica más que solventa esta posible situación futura.
18. El cálculo que realiza la función de JavaScript es lo que se conoce como “proof-of-work”, traducido al castellano “prueba de trabajo”.
La clave del “proof-of-work” es su asimetría: el trabajo debe ser moderadamente difícil (pero factible) por el lado del cliente, pero fácil de verificar por el lado del servidor.
El cliente debe dedicar un tiempo a calcular el resultado del trabajo, por lo que supondrá una gran penalización para un “bot” que intenta enviar miles y miles de comentarios, ya que tendrá que repetir este trabajo miles y miles de veces.
Sin embargo, para un único usuario no supone una penalización apreciable, ya que solamente lo hará una vez.
Además, al ser asimétrica la prueba de trabajo, el servidor puede verificar el resultado en un tiempo casi nulo.
Las ventajas y desventajas de esta propuesta son similares a las del captcha del “tarro de miel” que emplea CSS: es simple, transparente y accesible, siempre que el usuario utilice un navegador que admita JavaScript.
19. Para finalizar.
Hemos visto los problemas de accesibilidad que presentan los captcha actuales.
Los nuevos captcha que se están proponiendo no solucionan este problema, ya que siguen siendo no accesibles.
Incluso aquellos que se proponen como accesibles, en el fondo no lo son.
La solución es emplear algún tipo de captcha transparente que no afecte a la interacción de un usuario con una página web.
Hemos visto dos soluciones de este tipo, una basada en el empleo de CSS, y otra basada en el empleo de JavaScript.
Pero tampoco son la solución completa.
En realidad, es difícil que se llegue algún día a una solución total, ya que este es el típico juego del gato y el ratón, donde cada vez que se plantea un nuevo tipo de captcha, aparece un truco para saltarse ese captcha.
20. Y con esto finalizo este videotutorial en el que te he explicado cuales son los problemas de accesibilidad que presentan los captcha y qué posibles soluciones existen hoy en día para lograr que un captcha sea accesible.
Si necesitas más información o quieres contactar conmigo, en la página web http://accesibilidadweb.dlsi.ua.es podrás encontrar más información sobre accesibilidad web o también puedes contactar directamente conmigo a través de mi dirección de correo electrónico sergio.lujan@ua.es.
He preparado dos vídeos sobre la accesibilidad de los captcha. En la primera parte, explico los problemas de accesibilidad que tienen los captcha que se emplean en la actualidad. También muestro algunas de las alternativas a los captcha actuales que se están proponiendo, que tampoco son accesibles.
El vídeo es accesible: posee subtítulos en español, para que una persona sorda pueda seguirlo.
Además, también he publicado las transparencias empleadas en el vídeo.
Y a continuación incluyo la transcripción completa del vídeo.
1. Hola, soy Sergio Luján Mora, profesor de la Universidad de Alicante, y con este videotutorial vas a aprender los problemas de accesibilidad que presentan los captcha.
En primer lugar, recordemos qué es un captcha.
2. CAPTCHA es el acrónimo de “Completely Automated Public Turing test to tell Computers and Humans Apart”.
Traducido al castellano, “Prueba de Turing pública y automática para diferenciar máquinas y humanos”.
Un captcha es una prueba de tipo desafío-respuesta que se utiliza para determinar cuándo el usuario de un sistema informático es o no humano.
3. Los captchas son esas imágenes con letras y números distorsionados que vemos en muchas páginas web como son los formularios de registro, las páginas de envío de comentarios a foros y blogs, y muchas otras páginas.
4. El objetivo de un captcha es distinguir a un ordenador de un ser humano, y de este modo, impedir que los robots (también llamados bots) realicen un uso indebido de un servicio, como por ejemplo enviar comentarios automáticos con spam a un foro o un blog.
El captcha se sustenta en la idea de que un ser humano podrá resolver la prueba sin problemas, mientras que un ordenador tendrá muchas dificultades o será incapaz de hacerlo y por tanto, de este modo lograremos impedir su acceso.
5. Desgraciadamente, cada vez más los captcha son más difíciles, se aplican más variaciones, más distorsiones y se introduce más ruido para dificultar la resolución por parte de los ordenadores, pero a su vez también son más difíciles para las personas.
Pero además, este tipo de captcha que se emplea normalmente, una imagen con texto distorsionado, no puede ser utilizado por algunos grupos de usuarios.
6. En concreto, los captcha bloquean el acceso a muchos usuarios que padecen algún tipo de discapacidad.
Las personas con visión reducida, como pueden ser los daltónicos que tienen dificultades para distinguir algunas combinaciones de colores o las personas que usan magnificadores de pantalla para ampliar el tamaño de lo que se visualiza en una pantalla pueden tener graves problemas para distinguir el texto que se muestra en un captcha.
Por otro lado, es evidente que las personas ciegas que utilizan un lector de pantalla no pueden contestar los captcha basados en imágenes con texto en su interior, ya que estas imágenes no pueden incluir en el atributo "alt" de la etiqueta <img /> el texto que aparece escrito en los captcha, ya que entonces un ordenador también lo podría leer y podría pasar la prueba.
Además, las personas con algún tipo de discapacidad cognitiva o intelectual como la dislexia, también pueden tener problemas a la hora de interpretar el texto que contiene un captcha.
7. El problema de los captcha aparece como uno de los principales problemas de accesibilidad de las páginas web en la actualidad.
WebAIM, una organización dedicada al estudio y divulgación de la accesibilidad web, ha realizado en los últimos años varias encuestas sobre el uso de lectores de pantalla (en inglés, screenreaders).
Los lectores de pantalla son el software que emplean las personas ciegas o con graves problemas de visión para utilizar el ordenador y, por tanto, navegar por la Web.
8. La segunda encuesta que realizaron en octubre de 2009 tenía varias preguntas sobre el empleo de imágenes en las páginas web.
También había una pregunta sobre qué elementos eran los más problemáticos (difíciles y confusos) de las páginas web.
En los resultados obtenidos, los captcha aparecían en la primera posición, con un 28% de las respuestas.
Por ello, los captcha suponen un grave problema de accesibilidad, que impide la participación activa en Internet de algunos usuarios.
9. Por ejemplo, la famosa enciclopedia Wikipedia muestra un captcha cuando se quiere modificar un artículo.
Por tanto, una persona ciega no puede crear contenido en la Wikipedia.
10. O el sistema de correo de Yahoo! también muestra un captcha.
En estos servicios, una persona con discapacidad necesita la ayuda de otra persona para poder participar.
¿No existe alguna alternativa?
¿No existen captchas accesibles?
Existen algunas alternativas, como vamos a ver a continuación, pero todas tienen algún problema y no hay ninguna alternativa que sea la solución perfecta.
11. Por ejemplo, cuando se quiere obtener una cuenta en Google Accounts para utilizar un servicio como Blogger o Gmail, se proporciona un captcha alternativo para las personas ciegas que consiste en escuchar un fragmento sonoro y escribir las letras y números que se escuchan.
12. Este sistema también lo utilizan otras páginas web, como la de registro en Windows Live.
Vamos a probarlo.
Nos vamos a un navegador.
Estamos en la página de Windows Live para crear una cuenta nueva.
Y tenemos este captcha visual con dos palabras que hay que escribir en este cuadro de texto.
Además, tenemos la posibilidad de alternar a un captcha sonoro.
Vamos a probarlo y vamos a ver qué se escucha.
[Se escucha el captcha: unos números con ruido de fondo]
Hemos oído como se han nombrado unos números que tendríamos que escribir en este cuadro de texto.
Pero, al igual que el captcha visual, el captcha sonoro también incluye cierta distorsión, con lo cual a menudo son ininteligibles.
Además, requieren de un ambiente silencioso para poder ser entendidos correctamente.
También presentan un problema importante: el navegador del usuario debe admitir JavaScript y debe poseer ciertos complementos para poder reproducir el fragmento sonoro.
Por último, los usuarios sordociegos, no podrán acceder ni al captcha visual ni al captcha sonoro.
13. Comprobemos otro tipo de sitios web.
¿Son las redes sociales tan “sociales” como nos prometen?
Hagamos una prueba con Twitter, vamos a ver que pasa con su captcha en la página de registro.
Nos vamos otra vez al navegador, a la página principal de Twitter.
Nos vamos a registrar como un nuevo usuario, este es el formulario de registro, como vemos esta en castellano.
Pulso en el botón “Crear mi cuenta” y me aparece un captcha visual para que escriba las dos palabras que aparecen en la imagen.
Además, también tenemos la opción de alternar a un captcha sonoro.
Vamos a oírlo.
[Se escucha una explicación en inglés]
[Se escucha el captcha: palabras con ruido de fondo]
[Se vuelve a escuchar todo una vez más]
Como vemos, bastante sorprendente, el formulario está en castellano, pero el captcha sonoro está en inglés.
14. Para solucionar el problema de accesibilidad de los captcha han surgido algunas propuestas interesantes, pero ninguna es la panacea.
WebVisum es un complemento para Firefox que permite a los usuarios con problemas de visión o con ceguera navegar e interactuar con las páginas web de una forma más sencilla.
Entre sus funciones existe una ayuda para resolver los captcha.
Este complemento para Firefox permite enviar a la gente de Webvisum la imagen de un captcha, ellos solucionan el captcha y devuelven la solución a quien lo ha solicitado.
En concreto:
15. Supongamos que hemos accedido a una página web que contiene un captcha.
Se pulsa el botón derecho del ratón sobre el captcha y se selecciona “Solve CAPTCHA” en el menú contextual.
Con esto enviamos el captcha a la gente de Webvisum.
Una notificación informa de que el captcha ha sido enviado y se está procesando, el tiempo de resolución depende de diversos factores.
Cuando la solución del captcha se recibe, se muestra otra notificación con la solución y se indica que también se ha copiado al portapapeles.
Se selecciona el cuadro de texto correspondiente y se pega la solución.
Y, de esta forma, el formulario ya se puede enviar.
16. Otra iniciativa parecida es la que ofrece el proyecto Solona, una comunidad de usuarios que ayudan a resolver los captcha a los usuarios ciegos registrados en su web.
Este sistema es similar al anterior: una persona examina el captcha y lo resuelve de forma confidencial, enviando el resultado al otro usuario ciego.
Sin embargo, como ya he comentado antes, estos sistemas no son la solución universal, más aún cuando están apareciendo nuevos tipos de captcha que son aún más inaccesibles para algunos grupos de usuarios.
Veamos algunas propuestas novedosas de captcha.
17. Por ejemplo, en el sitio web “They Make Apps” emplean un captcha que consiste en una barra de desplazamiento que hay que mover hasta cierto punto.
Evidentemente, una persona ciega no puede resolver este captcha ni tampoco se puede resolver de formar remota empleando un sistema como Webvisum o Solona.
18. Otra propuesta es la que podemos encontrar en el sitio web “Web Design beach” donde hay que arrastrar un objeto hasta una zona de la página.
Vamos a probarlo.
Nos vamos al navegador, a la página de “Web Design beach” y aquí tenemos el captcha visual.
En este captcha, nos dan la instrucción de que para verificar que somos humanos debemos arrastrar el corazón al círculo.
Si yo intento arrastrar cualquier otra de las imágenes, no podré, solamente puedo arrastrar el corazón.
Y con esto ya podría enviar el formulario correctamente.
19. Otro captcha alternativo es el de “Animal Captcha Test”, donde hay que escribir el animal que aparece en una imagen distorsionada.
Evidentemente, este captcha también es inaccesible para una persona ciega o con problemas cognitivos y seguramente mucha gente también tendrá problemas a la hora de nombrar ciertos animales.
20. Otra captcha alternativo es el que podemos encontrar en “Captcha The Dog”, donde se muestran nueve fotografías de animales y hay que acertar cuál es el perro.
El proceso se repite un cierto número de veces hasta que todas las fotografías son del mismo animal, en este caso de gatos.
Vamos a probarlo.
Nos vamos al navegador, a la página web de “Captcha The Dog”, y aquí tenemos el captcha.
Y nos pregunta “cuál de estas cosas no es igual a las otras”.
Tenemos nueve fotografías, como podemos ver, ocho son de gato y hay una, que está aquí, que es un perro.
La selecciono y se vuelve a cargar otro conjunto de fotografías donde ocurre lo mismo, ocho son de gato y una de perro.
Vuelvo a seleccionar el perro y se vuelven a cargar nueve fotografías.
Otra vez, tenemos ocho de gato y una de perro.
Y, ya por fin, tenemos nueve fotografías que son de lo mismo, de gato.
Cuando todas las fotografías son iguales, ya podemos enviar el formulario.
21. Otra propuesta es la de “Imagination”, donde se utiliza un doble sistema.
En la primera prueba se muestra una imagen compuesta de varias imágenes y hay que marcar el centro geométrico de alguna de ellas.
Por ejemplo, si yo elijo esta imagen, su centro geométrico estaría más o menos por aquí.
22. En la segunda prueba de este captcha se muestra una imagen distorsionada que hay que etiquetar eligiendo una etiqueta de un conjunto que se propone.
En este ejemplo, tendría que elegir la etiqueta “man” (hombre, en inglés).
23. Otra propuesta es la de “Yuniti”, donde se emplea un captcha que consiste en reconocer modelos tridimensionales de objetos y animales.
Se muestra esta imagen con tres objetos, y para cada uno de ellos, hay que seleccionar un objeto similar de entre este conjunto de objetos.
24. Otro captcha alternativo es el que propone “NuCaptcha Engage”, donde se emplea un captcha parecido a los que estamos acostumbrados, pero en vez de emplear una imagen se utiliza un vídeo.
Veamos como funciona.
Nos vamos a la página de “NuCaptcha Engage” y aquí tenemos el captcha basado en vídeo.
Sobre un vídeo se muestra cierto texto en movimiento.
Y nosotros, lo que tenemos que hacer es escribir las tres letras que aparecen en rojo.
25. Finalmente, otra propuesta es la que han desarrollado unos ingenieros de Google y que fue presentada en la World Wide Web Conference de 2009 que se celebró en Madrid.
26. En esta propuesta, el captcha consiste en identificar la correcta orientación de una fotografía.
Para ello se emplea una barra de desplazamiento que permite girar 360º la imagen que se tiene que orientar.
Esta claro que esta solución tampoco es accesible, ya que las personas con deficiencia visual no lo podrán responder.
27. En resumen, hemos visto que los captcha que se emplean actualmente son inaccesibles para algunos grupos de usuarios.
Lo mismo ocurre con los nuevos captcha que se están proponiendo.
Pero es que además, los nuevos captcha son cada vez más complejos, más difíciles de entender.
Y, por supuesto, en algunos de ellos existe la barrera del idioma, como hemos visto, que no solo afecta a las personas con discapacidad.
28. Y con esto finalizo este videotutorial en el que te he explicado cuales son los problemas de accesibilidad que presentan los captcha.
En la próxima parte de este videotutorial veremos qué soluciones hay a los captcha no accesibles.
Si necesitas más información o quieres contactar conmigo, aquí tienes los datos.
