Unos monos "mueven y sienten" objetos virtuales utilizando sólo el cerebro

En este blog he escrito varias veces sobre este tema (la úlitma fue Situación actual del control mental del ordenador): controlar el ordenador (y cualquier otra cosa que se pueda controlar a través de un ordenador, es decir, casi cualquier cosa) con el pensamiento.

Acabo de leer el artículo Monkeys "Move and Feel" Virtual Objects Using Only Their Brains. Un paso más: ahora, además de poder realizar ciertas acciones solo con el pensamiento, en el artículo se presenta la primera demostración de interacción bidireccional entre un cerebro y un elemento virtual, ya que además de realizar la acción, también reciben una respuesta directamente en el cerebro. En concreto, en este experimento unos monos movían el brazo virtual de un avatar y recibían una respuesta que indicaba la textura de los elementos por lo que pasaba el brazo virtual.

En la noticia podemos leer:

"Someday in the near future, quadriplegic patients will take advantage of this technology not only to move their arms and hands and to walk again, but also to sense the texture of objects placed in their hands, or experience the nuances of the terrain on which they stroll with the help of a wearable robotic exoskeleton," said study leader Miguel Nicolelis, MD, PhD, professor of neurobiology at Duke University Medical Center and co-director of the Duke Center for Neuroengineering.

"This is the first demonstration of a brain-machine-brain interface (BMBI) that establishes a direct, bidirectional link between a brain and a virtual body," Nicolelis said.

Problemas de contraste en la página de El País

La página principal del periódico El País presenta numerosos problemas de contraste que pueden ocasionar problemas entre los usuarios que presenten sensibilidad reducida al contraste y entre los usuarios que tengan problemas de contraste debido al contexto de uso

Hace tiempo que escribí sobre este tema en la entrada ¿Por qué no cambian los colores en el periódico El País? Desgraciadamente, y aunque mandé un correo al periódico El País, todo sigue igual.

Para denunciar esta situación, he preparado el siguiente vídeo:

Recursos sobre problemas de visión

Un par de páginas con numeros enlaces a sitios web con información sobre problemas de visión, simuladores, etc.:

• Simulation of Vision Conditions
• Vision Simulation

Y también el usuario

Ayer escribí una entrada sobre la accesibilidad de Flash, y como respuesta recibí dos comentarios muy interesantes.

El primero estaba relacionado principalmente con el siguiente párrafo:

Hace unos días me hicieron una consulta sobre este tema, sobre si Flash puede ser accesible. La contestación rápida y corta es "Sí, puede ser accesible". Todo depende del desarrollador (y también del usuario final).

Y el segundo con el siguiente párrafo:

Además, las características de Flash sólo son accesibles en ciertos sistemas operativos, bajo ciertos navegadores y mediante el uso de algunos lectores de pantalla.

 En la página Essential Components of Web Accessibility podemos encontrar el siguiente gráfico:

Para el WAI, la accesibilidad se basa en tres pilares:

• La accesibilidad de las herramientas de autor (Authoring Tool Accessibility Guidelines, ATAG) .
• La accesibilidad de los agentes de usuario (User Agent Accessibility Guidelines, UAAG).
• La accesibilidad del contenido web (Web Content Accessibility Guidelines, WCAG).

Para que la accesibilidad funcione, los usuarios finales también tienen que poner de su parte. Y claro está, los fabricantes del software que emplean los usuarios finales (por mucho que los usuarios quieran, si los fabricantes de software no aplican la accesibilidad, poco pueden hacer los usuarios finales). Para ambos, el WAI ha desarrollado las User Agent Accessibility Guidelines.

¿Qué tiene que hacer el usuario final? El usuario final tiene que intentar utilizar el software más apropiado y tiene que asegurarse de que su software esté actualizado.

Por ejemplo, de nada sirve que un desarrollador web utilice las últimas características de accesibilidad de HTML5 o de WAI-ARIA en sus páginas web, si el usuario sigue utilizando el sistema operativo Microsoft Windows 95, con el navegador Microsoft Internet Explorer 6 y el lector de pantallas JAWS 6. Todas las últimas características de accesibilidad que el desarrollador pueda implementar pasarán desapercibidas para ese usuario final.

El caso de Flash, claro está, es un caso extremo de esta situación. O más bien se encuentra totalmente fuera de esta explicación, ya que no se trata de una tecnología estándar y por tanto los usuarios "no estamos obligados a aceptarlo". Pero sí que hay otras situaciones donde, aún empleando los estándares, habrá usuarios que tendrán problemas de accesibilidad porque el sistema que emplean no reconoce algunas características accesibles. En ese caso, yo creo que la responsabilidad es del usuario final: el usuario final tiene que estar preparado para aceptar las últimas características en materia de accesibilidad web.

Flash accesible

La accesibilidad de Flash es un tema que muy pocas veces he tratado, por principios y "por manía". Que recuerde, sólo he escrito un par de veces sobre este tema, una era cuando hacía referencia a un tutorial sobre accesibilidad en diferentes medios, y la otra fue cuando escribí sobre el consejo 3 "Multimedia" de la Guía breve para crear sitios web accesibles del W3C.

Hace unos días me hicieron una consulta sobre este tema, sobre si Flash puede ser accesible. La contestación rápida y corta es "Sí, puede ser accesible". Todo depende del desarrollador (y también del usuario final).

[Actualización: oihana me ha dejado un comentario muy interesante:

Pues precisamente por los motivos que has expuesto (sólo es accesible en parte y en algunos sistemas y navegadores) la respuesta creo que debería ser: "No, Flash no es accesible".

Por lo que he aprendido hasta ahora de accesibilidad, una cosa no puede ser parcialmente accesible, o lo es o no lo es. ¿No?

Comparto parcialmente este comentario. Aunque en el caso de Flash lo comparto plenamente: para mí Flash no es una tecnología estándar, es una tecnología propietaria con graves problemas de accesibilidad y, por tanto, no se debería emplear. Pero una puntualización sobre "o lo es o no lo es".

Asegurar que un sitio web es 100% accesible es un mito. Debido al amplio rango de discapacidades que existen, es imposible crear un sitio web que tenga en cuenta todo ese rango. Por tanto, la accesibilidad es una propiedad continua (hay diferentes niveles de accesibilidad), no una propiedad constante (es o no es). Por supuesto, el objetivo es lograr la máxima accesibilidad posible para llegar al máximo número de usuarios, pero el 100% de accesibilidad es un mito (por ejemplo, el idioma también se podría considerar una "discapacidad" y, por tanto, deberíamos ofrecer los sitios web en todos los idiomas que existen para no discriminar a nadie.
]

Flash siempre ha tenido graves problemas de accesibilidad. Recordemos el artículo de Jakob Nielsen Flash: 99% Bad del año 2000, en el que además de señalarse los problemas de accesibilidad de Flash, se destacaban otros muchos problemas que afectan a todos los usuarios.

A partir de la versión 6 de Flash se introdujeron ciertas características de accesibilidad, como el texto alternativo. Desde entonces, la accesibilidad de Flash ha ido mejorando, pero a día de hoy todavía hay algunas características básicas y sencillas, como indicar el idioma de un fragmento de texto (punto de verificación 4.1 "Identifique claramente los cambios en el idioma del texto del documento y en cualquier texto equivalente" de las Pautas de Accesibilidad al Contenido en la Web 1.0), que todavía no se pueden hacer (sólo se puede indicar el idioma de todo el objeto Flash).

Sin embargo, por mucho que mejore la accesibilidad de Flash, siempre existirá un problema: no es una tecnología estándar y siempre presentará problemas. La pauta 11 de las Pautas de Accesibilidad al Contenido en la Web 1.0 nos aconseja que utilicemos las tecnologías y pautas de W3C siempre que sea posible.

Además, las características de Flash sólo son accesibles en ciertos sistemas operativos, bajo ciertos navegadores y mediante el uso de algunos lectores de pantalla.

Además, hoy en día existen multitud de diferentes dispositivos que permiten navegar por la Web, y muchos de ellos no tienen soporte para Flash. Por ejemplo, hace unos días estuve probando el navegador web que incorpora Kindle, el lector de libros electrónicos de Amazon. Este dispositivo no soporta ni Flash ni los applets realizados en Java, por lo que muchas páginas web "desaparecen misteriosamente".

Pero además, hoy en día HTML5 puede sustituir a Flash en la mayoría de las situaciones en que se usa. En realidad, desde hace tiempo ya se podía sustituir a Flash por simple HTML + CSS + JavaScript + DOM. Estoy cansado de navegar por sitios web donde se emplea Flash simplemente para lograr un efecto visual en la barra de navegación principal (por ejemplo, para crear menús desplegables), cuando eso se puede crear con las tecnologías estándar desde hace años.

Para terminar, y volviendo al tema de cómo crear Flash accesible, unas referencias interesantes donde se puede encontrar información sobre este tema:

• WebAIM, Creating Accesible Flash Content: un tutorial con cuatro partes.
• Adobe, Best Practices for Accessible Flash Design: consejos generales y las características específicas de accesibilidad de Flash.
• Adobe, Creating Accessible Content with Flash Professional: de enero de 2011, así que está bastante actualizado.
• The Paciello Group, WCAG 2 Compliance With Flash: presentación de un seminario sobre la accesibilidad de Flash y WCAG 2.0.
• W3C, Flash Techniques for WCAG 2.0: las técnicas de WCAG 2.0 que son específicas para Flash.

Guía sobre la normalización en la accesibilidad TIC

Ayer asistí en Madrid a la presentación de la Guía sobre la normalización en la accesibilidad TIC, que ya tenemos disponible para descargar en formato PDF de forma gratuita.

Esta guía es un trabajo excelente que sistematiza y cataloga las normas de diferentes organismos (internacionales y nacionales) que hacen referencia a la accesibilidad de las Tecnologías de la Información y la Comunicación. En concreto, las normas están clasificadas en normas de Alto nivel, de Hardware y equipos, de Software, de Usuario y de Contenido.

Accesibilidad en primera persona

Interesante vídeo de una presentación que realizó una persona ciega en la Universitat Jaume I de Castellón:

Accesibilidad en primera persona from decharlas.com on Vimeo.

Una introducción sencilla a la accesibilidad web

El artículo A simple introduction to web accessibility de Ian Hamilton explica de una forma sencilla qué es la accesibilidad web. Según Ian, el primer paso es conocer quienes son las personas con discapacidad y cuales son sus necesidades.

Sólo hay cuatro tipos de discapacidad que estén relacionadas con la accesibilidad web: visual, auditiva, motora y cognitiva.

Discapacidad visual
Algunos tipos de discapacidades de este grupo son la miopia, la ceguera al color (daltonismo), el glaucoma y la ceguera completa.

Los consejos que proporciona son:

• No dependas de pistas visuales
• Utiliza colores con suficiente contraste
• Utiliza un tamaño de texto adecuado
• Haz que los enlaces sean fácilmente distinguibles
• No dependas únicamente del color
• Emplea los encabezados (h1, h2, h3, ...) correctamente
• Garantiza que los enlaces tengan sentido fuera de contexto
• Evita la ejecución automática de vídeos y audios

Discapacidad auditiva
Algunos tipos de discapacidad de este grupo son el trauma acústico, el trastorno de procesamiento auditivo y la sordera completa.

Como la Web es un medio principalmente visual, los usuarios con problemas auditivos no suelen tener muchos problemas.

El principal problema son los vídeos y la solución es muy sencilla, incluir subtítulos, aunque a veces puede ser costosa. Por ello, una solución alternativa es ofrecer la transcripción del audio.

[Nota: el autor de este artículo no explica que las personas con discapacidad auditiva pueden tener problemas de comprensión, por lo que la legibilidad de un texto es un aspecto a tener en cuenta si se quiere lograr una mejor accesibilidad]

Discapacidad motora
Algunos tipos de discapacidad de este grupo son la parálisis cerebral, el Parkinson y la distrofia muscular.

Se tiene que garantizar que una página se puede emplear exclusivamente con el teclado.

Además, hay que evitar que los elementos con lo que se puede interactuar, como por ejemplo los enlaces y los botones de los formularios, no son muy pequeños y no están muy cerca unos de otros. Además, hay que evitar las interacciones complicadas, como "drag&drop", y los interfaces de usuario en movimiento.

Discapacidad cognitiva
Algunos tipos de discapacidad de este grupo son el síndrome de Down, el autismo y la dislexia.

Las personas con discapacidad cognitiva tienen problemas para procesar la información. El consejo más obvio es simplificar la información que se ofrece, evitar un lenguaje complicado y plagado de acrónimos. Además, también ayuda a un gran porcentaje de usuarios que tienen problemas de comprensión.

También hay que evitar las animaciones y elementos en movimiento que puedan distraer al usuario.

También hay que evitar los elementos inesperados y la ejecución automática de los vídeos.

Simposio online sobre medidas de la accesibilidad web

El W3C, a través del WAI, organiza Website Accessibility Metrics Online Symposium el próximo 5 de diciembre de 2011. En la petición de artículos (call for papers) podemos ver que el plazo para enviar propuestas finaliza el próximo día 1 de noviembre.

El objetivo principal de este simposio es reunir, analizar y discutir experiencias prácticas relacionadas con la medición de la accesibilidad web.

Guía sobre Normalización en la Accesibilidad de las TIC

El próximo martes 27 de septiembre de 2011 se presentará en Madrid, en el Salón de Actos del Ministerio de Industria, Turismo y Comercio, la Guía sobre Normalización en la Accesibilidad de las TIC, editada por el Centro Nacional de Tecnologías de la Accesibilidad (CENTAC).

En el apartado Documentación se podrá descargar próximamente la guía.

Curso "Accesibilidad y estándares web"

La Universidad Politécnica de Valencia organiza el curso Accesibilidad y estándares web. Este curso es en realidad la asignatura Accesibilidad y estándares web que pertenece al Máster en Aplicaciones Multimedia. La descripción del curso es:

Curso teórico – práctico, de estudio y aplicación de las directivas de accesibilidad marcadas en la norma une 139803:2004, de obligado cumplimiento en España bajo las condiciones que se describen en la Ley 56/2007 de 28 de diciembre (Ley de Medidas para el Impulso de la Sociedad de la Información) cuyo objetivo es facilitar el acceso Web a la mayoría de los
usuarios, independientemente de sus capacidades, tipo de plataforma, navegador, idioma o localización.

Máster en sociedad de la información y del conocimiento, pero sin accesibilidad

Ayer recibí un correo anunciando el Master on-line en Sociedad de la Información y del Conocimiento, que organiza la Universidad de Santiago de Compostela.

He consultado el programa de materias del máster y me han defraudado dos cosas:

1. La pequeña descripción que se proporciona del programa del máster: sólo aparecen los títulos de las materias que componen el máster, no hay una descripción materia por materia.
2. La total ausencia de alguna referencia a la accesibilidad: es un máster dedicado a la sociedad de la información y del conocimiento, debería de destacar alguna materia dedicada a la accesibilidad o a la inclusión digital de todos los ciudadanos. Sin embargo, no hay ninguna referencia directa a ello. Espero que quizás, escondido en alguna de las materias, al menos se dedique un pequeño espacio de tiempo a hablar sobre este tema.

Además, y simplemente por curiosidad, en un rápido examen (en 1 minuto) de la accesibilidad de esta página, se pueden encontrar importantes problemas de accesibilidad:

• El HTML de la página no valida, tiene numerosos errores.
• La página no tiene un título significativo.
• No hay ni un solo encabezado.
• Se repiten numerosos enlaces con el mismo texto, como "Abrir", "Ver" y "Oir".

Libros sobre accesibilidad web

Hace unos días, uno de los asistentes a mi seminario sobre accesibilidad web que impartí en Quito me mandó un correo electrónico:

Me pareció interesante el seminario sobre accesibilidad web realizado en la EPN, es por ello que recurro a ud. para que me ayude con información sobre libros que contengan información sobre técnicas y evaluación en lo que se refiere a accesibilidad web. Ya he revisado los documentos que tratan de la accesibilidad web que están disponibles en la W3C en la parte de accesibilidad.

Hasta el momento he hallado este libro: Web Accessibility: Web Standards and Regulatory Compliance, sin embargo necesito recabar información de otras fuentes, y así poder implantar en un sitio web.

Desde ya le agradezco por la respuesta.

Mi respuesta fue:

En mi blog tengo un apartado sobre libros:

http://accesibilidadenlaweb.blogspot.com/search/label/Libros

Ahí puedes encontrar libros de pago y gratuitos.

Te sugiero que empieces por el libro Dive into accessibility, que lo puedes encontrar traducido al castellano Sumérjase en la accesibilidad.

Pregunta sobre los captchas

Me pregunta un lector de este blog:

Buen dia Sr. Sergio, acabo de ver el video de la soluciones de captcha, quiero implementar una
pero no tengo muchas nociones de programacion, el catpcha que quiero implemetar a mi web es del tipo:
http://diario16.pe/noticia/8812-organizan-iv-muestra-cientaifica-y-tecnolaogica-juvenil-en-trujillo

Le estaria agradecido si me indicaria un tutorial  o paquete de descarga para implementar un captcha de ese tipo.

Gracias
un cordial saludo.

Jorge Luis

 Los vídeos a los que hace referencia este lector son los siguientes:

• ¿Qué es un CAPTCHA? Origen y uso
• ¿Qué es un CAPTCHA? Futuro
• Problemas de accesibilidad de los captcha (1/2)
• Problemas de accesibilidad de los captcha (2/2)

El sistema que le recomiendo a este lector, y es el que empleo yo en mis desarrollos, es reCAPTCHA, un sistema desarrollado inicialmente en la Universidad Carnegie Mellon y que posteriormente fue adquirido por Google y que ahora ofrece de forma gratuita. Además, este sistema ofrece un captcha sonoro como alternativa al captcha visual, por lo que "se supone" que es accesible para las personas con problemas de visión.

Materiales del seminario "Accesibilidad en el Diseño de Aplicaciones Web"

Ya están disponibles los materiales del seminario Accesibilidad en el Diseño de Aplicaciones Web que impartí hace unos días en la Escuela Politécnica Nacional en Quito (Ecuador).

En el Congreso y en el Senado siguen haciendo las cosas fatal

Acabo de leer en el periódico El Mundo el artículo de opinión Transparencia, pero no accesibilidad. Me ha llamado la atención esta noticia, claro está, por la palabra accesibilidad.

Desgraciadamente el artículo no es sobre la accesibilidad en general, ni mucho menos sobre la accesibilidad web. El artículo es sobre la publicación de bienes y rentas de los congresistas y senadores españoles. El artículo comenta la mala forma en que ha sido publicada esta información.

Entre los problemas que describe, sí que hay uno que está totalmente relacionado con la accesibilidad web, el problema de los PDF no accesibles:

Si lo anterior parece grave, lo es mucho más que la información se publicase como un PDF de imagen -un formato inaccesible para el análisis de datos- y diputado a diputado.

Efectivamente, un PDF que contiene una imagen escaneada no es accesible. Para que un PDF sea accesible tiene que contener texto y además tiene que estar etiquetado (tagged).

Pero bueno, ya sabemos que en el Congreso y en el Senado de España no saben muy bien cómo usar las nuevas tecnologías, como ya comenté hace unos meses en El Senado se gastará 350.000 euros al año en traducciones, pero es incapaz de tener una página web accesible. La página del Senado de España sigue sin ser accesible a día de hoy (y lo que le queda...)

El municipio será accesible, pero su sitio web no

Después del éxito del seminario sobre accesibilidad web que impartí hace unos días en la Escuela Politécnica Nacional de Quito (Ecuador), me he tomado unos días de vacaciones.
Ahora me encuentro en Baños, Baños de Agua Santa, en la Sierra Central. He entrado a visitar el sitio web oficial del ayuntamiento y me he encontrado con un anuncio que indica que es un municipio accesible y que además recibió el Permio Reina Sofia 2009 de Accesibilidad Universal de Municipios.

Sin embargo, el contenido principal de esa página es una imagen, por lo que una persona ciega no podrá leer el mensaje del Vicepresidente de la República. Por tanto, el municipio será accesible en el medio físico, pero en Internet no es accesible, así que de "accesibilidad universal", poco.

[Actualización 25/01/2012]

Parece que han actualizado el sitio web de Baños, pero este error en la página Baños Ecuador - Ciudad accesible sigue igual, tal como podemos ver en las siguientes imágenes:

Con imágenes

Sin imágenes

Entrevista en la Escuela Politécnica Nacional

Hace unos días me hicieron una entrevista en la Escuela Politécnica Nacional para publicitar el seminario que voy a impartir en breves minutos.

El seminario en Twitter

Los alumnos de sistemas de la Escuela Politécnica Nacional han creado el hashtag #aweb_epn para que la gente pueda seguir y participar en el seminario a través de Twitter.

Retransmisión por Internet del seminario "Accesibilidad en el Diseño de Aplicaciones Web"

Respecto el seminario sobre accesibilidad web que voy a impartir este viernes 2 de septiembre en la Escuela Politécnica Nacional de Quito (Ecuador), va a ser retransmitido en directo y en abierto a través de su canal de streaming.

La retransmisión comenzará sobre las 9:15 horas de Ecuador, las 16:15 en España.

Me han dicho que se va a habilitar un "hashtag" en Twitter para que la gente pueda hacer preguntas. En cuanto lo conozca, lo dará a conocer por aquí.

Además, también me han dicho que se pretende publicar en Internet algún vídeo resumen del seminario, pero eso será unas semanas después porque lo tendrán que editar.

Seminario Internacional “Accesibilidad en el Diseño de Aplicaciones Web”

El próximo viernes 2 de septiembre de 2011, a las 9 horas de la mañana, impartiré un seminario sobre accesibilidad web en la Escuela Politécnica Nacional de Quito (Ecuador). El seminario tiene una duración de 8 horas y en él trataré los siguientes temas:

• ¿Qué es la accesibilidad web?
• ¿Accesibilidad = usabilidad?
• Ayudas técnicas para los discapacitados
• Pautas de accesibilidad
• Herramientas
• Legislación y estándares
• Tendencias

Una vez finalizado el seminario, publicaré los materiales en el apartado de cursos de mi sitio web Accesibilidad web.

Más información: Seminario Internacional "Accesibilidad en el Diseño de Aplicaciones Web"
Más información: Accesibilidad en el Diseño de Aplicaciones Web - Seminario

Versión de texto de una página web

Textise es una herramienta online que permite obtener una versión "sólo texto" de cualquier página web que esté publicada en Internet. Además, también dispone de un complemento para Firefox que permite obtener la versión sólo texto con una simple pulsación.

Por ejemplo, a continuación se muestra la versión sólo texto de mi sitio web Accesibilidad web:

Nuevo dispositivo para ver con las manos

En el periódico El País han publicado la noticia Ver con las manos. La noticia dice:

Tocar vale más que mil palabras. Así lo sienten ocho de los 18 ciegos que probaron el dispositivo táctil creado por un grupo de 13 investigadores (médicos, ingenieros y psicólogos) de la Universidad Complutense de Madrid. El producto, en el que ya se han invertido 1.460.000 euros, estará en el mercado en seis meses y costará entre 2.000 y 3.000 euros. Unos 80.000 ciegos españoles y más de 40 millones en el mundo podrán beneficiarse.Se trata de unas gafas de sol y un estimulador táctil similar a una cajita del tamaño de la palma de la mano, que pesa 200 gramos. En medio de las gafas hay una microcámara con un chip. Este transmite las imágenes al estimulador, que está cubierto de bolitas que se levantan coordinadamente, produciendo un relieve que, sobre la palma de la mano, emula las siluetas captadas por la grabadora. "Evoco las imágenes, las veo simplificadas y en blanco y negro, como si me las dibujaran sobre una pizarra", describe Enrique, de 52 años, uno de los invidentes que participa en el estudio desde su inicio.

[...]

Todos los objetivos se cumplieron. Los ciegos pueden reconocer objetos a ocho o 10 metros de distancia y el 40% siente que ve cuando recibe el estímulo táctil mientras que el 100% (incluidos un grupo de 10 videntes) reconoce los objetos a través del dispositivo. Gracias a esta nueva herramienta, las personas que padecen problemas severos de visión pueden ahora calcular la distancia a la que se encuentran los objetos aunque la percepción todavía no incluye colores y volúmenes. "En la calle es fantástico porque detecta cosas que el bastón no, como los toldos. Por eso hay muchas personas ciegas con marcas en la frente", subraya Enrique con humor. "Al principio era un poco escéptico, pero pasé de sentir cosquillas en la mano a delimitar la costa de Galicia, donde vivo", cuenta fascinado por las posibilidades que le abre el dispositivo. El objetivo a largo plazo es, según el investigador Tomás Ortiz, "reemplazar al bastón y a los perros guía".

En la noticia no se comenta, pero yo también le encuentro utilidad como dispositivo para manejar el ordenador e interactuar con elementos gráficos.

Editor de HTML5

Ernesto Arce, un lector de este blog que reside en Chile, me ha hecho llegar esta información. BlueGriffon es un editor de HTML5 gratuito. Está basado en Gecko, el motor de visualización del navegador Firefox.

Con este editor podemos hacer uso de las nuevas etiquetas semánticas de HTML5 como header, footer, article y section, que permiten mejorar la accesibilidad de las páginas web.

Además, también soporta otros estándares como CSS3, SVG y MathML. Y el editor también puede ser extendido mediante complementos. ¡Y todo gratuito!

Los problemas de las herramientas automáticas de revisión de la accesibilidad

En la entrada de ayer, ¿Son útiles las herramientas automáticas de revisión de la accesibilidad web?, cité algunas referencias en las que se critican las herramientas automáticas de revisión (análisis, evaluación, chequeo o testeo) de la accesibilidad web. Algunos ejemplos de estas herramientas son Cynthia Says, TAW, Total Validator o WAVE.

En el artículo The problem with automated accessibility tools nos explican muy bien los diferentes problemas que pueden mostrar estas herramientas:

• Interpretan de forma literal las pautas: una herramienta automática no tiene "sentido común", comprueba las pautas independientemente de otros factores. Por ejemplo, en WCAG 1.0, la pauta 5.5 Proporcione resúmenes de las tablas indica que se tiene que emplear el atributo summary en las tablas para proporcionar un resumen. Pero puede ser que ya exista un resumen de la tabla en el propio texto de la página, por lo que proporcionar otro resumen en la propia tabla resulta repetitivo y claramente inútil.
• No pueden revisar los problemas relacionados con el contenido: una herramienta automática no puede verificar la estructura del contenido de una página individual ni como se distribuye todo el contenido de un sitio web a través de múltiples páginas. Por ejemplo, una herramienta automática no puede comprobar que el contenido más importante se indica al principio de la página, o que se emplean las listas de forma correcta.
• No pueden revisar muchos problemas relacionados con la codificación: una herramienta automática no puede comprobar que un sitio web funciona correctamente sin Flash o JavaScript, o que la estructura HTML refleja la estructura visual de la página.
• Suelen emplear pautas anticuadas: las herramientas automáticas no suelen estar actualizadas y se ajustan estrictamente a las pautas (WCAG 1.0, WCAG 2.0, Section 508), que al poco tiempo quedan desfasadas por los avances tecnológicos.
• Muchas pautas no se comprueban correctamente: por ejemplo, una herramienta automática puede comprobar si todas las imágenes tienen texto alternativo, pero no puede comprobar si el texto alternativo es relevante y significativo.
• Las advertencias que emiten pueden ser malinterpretadas: mucha gente considera que tiene que corregir las advertencias que emiten estas herramientas, pero en algunas ocasiones al corregir estas advertencias disminuye la accesibilidad de la página.

¿Son útiles las herramientas automáticas de revisión de la accesibilidad web?

Sin duda alguna. Son una gran ayuda, te pueden ayudar a tener una rápida idea del nivel de accesibilidad de una página web, te ayudan a localizar posibles problemas, pero no son "la solución a todos los problemas". Y una pequeña prueba lo demuestra:

• Si analizamos una misma página con diferentes herramientas automáticas de revisión (evaluación) de la accesibilidad web, lo más seguro es que obtendremos diferentes resultados.
• No es difícil hacer una página web que no contenga ningún problema de accesibilidad, pero que una herramienta automática de revisión indique que sí, y al contrario.

 Hay numerosas referencias que nos avisan de esta situación. Por ejemplo, el propio W3C dice:

• Selecting Web Accessibility Evaluation Tools:
  

  What evaluation tools can not do
  
  Many accessibility checks require human judgement and must be evaluated manually using different techniques. Also, in some cases evaluation tools are prone to producing false or misleading results such as not identifying or signal incorrect code. The results from evaluation tools should not be used to determine conformance levels unless they are operated by experienced evaluators who understand the capabilities and limitations of the tools in order to achieve accurate results. Web accessibility evaluation tools can not determine the accessibility of Web sites, they can only assist in doing so.

• Evaluating Web Sites for Accessibility:
  

  No single evaluation tool yet provides comprehensive information or captures all problems with regard to the accessibility of a site; therefore evaluation involves a combination of approaches.

En  la investigación The Web: Access and Inclusion for Disabled People que publicó la Disability Rights Commission (ahora llamada Equality and Human Rights Commission) del Reino Unido en el año 2004 se dice:

It is very significant that the majority of those Checkpoints that this investigation found to be the most important are qualitative, in the sense that they require the exercise of human judgement. Automatic testing tools alone cannot, therefore, verify effective compliance.

Por último, en el artículo Automated testing - How useful is it? se dice:

Many who purchase automated tools believe that they make entirely accurate assessments of web pages. In actual fact, automated testing tools are prone to making mistakes, some of which are discussed in this article.

[Actualización 06/05/2013]
Un par de artículos que explican los problemas de las herramientas automáticas de evaluación de la accesibilidad web:

• Pitfalls of Web Accessibility Evaluation Tools
• The problem with automated accessibility testing tools

Análisis de la página web del Ministerio de Sanidad, Política Social e Igualdad

He publicado el análisis de la accesibilidad de la página de los centros de vacunación internacional del Ministerio de Sanidad, Política Social e Igualdad. Aunque la página dispone de una certificación de su accesibilidad, en la página web analizada existen numerosos problemas de accesibilidad, algunos de ellos muy importantes, como imágenes en enlaces sin texto alternativo, contenido pobremente etiquetado o uso de combinaciones de colores con poco contraste.

La nueva web del Senado

Ya dice el refrán que "las cosas de palacio, van despacio"... y así está ocurriendo con la web del Senado de España.

Recordemos que pasa con la web del Senado, que podemos ver en la siguiente imagen su aspecto a día de hoy:

Tal como mostré en el análisis de su accesibilidad que publiqué en El Senado se gastará 350.000 euros al año en traducciones, pero es incapaz de tener una página web accesible a mediados de enero de 2011, esta página web no ha variado prácticamente nada en los 10 últimos años, por lo que presenta graves problemas de desarrollo, de diseño y de accesibilidad.

También en enero de 2011, el Senado publicó un procedimiento de contratación para la renovación de su página web y otros aspectos de su sistema de información (Quedan 4 días para que la web del Senado empiece a ser accesible).

Este procedimiento de contratación se adjudicó el pasado 14 de junio de 2011 a la empresa Vass Consultoría de Sistemas, S.L. por un importe de 232.500 euros (IVA no incluido, el presupuesto máximo de licitación establecido era de 310.000 euros).

Según el pliego de cláusulas administrativas particulares, el plazo de ejecución de la nueva página web es 6 meses. Por tanto, es de suponer que hasta principios del próximo año, no tendremos la nueva web del Senado. ¡Aún tendremos que esperar un poco para saber si la nueva web es accesible!

Consejos para crear páginas web accesibles

A la mayoría de la gente le gusta las listas de consejos (los tips), porque piensa que con eso es suficiente para lograr o entender algo. En el campo de la accesibilidad web esto es un error, ya que es necesaria una comprensión profunda para llegar a desarrollar páginas web realmente accesibles.

Por ejemplo, el mismísimo W3C tiene Quick Tips to Make Accessible Web Sites. El primero nos dice:

1. Images & animations: Use the alt attribute to describe the function of each visual.

Traducido:

1. Imágenes y animaciones: Use el atributo alt para describir la función de cada elemento visual.

 Sin embargo, la cuestión es más complicada. No todos los elementos visuales necesitan obligatoriamente un texto alternativo, y para aquellos que sí que lo necesitan, a veces no es trivial decidir cuál es el mejor texto alternativo.

De todas formas, aquí recopilo algunas listas de típicos errores o consejos para crear páginas web accesibles que he ido publicando en este blog:

• Los 10 errores de diseño web de 2005 (Top Ten Web Design Mistakes of 2005).
• Siete errores de accesibilidad que no se deben cometer (Seven accessibility mistakes you don't want to make).
• 10 errores en el diseño de aplicaciones web (Top-10 Application-Design Mistakes).
• Más errores de diseño (Top 10 Mistakes in Web Design).
• 10 ideas para mejorar la accesibilidad web en tu blog.

Y los últimos que he encontrado:

• 10 common Web design mistakes to watch our for.
• Common Accessibility Mistakes.
•  Most Common Web Standards and Accessibility Errors.
• Seven Accessibility Mistakes (Part 1), Seven Accessibility Mistakes (Part 2).
• 10 common errors when implementing accessibility.
• Web Accessibility: 10 Common Developer Mistakes.

[Actualización 13/03/2012]

• Accessibility Heuristics
• 10 Simple Web Accessibility Tips You Can Do Today
• 25 Ways To Make Your Website Accessible

Texto en imágenes: un gran error

Pensaba que ya no había gente que hacía esto, pero todavía queda gente por ahí...

Hace años, era muy normal hacer las páginas web solo con imágenes. El texto se ponía en imágenes, porque por aquel entonces no se disponía de la tecnología necesaria para modificar la tipografía del texto al gusto del diseñador (o del cliente).

Por ejemplo, un caso famoso fue la página de promoción del libro de Bill Gates "Business at the Speed of Thought" (hoy en día esa página ya no existe, redirige a una página de Microsoft).

Si se desactivaban las imágenes, ocurría lo siguiente:

Nada, absolutamente nada. Aunque de entrada poner texto en una imagen es un error tremendo que causa muchos problemas de mantenimiento (¿cuánto tiempo tengo que perder para corregir una simple coma en el texto?), existe la solución de emplear el texto alternativo (el atributo alt) para ofrecer una alternativa textual. Sin embargo, en la página de Bill Gates tampoco había texto alternativo.

Por casualidad he encontrado esta página web:

Me ha gustado el efecto con sombra del texto principal. Al revisar el código fuente de la página para ver cómo se había logrado ese efecto, he comprobado que la solución era bien simple: el texto no era texto, era una imagen.

Hoy en día no se deben hacer estas burradas, con CSS3 se puede lograr este tipo de efectos, manteniendo la accesibilidad de la página web.

Cómo elegir un color adecuado para un sitio web

En varias ocasiones he escrito sobre la ceguera al color, popularmente conocida como daltonismo. El artículo Find the perfect colour for your website nos habla de ello, pero además nos explica que elegir un color no es tan sencillo si lo que queremos es crear un sitio web de proyección internacional, ya que los colores tienen distintos significados en distintas culturas.

En este artículo podemos encontrar la siguiente tabla con una serie de colores básicos y su significado en distintos países.

Así, por ejemplo, al cambiar los colores de un sitio web se pueden transmitir diferentes sensaciones:

• El verde y el azul transmiten calma y confianza, aunque el verde es demasiado brillante.
  
• El color rojo recuerda a la sangre y sugiere un daño personal.
  
• El color negro implica profesional/legal, pero también implica muerte.

Características accesibles de HTML/XHTML

La página HTML/XHTML Accessibility Features contiene una lista de los elementos (etiquetas) y atributos de HTML 4.01 (XHTML 1.0) que podemos emplear para mejorar la accesibilidad de un sitio web:

Tablas

• table: el atributo summary
• th/td: el atributo scope
• th/td: el atributo headers

Formularios

• Los elementos fieldset y legend
• El elemento label

Imágenes

• El atributo alt
• El atributo longdesc

En general

• El título de la página: el elemento title
• Los encabezados de la página: los elementos h1-h6
• Las listas de elementos: los elementos ul/ol

Todos los Mozilla Firefox en nuestro ordenador

Hace tiempo escribí la entrada Todos los Internet Explorer en nuestro ordenador, donde comentaba un par de paquetes de software (el más conocido Utilu Internet Explorer Collection), que permiten tener instaladas distintas versiones de Internet Explorer en un mismo ordenador. Esto es algo imprescindible para un buen desarrollador web, ya que permite comprobar cómo verán y percibirán un mismo sitio web distintos usuarios.

Ahora acabo de descubrir Utilu Mozilla Firefox Collection, que es exactamente lo mismo, pero con el navegador Mozilla Firefox. En concreto, la versión actual 1.0.4.9 contiene las siguientes versiones:

• Mozilla Firefox 2.0.0.20
• Mozilla Firefox 3.0.19.0
• Mozilla Firefox 3.5.19.0
• Mozilla Firefox 3.6.19.0
• Mozilla Firefox 4.0.1.0
• Mozilla Firefox 5.0.1.0
• Mozilla Firefox 6.0.0.0 beta 3
• Mozilla Firefox 7.0.0.0 Aurora
• Mozilla Firefox 8.0.0.0 Nightly

Accesibilidad en las redes sociales

El artículo Addressing Accessibility in Social Media ofrece algunos consejos para que el uso de las redes sociales en un sitio web no supongan nuevas barreras de accesibilidad:

User Accounts & Profiles

• Keep it simple
• Make it keyboard friendly
• Provide clear feedback

Social Conversations

• Stop spam, not people: utiliza un CAPTCHA que ofrezca una alternativa accesible.
• Use an accessible editor: por ejemplo, CKEditor.
• Implement accessible widgets

Media

• Provide text alternatives
• Require accessibility
• Prepare guidelines

Keep Accessibility in Mind

Publicada la versión candidata de NVDA 2011.2

Se acaba de publicar la versión candidata del lector de pantallas gratuito NVDA: NVDA 2011.2rc1 Released. Las novedades que incorpora esta versión las podemos encontrar en la página What's New in NVDA.

Encuesta sobre la accesibilidad de las redes sociales

Acabo de encontrar la encuesta Social Media Accessibility Survey que tiene como objetivo determinar las principales barreras de accesibilidad que presentan las redes sociales más conocidas (Twitter, LinkedIn, Facebook and YouTube). Desgraciadamente, no está muy claro quién está detrás de esta encuesta.

Las nueve preguntas de la encuesta son:
1. Do you have a disability affecting the way your browse the web?
Yes
No


2. If so, what kind of disability?
Visual
Hearing
Cognitive
Motor
I do not have a disability
Other (please specify)


3. Do you use assistive technologies to browse the web?
Yes
No


4. If so, what type of assistive technologies do you use?
Screen Readers
Zooming Software
Braille Keyboard
Adapted Keyboard or Mouse
I do not use assistive technologies
Other (please specify)


5-8. How would you rate the following accessibility best practices while using the Twitter.com interfaces? If you feel some best practices are not an issue, choose “N/A” (Not Applicable).
A Real Problem A Slight Problem Not a Problem    N/A
Appropriate Use of Heading and Subheading   
Use of Sufficient Color Contrasts   
Explicit Association of Labels and Form Fields   
Ease of Navigation Using Only the Keyboard   
Text Equivalents for Images   
Compatibility with Assistive Technologies   
Captions or Text Transcripts to Multimedia
Have you encountered any other significant accessibility problems while using the Twitter.com services? If so, please specify:


9. Overall and generally speaking, do you think adopting social medias, as part of a governmental communication strategy is a good idea when it comes to public information?

Oferta de trabajo en accesibilidad web en el MIT

El Computer Science and Artificial Intelligence Laboratory del Massachusetts Institute of Technolog (MIT) ofrece un puesto de trabajo como ingeniero en accesibilidad web: Web Accessibility Engineer. Esta misma oferta de trabajo también la podemos encontrar en la web del W3C: Web Accessibility Engineer.

La tecnología de eye tracking puede ayudar al aprendizaje de los niños con discapacidad

Un sistema de "seguimiento de los ojos" (eye tracking) es un sistema que permite detectar el punto donde un sujeto de estudio está situando su mirada. Estos sistemas se emplean en diversas áreas, como el márketing y la publicidad, el diseño de objetos, la psicología, etc.

Dentro de la accesibilidad y la usabilidad se emplea principalmente con dos fines:

• Para realizar los test de usuario, y también los de accesibilidad: un sistema de eye tracking permite detectar las zonas de una página web que más llaman la atención de un usuario, o al contrario, las zonas que no originan mucho interés.
• Como ayuda técnica para controlar el ordenador: un sistema de eye tracking permite sustituir el ratón del ordenador y permite que el usuario maneje el ordenador simplemente con su mirada.

En el artículo Eye-tracking technology could benefit disabled children nos cuentan otra aplicación de los sistemas de eye tracking: se pueden emplear para mejorar el aprendizaje de los niños con discapacidad:

The team has been working alongside the charity SpecialEffect to design a computer program that uses an eye-tracker to find out exactly how eye movements correspond with the participant’s preferences.
Once a pattern of eye-movements is identified for the user, algorithms manipulate designs on the screen so that they gradually evolve to match each person’s preferences.

Situación actual del control mental del ordenador

Ya he escrito varias veces sobre el control mental, la última el pasado 5 de junio: Otros que se apuntan al control mental del ordenador.

Acabo de encontrar un artículo del 2 de julio de 2011 que resume muy bien la situación actual del control mental: Mind-Controlled, publicado en el volumen 180, número 1, de la revista ScienceNews. El artículo es un poco largo, pero explica muy bien los distintos tipos de dispositivos que existen hoy en día y lo que es realidad y lo que es mito hoy en día.

Un ejemplo de accesibilidad web mal entendida

En el artículo Web Accessibility - What not to do de Jim Thatcher, un gran experto en accesibilidad web, encontramos un buen ejemplo de accesibilidad mal entendida: una página del Gobierno Federal de Estados Unidos, que por la ley Section 508 debe ser accesible (y se ha intentado que sea accesible), que pasa las pruebas automáticas de evaluación de la accesibilidad web, pero que tiene graves problemas de usabilidad.

Existe otra copia de este artículo.

Tutorial sobre la accesibilidad en diferentes medios

accesselearning es un tutorial gratuito desarrollado por la universidad Georgia Institute of Technology en el que explican cómo hacer accesibles diversos tipos de contenidos, como vídeos, presentaciones PowerPoint, documentos PDF y, por supuesto, páginas web.

El contenido de este tutorial es:
   1. Accessibility Issues of Disabilities in Distance Education
   2. Planning for Accessibility in Distance Education
   3. Making PowerPoint Slides Accessible
   4. Making Video Accessible
   5. Making Flash Accessible
   6. Making Word Documents Accessible
   7. Making Excel Documents Accessible
   8. Making PDF Documents Accessible
   9. Making Webpages Accessible
  10. Making Scripts and Java Accessible

El arte de la accesibilidad

El artículo The Art of Accessibility es corto, fácil de leer, pero ofrece algunos puntos de vista sobre la accesibilidad web muy interesantes.

En primer lugar, el autor de este artículo deja claro que la accesibilidad es mucho más importante que el aspecto visual de una página web:

I could try to refute that on the grounds of practical ethics — the aesthetic preferences of one are simply not important, when stacked up against the functional needs of another.

A continuación, el autor pone un par de ejemplos para fundamentar su idea principal: no hay que entender la accesibilidad como algo negativo, como un escollo que nos impide lograr lo que queremos, sino como un desafío que nos invita a hacer las cosas de otra manera.

Además del propio artículo, también son muy interesantes algunos de los comentarios que ha ido dejando la gente.

Denuncias contra sitios web no accesibles en Estados Unidos

En Estados Unidos se toman la accesibilidad web con mucha más seriedad que en España y otros países europeos. Aunque en España tengamos desde finales del año 2007 la LEY 49/2007, de 26 de diciembre, por la que se 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, no tengo noticia de que a nadie se le haya impuesto una sanción por tener un sitio web no accesible e incumplir dicha ley (y otras más). Pero es algo normal que no haya sanciones, ya que las propias administraciones públicas, recordemos el caso de la página web del Senado, son las primeras en incumplir sus propias leyes.

Como digo, en Estados Unidos sí que ha habido algunas denuncias interesantes, como la indemnización histórica de 6 millos de dólares que tuvo que pagar la compañía Target.

Ahora, a través de la página web Disney & Other Recent Web Accessibility Lawsuits me he enterado de que tres mujeres ciegas han denunciado a Disney porque los sitios web de sus parques temáticos no son accesibles. La noticia dice que los sitios web no son accesibles porque "están repletos de vídeos y audios que no pueden ser desactivados por personas que no utilizan el ratón y dependen de un lector de pantallas" y que los sitios web "también contienen contenido Flash que no es accesible para las personas ciegas". En definitiva, lo que todo el mundo sabe que tiene problemas de accesibilidad, pero que mucha gente se empeña en seguir usando.

Nueva campaña a favor de la accesibilidad web

The European Disability Forum acaba de iniciar una nueva campaña para fomentar la accesibilidad de los sitios web. El título de la campaña es Access Denied! y su objetivo principal es que la Unión Europea desarrolle una legislación que asegure que los sitios web de las administraciones públicas y los sitios web que proporcionen servicios básicos sean accesibles tan pronto como sea posible:

The European Commission is due to make a “legislative proposal to ensure public sector websites and websites providing basic services to citizens are fully accessible by 2015.” So we are calling for:

• The European Commission to review our Proposal for a Legal Act on Accessible Websites

• The European Commission to propose binding EU legislation to ensure that public websites and websites delivering basic services of public interest are made accessible as soon as possible

Recordemos que en España existe desde hace años legislación en este sentido, como el Real Decreto 1494/2007 que obliga a las "páginas de internet de las administraciones públicas o con financiación pública" a ajustarse a una serie de normas sobre accesibilidad web, o como la Ley 56/2007 que obliga en un sentido similar a empresas privadas de un volumen mínimo de negocios que ofrezcan una serie de servicios básicos.

Desgraciadamente, esta legislación es muchas veces incumplida (recordemos la nula accesibilidad de la página web del Senado) y lo que ahora hace falta es que se apliquen las medidas sancionadoras que contempla la Ley 49/2007.

Cómo escribir textos accesibles para la Web

La Pauta 14 Asegúrese de que los documentos sean claros y simples de WCAG 1.0 nos indica que hay que emplear un lenguaje claro y sencillo porque algunos usuarios con discapacidades cognitivas o de aprendizaje pueden tener problemas para entender textos largos y complejos.

La Pauta 3.1 Legible: Hacer que los contenidos textuales resulten legibles y comprensibles de WCAG 2.0 nos indica que hay que evitar las palabras inusuales, hay que proporcionar mecanismos para identificar y expandier las abreviaturas y hay que escribir textos con un nivel de lectura adecuado.

En ocasiones anteriores he escrito sobre el concepto de legibilidad, sobre la facilidad de lectura y comprensión de un texto (Consejos para escribir en la Web).

En la página Resources for Writing for Web Accessibility nos ofrecen una buena colección de artículos con consejos para escribir textos legibles y accesibles en las páginas web. Por ejemplo, en el artículo Accessible writing versus writing for a global audience encontramos los siguientes consejos sobre lo que debemos hacer y lo que no debemos hacer:

Usa:

1. Palabras cortas.
2. Frases cortas.
3. Párrafos cortos.
4. Estructura clara: encabezados, viñetas, sangrías, citas (debidamente etiquetados).
5. Oraciones activas: "Leo el libro" en lugar de "El libro es leído por mí".
6. Lenguaje conciso.
7. Formatos claros y sencillos: texto negro sobre un fondo blanco, o similar.

Evita:

1. Jerga.
2. Gramática compleja.
3. Abreviaturas.
4. Argot.
5. Un montón de gráficos.
6. Flash y otro tipo de animaciones.
7. Texto que se muestra como una imagen.

Formato para crear un informe sobre accesibilidad web

En lista de discusión accesoweb se planteó hace una días una pregunta sobre formatos para presentar informes sobre accesibilidad web. Las respuestas que se recibieron (hasta el 1/7/2011) fueron:

• Template for Accessibility Evaluation Reports: es un formato del W3C para comunicar los resultados de evaluar la accesibilidad de sitios web según WCAG 1.0 (es de esperar que esté en preparación un formato parecido para WCAG 2.0, o incluso este mismo formato se puede adaptar fácilmente). Este formato consta de los siguientes apartados:

1. Resumen
2. Antecedentes de la evaluación
3. Sitio web revisado
4. Revisor(es)
5. Proceso de revisión
6. Resultados y acciones recomendadas
7. Referencias
8. Apéndices

• UWEM, Unified Web Evaluation Methodology version 1.2 (traducción al castellano de la versión 1.0): se basa en el anterior, aunque introduce algunos pequeños cambios:

1. Introducción
2. Resumen
3. Contexto de la evaluación
1. El sitio web evaluado
2. Evaluador(es)
3. Proceso de evaluación
4. Lista de recursos
5. Resultados de las verificaciones
6. Referencias
7. Anexos

¿Alguien conoce algún formato más?

Unos libros sobre accesibilidad

En la página Accessible Web Design Ebooks podemos encontrar los siguientes libros sobre accesibilidad:

• Accessible Web Typography, an introduction for web designers
• How to Create Accessible PDFs with Adobe Acrobat 6
• 50 hot to touch accessible web design tips - the tips no web developer can live without

El autor dice que en breve estarán disponibles de forma gratuita.

Guía de accesibilidad y estándares

Apoyo Tecnológico para la Discapacidad, una iniciativa del Programa Nacional para la Sociedad de la Información en Argentina, ofrece una Guía de accesibilidad y estándares. Esta guía está disponible online y para descargar en formato PDF.

El contenido de la guía es:

• Capítulo I: Qué es Accesibilidad Web
• Capítulo II: Pautas y Leyes
• Capítulo III: El Validador Automático
• Capítulo IV: Las Hojas de Estilo

Problemas con las entidades HTML

En el apartado  5.3 Character references de la especificación de HTML 4.01 del W3C encontramos la siguiente definición de referencias de caracteres:

Una codificación de caracteres dada puede no ser capaz de expresar todos los caracteres del conjunto de caracteres del documento. Para tales codificaciones, o cuando las configuraciones de hardware o de software no permitan a los usuarios introducir algunos caracteres del documento directamente, los autores pueden usar referencias de caracteres SGML. Las referencias de caracteres son un mecanismo independiente de la codificación de caracteres para introducir cualquier carácter del conjunto de caracteres del documento.

Las referencias de caracteres en HTML pueden aparecer de dos maneras:

• Referencias numéricas de caracteres (bien decimales, bien hexadecimales). Por ejemplo: å o &Xe5;
• Referencias a entidades de caracteres. Por ejemplo, å

Esta claro que las referencias a entidades de caracteres son más útiles porque son más intuitivas y más fáciles de recordar. En el capítulo 24 Character entity references in HTML4 de la especificación de HTML 4.01 se pueden encontrar las listas de referencias a entidades de caracteres definidas en HTML 4.

En principio, si se emplea la codificación Unicode ya no es necesario utilizar las referencias a entidades de caracteres, ya que esta codificación permite representar todos los caracteres. Sólo hay cuatro caracteres especiales que por tener una función especial en HTML sí que se tienen que representar como referencias a entidades de caracteres para evitar confusión:

• "&lt;" representa el signo <.
• "&gt;" representa el signo >.
• "&amp;" representa el signo &.
• "&quot;" representa el signo ".

En la página 10 HTML Entity Crimes You Really Shouldn't Commit nos explican 10 errores típicos que se cometen por un no uso de las referencias a entidades de caracteres. Estos errores pueden perjudicar la accesibilidad de una página web, en especial pueden perjudicar a los usuarios invidentes que utilicen un lector de pantallas, ya que el lector de pantallas puede vocalizar un carácter erróneo y puede crear cierta confusión.

Los 10 errores típicos son:

1. No convertir el "ampersand": &amp;
2. Uso de una elipsis propia (...): &hellip;
3. Uso incorrecto del guión "em": &mdash;
4. Uso incorrecto del gión "en": &ndash;
5. Uso de un símbolo de copyright propio: &copy;
6. Uso de un símbolo de marca registrada propio: &trade;
7. Uso de fracciones como texto plano: &frac14; &frac12; &frac34;
8. Uso de texto plano como símbolos matemáticos: &times; &divide;
9. Uso de la "o" como símbolo de grados: &deg;
10. Uso incorrecto de las comillas simples y dobles: &lsquo; &rsquo; &ldquo; &rdquo;

Otra herramienta para simular la ceguera al color: Color Oracle

En varias ocasiones he escrito sobre la ceguera al color, popularmente conocida como daltonismo.

Ahora acabo de encontrar la herramienta Color Oracle, un simulador de la ceguera al color para Windows, Mac y Linux. Aplica un filtro de color a toda la pantalla del ordenador, por lo que es independiente del software que se esté utilizando.