Traductor de lengua de signos a habla

MotionSavvy es un sistema automático de traducción de lengua de signos a habla. Se supone que saldrá al mercado en otoño de 2015.

Daltónicos que pueden ver colores

Daltónicos viendo algunos colores por primera vez explica que se han desarrollado unas gafas para que los daltónicos puedan ver los colores, ¿será verdad?

Subtítulos en HTML5

Una breve explicación sobre los subtítulos en HTML5: HTML5 Video Captioning. El texto dice:

How does HTML5 simplify web video and accessibility?

HTML5 is a major step forward for standardizing video across web browsers and devices, and thus simplifying closed captioning. The idea is that web video will be based on an open, universal standard that works everywhere. HTML5 natively supports video without the need for third party plugins. A video can be added to a web page using the video element, which makes it almost as simple as adding an image. The track element can then be used to display closed captions, subtitles, text video descriptions, chapter markers, or other time-aligned metadata.

Herramienta de revisión de la accesibilidad web brasileña

He localizado esta herramienta de revisión brasileña, daSilva. Lo he probado un par de veces y no funciona.

Aprende Accesibilidad Web paso a paso

Aprende accesibilidad web desde cero, paso a paso, a tu ritmo, gratis y de la mano de expertos, apúntate a Aprende Accesibilidad web paso a paso.

Y el sitio web del curso: accesibilidadweb.es

El temario resumido del curso es:

1. Bienvenida al curso
2. Qué es la accesibilidad web
3. Las personas con discapacidad y la Web
4. Pautas y leyes
5. Contenido accesible
6. Navegación accesible
7. Diseño accesible
8. Interacción accesible
9. Accesibilidad y posicionamiento
10. Análisis y evaluación de la accesibilidad
11. Conclusiones

Y el vídeo de presentación del curso:



Transcripción del vídeo "Aprende Accesibilidad Web paso a paso"

Usar anuncios como captcha

Solve Media es una empresa de publicidad que ofrece un sistema de captcha bastante curioso: se muestran anuncios con algunas palabras que el usuario debe teclear como en un captcha normal.

Pero por muy curioso que sea, este sistema sigue siendo no accesible, y recordemos que los captchas suelen uno de los primeros problemas a los que se enfrentan algunos grupos de usuarios como las personas ciegas.

Los orígenes de la WAI

El World Wide Web Consortium (W3C) es un grupo internacional e independiente que define los protocolos y estándares para la Web. El W3C desarrolla muchas de las tecnologías que hacen que la Web funciones, como por ejemplo las especificaciones de los lenguajes HTML y CSS que se emplean para escribir las páginas web, o la especificación del protocolo HTTP que se emplea para transmitir las páginas web por Internet.

Una de iniciativas del W3C es el desarrollo de pautas (normas o estándares) de accesibilidad web. Para ello el W3C lanzó la Iniciativa para la Accesibilidad Web (Web Accessibility Initiative, WAI) en abril de 1997. El objetivo de la WAI es desarrollar las pautas de accesibilidad web.

En WAI early days se explica el nacimiento de la WAI.

HTML Accessibility API Mappings 1.0

HTML Accessibility API Mappings 1.0 es una nueva especificación que está desarrollando el W3C. Por ahora está en estado "Editor's Draft".

El resumen dice:

HTML Accessibility API Mappings (HTML-AAM) defines how user agents map HTML 5.1 [HTML51] elements and attributes to platform accessibility application programming interfaces (APIs). It leverages and extends the Core Accessibility API Mappings 1.1 [CORE-AAM] and the Accessible Name and Description: Computation and API Mappings 1.1 [ACCNAME-AAM] for use with the HTML 5.1 host language. Documenting these mappings promotes interoperable exposure of roles, states, properties, and events implemented by accessibility APIs and helps to ensure that this information appears in a manner consistent with author intent.
The HTML-AAM is part of the WAI-ARIA suite described in the WAI-ARIA Overview.

Por ejemplo, en la siguiente imagen podemos ver que la etiqueta aside se corresponde con el role complementary de WAI-ARIA, y la etiqueta body con el role document.

Aprende Accesibilidad web paso a paso en la televisión

Me han avisado de algo muy interesante...

En el programa “Sorteos ONCE” de TVE, emitido el día 5 de abril, se informó de que desde la Cátedra Telefónica de la Universidad de Alicante se ha  puesto en marcha el curso gratuito Aprende Accesibilidad web paso a paso.

El vídeo no lo puedo insertar, se puede visualizar en Sorteo ONCE - 05/04/15.

Este es el temario resumido del curso:

1. Bienvenida al curso
2. Qué es la accesibilidad web
3. Las personas con discapacidad y la Web
4. Pautas y leyes
5. Contenido accesible
6. Navegación accesible
7. Diseño accesible
8. Interacción accesible
9. Accesibilidad y posicionamiento
10. Análisis y evaluación de la accesibilidad
11. Conclusiones

Y el vídeo de presentación del curso:



Transcripción del vídeo "Aprende Accesibilidad Web paso a paso"

Las pautas de accesibilidad web del W3C

Ayer se publicó el artículo Las pautas de accesibilidad web del W3C, mi cuarta contribución al Observatorio de la Accesibilidad de la Confederación Española de Personas con Discapacidad Física y Orgánica (COCEMFE).

Las APIs de accesibilidad

Muy interesante el artículo Accessibility APIs: A Key To Web Accessibility publicado en Smashing Magazine.

El artículo repasa la evolución de las APIs de accesibilidad y cómo es su relación con los productos de apoyo como los lectores de pantalla.

La sordoceguera

Hace unos días apareció en el periódico El País el artículo “Es terrible ser ciego y sordo, pero no es el final” que anuncia el estreno de la película La historia de Marie Heurtin, una historia similar a El milagro de Ana Sullivan. Ambas historias relatan la vida de una chica sordociega.

Yo he tenido la oportunidad de conocer a dos personas sordociegas, las dos también mujeres, como en la película. A las dos las he entrevistado, la entrevista de la primera la publiqué hace tiempo, la segunda entrevista la publicaré en breve.



Transcripción Entrevista a Santi Trigueros, una persona sordociega (parte 1)



Transcripción Entrevista a Santi Trigueros, una persona sordociega (parte 2)



Transcripción Entrevista a Santi Trigueros, una persona sordociega (parte 3)

Cansados de los captchas

He encontrado dos noticias sobre los captchas de hace un par de años que básicamente dicen lo mismo:

• Blind Federation criticises Captcha security test
• The blind community has had enough of CAPTCHA

En la primera, la  National Federation for the Blind de Estados Unidos denució que una petición para que el material impreso fuera más accesible para las personas ciegas no se pudo firmar porque el formulario alojado en la web de la Casa Blanca (We the People) tenía un captcha. En el artículo se comenta que los captchas son el elemento de una página web más molesto para las personas ciegas que navegan por la Web.

En la segunda noticia se comentan los mismos problemas pero en la otra parte del mundo, en Australia.

Lo no accesible es ilegal

Un mensaje de Juan Luis Quincoces, director general de CENTAC:

Un captcha de Yahoo

El otro día me encontré este captcha de Yahoo:

Los captchas se suelen situar como una de las primeras barreras de accesibilidad que presentan las páginas web.

Hace tiempo publiqué unos vídeos sobre los problemas de accesibilidad de los captchas:

¿Qué es un CAPTCHA? Problemas de accesibilidad (1/2):


¿Qué es un CAPTCHA? Problemas de accesibilidad (2/2):

Relación entre la accesibilidad web y los dispositivos móviles

El 26 de febrero el W3C publicó el primer borrador de Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile. El resumen dice:

This document, “Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile” describes how the Web Content Accessibility Guidelines (WCAG) 2.0 [WCAG20] and its principles, guidelines, and success criteria can be applied to mobile web content, mobile web apps, native apps, and hybrid apps using web components inside native apps. It provides informative guidance, but does not set requirements. It also highlights the relevance of the User Agent Accessibility Guidelines 2.0 [UAAG20] in the mobile context.

Unas personas con discapacidad que se olvidan del resto de las personas con discapacidad

Ayer tuve una agradable conversación con una de mis doctorandas. Mi doctoranda me contaba que en un congreso habían presentado un blog para personas sordas en el que la gente no escribe, sino que manda vídeos "hablando" con la lengua de signos. Por cierto, ahora mismo estoy en Ecuador y aquí usan el término "lengua de señas".

"¿No ves el problema que presenta ese blog?", le pregunté a mi doctoranda. Después de unos segundos me contestó "¿Es discriminatorio? ¿Los que no sabemos la lengua de signos no podemos utilizar ese sitio web?"

"Exacto", y en ese momento me puse en plan inquisidor y... mejor no lo cuento.

Pero lo que sí que puedo contar es un ejemplo de lo que le conté. Examinemos el sitio web de la Confederación Estatal de Personas Sordas. ¿Es accesible?

Según eXaminator, no es accesible, obtiene una calificación de 3.0:

Los errores, imágenes sin texto alternativo, enlaces con el mismo texto pero destinos diferentes y problemas con los manejadores de eventos:

Si examinamos el código fuente, descubrimos cosas como unas cuantas imágenes sin texto alternativo que son botones porque tienen definido el evento onclick:

Y en la página de contacto nos encontramos un captcha:

Y si vemos el código fuente, el formulario no está correctamente etiquetado (y además está maquetado con tablas):

Y el botón de envío es una imagen que no tiene texto alternativo:

Y de navegar correctamente por teclado ya ni hablamos... Hay más cosas, pero con esto ya es suficiente.

Bueno, ¿debería ser este sitio web accesible? Pues, por un lado deberían dar ejemplo y deberían garantizar que su sitio web es accesible para todo el mundo, no sólo para las personas sordas.

Y por otro lado, en el sitio web aparece el logo del Ministerio de Sanidad, Servicios Sociales e Igualdad, quizás porque recibe subvenciones de dicho ministerio. Si es así, la ley indica que el sitio web debería ser accesible.

Denuncia contra Scribd

Scribd, el sitio web de publicación de documentos como libros y revistas ha sido denunciado por una persona ciega en Estados Unidos porque no es accesible: Scribd Faces Setback in Lawsuit Over Accessibility. Según la noticia, parece que Scribd tiene todas las de perder, ya que el juez ha aceptado la demanda presentada en julio de 2014.

Sin embargo, yo me pregunto, ¿hasta que punto Scribd puede ser denunciado? No conozco todo el modelo de negocio de Scribd, sé que cobran por acceder a todo o parte del contenido publicado, pero también sé que parte del contenido es publicado por cualquier persona, es decir, no es contenido creado por Scribd. Por ejemplo, he buscado y he encontrado que alguien ha publicado algunos de mis libros, sin pedirme permiso, en Scribd:

• Programación en Internet: Clientes web
• Programación de servidores web
• Programación de aplicaciones web: historia, principios básicos y clientes web

¿Quién debería asegurar que esos libros son accesibles? ¿Scribd? ¿Yo, que no sabía que mis libros estaban ahí? ¿El que ha subido los libros sin decirme nada?

No diseñar contenido de un modo que se sepa podría provocar ataques, espasmos o convulsiones

Las Pautas de accesibilidad para el Contenido Web 2.0 (WCAG 2.0) tienen una pauta un poco "extraña":

Pauta 2.3 Convulsiones: No diseñar contenido de un modo que se sepa podría provocar ataques, espasmos o convulsiones.

Esta pauta tiene como objetivo evitar ataques epilépticos (epilepsia fotosensible) y otras complicaciones derivadas de la fotosensibilidad que presentan ciertas personas cuando una imagen parpadea con cierta frecuencia.

El caso más conocido fue el de la serie de dibujos animados Pokémon. En diciembre de 1997 se emitió el capítulo Dennō Senshi Porygon que causó supuestos ataques epilépticos en 12.000 niños (Pokémon contagion: photosensitive epilepsy or mass psychogenic illness?). Hay dudas de que todos fueran ataques reales, se cree que fue más producto de una "histeria colectiva", pero sí que hay varios cientos de casos que fueron reales.

Parece que la peor combinación es el rojo con el cyan, justo la que apareció en ese capítulo de Pokémon: A study of the effect of color photostimulation from a cathode-ray tube (CRT) display on photosensitive patients: the effect of alternating red-cyan flicker stimulation.

Por cierto, este fue el fragmento culpable:

Si no funciona el anterior, quizás funcione este:

Cómo mostrar el atributo longdesc en Internet Explorer

Mozilla Firefox incluye una opción en el menú contextual de las imágenes para acceder a longdesc desde la versión 25.

En Google Chrome se puede instalar un complemento como Long Descriptions in Context Menu.

¿Y en Internet Explorer? Es el más divertido, el usuario lo puede programar, tal como explican en Configuring Internet Explorer to handle longdesc.