Buscador

martes, 11 de enero de 2011

Problemas de accesibilidad de los captcha (2/2)

Segunda parte del videotutorial sobre los problemas de accesibilidad de los captcha (la primera parte es Problemas de accesibilidad de los captcha (1/2)).

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.

domingo, 9 de enero de 2011

Problemas de accesibilidad de los captcha (1/2)

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.

sábado, 8 de enero de 2011

Curso en línea de diseño web profesional: usabilidad, estándares y arquitectura de información

La Universidad de Murcia organiza la segunda edición del curso Curso en línea de diseño web profesional: usabilidad, estándares y arquitectura de información. El curso se desarrollará del 21 de febrero al 20 de marzo de 2011, tiene un coste de 70€ para alumnos de la Universidad y 100€ para el resto.

El contenido del curso es:
  1. Diseño de sitios web con HTML y CSS
    • Introducción a los estándares web.
    • HTML (tipo de documento, head, reglas para escribir HTML, atributos genéricos, tablas y formularios).
    • CSS. Hojas de estilo (árbol del documento, selectores, unidades de medida, color y fondos, margen, espaciado y borde, texto, menús, disposición en página).
    • Diseños para todos (escribir código accesible, problemas con algunos navegadores, validación de formularios).
  2. Usabilidad y accesibilidad
    • Introducción a la Usabilidad (definiciones, disciplinas afines...).
    • Evaluación de la Usabilidad (test de usuarios, evaluación heurística, estudio de casos).
    • Accesibilidad.
    • Pautas de Accesibilidad.
    • Validación de la accesibilidad (herramientas para la revisión, revisión manual y automática).
    • Ejercicios prácticos (heurística de usabilidad, revisión de pautas de accesibilidad).
  3. Arquitectura de la información
    • Arquitectura de información: Disciplina, rol profesional y proceso.
    • El usuario: Necesidades y estrategias de búsqueda de información.
    • Diseño conceptual: Descripción y organización de información.
    • Diseño navigacional: Rotulado, navegación e interacción.
    • Documentación: Elaboración de entregables.

martes, 4 de enero de 2011

Primer juego diseñado por un invidente para los teléfonos de Apple

Acabo de leer en el periódico El País la noticia Apple publica el primer juego diseñado por un invidente. La noticia dice:
Jonathan Chacón contribuye con su trabajo a hacer más agradable la vida de muchas personas. Es el primer desarrollador ciego del mundo en publicar una aplicación en latienda de Apple. Se trata de Buscaminas accesible, un juego para personas ciegas, sordas y con discapacidad motora. También pueden jugar personas sin discapacidad.
"En 2008 me empecé a acercar al mundo de Apple. Con el tiempo, personas de Apple me preguntaron si era ciego. Y me comentaron que si conseguía publicar la aplicación, sería el primer ciego en el mundo en hacerlo", relata este sevillano de 31 años, empleado en Technosite. "Soy consultor de accesibilidad y experiencia de usuario, principalmente sobre web, aunque también analizo posibilidades de accesibilidad en aparatos, aplicaciones de escritorio y móviles...". Chacón es técnico superior en Diseño y Desarrollo de Aplicaciones Informáticas.

Punto de vista ciego

Acabo de leer en el periódico El País la noticia Antoni Abad lanza la red social Punto de Vista Ciego. La noticia dice:
En la web Punto de Vista Ciego, una red social concebida para personas ciegas o con visión reducida, ya hay decenas de indicaciones que forman una cartografía de Barcelona a medida de invidentes. Se trata del último proyecto de Antoni Abad, un artista que utiliza las nuevas tecnologías para dar voz y visibilidad a los colectivos más desfavorecidos.
Punto de Vista Ciego se basa en un software para teléfonos móviles con GPS integrado, realizado por Lluís Gómez y un sitio web especialmente adaptado para personas con discapacidad visual, elaborado por Eugenio Tisselli. Estas dos herramientas permiten a los participantes grabar y publicar en Internet textos, imágenes y sonidos (geolocalizados por Google Maps) de obstáculos y barreras arquitectónicas -y también ejemplos de buenas prácticas- con los que se encuentran en su vida diaria. El proyecto es una evolución de Barcelona *Accesible, una red para personas con discapacidades motoras, que le valió a Abad el premio Golden Nica en el apartado Comunidades Digitales de los prestigiosos Ars Electronica Prix de Linz (Austria).

miércoles, 29 de diciembre de 2010

Ceguera al color y simulador de visión

La página web Colorblindness explica qué es la ceguera al color (popularmente conocido como daltonismo) y explica los diferentes tipos que existen.

Además, incluye Vision simulator, que permite simular en un conjunto de imágenes diferentes tipos de ceguera al color.


Sobre la ceguera al color ya he escrito en ocasiones anteriores. Algunos de mis entradas antiguas relacionadas con el daltonismo o ceguera al color:
Y algunas herramientas que nos pueden ayudar a elegir colores que no ocasionen problemas:

lunes, 27 de diciembre de 2010

Teléfono de contacto en un formulario web

Los formularios son el principal mecanismo de interacción y de obtención de información en las aplicaciones web. La creación de formularios accesibles es un tema bastante complejo (por ejemplo, leed e intentad aplicar todo lo que se explica en este artículo Formularios accesibles según las WCAG 2.0).

Sin embargo, dejando de lado todas las cuestiones técnicas que nos marca WCAG 2.0, a veces hay errores evidentes que se cometen por falta de "sentido común" o por desconocimiento.

Por ejemplo, Sergio López Lozano, un lector de este blog, me manda su artículo Webs, formularios y documentos accesibles, en el que explica el error que supone exigir en un formulario web el teléfono (móvil) como un dato obligatorio. ¿Qué pasa si tengo problemas auditivos y no empleo la función de voz del teléfono, sino que únicamente lo utilizo para enviar texto?

Por ejemplo, el formulario de la compañía aérea EasyJet exige introducir un teléfono móvil por si se quieren poner en contacto contigo:


Lo mismo ocurre con el formulario de otra compañía aérea, Ryanair:


En estos dos ejemplos, si no se introduce un teléfono, es imposible completar el proceso de compra de un billete de avión. Y lo mismo ocurre en la mayoría de los formularios web hoy en día.

Sergio López propone en su artículo añadir una casilla para indicar que se posee una discapacidad auditiva y que, por tanto, se desea que la comunicación sea vía correo electrónico o mensaje de texto al teléfono móvil. Pero solicitar este dato quizás complique el mantenimiento de los ficheros de datos e infrinja alguna de las normas de la Ley Orgánica de Protección de Datos de Carácter Personal.

jueves, 23 de diciembre de 2010

¿Cuándo escribir el texto alternativo?

El artículo Text alternatives for images: a decision tree presenta un árbol de decisión que nos ayudará a decidir cuándo escribir el texto alternativo para una imagen y qué escribir.


Este árbol de decisión se puede resumir en la siguiente pregunta: si yo quito la imagen de la página web, ¿la página se puede seguir utilizando igual y no se pierde información? Si la respuesta es SÍ, no hace falta que escriba un texto alternativo (pero debo escribir un texto alternativo nulo con alt=""); si la respuesta es NO, tendré que escribir un texto alternativo, o explicar la imagen en el texto o incluso utilizar el atributo longdesc.

miércoles, 22 de diciembre de 2010

Estudio de Accesibilidad a la Red

Estudio de Accesibilidad a la Red es un libro que se publicó en septiembre de 1998 y que quizás es de los primeros que se publicó en España sobre accesibilidad web. Aunque es un poco viejo, es interesante ojearlo para comprobar cómo algunos aspectos siguen siendo totalmente válidos.


martes, 21 de diciembre de 2010

Vídeo sobre accesibilidad en HTML5

Hace unos pocos meses, en octubre, se celebró Amsterdam el congreso Fronteers 2010, dedicado a los últimos avances del desarrollo web, como son HTML5, CSS3, SVG, etc.

Se grabaron 14 sesiones en vídeo y se han publicado en Internet.

Una de las sesiones fue HTML5 Accessibility: Is it ready yet? de Steve Faulkner y Hans Hillen, que tenía la siguiente descripción:

What are the features in HTML5 that have the potential to:

* make it easier for developers to provide a more accessible user experience?
* make it harder for developers to provide a more accessible user experience?

Where does WAI-ARIA fit into the HTML5 accessibility story? How can WAI-ARIA fill the gaps in HTML5 UI accessibility?

Y a continuación el vídeo:


Steve Faulkner & Hans Hillen | HTML5 Accesibility: is it ready yet? | Fronteers 2010 from Fronteers on Vimeo.

También tenemos la presentación disponible en Slideshare:

viernes, 17 de diciembre de 2010

ReadSpeaker

ReadSpeaker es un sistema que permite ofrecer un sistema de lectura, como si fuera un lector de pantalla, en cualquier página web, sin necesidad de que el usuario del sitio web se tenga que descargar e instalar algún tipo de software.

El sistema, además de leer el contenido de la página, también permite resaltar el texto, frase a frase o palabra a palabra, conforme lo va leyendo. Este tipo de sistema puede ayudar a algunos tipos de usuarios, como por ejemplo los que tienen algún tipo de problema cognitivo como la dislexia.

Como curiosidad, en este sitio web podemos leer que el Gobierno de España, en concreto el Ministerio de Ciencia e Innovación, emplea este sistema: Spanish Government adds online text to speech.

jueves, 16 de diciembre de 2010

¿Qué pasa con CATIC?

Allá por el 2008 tuve las primeras noticias del Centro de Accesibilidad TIC (CATIC), un organismo desarrollado en el seno de la Fundación Oficina Valenciana para la Sociedad de la Información (OVSI) con el fin de promover la accesibilidad tecnológica en la Comunitat Valenciana y facilitar el acceso a las Tecnologías de la Información y la Comunicación al conjunto de la ciudadanía.

El CATIC se presentaba como el "Primer Centro dedicado a la Accesibilidad TIC en la Comunitat Valenciana":


Entre sus tareas, prometía "la observación del estado de la accesibilidad web, la difusión de tecnologías inclusivas y la formación y promoción de las buenas prácticas en el ámbito de la accesibilidad Web".

¿Cuál es la situación de CATIC a día de hoy? Más de 2 años después, está completamente abandonado. Su sitio web sigue funcionando, por ahora.


Pero el contenido del sitio web es bastante reducido y poco útil. Si consultamos el apartado de Noticias, veremos que la última noticia data de diciembre de 2008.

Además, contiene algunos errores. Por ejemplo, en el Centro de documentación encontramos documentos que se han subido de prueba y alguien ha olvidado borrar:


O en el apartado de Publicaciones de otras fuentes encontramos un perenne mensaje de "En construcción":


Incluso podemos encontrar páginas vacías, sin contenido, como el apartado de Eventos:



CATIC ha sido otra idea publicitaria de los políticos, con arranque de caballo, pero parada de burro. Otra idea de los políticos para hincharse la boca con promesas sobre su preocupación por las personas con discapacidad y otros grupos desfavorecidos que al final se queda en eso, en promesas.

miércoles, 15 de diciembre de 2010

Control del ordenador con los ojos

En el periódico El País han publicado  la noticia Cómo controlar un ordenador con los ojos. La noticia dice:
El tema de la tesis doctoral de Aleksandra Królak era el algoritmo que detecta los parpadeos. Mientras trabajaba en este proyecto, midió la fatiga de la gente que realizaba un trabajo intelectual sostenido durante varias horas, analizando los cambios en su ritmo de parpadeo. Al mismo tiempo vio La escafandra y la mariposa, una película que narra la historia real de un hombre paralizado después de un accidente, que podía mover sólo un ojo y se comunicaba con su enfermera parpadeando; ella iba leyendo el abedecario y escribía las letras que él le indicaba.
[...]
La principal ventaja de b-Link es que no exige ninguna capacidad técnica ni ningún equipo complejo, sólo un ordenador y una webcam normales. La instalación de la aplicación y la configuración de la cámara son los únicos pasos que necesitan la ayuda de una persona sana. Después, el discapacitado puede usar el programa sin ninguna ayuda. La cámara, debidamente ajustada, detecta el rostro del usuario, localiza la posición de sus ojos y capta los parpadeos. De esa forma, sólo con parpadear, el usuario puede navegar por internet y utilizar programas como Word Pad, MS Word y MS Outlook o apagar el ordenador.
[...]
Existen otros sistemas semejantes a b-Link, pero que necesitan equipos caros o complicados. El programa desarrollado conjuntamente por la Universidad Técnica de Lodz y Telekomunikacja Polska es la única aplicación de este tipo en el mundo que puede descargarse de manera gratuita en internet. Puede descargarse en tres idiomas (polaco, inglés y francés); el software incluye manuales de instrucciones a los que se puede acceder una vez que se ha escogido la versión en un idioma. Todos los archivos y los códigos fuente de b-Link pueden encontrarse en http://b-link.sourceforge.net/. Además, b-Link no sólo es gratuito, sino que es de código abierto, lo cual permite que la comunidad de internautas siga desarrollándolo. También está publicado en el sitio web de TP y la página web polaca de Orange; hasta ahora, ha habido ya más de 13.000 descargas.

martes, 14 de diciembre de 2010

Nuevos tipos de captcha, que no son accesibles

Los captchas son las pruebas de tipo desafío-respuesta que se emplean en muchas páginas web para diferenciar los humanos de los ordenadores. ¿Para qué? Para evitar un uso abusivo de algunos servicios que se proporcionan de forma gratuita en Internet, como el correo electrónico.

Ya he escrito en otras ocasiones sobre este tema, como en el artículo ¿Captcha accesible? No. Hoy en día, los captchas suponen un  grave problema de accesibilidad, ya que se suelen basar en pruebas visuales.

Según algunos estudios (Encuestas sobre uso de lectores de pantalla), los captchas son uno de los "elementos más problemáticos (difíciles y confusos) de las páginas web".

Desgraciadamente, no parece que vaya a mejorar la situación, ya que los nuevos tipos de captcha que se están desarrollando siguen utilizando pruebas visuales, como podemos ver en los siguientes ejemplos.

En la web They Make Apps, el captcha que emplean es una barra de desplazamiento que el usuario tiene que mover hasta cierta posición.


Animal Captcha Test muestra una imagen distorsionada y el usuario tiene que introducir el animal que aparece en la fotografía.


IMAGINATION: Image-based Authentication, propone una doble prueba en la que primero hay que marcar el centro geométrico de una imagen y luego etiquetar una imagen (el usuario tiene que asignar a una imagen una etiqueta de un conjunto).




Por último, NuCaptcha Engage propone algo totalmente distinto: mostra el captcha en un vídeo.


Y para terminar, un vídeo donde explico estas nuevas formas de captchas:

domingo, 12 de diciembre de 2010

Video sobre accesibilidad de red.es

Interesante vídeo divulgativo sobre la accesibilidad de red.es, aunque quizás muy superficial y con ningún contenido técnico:

viernes, 10 de diciembre de 2010

Observatorio de Accesibilidad Universal en los Municipios de España 2010

El pasado 24 de noviembre de 2010 tuvo lugar en la sede de Fundación ONCE la presentación del Observatorio de Accesibilidad Universal en los Municipios de España 2010.

En el sitio web de la Fundación ONCE se ha publicado la noticia La media en accesibilidad web de los municipios españoles es de 6,5 en la que cabe destacar:
La media de accesibilidad en las páginas web de los municipios españoles es de 6,5 puntos, según datos del Observatorio de Accesibilidad de sitios web municipales, presentado ayer por la Fundación ONCE. Aunque 6,5 es aprobado, según la escala de este Observatorio esta puntuación responde a un nivel de accesibilidad deficiente.

Sin embargo, hay algunas ciudades como Zaragoza cuya página web ha obtenido una puntuación de 9,03 puntos, seguida de Pamplona con un 8,94; Madrid, con un 8,56 y Guadalajara, con un 8,42. En el lado opuesto, están las Web de El Casar, con un 1,97; Puente Genil (Córdoba), con 4,20 puntos; Moguer (Huelva), con 4,26 o Logroño, con un 4,48.

Los principales problemas de accesibilidad se encuentran, según destacó Jesús Hernández, director de Accesibilidad de Fundación ONCE, en los contenidos multimedia, aplicaciones como Flash y los archivos PDF.

martes, 7 de diciembre de 2010

Encuesta para usuarios de lectores de pantalla

El WebAIM acaba de publicar en español la Encuesta para usuarios de lectores de pantalla. Este es el tercer estudio sobre el uso de lectores de pantallas que realiza.

La encuesta está dirigida a todos los usuarios de lectores de pantallas, tanto a aquellos que los usan como un producto de apoyo, como a aquellos que los usan como herramienta de revisión de la accesibilidad web.

La encuesta estará abierta hasta el 10 de enero de 2011 y los resultados se publicarán en marzo de 2011.

¡Todos a contestar la encuesta!

[Actualización 29/03/2012]
Los resultados de esta encuesta están disponibles en Screen Reader User Survey #3 Results.

lunes, 6 de diciembre de 2010

Sistemas de barrido para teclados

Acabo de leer el artículo SAK: Scanning Ambiguous Keyboard for Efficient One-Key Text Entry, publicado en el volumen 17, número 3 (julio 2010) de ACM Transactions on Computer-Human Interaction (TOCHI).

En este artículo se explican qué son los sistemas de barrido que se emplean para introducir textos en un dispositivo como un ordenador o un teléfono móvil. Estos sistemas son utilizados por personas con problemas de movilidad que no pueden emplear un teclado normal.

El sistema de barrido más simple es un sistema lineal, en el que se le presenta a la persona las opciones (por ejemplo, los caracteres de un teclado) una a una. Cuando el barrido se sitúa sobre el carácter que desea la persona, mediante la activación de un interruptor la selecciona.


Evidentemente, este sistema es lento y se pueden crear sistemas mejores como el de la siguiente imagen, donde el barrido actúa en dos fases: en primer lugar se realiza un barrido por filas y después, dentro de una fila, se realiza un barrido por columnas.


El artículo también explica el empleo de teclados ambiguos, algo a lo que estamos todos acostumbrados, ya que cuando escribimos un SMS en un teléfono móvil estamos utilizando un teclado ambiguo.

domingo, 5 de diciembre de 2010

Otro sistema para controlar el ordenador con la lengua

Hace un par de años, escribí una entrada sobre un sistema que permitía controlar el ordenador con la lengua. Ese sistema se basaba en el empleo de un pequeño iman del tamaño de un grano de arroz, que se colocaba en la lengua mediante un implante o un piercing, y traducía el movimiento de la lengua en el movimiento de un cursor en la pantalla del ordenador.

Ahora acabo de leer el artículo (con vídeo de demostración) Tongue clicks to control wheelchairs donde se muestra un sistema que también emplea la lengua, pero que se basa en analizar los ruidos y chasquidos que produce la lengua. Para ello, se emplea un pequeño audiofono que capta los sonidos y los transmite al ordenador, donde se analizan y se convierten en comandos.

viernes, 3 de diciembre de 2010

INTAV

INTAV (INTECO Accessibility Validator) es un servicio que analiza, de forma automática, el cumplimiento de los requisitos de accesibilidad web en base a los estándares vigentes, como son UNE 139803:2004 y WCAG 1.0.

miércoles, 1 de diciembre de 2010

Nueva encuesta del WebAIM sobre el uso de lectores de pantalla

El WebAIM acaba de iniciar su tercer estudio sobre el uso de lectores de pantalla (Screen reader user survey). Desgraciadamente, la encuesta está solo en inglés, aunque les he mandado un correo preguntando si la van a tener en español.

Respecto las dos primeras encuestas, en mi entrada Encuestas sobre uso de lectores de pantalla comento algunos de los resultados.

jueves, 25 de noviembre de 2010

Larga vida a la Web

Acabo de leer el artículo Long Live the Web: A Call for Continued Open Standards and Neutrality de Tim Berners-Lee, el padre de la Web. Este artículo explica los principios fundamentales que sustentan la Web, que hicieron que se convirtiera en lo que es hoy en día y como, desgraciadamente, hoy en día se están viendo atacados por varios frentes. En definitiva, un artículo de lectura obligatoria para cualquiera que quiera "hacer algo" en la Web.

Algunas de las mejores frases del artículo:
  • The principle of universality allows the Web to work no matter what hardware, software, network connection or language you use and to handle information of all types and qualities. This principle guides Web technology design.
  • Technical standards that are open and royalty-free allow people to create applications without anyone’s permission or having to pay. Patents, and Web services that do not use the common URIs for addresses, limit innovation.
Traducido al español:
  • El principio de universalidad permite que la Web funcione sin importar el hardware, software, conexión de red o el lenguaje que se utilice y permite manejar la información de cualquier tipo y calidad. Este principio guía el diseño de las tecnologías de la Web
  • Los estándares técnicos que son abiertos y no exigen el pago de un canon (sin derechos de autor) permiten a los usuarios crear aplicaciones sin permiso de nadie o sin tener que pagar. Las patentes y los servicios web que no utilizan los URI comunes para las direcciones, limitan la innovación. 
Respecto la accesibilidad web, Tim Berners-Lee dice:
The Web should be usable by people with disabilities.
[...]
Much more needs to be done, of course, including accessibility for people with disabilities and devising pages that work well on all screens, from huge 3-D displays that cover a wall to wristwatch-size windows.
Traducido al español:
La Web debería de poder ser utilizado por las personas con discapacidad.
[...]
Aún queda mucho por hacer, por supuesto, incluyendo la accesibilidad para las personas con discapacidad y la elaboración de páginas que funcionen bien en todas las pantallas, desde enormes pantallas en 3-D que cubren una pared a ventanas del tamaño de un reloj de pulsera.

Y respecto HTML5 dice:
For example, the latest version of HTML, called HTML5, is not just a markup language but a computing platform that will make Web apps even more powerful than they are now.
Traducido al español:
Por ejemplo, la última versión del HTML, denominado HTML 5, no es sólo un lenguaje de marcas, sino una plataforma informática que hará que las aplicaciones web sean más potentes de lo que son ahora.

Y el artículo lo termina con las siguientes frases:
The goal of the Web is to serve humanity. We build it now so that those who come to it later will be able to create things that we cannot ourselves imagine.

Traducido al español:
El objetivo de la web es servir a la humanidad. La tenemos que construir ahora de forma que los que vengan más adelante sean capaces de crear cosas que no nos podemos ni imaginar.

miércoles, 24 de noviembre de 2010

Una noticia sobre investigación en control mental del ordenador en Tailandia

Lo del control del ordenador mediante el pensamiento parece que se está convirtiendo en una "obsesión" en este blog, pero nada más lejos de la realidad. Ya he escrito sobre este tema en numerosas ocasiones anteriores:
Lo que en realidad ocurre es que hay mucha gente investigando en ello y, como es algo bastante sorprendente, los medios de comunicación se hacen eco constantemente de los pequeños avances que se producen. Porque por ahora, estamos bastante lejos de tener un sistema que funcione correctamente y que sea una realidad comercial.

Acabo de leer en el periódico Bangkok Post la noticia Technology puts mind over body. En esta ocasión, se trata de un sistema llamado iThink2 desarrollado en la Mahidol University de Tailandia.

En la siguiente imagen podemos ver en que consiste este dispositivo: una especie de gorra con sensores que detecta las señales eléctricas del cerebro (obtiene un electroencefalograma, o EEG) y aplicando algoritmos de reconocimiento de patrones, logra traducir los "pensamientos" en acciones en el ordenador.

lunes, 22 de noviembre de 2010

Mitos y malentendidos sobre la ceguera al color

En mi clase del sábado sobre accesibilidad web de la asignatura Experiencia de usuario perteneciente al Curso de especialista en Diseño Web de la Universidad de Alicante surgió el daltonismo o ceguera al color, un problema de la visión que impide la correcta diferenciación de algunos colores. Sobre este tema ya he hablado en otras ocasiones, como por ejemplo:
¿Qué dice WCAG 1.0 sobre este tema? Si consultamos las Pautas de Accesibilidad al Contenido en la Web 1.0 del WAI podemos encontrar la siguiente pauta que hace referencia al color:
Pauta 2: No se base sólo en el color.
Asegúrese de que los textos y gráficos son comprensibles cuando se vean sin color.

Si el color por sí mismo se usa para transmitir información, las personas que no puedan diferenciar ciertos colores, y los usuarios que no tengan pantallas en color o utilicen dispositivos de salida no visuales, no recibirán la información. Cuando los colores de primer plano y de fondo tienen un tono similar, pueden no proporcionar suficiente contraste en las pantallas monocromáticas, así como a las personas con diferentes tipos de deficiencias de percepción de los colores.
Puntos de verificación:
2.1 Asegúrese de que toda la información transmitida a través de los colores también esté disponible sin color, por ejemplo mediante el contexto o por marcadores [Prioridad 1]
2.2 Asegúrese de que las combinaciones de los colores de fondo y primer plano tengan suficiente contraste para que sean percibidas por personas con deficiencias de percepción de color o en pantallas en blanco y negro [Prioridad 2 para las imágenes. Prioridad  3 para texto].
Esta claro que una persona ciega no puede percibir los colores y un lector de pantallas tampoco le va a leer los colores, así que no se puede depender de los colores para transmitir información esencial. ¿Y qué problemas tienen los daltónicos?
Existe bastante desinformación al respecto: por ejemplo, la mayoría de la gente asocia daltonismo con los colores rojo y verde, pero también existen otros tipos de daltonismo. El artículo Color Blindness Myths and Misunderstandings explica algunos mitos y malentendidos que existen sobre la ceguera al color. Los principales mitos son:
  • Normalmente, la ceguera al color no significa la incapacidad de ver los colores, sino la incapacidad de distinguir algunos colores entre sí.
  • La ceguera al color no significa que no se pueda ver el color rojo: no se puede distinguir de otros colores y, además, existe problemas de visión similares con otros colores distintos al rojo.
  • Existe una visión normal del color: no exactamente, existe todo un espectro de posibilidades.
  • Los problemas de visión con los colores suponen una molestia, pero no un problema grave: no es así, hoy en día los colores se emplean profusamente y su incorrecta interpretación puede ocasionar graves problemas.

Para terminar esta entrada, un par de herramientas que nos pueden ayudar a entender el daltonismo.

Color Blind Web Page Filter simula cómo ve una página web una persona con daltonismo: permite introducir la URL de una página y seleccionar el tipo de daltonismo, tal como podemos observar en la siguiente imagen.


Por otro lado, Colour Contrast Analyser es una herramienta que permite determinar si una combinación de dos colores (color de primer plano y de fondo) poseen el suficiente contraste de brillo y color.

sábado, 20 de noviembre de 2010

Accesibilidad y SEO

Esta mañana he impartido cinco horas de clase de la asignatura Experiencia de usuario perteneciente al Curso de especialista en Diseño Web de la Universidad de Alicante, donde he dado una pequeña introducción a la accesibilidad web.

"¿Y por qué nos debemos preocupar por la accesibilidad web?", le he preguntado a mis alumnos. Las tres principales razones podrían ser:
  1. Por solidaridad y no excluir a ningún usuario (y posible cliente).
  2. Por mandato legal (en España, por el Real Decreto 1494/2007, las administraciones públicas están obligadas a que sus páginas web sean accesibles, y por la Ley 56/2007, una serie de empresas privadas también están obligadas).
  3. Para mejorar el posicionamiento (SEO) en los buscadores.
De estas tres razones, la última es seguramente la más convincente hoy en día para la mayoría de la gente. ¿Qué es el posicionamiento, el SEO? La Wikipedia define el SEO como:
El posicionamiento en buscadores o posicionamiento web (SEO por sus siglas en inglés, de Search Engine Optimization) es el proceso de mejorar la visibilidad de una página web en los diferentes buscadores, como Google, Yahoo! o Bing de manera orgánica (gratuita).

La tarea de optimizar la estructura de una web y el contenido de la misma, así como la utilización de diversas técnicas de linkbuilding, linkbaiting o contenidos virales con el objetivo de aparecer en las primeras posiciones de los resultados de los buscadores (cuando un usuario busca por una determinada palabra o keyword), es conocida como SEO, sigla en inglés que significa Search Engine Optimization, o sea, 'Optimización para motores de búsqueda'.
¿Y qué tiene que ver el SEO con la accesibilidad? Uno de mis alumnos ya lo sabía y lo ha apuntado de forma muy acertada: los "robots" de los buscadores se comportan como si fueran usuarios ciegos. Y hoy en día, la mayor parte del tráfico de un sitio web llega a partir de los buscadores.

El artículo SEO and Accessibility lo explica muy bien. En primer lugar, da un pequeña explicación sobre qué es el SEO y comenta las malas prácticas (el SEO de sombrero negro) que existen:
Search Engine Optimization is, at it's best, a way of managing the content and code of a web site so that it best represents what the site is trying to do. At it's worst, it's a scam to trick an innocent search engine algorithm into thinking a site is relevant when it's not.
Y poco después explica la relación entre accesibilidad y SEO:
Don't consider search engines as a separate entity from your human visitors. Instead, consider a search engine as a type of disabled visitor - one who is blind to your images, can't access your Javascript based navigation, and doesn't really care about the beauty of your flash animation.
[...]
Accessibility offers quite a few inherent benefits for SEO. The most common metaphor is to consider that a search engine robot is the most frequent disabled visitor your site may receive: it's blind, it navigates with Javascript disabled, and if it can't operate a link it stops cold. Since one of the principles of accessibility is about ensuring that your website can be navigated and understood by a blind visitor who is unable to use Javascript, these characteristics are an automatic guarantee for a well-designed accessible web site.

Si no te preocupa la accesibilidad web porque no te importa que las personas con algún tipo de discapacidad no puedan utilizar correctamente tu sitio web, por los menos preocupate para mejorar el posicionamiento de tu sitio web. Aunque de forma indirecta, la accesibilidad web puede ser que mejore.

jueves, 18 de noviembre de 2010

Investigación sobre el control del ordenador con la mente en Israel

El control del ordenador con la mente tiene el propósito de desarrollar un interfaz que sea capaz de captar las señales eléctricas que producen las neuronas en el cerebro, analizarlas e interpretarlas, para así poder controlar un ordenador, dar órdenes a un robot, etc. Este tipo de interfaz sería un gran avance y una gran ayuda para todo el mundo, pero mucho más para las personas que sufren problemas de movilidad.

Hace unos días, se publicó en el periódico The Jerusalem Post la noticia Israeli researchers pursue brain-operated computing, donde se comenta que científicos de la Universidad de Tel Aviv están trabajando en este campo, además de en el desarrollo de una retina electrónica.

En varias ocasiones anteriores he escrito sobre este tema:

viernes, 12 de noviembre de 2010

Guía de accesibilidad web para principiantes

A Complete Beginner’s Guide to Web Accessibility es una pequeña guía que explica los principales problemas de accesibilidad y cómo resolverlos. Además, también sugiere algunas herramientas.

  • Los temas tratados son:
  • What is Accessibility
  • You Are Not The Default
  • Things to Consider:
    1. Placement of Things
    2. Present Content in Different Ways
    3. Provide Easy Navigation
    4. Use HTML Tags Accordingly
    5. Do Not Rely on Colors Alone
    6. Icons and Texts for Better Context
    7. Give More Control
    8. W3C’s Guidelines and Checklist for Accessibility
  • Some Tools to Use

miércoles, 10 de noviembre de 2010

Subtitulado automático de la televisión

En el periódico El País se ha publicado la noticia Imposible subtitular 'La noria'. Algunos extractos de la noticia:
Alrededor de un millón de personas tienen algún tipo de deficiencia auditiva o visual y la ley española obliga a todos los operadores a emitir un determinado porcentaje de la parrilla con rótulos y a ofrecer un número de horas diarias en lengua de signos y audiodescripción.
Para agilizar los procesos de subtitulado, sobre todo en los programas en directo -como Los desayunos de TVE, España directo o 59 segundos-, TVE utiliza un sistema de reconocimiento de voz. Transmisiones en directo, desde el telediario a la misa, pasan por la máquina que identifica el habla.
TVE utiliza el mismo sistema que la televisión pública británica, la BBC. "No hay ninguno más rápido. Es cierto que hay un retardo, pero los sordos parten de cero y pueden seguir un programa. Es lo que diferencia entre programas accesibles y no accesibles", dice Díez Argüelles.
¿Hasta qué punto es fiable este sistema? Mercedes de Castro, coordinadora técnica del Centro Español de Subtitulado y Audiodescripción (CESyA), es escéptica. "La tecnología de reconocimiento de habla puede dar un error de entre el 15% y el 80%, si se trata de un programa con mucho ruido, como por ejemplo, un magacín. Si hay problemas de acústica, es una locura".

Hace unos meses escribí sobre algo parecido pero relacionado con YouTube: Subtítulos automáticos.

martes, 9 de noviembre de 2010

Ofertas de trabajo en accesibilidad

En Web Accessibility Jobs podemos encontrar algunas ofertas de trabajo recientes (octubre de 2010) donde se solicita conocimientos de accesibilidad. Por ejemplo, hay una oferta de Facebook que solicita User Experience - Accessibility con la siguiente descripción:
User Experience – Accessibility (HTML/CSS/JavaScript)
Are you interested in building products used by hundreds of millions of people? Do you have direct experience working with assistive technology (ie screen readers)? Facebook is seeking an experienced User Interface Engineer that is passionate about building accessible user-facing web applications. This role includes the management of technical accessibility processes as well as ownership over internal and external communication of Facebook’s accessibility strategies. This position is contractual and is based at our main office in Palo Alto, CA.

Responsibilities
  • Work with product teams to implement accessible 
  • Participate in code reviews with an eye for accessibility
  • Identify and communicate accessibility best practices for front-end engineering
  • Manage technical process for accessibility
  • Communicate Facebook’s accessibility strategy internally and externally

Requirements
  • Expert knowledge of web technologies (HTML/CSS/JS)
  • Expert knowledge of assistive technology (JAWS, VoiceOver, Dragon NaturallySpeaking)
  • Experience with scripting languages (PHP)
  • Passion for elegant, intuitive, and accessible user interfaces
  • Ability to write well-abstracted, reusable code for UI components
  • Familiarity with Object Oriented JavaScript Frameworks (Prototype JS, MooTools, Dojo, etc.)
  • Experience working with HTML/CSS/JS in high-performance environments
  • 3+ years experience in building web products with assistive technology in mind
  • BS or MS degree in Computer Science or a related technical field

Bonus
  • Experience building complicated workflows
  • Relevant experience includes self-started personal projects

lunes, 8 de noviembre de 2010

Subtítulos para cualquier vídeo

Acabo de leer en el periódico El País la noticia Subtítulos para todos en la Red. Según la noticia:
La organización sin ánimo de lucro Participatory Culture Fundation ha creado una herramienta que trabaja con código libre y gratuito. Lanzada oficialmente hace dos semanas, permite subtitular cualquier tipo de vídeo sin necesidad de descargar software o alojar el vídeo en ninguna plataforma o formato. La tecnología es simple: se añade la aplicación al vídeo y ya se pueden escribir los subtítulos, visibles para todos los usuarios.
La herramienta está pensada para permitir la colaboración entre la gente, ya que funciona de forma similar a un artículo de Wikipedia, en el que se pueden hacer mejoras de forma continuada y marcar los cambios. Una vez que un vídeo ha sido subtitulado, se pueden añadir cuantas traducciones se quiera en todos los idiomas.
En la web de Participatory Culture Fundation podemos encontrar sus proyectos, entre los que aparece Universal Subtitles y Miro.

domingo, 7 de noviembre de 2010

Ley de accesibilidad de la información en las páginas web en Argentina

Se acaba de aprobar en Argentina la Ley de accesibilidad de la información en las páginas web. Quizás sea la primera o una de las primeras legislaciones sobre accesibilidad web que se promulgan en Sudamérica.

Los principales artículos de este texto, que sólo tiene 3 páginas, son:
ARTÍCULO 1º.- El Estado nacional, entiéndanse los tres poderes que lo constituyen, sus organismos descentralizados o autárquicos, los entes públicos no estatales, las empresas del Estado y las empresas privadas concesionarias de servicios públicos, empresas prestadoras o contratistas de bienes y servicios, deberán respetar en los diseños de sus páginas Web las normas y requisitos sobre accesibilidad de la información que faciliten el acceso a sus contenidos, a todas las personas con discapacidad con el objeto de garantizarles la igualdad real de oportunidades y trato, evitando así todo tipo de discriminación.

ARTÍCULO 3º.- Se entiende por accesibilidad a los efectos de esta ley a la posibilidad de que la información de la página Web, comprendida y consultada por personas con discapacidad y por usuarios que posean diversas configuraciones en su equipamiento o en sus programas.

ARTÍCULO 5º.- Las normas y requisitos de accesibilidad serán las determinadas por la Oficina Nacional de Tecnologías de la Información (ONTI), debiendo actualizarse regularmente dentro del marco de las obligaciones que surgen de la Convención sobre los Derechos de las Personas con Discapacidad (ley 26.378).

ARTÍCULO 7º.- Las normas y requisitos de accesibilidad mencionados en esta ley, deberán ser implementados en un plazo máximo de veinticuatro (24) meses para aquellas páginas existentes con anterioridad a la entrada en vigencia de la presente ley. El plazo de cumplimiento será de doce (12) meses a partir de la entrada en vigencia de la presente ley para aquellas páginas Web en proceso de elaboración, debiendo priorizarse las que presten servicios de carácter público e informativo.

Esta ley comenzó a elaborarse en el 2008. En el apartado de trámite parlamentario podemos consultar los fundamentos de esta ley:

Las normas o requisitos para el desarrollo de sitios de Internet accesibles no incrementan apreciablemente el trabajo o la complejidad de creación de un sitio y no limitan las posibilidades artísticas del diseñador.

En la actualidad en el ámbito internacional, las recomendaciones del W3C-WAI (Web accesibility Initiative del World Wide Web Consortium) constituyen la referencia en cuanto a criterios y estrategias de accesibilidad a Internet. Estas recomendaciones no son normas estrictas, sino que indican lo que el usuario debe poder hacer y que tipo de información debe estar disponible. De esta manera se pueden efectuar consultas y utilizar servicios relacionados con las actuales tecnologías, y participar activamente en la sociedad de la información.

La iniciativa para la Accesibilidad a la Web, a través de sus pautas, propone tres niveles de adecuación a la accesibilidad de una página, de acuerdo a que prioridad le da el webmaster.

Así, una página que posee el "nivel de adecuación A" es una página que cumple con la prioridad 1 (todas las personas con cualquier problema de accesibilidad no podrán ingresar a dicha página si no cumplen al menos las pautas de esta prioridad) .

Las páginas de " nivel de adecuación AA" o "doble A" que cumplen con la prioridad 2 (muchas personas con problemas de accesibilidad tendrán inconvenientes para ingresar a las páginas que no cumplan con esta prioridad).

Por último existen las páginas de "nivel de adecuación AAA" o "triple A" que cumplen con la prioridad 3 (algunas personas con problemas de accesibilidad tendrán inconvenientes para ingresar a las páginas que no cumplen con ésta prioridad).

sábado, 6 de noviembre de 2010

Características para mejorar la accesibilidad en HTML5

Hace unos días escribí el artículo El futuro de la accesibilidad web con HTML5 sobre una interesante serie de artículos de WebAIM sobre las nuevas características que incorpora HTML5 que mejorarán la accesibilidad web.

El sitio web HTML5 accessibility proporciona información sobre que nuevos elementos de HTML5 proporcionan características de accesibilidad que hacen que sean utilizables por los usuarios que utilicen productos de apoyo (ayudas técnicas) para navegar por la web.

Por ahora, como podemos ver en la siguiente imagen que muestra parte de la tabla que analiza el nivel de soporte por parte de los navegadores más importantes, la situación no es muy buena, ya que pocas son las características soportadas por algunos navegadores:

viernes, 5 de noviembre de 2010

Nueva versión de Dolphin SuperNova

Un magnificador de pantalla es un software que permiten visualizar la pantalla con un considerable aumento en su tamaño, lo que supone una ayuda para las personas con problemas de visión.

Dolphin SuperNova es uno de los mejores lectores de pantalla que existen. Su fabricante acaba de anunciar la nueva versión 12: Exclusive to SuperNova v12, Crystal clear magnified text with True Font technology.

Una nueva característica que ofrece esta versión es la utilización de la tecnología True Font con cualquier nivel de aumento. Como podemos apreciar en la parte izquierda de la siguiente imagen, los peores magnificadores simplemente aumentan el tamaño de la pantalla, por lo que se ven los pixels que forman los textos. Algunos magnificadores aplican algunas técnicas para suavizar el pixelado, como se puede ver en la imagen central. Sin embargo, Dolphin SuperNova aplica la tecnología True Font que permite mostrar el texto con la misma cualidad sea cual sea el nivel de ampliación.

jueves, 4 de noviembre de 2010

El futuro de la accesibilidad web con HTML5

La nueva especificación de HTML5 va avanzando (el último borrador, y con ese ya van ocho, se publicó el 19 de octubre de 2010) y no hay fecha para la publicación definitiva, pero quizás en 2011-12 vea la luz. Mientras tanto, ya podemos disfrutar de muchas de sus nuevas características ya que los navegadores más modernos ya las incorporan.

HTML5 incorpora algunas características que mejoran la accesibilidad de los sitios web. La serie de artículos Future Web Accessibility del sitio web Web Accessibility in Mind (WebAIM) explica las principales características que vamos a poder utilizar:
  1. Future Web Accessibility: HTML5 <video>: la nueva etiqueta <video> permite tener vídeo de forma nativa en las páginas webs, sin tener que utilizar un plugin. Sin embargo, abre una guerra para decidir cuales van a ser los codecs para transmitir los vídeos. Respecto la accesibilidad, se espera que mejore al incorporar el manejo de los controles del reproductor mediante el teclado, pero por ahora la especificación no proporciona soporte para los subtítulos o descripciones del audio.
  2. Future Web Accessibility: HTML5 Semantic Elements: HTML5 incorpora nuevos elementos (etiquetas) que añaden más semántica a una página web al permitir etiquetar secciones lógicas o componentes de una aplicación web o un documento, como <section>, <nav>, <article>, <aside>, <hgroup>, <header> y <footer>. El empleo de los elementos <section> y <article> resuelve un problema que existe al emplear las etiquetas <h1>-<h6>, ya que estas etiquetas representan una jerarquía absoluta y tienen problemas al incluir contenido de diversos orígenes. El elemento <nav> permite definir los elementos (normalmente, los enlaces) que definen la navegación de un sitio web. La utilidad de estos nuevos elementos de cara a la accesibilidad web dependerá del nivel de soporte que proporcionen las ayudas técnicas como los lectores de pantalla.
  3. Future Web Accessibility: New <input> Types in HTML5: HTML5 define 13 nuevos valores para el atributo type: search, tel, url, email, datetime, date, month, week, time, datetime-local, number, range y color. Estos nuevos controles ofrecen mejoras, ya que las ayudas técnicas como los lectores de pantalla pueden realizar un mejor tratamiento de ellos, y permiten lograr una mejor consistencia entre diferentes sitios web, lo que disminuye su complejidad y facilita su uso por parte de personas con discapacidad cognitiva.
  4. Future Web Accessibility: HTML5 <input> Extensions: HTML5 también añade cuatro nuevos atributos a la etiqueta <input> que pueden mejorar la accesibilidad y el manejo de los formularios: autofocus, placeholder, required y pattern.
  5. Future Web Accessibility: SVG: SVG es una especificación de W3C que permite crear gráficos escalables. Incorpora ciertas características que permiten que los gráficos creados sean accesibles.
  6. Future Web Accessibility: canvas: el nuevo elemento <canvas> proporciona un área en blanco en la página web que permite dibujar en 2D lo que se quiera mediante un lenguaje de script como JavaScript. Este elemento plantea bastantes retos de accesibilidad.
  7. Future Web Accessibility Updates: en este artículo refleja algunos cambios que se han producido en los últimos meses y que afectan a los artículos anteriores. En concreto, se refiere al elemento <video>, a los gráficos SVG y al elemento <canvas>.