Accesibilidad de los portales web de las Comunidades Autónomas

El Observatorio de la Infoaccesibilidad de Discapnet ha publicado el Informe de Accesibilidad en los Portales Web de las Comunidades Autónomas. Revisión 2007. Las conclusiones de este informe son:

1. Hay un ligero, pero apreciable, incremento del porcentaje de éxito en la aplicación de los criterios analizados. El aumento es de casi el 14% en el promedio de todos los portales.
2. La mejora más notable se encuentra en el portal de Castilla y León, que aumenta 50,85 puntos porcentuales la puntuación obtenida en el estudio anterior y ahora ocupa el segundo lugar en el ranking general, cuando antes era el quinto por la cola (ha subido 12 puestos).
3. El portal mejor posicionado es el de la Generalitat de Catalunya, que alcanza un porcentaje de cumplimiento en los criterios evaluados de casi el 70%. Este puesto se lo debe a la mejoría de 32 puntos porcentuales con respecto al estudio anterior, ascendiendo del tercer al primer puesto.
4. Otras mejoras destacables son las que presentan los portales de Extremadura (más 40 puntos porcentuales), Islas Baleares (casi 40 puntos porcentuales) y Asturias (más de 38 puntos porcentuales).
5. Un aspecto positivo es que son 9 de los 17 portales analizados los que han mejorado su porcentaje de éxito en la aplicación de los criterios técnicos analizados. A los ya citados en los tres anteriores apartados, se suman Navarra, Castilla-La Mancha, Andalucía y Galicia.
6. En otros cuatro portales (Cantabria, Aragón, Canarias y La Rioja) la variación positiva ha sido inferior a 10 puntos porcentuales, lo que podríamos considerar como resultado estable. También en el caso del portal de Valencia el cambio porcentual ha sido inferior al 10%, pero en este caso con una ligera bajada que empeora el mal resultado del 2005 de poco más del 20% de éxito en la aplicación de los criterios analizados.
7. En el apartado negativo se encuentran los resultados obtenidos por tres portales: Región de Murcia, Madrid y Euskadi. Destaca la bajada de 21 puntos porcentuales en el porcentaje de éxito del portal de Euskadi. Los portales de las Comunidades Autónomas de la Región de Murcia y de Madrid, que en el estudio anterior ocuparon los dos primeros puestos en el ranking, han sufrido un retroceso de en torno a 13 puntos porcentuales, lo que los ha llevado a descender 8 y 11 puestos en el ranking.
8. Sólo se ha registrado empeoramiento en la aplicación de un criterio: la alineación del contenido de las tablas utilizadas para maquetar (desciende 45 puntos porcentuales). Este significativo empeoramiento puede ser imputable, al menos en parte, a que han sido sustituidas las tablas utilizadas para maquetar por procedimientos mediante hojas de estilos y en otros casos se han utilizado ambas estrategias de diseño, lo que no ha ofrecido resultados favorables.
9. Los formularios han mejorado en 56 puntos porcentuales, lo que resulta especialmente relevante ya que este recurso es el que propicia la mayoría de las interacciones entre el sistema administrativo y el usuario.
10. La mitad de los criterios analizados (6) han mejorado más de un 10% entre ambos estudios. Este dato marca de forma clara la tendencia de mejora que se aprecia en el promedio de éxito en el análisis técnico realizado.

Traductor automático del lenguaje oral al lenguaje de señas

He encontrado una nota de prensa de IBM, IBM Research Demonstrates Innovative 'Speech to Sign Language' Translation System, en la que se describe el sistema SiSi (Say It Sign It) que automáticamente convierte el lenguaje hablado al lenguaje de señas (la versión británica) empleado por las personas sordas.

El sistema primero convierte el lenguaje hablado en texto; posteriormente, para mostrar la lengua de señas se emplea un carácter animado o avatar.

A continuación se puede ver un vídeo demostrativo del sistema:

Taller de accesibilidad web

Según se puede leer en Día de Internet: Taller de Accesibilidad Web, INTECO organizó el pasado 14 de mayo un taller sobre accesibilidad web. Los temas tratados fueron:

• La normativa y la legislación vigente en materia de accesibilidad web, como el RD 1494/2007 sobre las condiciones básicas para el acceso de las personas con discapacidad a las tecnologías, productos y servicios relacionados con la sociedad de la información y medios de comunicación social.
• Demostración práctica de la navegación Web a través un sistema de reconocimiento de voz.
• Proyectos sobre accesibilidad de INTECO.

¿Funciona el certificado de accesibilidad web de AENOR?

A principios del 2007, AENOR lanzó la certificación de accesibilidad web en colaboración con CTIC y ESI. En poco tiempo, podíamos leer que se habían otorgado los primeros certificados de accesibilidad de AENOR a ocho sitios web españoles.

Según leo en la página Los certificados de accesibilidad Web de AENOR no terminan de funcionar, estos certificados no garantizan la accesibilidad de los sitios web que los obtienen. El autor de este artículo ha revisado la accesibilidad de los 8 primeros sitios que obtuvieron la certificación de AENOR y resulta que la mitad de ellas contiene errores.

WCAG 2.0 Candidata a Recomendación

Con fecha 30 de abril, el W3C ha anunciado que las Pautas de Accesibilidad al Contenido en la Web (WCAG) 2.0 tienen la consideración de "Candidata a Recomendación" (Candidate Recommendation) y están listas para que los desarrolladores y diseñadores las prueben sobre el contenido y las aplicaciones web.

Por fin parece que dentro de poco tendremos la versión definitiva. Parece que se han adelantado, ya que en una entrada anterior (¿Cómo va WCAG 2.0?) comentaba que se esperaba que estuviera disponible durante del último trimestre de 2008.

Razones para hacer un sitio web accesible

En su artículo Otra razon más para hacer una Web accesible: obtener ayudas y subvenciones, Fran Tarifa plantea 11 razones por las que hacer un sitio web accesible:

• Razones Sociales.
• Motores de búsqueda.
• Aumenta la usabilidad de la página.
• Se cumplen los estándares web.
• Dispositivos móviles.
• Navegadores web.
• Tendrás más visitantes.
• Reducir el coste de mantenimiento.
• Costes adicionales.
• Cumplir la ley.
• Obtener ayudas y subvenciones.

Conferencia sobre diseño para todos

Los días 12 y 13 de junio de 2008 se celebrará en León la Conferencia Europea EDeAN 2008. Formación en Diseño para Todos: Experiencias Innovadoras.

EDeAN (European Design for All e-Accessibility Network) es una red formada por más de 160 organizaciones de estados miembros de la Unión Europea, que nace con el propósito de compartir y generar experiencias sobre diseño para todos y accesibilidad en la Sociedad de la Información.

Control del ordenador mediante el movimiento de los ojos

Acabo de encontrar la página de Iriscom, una empresa española que comercializa un sistema que permite controlar un ordenador mediante el movimiento de los ojos. Este sistema está destinado a aquellas personas que presentan problemas de movilidad y control, como enfermos de esclerosis lateral amiotrófica, lesión medular, párkinson, parálisis cerebral, etc.

Este sistema permite mover el cursor del ratón por la pantalla con el solo movimiento de los ojos y sin utilizar las manos. El doble "click" se efectúa parpadeando de forma lenta o fijando la mirada en un punto. Los usuarios de este sistema deben colocar una cámara especial en el ordenador que mediante unas luces infrarrojas controla el movimiento de los ojos y permite dirigir el ratón hacia la parte de la pantalla que se desee.

Interesante entrevista al presidente de Mozilla Europa

He encontrado en el periódico El País el artículo Firefox llegó para salvar la web.

El navegador Mozilla Firefox ha ayudado a que la Web e Internet sigan avanzando y no se queden estancados por culpa de Microsoft Internet Explorer que estuvo varios años sin incorporar nuevas mejoras, muchas de las cuales redundan en que las páginas web sean más accesibles.

En la noticia podemos leer que el próximo junio saldrá la versión definitiva de Firefox 3. Habrá que estar atentos para descargarla.

¿Denuncias ante la ONU?

Acabo de encontrar en el periódico El Mundo la noticia Los discapacitados podrán denunciar a España ante Naciones Unidas si sufren discrimación. Según esta noticia:

De este modo, los particulares y las entidades de discapacitados podrán presentar al comité sus reclamaciones si consideran que sus derechos han sido violados, siempre y cuando hayan agotado los procedimientos de recurso a escala nacional.

¿Veremos alguna denuncia ante la ONU porque las páginas de alguna Administración Pública no cumple los niveles de accesibilidad exigidos por las leyes españolas?

En el BOE n° 96 del 21 de abril de 2008 se ha publicado el Instrumento de ratificación de la Convención sobre los derechos de las personas con discapacidad, hecho en Nueva York el 13 de diciembre de 2006 que es la razón del titular tan sensacionalista de la noticia.

El libro blanco (o verde) de la accesibilidad en España

Acabo de encontrar los libros el Libro Blanco de la Accesibilidad: Por un nuevo paradigma, el Diseño para Todos, hacia la plena igualdad de oportunidades y el Libro Verde: La Accesibilidad en España. Diagnóstico y bases para un plan integral de supresión de barreras.

Estos dos libros se parecen bastante, prácticamente son iguales en estructura, aunque su contenido varía un poco. Y esto no es algo extraño, ya que los dos libros están desarrollados por el mismo equipo.

En la introducción del Libro Verde se establece el propósito de este libro:

[...] difundir, compartir y discutir públicamente la situación de la accesibilidad en España, así como los instrumentos y políticas puestos en marcha en los últimos años para su promoción y las necesarias reformas o iniciativas para avanzar en el proceso de supresión de todo tipo de barreras –arquitectónicas, urbanísticas, en el transporte, la comunicación e información, etc.– en nuestro país.

En el Libro Verde es donde está más desarrollado el tema de la accesibilidad web en el apartado 7.3.3 La red / Internet:

La red, o lo que familiarmente conocemos por Internet, permite la conexión de personas localizadas en cualquier parte del planeta mediante el uso de redes para la transferencia de contenidos y la utilización de diferentes tipos de terminales como el teléfono fijo o móvil, la televisión, los palm-tops u ordenadores de bolsillo, etc., pero fundamentalmente del ordenador.

Las personas con discapacidad pueden, por una parte, minimizar sus limitaciones operativas mediante la utilización de muchos de estos servicios, pero también pueden encontrar nuevos problemas de accesibilidad en el uso de la red. Así y como un ejemplo de aplicación positiva, el uso de Internet facilita que usuarios con discapacidad física puedan ver reducido considerablemente el esfuerzo y tiempos dedicados a desplazamientos, pudiendo disponer de más tiempo en el propio domicilio o en su trabajo y evitando la necesidad de contar con la ayuda de terceras personas en gestiones personales. Por regla general, los beneficios derivados de la utilización de los servicios existentes en la red redunda en una mayor autonomía de los individuos y una mejora en su autoestima.

La red dispone de diferentes herramientas de comunicación como son el correo electrónico, las listas de correo, los foros de discusión más conocidos como «news», el IRC (Internet Relay Chat) o «chat» y la videoconferencia.

La accesibilidad
El entorno fundamentalmente gráfico de la red le confiere un manejo fácil e intuitivo; sin embargo a la vez que facilita el acceso a la información a muchas personas supone una serie de barreras para otros usuarios a los que les impide acceder a gran parte de sus contenidos y servicios. El bajo nivel de accesibilidad de Internet se debe a que tanto los diseñadores de páginas web como los creadores, los administradores o los dueños de las mismas carecen de información sobre los problemas de accesibilidad, sus implicaciones, la existencia de grupos de trabajo sobre accesibilidad, así como de las soluciones que ya se pueden implementar. Por regla general estas soluciones son sencillas, no modifican la apariencia de las páginas y además contribuyen a facilitar la navegación de usuarios ajenos al colectivo pero que se ven favorecidos al utilizar ordenadores de bajas prestaciones, monitores de poca resolución, módems cuya lentitud de conexión se ve favorecida por la existencia de páginas alternativas de sólo texto, etc.

Para tener una mejor comprensión de las barreras de acceso a la red, se hace a continuación una breve caracterización de los usuarios en función de sus discapacidades.

Barreras específicas para el acceso a Internet

Discapacidades físicas
La discapacidad en brazos y manos por pérdidas de miembros, limitación de fuerza o problemas de coordinación tiene una importante repercusión en el acceso a la red a través del ordenador pues genera problemas de manipulación y destreza con el teclado, ratón, controles, carga/descarga de unidades de disco o CD-ROM, manejo de periféricos como impresoras, etc.

Discapacidades de visión
Tanto la ausencia total de visión como los casos con visión residual, plantean importantes limitaciones en el acceso a la red dado que los contenidos que se manejan son fundamentalmente de tipo textual y gráfico. El ordenador en su configuración básica resulta imposible de utilizar, ya que tanto la salida por la pantalla o por la impresora se basan exclusivamente en la información visual.

Discapacidades de audición
Las discapacidades auditivas con pérdida total o parcial severa de la información auditiva implican dos tipos de limitaciones al utilizar la red. Por un lado, las limitaciones derivadas de la comprensión de cualquier información sonora presente en las páginas visitadas y, por otro, las derivadas de una mala comprensión de los textos escritos.

Discapacidades de la voz
La presencia de alteraciones en el habla bien porque la imposibiliten, caso de la apraxia verbal, o bien que la dificulten como es el caso de las disartrias, disfemias, taquifemias, etc., reducen la capacidad de una persona para utilizar la voz de un modo funcional e inteligible que se traduce en las dificultades o imposibilidad de utilizar sistemas de dictado o control por la voz del ordenador.

Discapacidades intelectuales
Esta discapacidad conlleva dificultades para procesar cualquier tipo de información o contenido lo que, en la mayoría de las ocasiones, da lugar a situaciones de gran dificultad a la hora de manejar las herramientas de navegación en la red dado que implican analizar, asimilar y dar respuestas adecuadas a procedimientos muchas veces complejos y largos. A su vez, el elevado número de elementos a considerar y la necesidad de disponer de estrategias de respuesta que comportan la mayoría de los recursos tecnológicos imponen una barrera de difícil superación.

Con este tipo de discapacidad suelen venir asociadas otras como dificultades de visión, audición, coordinación, etc., que tienen un efecto multiplicador de los problemas en el manejo de las herramientas informáticas.

Tecnologías de acceso
Se puede considerar que las áreas claves de la accesibilidad a la web de las personas con discapacidad son las siguientes:

1. La accesibilidad al ordenador, distinguiendo entre los programas de acceso o software, y los equipos físicos de acceso o hardware. En ambos casos, existen dispositivos alternativos para la entrada o salida de contenidos en el ordenador de forma accesible para diversas personas con discapacidades.
2. La accesibilidad al navegador, que es el programa utilizado para presentar al usuario el contenido de la página web y que puede ser de dos tipos: a) estándar o de acceso general para cualquier persona y b) específico destinado a ofrecer facilidades de acceso a un determinado tipo de usuarios, por ejemplo, a las personas con discapacidad de visión.
3. La accesibilidad a las páginas web. Cabría diferenciar entre los contenidos, la estructuración de cada página o del sitio web en general y el formato o maquetación con que se presentan las páginas. Una vez confeccionada la página web resulta conveniente confirmar que se han respetado las recomendaciones de accesibilidad para lo cual existen servicios y listas de validación automática que facilitan la comprobación, como el analizador Bobby desarrollado por el Center for Applied Special Te chnology (CAST) y otros.

La accesibilidad en las páginas de las administraciones públicas
La red es un medio con trayectoria breve y al que las diferentes administraciones se han incorporado recientemente, por lo que todavía se aprecia en las mismas poca conciencia de la necesidad de diseñar los contenidos de una forma accesible. Egea (1998) analiza veintiséis servidores de administraciones públicas de nuestro país. Como resultado, se aprecian numerosas barreras de diseño, que con la simple medida de crear una página alternativa de «solo texto», se habrían evitado. También se constata a través de la experiencia de la navegación que los contenidos que algunas de las administraciones tienen en las guías y directorios de la red no se actualizan ni hay referencias a los departamentos a que pertenecen, ni resulta posible conocer en muchas ocasiones, al efectuar una consulta o reclamación, cuál es la persona o departamento al que se la está enviando.

Además no se debe olvidar que el Plan de Acción de la iniciativa europea eEurope tiene previsto aprobar en el año 2001, por parte de la Comisión Europea y de Estados Miembros, las directrices WAI para sitios w e b públicos de manera que se garantice a todos los ciudadanos europeos la accesibilidad de estos sitios y de sus contenidos.

Evolución futura
Internet es el soporte tecnológico de infinidad de servicios en la actualidad, y lo será más en el futuro. Si hoy en día la teleformación, la banca en línea, la compra y la sanidad disponen ya de un amplio abanico de servicios, es previsible que aparezcan muchos más, y que evolucionen separadamente en lo que respecta a su funcionalidad y tecnología. Lo mismo que ocurrirá con las comunidades virtuales, nueva manera de comunicación social y convivencia que se implantará en nuestras vidas. Habrá que prestar especial atención a que esta evolución se haga de manera que no discrimine a las personas con discapacidad, por lo que será necesario una mayor participación de especialistas en su accesibilidad, de manera que ésta impregne las tecnologías básicas y se extienda de manera natural.

Los menús de navegación desplegables

He encontrado la página Menús de navegación desplegables y problemas de usabilidad donde se comentan los problemas de accesibilidad y de usabilidad que presentan los menús de navegación desplegables que se emplean para ocultar las opciones de navegación. Estos menús suelen estar programados con JavaScript, por lo que son inaccesibles si no se tiene soporte de JavaScript en el navegador empleado.

Voces en castellano

Hace un tiempo escribí una entrada titulada Lector de pantalla para Mozilla Firefox. Martín Baldassarre, un lector de este blog, me ha hecho la siguiente puntualización:

No es cierto que todas las voces en castellano son de pago.

Por un lado, hay una voz de codigo abierto, llamada eSpeak, que si bien no tien la calidad de las comerciales, es liviana y se está perfeccionando a diario.

Por otro lado, esta la que se entrega con el Windows Vista, y se puede descargar de (ahora mismo no funciona el enlace):

http://download.microsoft.com/download/1/2/2/12246417-CD66-4541-B32B-8CD18E92AAE7/RSSolo4Spanish.zip

Por último, date una vuelta por la página Dimio's Tools donde encontrarás mas voces para descargar, y programas muy interesantes como el dSpeech.

Google más accesible

He encontrado en El Mundo la noticia Google adapta su servicio de noticias para las personas con discapacidad visual. Según dice la noticia, "esta iniciativa permite la utilización de aplicaciones como líneas braille o lectores de pantalla, herramientas que las personas con discapacidad visual emplean para acceder a los textos que aparecen en el monitor del ordenador".

Estudio Intersectorial de Accesibilidad en la Web

El Estudio Intersectorial de Accesibilidad en la Web, realizado por Technosite bajo la iniciativa de discapnet, ofrece una visión de la evolución y el estado actual de la accesibilidad en la Web de diferentes sectores.

El estudio analiza la evolución de los portales que habían obtenido mejores resultados en los estudios sectoriales del Observatorio sobre Servicios Electrónicos de la Administración del Estado (marzo 2005), Comunidades Autónomas (noviembre 2005), Universidades (febrero 2006), Ayuntamientos de capitales de provincia (mayo 2006), Viajes y Transportes (julio 2006) y Banca (noviembre 2006).

El contenido del informe es:
1. Introducción
2. Resultados del análisis técnico.
    * Mejoría, continuidad y empeoramiento.
    * Clasificación por porcentaje de éxito.
    * Comportamiento por sectores.
    * Comportamiento por criterio y verificación.
3. Conclusiones.
4. Recomendación.
5. Anexo 1:
    * El observatorio de Infoaccesibilidad de Discapnet.
6. Anexo 2.
    * Muestras de Portales para el análisis intersectorial.
    * Muestra de páginas por portal.
7. Anexo 3.
    * Metodología para el análisis técnico.
8. Anexo 4.
    * Tabla completa del análisis técnico.

Lo más interesante son los anexos 3 y 4 donde se explica la metodología empleada en el análisis y la tabla completa con los resultados.

Navegación por voz en Opera

En la entrada Características que mejoran la accesibilidad del navegador Opera he comentado las principales características que incorpora el navegador Opera de cara a mejorar su accesibilidad. Una de las más interesantes es la navegación por voz.

La navegación por voz de Opera ofrece dos funciones. Por un lado, permite al usuario emplear comandos de voz para controlar el funcionamiento del lector. Por otro lado, Opera incluye un lector de documentos que realiza la misma función que un lector de pantallas.

Para que funcione la navegación por voz, es necesario activarla en Herramientas -> Opciones -> Avanzado -> Voz. Cuando se activa la opción "Activar control de navegación por voz", Opera informa al usuario de la necesidad de descargar unos módulos para su funcionamiento (unos 10Mb).


Más información:

• Talking to Opera
• Using Opera with Voice
• Accessibility and voice browsing - Opera Community

Características que mejoran la accesibilidad del navegador Opera

Acabo de encontrar el comentario ¿Cómo ayuda Opera a las diferentes discapacidades?, en el que se describen las características que posee este navegador y que suponen una ayuda para algunos grupos de personas con discapacidad. En concreto:

Personas con discapacidades físicas:

• Las personas que no puedan utilizar el ratón, podrán usar la navegación por tabulación, o la navegación espacial, navegación siguiendo los títulos, los numerosos atajos de teclado con los que acelerar la navegación, etc. Soporta las teclas de acceso de las páginas que carguemos, permitiendo eliminar temporalmente los atajos de Opera para no provocar problemas si coinciden con las teclas de acceso de la página web.
• Para personas que puedan usar el ratón incluye la posibilidad de usar gestos de ratón, mediante los cuales se pueden realizar operaciones frecuentes con pequeños movimientos de ratón.

Personas con discapacidades intelectuales:

• Puede bloquear pop-ups y ciertos contenidos que puedan distraer o llevar a ventanas en las que no se puede volver atrás.
• Puede recuperar páginas cerradas por error.
• Tiene gran capacidad de configuración.

Personas con discapacidades visuales:

• Puede realizar zoom de las páginas, ampliando no sólo el texto sino también las imágenes.
• Permite configurar fácilmente las páginas para poder verlas sin imágenes.
• Con la síntesis proporciona salida de voz a los documentos. Las características de la voz son configurables: se puede elegir entre masculina, femenina e infantil, y se puede modificar el volumen, tono y velocidad.
• Soporta navegación por reconocimiento de voz.
  

Las principales características son:

• Navegación por medio del teclado (sin ratón): Use Opera without a mouse.
• Navegación por medio del ratón (con atajos realizados con el ratón): Mouse Gestures in Opera.
• Navegación por medio de la voz: Talking to Opera.
  

Abreviaturas y acrónimos

Antes que nada, ¿qué es una abreviatura y qué es un acrónimo? Consultemos el diccionario de la Real Academia Española:

abreviatura.

(Del lat. abbreviatūra).

1. f. Tipo de abreviación que consiste en la representación gráfica reducida de una palabra mediante la supresión de letras finales o centrales, y que suele cerrarse con punto; p. ej., afmo. por afectísimo; Dir.^a por directora; íd. por ídem; SS. MM. por Sus Majestades; D. por don.

acrónimo.

(Del gr. ἄκρος, extremo, y -ónimo).

1. m. Tipo de sigla que se pronuncia como una palabra; p. ej., o(bjeto) v(olante) n(o) i(dentificado).

2. m. Vocablo formado por la unión de elementos de dos o más palabras, constituido por el principio de la primera y el final de la última, p. ej., ofi(cina infor)mática, o, frecuentemente, por otras combinaciones, p. ej., so(und) n(avigation) a(nd) r(anging), Ban(co) es(pañol) (de) (crédi)to.

¿Qué problema de accesibilidad tienen las abreviaturas y acrónimos? Recordemos la lectura de la condena contra RTVE en el 2003 por Alfredo Urdaci que leyó "Ce Ce O O" en vez de Comisiones Obreras y la mitad de los televidentes no entendieron nada. Pues eso mismo ocurre con las abreviaturas y acrónimos y los lectores de pantalla: si no se indica nada, lo leen de forma literal, letra a letra, lo que dificulta su entendimiento muchas veces. En Dive Into Accessibility: Day 17: Defining acronyms nos explican muy bien los problemas que existen.

¿Qué nos dice el W3C? En la Pauta 4, Identifique el idioma usado de las Pautas de Accesibilidad al Contenido en la Web 1.0 dice:

4.2 Especifique la expansión de cada abreviatura o acrónimo cuando aparezcan por primera vez en el documento. [Prioridad 3]

Por ejemplo, en HTML, use el atributo "title" de los elementos "ABBR" y "ACRONYM". Proporcionar la expansión en el cuerpo principal del documento también ayuda a la usabilidad del documento.

¿Y para qué sirven las etiquetas ABBR y ACRONYM? En Especificación HTML 4.01 del W3C, en el apartado 9.2.1 Elementos de frase: EM, STRONG, DFN, CODE, SAMP, KBD, VAR, CITE, ABBR, y ACRONYM nos explican la utilidad de estas dos etiquetas:

ABBR:

Indica una forma abreviada (p.ej., WWW, HTTP, URI, Mass., etc.).

ACRONYM:

Indica un acrónimo (p.ej., WAC, radar, etc.).

Los elementos ABBR y ACRONYM permiten a los autores indicar claramente la aparición de abreviaturas y acrónimos. Los idiomas occidentales hacen uso extensivo de acrónimos tales como "GmbH", "NATO", y "F.B.I.", así como de abreviaturas como "M.", "Inc.", "et al.", "etc.". Tanto en chino como en japonés se utilizan mecanismos de abreviación análogos, por los cuales las referencias subsiguientes a un nombre largo se realizan con un subconjunto de los caracteres Han del nombre original. Al marcar estas estructuras se proporciona información útil a los agentes de usuario y a herramientas tales como correctores ortográficos, sintetizadores de voz, sistemas de traducción e indexadores de motores de búsqueda.

El contenido de los elementos ABBR y ACRONYM especifica la expresión abreviada, tal y como aparece en el texto. Puede utilizarse el atributo title de estos elementos para proporcionar la forma completa o expandida de la expresión.

[...]

Obsérvese que las abreviaturas y los acrónimos tienen a menudo pronunciaciones idiosincráticas. Por ejemplo, mientras que "IRS" y "BBC" se suelen pronunciar letra por letra, "OTAN" y "UNESCO" se pronuncian fonéticamente. Y hay otras formas abreviadas (p.ej., "URI" y "SCSI") que algunas personas deletrean y que otras pronuncian como palabras. Cuando sea necesario, los autores deberían usar hojas de estilo para especificar la pronunciación de una forma abreviada.

Por tanto, tenemos que etiquetar las abreviaturas con la etiqueta <abbr> y los acrónimos con la etiqueta <acronym>. Con el atributo title indicamos la expansión de las abreviaturas y acrónimos, que será empleada por los agentes de usuario (navegadores, lectores de pantalla, etc.) para mostrarla al usuario

¿Todos los navegadores y lectores de pantalla interpretan correctamente estas dos etiquetas? Desgraciadamente, NO. En las páginas del SIDAR Abreviaturas versus acrónimos y Abreviaturas versus acrónimos: resultados de la comparativa podemos encontrar un amplio estudio donde se analiza la interpretación de estas dos etiquetas por parte de algunos navegadores (Opera, Internet Explorer, Netscape) y lectores de pantalla (JAWS, NVDA, IBM HomePageReader). Desgraciadamente, este análisis no está actualizado y es de hace unos años.

El 60% de las web de la Administración General del Estado son inaccesibles o poco accesibles para los discapacitados

Acabo de encontrar la noticia El 60% de las web de la Administración General del Estado son inaccesibles o poco accesibles para los discapacitados.

El estudio realizado por el Ministerio de Administraciones Públicas pone de manifiesto que "el 44,4% de las web de la Administración General del Estado son aún inaccesibles para las personas mayores o con discapacidad y el 15,3 por ciento son poco accesibles".

Esta noticia me sorprende bastante, si tenemos en cuenta que el REAL DECRETO 1494/2007, de 12 de noviembre, por el que se aprueba el Reglamento sobre las condiciones básicas para el acceso de las personas con discapacidad a las tecnologías, productos y servicios relacionados con la sociedad de la información y medios de comunicación social establece en la Disposición transitoria única los siguientes plazos:

2. Las páginas de internet de las administraciones públicas o con financiación pública deberán adaptarse a lo dispuesto en el artículo 5 de dicho reglamento, en los siguientes plazos:
a) Las páginas nuevas deberán ajustarse a la prioridad 1 de la Norma UNE 139803:2004 desde la entrada en vigor del real decreto.
b) Las páginas existentes deberán adaptarse a la prioridad 1 de la Norma UNE 139803:2004 en el plazo de 6 meses desde la entrada en vigor.
c) Todas las páginas, actualmente existentes o de nueva creación, deberán cumplir la prioridad 2 de la Norma UNE 139803:2004 a partir del 31 de diciembre de 2008. No obstante, este plazo de adaptación y la citada norma técnica de referencia podrán ser modificados a efectos de su actualización mediante orden ministerial conjunta, en los términos establecidos en la disposición final tercera de este real decreto.

Pues no están cumpliendo la ley, SU PROPIA LEY, pero luego bien que obligan a los demás a que las cumplan. Hay que predicar con el ejemplo...

¿Cómo va WCAG 2.0?

El 11/12/2007 se publicó el último borrador de WCAG 2.0 y se abrió el plazo para el envío de comentarios.

Según nos cuenta Alan Chuter en Progreso de WCAG 2.0, se están resolviendo los más de 200 comentarios que se recibieron y se espera que "el último borrador de WCAG 2.0 (llamada “Propuesta de Recomendación”) podría estar disponible en el último trimestre del 2008".

Más información:

• Overview of WCAG 2.0 Documents
• WCAG 2 FAQ

Magnificador de pantalla en USB

Acabo de encontrar el software RehaSoft Lightning. Según el fabricante:

Lightning es un nuevo programa de aumento de imagen para el PC. Aumenta la pantalla 2-32 veces. Cambia la forma o tamaño de letras e imágenes. Invierte los colores de la pantalla para conseguir un mejor contraste.

Lightning también existe en una versión USB. Se puede insertar en cualquier ordenador, y el aumento se ejecuta desde la memoria USB.

Guía sobre SMIL

Gracias a un comentario que me han dejado he encontrado la Guía Breve de Subtitulado y Sincronización de Vídeos con SMIL de INTECO.

Recordemos que es SMIL:

SMIL es el acrónimo de Synchronized Multimedia Integration Language, una recomendación del W3C que se emplea para describir presentaciones multimedia, es decir, presentaciones donde podemos combinar texto (con formato), imágenes, audio y vídeo. SMIL es un lenguaje de marcado basado en XML.

En esta guía nos explican cómo emplear SMIL para subtitular una presentación multimedia o un vídeo.

Internet Explorer 8 tendrá soporte de WAI-ARIA

Acabo de encontrar el artículo Soporte para WAI-ARIA en Internet Explorer 8.

Hace unos meses hablé sobre WAI-ARIA: una iniciativa del W3C para estudiar y solucionar los problemas que presentan las páginas web actuales que se basan en contenido dinámico, como por ejemplo las páginas web que emplean AJAX.

En WAI-ARIA se emplean los conceptos rol, estado y propiedad para indicar el funcionamiento de los elementos de una página web y comunicar esta información a las ayudas técnicas (lectores de pantalla, por ejemplo). Pero si un navegador no reconoce estos nuevos conceptos, de nada servirá que los incluya el diseñador en la página web.

Según el artículo que comento, el próximo Microsoft Internet Explorer 8 incluirá soporte para WAI-ARIA. Más información: Internet Explorer 8 Beta 1 Whitepapers, W3C’s ARIA Support

Más errores de diseño

Siguiendo con la entrada anterior, también es muy interesante el artículo Top Ten Mistakes in Web Design, también de Jakob Nielsen. Estos consejos generales también suponen una buena ayuda para mejorar la accesibilidad de un sitio web.

El contenido de esta lista varía con el tiempo, es decir, Jakob Nielsen actualiza esta lista de los errores más importantes en el diseño web:

1. Malos buscadores: buscadores demasiado literales, que no permiten errores tipográficos, el empleo del plural u otras variantes de un mismo término.
2. Ficheros PDF para leerlos en la Web: los ficheros PDF son molestos porque interrumpen el flujo normal de lectura de las páginas web.
   
3. No cambiar el color de los enlaces visitados: una ayuda buena para saber dónde estamos situados en un sitio web no es utilizado en muchas ocasiones.
4. Texto plano: texto plano sin zonas destacadas.
5. Tamaño del texto fijo: utilizar medidas físicas en vez de relativas, lo que impide que el usuario modifique el tamaño del texto.
6. Títulos de las páginas con poca visibilidad para los buscadores: el título es clave de cara a los buscadores y los favoritos de los usuarios.
7. Cualquier cosa que parece un anuncio: y no sea un anuncio, pasará desapercibida para los usuarios.
   
8. Violación de las convenciones de diseño: la consistencia es uno de los principios de usabilidad más importante: cuando las cosas se comportan de una misma forma, los usuarios no se tienen que preocupar de lo que pasa.
   
9. Apertura de nuevas ventanas del navegador: son molestas y producen confusión en muchos usuarios.
   
10. No responder a las preguntas del usuario: no proporcionar la información que buscan los usuarios.

10 errores en el diseño de aplicaciones web

He encontrado el artículo 10 errores en el diseño de aplicaciones web, que es una traducción al españo del artículo Top-10 Application-Design Mistakes de Jakob Nielsen.

Estos errores afectan a todos los usuarios y, en especial, a los usuarios con discapacidad, por lo que si los evitamos estaremos mejorando la accesibilidad de las páginas web.

Los errores son:

• Controles no estándares: los enlaces, botones, radio buttons y demás controles tienen una utilidad específica y estándar. Cambiar el comportamiento no es lo correcto y no hace más que confundir al usuario.
• Inconsistencia: diferentes cosas para una misma utilidad, usa lo mismo en el mismo lugar para la misma acción.
• Acciones no perceptibles: se debe saber qué acción realiza un control a simple vista. Si hay que investigar para qué sirve algo no cumple su cometido.
• Controles sin reacción: cada control debe indicar 3 cosas: mostrar a los usuarios el estado actual, cómo se interpretan los comandos y qué está pasando.
• Malos mensajes de error: no basta con decir que hay un error, sino que es lo que ha pasado y que se puede hacer para solucionarlo.
• Preguntar por lo mismo dos veces
• No hay valores por defecto: os valores por defecto sirven para que haya más rapidez en las respuestas, para enseñar mediante el ejemplo y para dirigir a usuarios novatos.
• No explicar cómo funciona la aplicación: en aplicaciones estándar eso no es muy problemático, pero en otras aplicaciones hay que explicar qué se puede conseguir y cómo y no únicamente acceder a la aplicación.
• No indicar qué se hace con la información
• Mostrar características internas: al usuario no le importa y no llegará a entender cosas internas de la aplicación, por lo que no es necesario que el usuario lea.

AENOR organiza una jornada informativa sobre accesibilidad web

He encontrado esta noticia de AENOR: Jornada informativa sobre accesibilidad web. El principio de la noticia dice:

El próximo 11 de marzo la Asociación presentará una Jornada dirigida especialmente a las Administraciones públicas, a propietarios de sitios Web financiados por estas instituciones, a las organizaciones que gestionan servicios públicos o a empresas que presten servicios por medio de sus sitios Web. El evento, en el que colabora el Ministerio de Industria, Turismo y Comercio y el Plan Avanza, tendrá lugar en la Secretaría de Estado de Telecomunicaciones y para la Sociedad de la Información (SETSI).

El programa de la jornada, que es gratuita, está disponible en formato PDF.

Lector de pantalla para Mozilla Firefox

Acabo de encontrar CLiCk, Speak, un complemento para Mozilla Firefox que proporciona un lector de pantalla.

Permite emplear diferentes softwares de síntesis de voz, como por ejemplo Microsoft SAPI 5 que está disponible en Microsoft Windows XP. Desgraciadamente, parece ser que no existe el español de forma gratuita para SAPI, sino que todas las que hay son comerciales y de pago.

Interesante idea

Acabo de encontrar la web UsabilityExchange. ¿Qué ofrece esta web?

El objetivo de este sitio web es mejorar la accesibilidad y usabilidad de los sitios web. Para ello ofrece conectar a los usuarios discapacitados con los desarrolladores de sitios web para que se pueda aprovechar su conocimiento y experiencia.

¿Tienes un sitio web y quieres mejorar su accesibilidad? A través de este sitio web lograrás que usuarios discapacitados evalúen la accesibilidad de tu sitio web.

Premio Complutense-Microsoft de Diseño Accesible

He encontrado la noticia Entrega de la II Edición del Premio Complutense-Microsoft de Diseño Accesible.

El premio ha sido entregado al proyecto WebCS del Centro de Referencia en Accesibilidad y Estándares Web del Instituto Nacional de Tecnología de la Información (INTECO). El jurado "ha considerado el "Proyecto WebCS" merecedor de dicho premio por tratarse de una herramienta desarrollada con el objetivo de garantizar la accesibilidad de las páginas web editadas, basándose en la separación total entre contenido y presentación, una de las principales premisas de la accesibilidad".

Los errores más comunes

He encontrado estas páginas que comentan cuales son los errores más comunes respecto a la accesibilidad web:

• 7 errores de accesibilidad que se cometen a menudo: son consejos bastante generales, poca información técnica.
  
• Aciertos y fallos en el artículo: "10 common errors when implementing accessibility": crítica del artículo 10 common errors when implementing accessibility. Es un excelente artículo donde explica y corrige claramente los consejos del artículo original.

La accesibilidad web y los dispositivos móviles

Normalmente la accesibilidad web se asocia con la idea de desarrollar páginas web que puedan ser utilizadas por las personas con discapacidad.

Sin embargo, hoy en día la accesibilidad web no está orientada exclusivamente a las personas con discapacidad. Con el aumento del uso de los dispositivos móviles que permiten el acceso a la Web con las mismas prestaciones que desde un ordenador, la accesibilidad web pasa a significar que la Web es única (no diferentes versiones según el dispositivo o el navegador que se utilice) y universal (utilizable independientemente de las características del usuario).

Debido a ello, el W3C está desarrollando actividades para fomentar que las páginas web sean totalmente accesibles, incluyendo en esta accesibilidad los dispositivos móviles.

Más información:

• Web Content Accessibility and Mobile Web:
  Making a Web Site Accessible Both for People with Disabilities and for Mobile Devices
• Mobile Web Best Practices 1.0, Basic Guidelines, W3C Proposed Recommendation 2 November 2006
  
• Tarjetas de MWBP
  

Serie "Guía breve": Marcos: use el elemento noframes y títulos con sentido

Consejo 8: Marcos: Use el elemento noframes y títulos con sentido.

Los marcos (frames) son un elemento del HTML que siempre han causado problemas. Tanto es así que en XHTML 1.0 Strict y Transitional no se pueden emplear y tenemos que utilizar XHTML 1.0 Frameset si queremos tener marcos.

En XHTML 1.1 Modularization, si se quieren emplear los marcos se tiene que implementar el módulo Frames que define los elementos frameset, frame y noframes.

¿Qué problemas tienen los marcos? Un par de páginas sobre el tema:

• Los problemas de los marcos
• Problemas con marcos
  
• 9 razones para no utilizar frames (marcos)

¿Y si aún así quiero utilizar los marcos? Pues tendremos algunos problemas de accesibilidad:

1.1 Proporcione un texto equivalente para todo elemento no textual (Por ejemplo, a través de "alt", "longdesc" o en el contenido del elemento). Esto incluye: imágenes, representaciones gráficas del texto, mapas de imagen, animaciones (Por ejemplo, GIFs animados), "applets" y objetos programados, "ascii art", marcos, scripts, imágenes usadas como viñetas en las listas, espaciadores, botones gráficos, sonidos (ejecutados con o sin interacción del usuario), archivos exclusivamente auditivos, banda sonora del vídeo y vídeos. [Prioridad 1]

12.1 Titule cada marco para facilitar su identificación y navegación. [Prioridad 1]

12.2 Describa el propósito de los marcos y como éstos se relacionan entre sí, si no resulta obvio solamente con el título del marco. [Prioridad 2]

Fuente: Pautas de Accesibilidad al Contenido en la Web 1.0, Recomendación W3C de 5 de mayo de 1999

Cada marco debe tener un título y una descripción. Para ello, se tienen que emplear los atributos title y longdesc en la etiqueta <frame>.

Además, se tiene que proporcionar una versión alternativa sin marcos para aquellos agentes de usuario (navegadores) que no sean capaces de interpretar los marcos. Para ello se tiene que emplear la etiqueta <noframes>.

El atributo target

Siempre se aconseja que para mejorar la accesibilidad de las páginas web se deben emplear los estándares. Respecto al HTML, en la actualidad se debe emplear XHTML 1.0 Strict, pero esta elección puede implicar algunos problemas a los desarrolladores, ya que descubrirán que algunos elementos y atributos de HTML no están. Uno de ellos es el atributo target.

El atributo target de HTML se emplea para abrir un enlace en un destino distinto a la ventana actual. Este atributo se puede aplicar a las etiquetas A, AREA, BASE, FORM y LINK. Según HTML 4.01 Specification de W3C:

This attribute specifies the name of a frame where a document is to be opened.

The following target names are reserved and have special meanings.

_blank
The user agent should load the designated document in a new, unnamed window.
_self
The user agent should load the document in the same frame as the element that refers to this target.
_parent
The user agent should load the document into the immediate FRAMESET parent of the current frame. This value is equivalent to _self if the current frame has no parent.
_top
The user agent should load the document into the full, original window (thus canceling all other frames). This value is equivalent to _self if the current frame has no parent.

¿Presenta algún problema de accesibilidad este atributo? Sí, porque la apertura de ventanas nuevas o el uso de marcos puede dificultar la navegación de algunos grupos de usuarios:

10.1 Hasta que las aplicaciones de usuario permitan desconectar la apertura de nuevas ventanas, no provoque apariciones repentinas de nuevas ventanas y no cambie la ventana actual sin informar al usuario. [Prioridad 2]

Fuente: Pautas de Accesibilidad al Contenido en la Web 1.0, Recomendación W3C de 5 de mayo de 1999, Pauta 10. Utilice soluciones provisionales

Por tanto, se debe reducir su uso todo lo posible. Además, XHTML 1.0 Strict no permite su uso. Si queremos utilizarlo, tenemos que emplear XHTML 1.0 Transitional o Frameset.

¿Y cómo está la situación con las nuevas versiones de XHTML?

En XHTML 1.1 Modularization, XHTML 1.0 Strict se divide en una serie de módulos abstractos que agrupan los elementos y atributos relacionados entre ellos. El objetivo es proporcionar la máxima flexibilidad y que un dispositivo (navegador) implemente únicamente aquellos módulos que necesite o que pueda implementar. Con el fin de asegurar cierta consistencia, existen cuatro módulos básicos (core) que son necesarios siempre:

• Structure: define body, head, html y title.
  
• Text: define, entre otras, br, cite, div, h1...h6, p, span, etc.
  
• Hypertext: define a.
  
• List: define dl, dt, dd, ol, ul y li.
  

Existen otros módulos que definen el resto de elementos y atributos de HTML: Applet, Basic Forms, Forms, Basic Tables, Tables, Image, etc.

Si se quiere emplear el atributo target es necesario incluir el módulo Target, que incluye la definición de este atributo para las etiquetas a, area, base, link y form.

Más información: Standards-Compliant New Windows

HTML 5

He encontrado el comentario El HTML 5: el futuro del contenido web. Copio el comentario:

Hoy ha publicado el W3C un borrador del HTML 5, lo que ellos mismos llaman el futuro del contenido web, pero aunque todavía pasará mucho tiempo hasta que este estándar vea la luz (ya sabemos la velocidad que llevan las cosas del W3C), es conveniente empezar a saber que va a suponer el HTML 5, por lo que vamos a responder una serie de preguntas básicas para comenzar a conocer este nuevo estándar.

¿Este nuevo estándar supone cambios para las nuevas guías de accesibilidad?
Por supuesto que no, las guías de accesibilidad son totalmente independientes del estándar (X)HTML que se utilice, por lo tanto lo único que supondrá es añadir un nuevo enlace al nuevo estándar.

¿Se necesitan unos nuevos estándares de HTML?
Personalmente pienso que lo que se necesita es que se cumplan, pero si es verdad que los anteriores son ya muy antiguos y todos sabemos la velocidad a la que se mueve la tecnología en el mundo de la informática.

¿Qué pasará con nuestras páginas realizadas en HTML 4.0 o XHTML 1.0?
Pues es de suponer que si tus páginas cumplen con los estándares correctamente no debe pasar nada, se deben seguir viendo correctamente en los navegadores futuros. Otra cosa es que páginas que no cumplan con los estándares y que ahora se ven bien en un determinado navegador, se sigan viendo bien en un futuro; ésto me parece que va a ser más difícil.

¿Nos aseguraremos que si nuestra página cumple con los estándares HTML 5 se verá por fin correctamente en todos los navegadores?
Pues aunque en la redacción de estos nuevos estándares está trabajando un grupo formado por personas de los principales navegadores, sería muy optimista pensar que nuestra página por cumplir con los estándares HTML 5 se va a ver correctamente en todos los navegadores. Me temo que este problema no será tan fácil de solucionar.

¿Qué características nuevas nos aporta el HTML 5?
Pues según el W3C, algunas de las características más interesantes para los autores son APIs para dibujar gráficos en dos dimensiones, incorporar y controlar contenido de audio y vídeo, mantener persistente en la parte del cliente el almacenamiento de datos y para ofrecer a los usuarios la edición de documentos, o partes de éstos, de forma interactiva. Otras características facilitan la representación de elementos familiares de las páginas, incluyendo (sección) (pie); (para navegación) y (para asignación de un título a una foto u otro contenido incluido en la página).

¿Tendremos que aprender un nuevo lenguaje de etiquetado web?
Pues seguro que no, sólo habrá que ver que etiquetas han cambiado su uso y cuales se han añadido nuevas.

¿Tenemos que empezar a usar HTML 5 en nuestras páginas web?
Ahora mismo ni pensarlo, recordar que en estos momentos es sólo un borrador y con total seguridad sufrirá muchos cambios, por lo que nos queda esperar hasta que se apruebe definitivamente.

Serie "Guía breve": Scripts, applets y plug-ins

Consejo 7: Scripts, applets y plug-ins: Proporcione una alternativa en caso de que los recursos utilizados no sean accesibles o compatibles.

Algunos de los navegadores que emplean las personas discapacitadas no son capaces de interpretar el código de script (JavaScript) o algunos elementos multimedia como applets programados en Java u objetos realizados con Macromedia Flash que requieren de un plug-in. Además, aún en el caso de que pudiesen interpretarlos, sería muy difícil proporcionar una representación alternativa (por ejemplo, una representación textual para una animación de un applet).

Por regla general, el HTML Dinámico (DHTML) no funcionará con un navegador no visual y no será accesible. Cualquier efecto que se base en mostrar u ocultar capas como respuesta a un evento del ratón, como por ejemplo, menús desplegables o información adicional al pasar el ratón por encima de un elemento, no será accesible y es necesario proporcionar una alternativa.

En entradas anteriores se ha explicado cómo lograr que el código JavaScript sea accesible. Estas entradas han sido:

• JavaScript no molesto (1): definición
• JavaScript no molesto (2): cómo desactivar JavaScript
• JavaScript no molesto (3): las ventanas emergentes
• JavaScript no molesto (4): separación del JavaScript

Un joystick vocal

He encontrado la noticia Un Joystick Vocal ayuda a los discapacitados a manejar el ordenador. La noticia dice:

Informáticos e ingenieros de la Universidad de Washington han creado un “Joystick Vocal” que permite mover el cursor del ordenador a personas discapacitadas. El sistema convierte sonidos vocálicos sencillos en movimientos del cursor sobre la pantalla. Asimismo, es capaz de simular los clics que hacemos con los botones derecho e izquierdo del ratón. Frente a otros sistemas, éste no requiere una gran inversión de hardware, ya que sólo precisa un micrófono y un ordenador para poder usarlo. Sus creadores han hecho otros desarrollos de esta tecnología para buscar en la web, jugar a juegos o manejar un brazo robótico.

Ratón con el movimiento de la cabeza

He encontrado la noticia HeadMouse: mouse virtual para personas con discapacidad. La noticia dice:

El dispositivo se basa en la utilización de una cámara de bajo coste para captar las acciones del usuario delante de la pantalla. Las personas con discapacidad motriz acceden al control del mouse a través de los movimientos de la cabeza con todas las funciones incorporadas de «arrastrar», mientras que las acciones faciales se convierten en diversas modalidades de «clic».

La página oficial del proyecto es HeadMouse (Grupo de Robótica, Universidad de Lérida).

Resulta que también existe un producto comercial con el mismo nombre: HeadMouse Extreme. ¿Qué diferencias hay entre uno y otro? ¿Por qué le ponen el mismo nombre?

Ejemplo de vídeo con subtítulos

He encontrado la página web Uso de subtítulos en la presentación de un segmento de baile con descripción por medio de audio. En esta página se explica cómo crear vídeo con subtítulos mediante SMIL para que sea empleado por el reproductor RealPlayer.

La versión demo de JAWS no se puede utilizar para evaluar

He encontrado el comentario El lector de pantallas JAWS no se podrá usar para evaluar la accesibilidad web. Según parece, Freedom Scientific, el fabricante de JAWS, ha modificado la licencia de uso de la versión demostrativa de su lector de pantallas y ya no se puede utilizar para evaluar la accesibilidad de un sitio web.

Según leo en JAWS license not developer friendly, la licencia dice en uno de sus párrafos:

… these demonstration or evaluation licenses are not permitted for purposes of development and testing of JAWS scripts, applications, HTML coding, or other Web Based code.

Así que, nos tenemos que comprar JAWS y pagar unos 900$.

Nuevas leyes sobre accesibilidad web

El 2007 ha sido un buen año para la accesibilidad web en cuanto a leyes en España.

Las nuevas leyes que se han promulgado complementan a las que ya se tenían desde hace unos años:

• BOE n. 166 de 12/7/2002: LEY 34/2002, de 11 de julio, de servicios de la sociedad de la información y de comercio electrónico.
• BOE n. 289 de 3/12/2003: LEY 51/2003, de 2 de diciembre, de igualdad de oportunidades, no discriminación y accesibilidad universal de las personas con discapacidad.

El 21 de de noviembre de 2007 se publicón en el BOE el REAL DECRETO 1494/2007, de 12 de noviembre, por el que se aprueba el Reglamento sobre las condiciones básicas para el acceso de las personas con discapacidad a las tecnologías, productos y servicios relacionados con la sociedad de la información y medios de comunicación social. Este reglamento establece que la accesibilidad de las páginas web está regulada por la Norma UNE 139803:2004, que establece tres niveles de prioridades, y también establece el grado de accesibilidad aplicable a las páginas de internet de las administraciones públicas (prioridades 1 y 2 de la citada Norma UNE).

El 27 de diciembre de 2007 se publicó en el BOE 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. Las infracciones serán multas entre los 301 euros y el millón de euros. Su entrada en vigor está fijada a los tres meses de su publicación.

El 29 de diciembre de 2007 se publicó en el BOE la LEY 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la Información. Esta ley obliga a las empresas que cumplan una serie de condiciones a satisfacer un nivel de accesibilidad en sus páginas web equivalente al nivel AA del W3C.

Llegó la hora de las empresas

He encontrado esta noticia en el periódico El Mundo: Las grandes empresas deberán hacer accesibles sus páginas web a discapacitados.

A partir del 31 de diciembre de 2008, es decir, en 12 meses, una serie de empresas que cumplan una serie de condiciones, deberán de satisfacer en sus páginas web el nivel medio (prioridades 1 y 2) de la Norma UNE 139803:2004 (equivalente al nivel AA del W3C).

La noticia dice:

Las páginas de Internet de las empresas que presten servicios al público de especial trascendencia económica deberán alcanzar el 31 de diciembre de 2008 el nivel medio de los criterios de accesibilidad para personas con discapacidad, según establece la nueva Ley de Medidas de Impulso de Sociedad de la Información, que ya ha entrado en vigor.

Según esta nueva norma legal, son consideradas empresas que prestan servicios al público en general de especial trascendencia económica aquéllas con más de cien trabajadores o cuyo volumen anual de operaciones supere los seis millones de euros.

Además, deben operar en el sector de los servicios de las comunicaciones electrónicas o en servicios financieros destinados a consumidores, que incluyen los servicios bancarios, de crédito o de pago, los servicios de inversión, las operaciones de seguros privados, los planes de pensiones y la actividad de mediación de seguros.

Hasta la aprobación de esta ley, la obligación de accesibilidad sólo vinculaba a las páginas de Internet de las Administraciones Públicas.

¿El portal de ayuntamiento más accesible?

He encontrado esta noticia en el periódico El Mundo: El portal de Internet del Ayuntamiento de Pamplona, el único 100% accesible.

La noticia dice:

El Ayuntamiento de Pamplona cuenta con el primer portal de internet que alcanza el 100% de éxito en el cumplimiento de los criterios de accesibilidad analizados por el Observatorio de la Infoaccesibilidad de la Fundación Once. Por esta razón será galardonado el próximo día 17 de enero, según informó el consistorio en un comunicado.

El estudio llevado a cabo por el Observatorio de la Infoaccesibilidad ha analizado 19 portales y 93 páginas web. El Ayuntamiento de Pamplona es el único que ha alcanzado la cota máxima. A continuación se han situado Bankinter, que supera el 81 por ciento en el cumplimiento de los criterios de referencia, y la Seguridad Social con su portal de vida laboral que presenta el 85,71 por ciento de éxito.

El estudio intersectorial el Observatorio de la Infoaccesibilidad revisa comparativamente el estado de accesibilidad de las webs y su evolución a lo largo de tres años. El Observatorio, para este estudio eligió 19 portales, los tres mejores en la evaluación técnica de accesibilidad de cada uno de los ocho informes/áreas observadas.

Estos informes abarcaban distintos campos: universidades, administración general del Estado, comunidades autónomas, ayuntamientos, viajes y transportes, banca y diarios digitales.

El propósito de los resultados publicados consiste en dar a conocer y destacar, además de niveles de cumplimiento respecto a las pautas vigentes, prácticas favorables y las principales barreras e impedimentos en la web, incluyendo en esta valoración la perspectiva de los usuarios.

Ley de Medidas de Impulso de la Sociedad de la Información

He encontrado esta noticia en el periódico El Mundo: Garantizado el acceso de personas con discapacidad a las nuevas tecnologías.

La noticia dice:

El Boletín Oficial del Estado publicó, el pasado sábado 29 de diciembre, la Ley de Medidas de Impulso de la Sociedad de la Información (LMISI), que garantiza el acceso de las personas con discapacidad a la información en Internet y en otros soportes de nuevas tecnologías de la información y la comunicación.

Además, esta ley garantizará la accesibilidad de las cabinas telefónicas a los usuarios con alguna discapacidad, así como el establecimiento de una oferta tal que pueda cubrir la demanda nacional en todos las provincias.

La disposición adicional undécima de la LMISI recuerda también a las administraciones y entidades públicas su obligación de promover y garantizar el diseño accesibles para personas con discapacidad de todos los elementos y procesos basados en las nuevas tecnologías de la Sociedad de la Información.

Esta norma, que entró en vigor el pasado domingo 30 de diciembre, establece, además, que el incumplimiento de las medidas de acceso a la sociedad de la información será regulado por la ley de infracciones y sanciones que el BOE publicó el 27 de diciembre y que comenzará a funcionar pasados tres meses de su publicación en el BOE.

Vídeos sobre accesibilidad web

Tres vídeos de un seminario sobre la accesibilidad web. El contenido está bien, pero el sonido es muy malo.

Legibilidad de una página web

En ¿Tu Sitio es Entendible y Fácil de Leer? nos presentan la herramienta TxReadability (versión en español) que evalúa la facilidad de lectura de una página web, para textos en español, inglés y japonés.

El W3C, en la pauta 14 de sus Pautas de Accesibilidad al Contenido en la Web 1.0 nos dice:

Pauta 14. Asegúrese de que los documentos sean claros y simples.

Asegure que los documentos son claros y simples para que puedan ser más fácilmente comprendidos.

La maquetación coherente de páginas, los gráficos reconocibles y el lenguaje fácilmente comprensible benefician a todos los usuarios. En particular, ayudan a personas con discapacidades cognitivas o con dificultades en la lectura. (Por tanto, asegúrese de que las imágenes tienen textos equivalentes para los ciegos, los de baja visión o para cualquier usuario que no puede o ha elegido no ver los gráficos. Consulte también la pauta 1).

La utilización de un lenguaje claro y simple promueve una comunicación efectiva. El acceso a la información escrita puede ser difícil para personas con discapacidades cognitivas o de aprendizaje. La utilización de un lenguaje claro y simple también beneficia a las personas cuyo primer idioma es diferente al del autor, incluidos aquellos que se comunican principalmente mediante lengua de signos.

Puntos de verificación:

14.1 Utilice el lenguaje apropiado más claro y simple para el contenido de un sitio. [Prioridad 1]
Técnicas para el punto de verificación 14.1.

14.2 Complemente el texto con presentaciones gráficas o auditivas cuando ello facilite la comprensión de la página. [Prioridad 3]
Consultar también la pauta 1.
Técnicas para el punto de verificación 14.2.

14.3 Cree un estilo de presentación que sea coherente para todas las páginas. [Prioridad 3]
Técnicas para el punto de verificación 14.3.

Esta herramienta nos puede ayudar a cumplir esta pauta.

Nuevo borrador de WCAG 2.0

Con fecha 11/12/07 se ha publicado un nuevo borrador de las Web Content Accessibility Guidelines 2.0. La fecha límite para enviar comentarios es el 01/02/08. ¿Para cuándo la recomendación definitiva?

En la entrada ¿Qué pasa con WCAG 2.0? comenté los problemas que está teniendo esta nueva recomendación.

JavaScript no molesto (5): validación de formularios

En la entrada JavaScript no molesto (4): separación del JavaScript se explicó cómo aprovechar el atributo class para separar el código JavaScript del código XHTML. En esta entrada se va a explicar cómo utilizar la misma técnica para validar formularios.

Los formularios se deben validar en el navegador por varias razones, las más importantes son:

• Disminuye el tiempo de respuesta de la aplicación: el usuario no tiene que esperar a que se envíen los datos al servidor, se validen en el servidor y se reciba una respuesta para saber si los datos están bien o están mal.
• Se reduce la carga de trabajo del servidor (no del todo, como ahora se explicará): en el servidor no se tienen que validar los formularios de todos los usuarios, en el navegador de cada usuario se validan los datos que ha introducido.

La segunda razón no es verdad en parte, porque SIEMPRE hay que validar los datos que se reciben en el servidor, ya que un usuario malicioso los puede enviar directamente, sin pasar antes por la validación de nuestro formulario. Por tanto, la solución que vamos a ver para separar el JavaScript del XHTML no supone un problema cuando no se dispone de JavaScript, ya que los datos serán validados en el servidor.

Sí que puede haber problemas cuando se emplea JavaScript para actualizar un control del formulario o una página web en función de las acciones del usuario. Por ejemplo, el típico caso de las listas desplegables en cascada (una lista que muestra sus valores en función de lo que se ha elegido en otra lista) realizado con JavaScript no funcionaría si está desactivado. Este problema es distinto al que se explica en esta entrada y merece una para él solo.

Consejo 1: no se debe usar botones de tipo button con el evento onclick para enviar un formulario

El código siguiente presenta un grave problema de accesibilidad: cuando JavaScript no está disponible, el formulario no se puede enviar.

function validar() {
// Algunas instrucciones para validar
// Al final, si todo va bien, se envía el formulario
document.forms[0].submit();
}

<input type="button" value="Enviar" onclick="validar()">Para solucionar este problema, se deben emplear los botones de tipo submit y utilizar el evento onsubmit para llamar al código de validación:

function validar() {
// Algunas instrucciones para validar
// Al final, si todo va bien, se envía el formulario
document.forms[0].submit();
}

<form action="unapagina.php" onsubmit="return validar()"></form>Consejo 2: utiliza múltiples clases para indicar el tipo de validación que requiere cada control de un formulario

En el artículo A Guide to Unobtrusive JavaScript Validation se presentan técnicas para separar el código JavaScript que realiza la validación de un formulario:

• Utilizar campos ocultos (hidden) para indicar las validaciones que se tienen que realizar (valor requerido, correo electrónico, código postal).
• Utilizar el atributo class para indicar el tipo de validación.
• Crear un DTD propio para añadir atributos que indican el tipo de validación.

La primera opción es poco práctica, ya que no es adecuada para formularios complejos con muchos campos. La tercera opción tampoco es práctica, ya que una página web basada en un DTD propio no es una página válida respecto a XHTML. Por tanto, la opción más recomendable es la segunda.

En el class se pueden añadir valores para indicar el tipo de validación que requiere el control:

• required
• notrequired
• email
• integer
• date

Por ejemplo:

<input type="text" name="correo" class="required email">
Para más información sobre cómo lograr un manejo de formularios correcto con JavaScript:

• A Guide to Unobtrusive JavaScript Validation
• Unobtrusive Javascript
• Javascript no obstructivo, Manual de buenas maneras (traducción al español del anterior)

III Premios TAW 2007

He encontrado esta noticia en el periódico El País: Los portales del Ministerio de Fomento y Ayuntamiento de Madrid los más accesibles. TAW ya ha otorgado sus premios anuales a las páginas web más accesibles. En la página Los portales del Ministerio de Fomento y Ayuntamiento de Madrid ganan los III Premios TAW a las web públicas más accesibles podemos encontrar la nota de prensa de TAW y en la página Premiados 2007 la lista de premiados que reproduzco:

Reunido el jurado para la concesión de los III Premios TAW a la Accesibilidad Web, el día 15 de Noviembre de 2007 en la sede de la Fundación CTIC, resuelven conceder los premios por categorías a:
T.1. Premio TAW a la Web pública más Accesible I.
GANADOR: Sitio web Ministerio de Fomento
Finalista: Sitio web Ministerio de Cultura
Finalista: Sitio web Autoridad Administrativa CITES
T.2. Premio TAW a la Web pública más Accesible II.
GANADOR: Sitio Web Ayuntamiento de Madrid
Finalista: Sitio web Ayuntamiento de Ermua
Finalista: Sitio web Ayuntamiento de Murcia
T.3. Premio TAW a la Web Empresarial más Accesible I.
GANADOR: Sitio web Cajastur
Finalista: Sitio web Gamesa
Finalista: Sitio web Babel Sistemas de información
T.4. Premio TAW a la Web Empresarial más Accesible II.
GANADOR: Sitio web Cafetto Kaldi
Finalista: Sitio web Serviweb S.L.
Finalista: Sitio web Gateway S.C.S.
T.5. Premio TAW a la Web de entidades sin ánimo de lucro más Accesible.
GANADOR: Sitio web Aspaym Cantabria
Finalista: Sitio web Asociación Síndrome Prader-Willi
Finalista: Sitio web Fundación Estudios e Análises
T.6. Premio TAW al Mejor Proyecto en Accesibilidad Web.
El jurado declara desierta esta categoría.

Facilidades para el acceso a la administración electrónica

He encontrado esta noticia en el periódico El Mundo: El acceso a la administración electrónica para los discapacitados, más fácil. La noticia dice:

Las personas con discapacidad podrán acceder a la administración electrónica con mayor facilidad, gracias a la firma de un convenio firmado entre la Fundación ONCE y la Fundación Europea para la Sociedad de la Información y la Administración Electrónica.

El convenio, entre otros puntos, incluye el desarrollo de una herramienta informática para permitir el uso de todos los programas del Servicio Administratel a las personas con discapacidad, incluyendo aquellas que poseen una discapacidad visual severa.

¿Qué es Administratel? Pues no lo sé, pero esta es la página web de Administratel.

Esquinas redondeadas

Las esquinas redondeadas, como las que se pueden ver en esta misma página, son un estilo visual muy empleado por su vistosidad. Sin embargo, tienen varios problemas de los que me gustaría destacar dos:

• Se suelen basar en el empleo de imágenes, lo que origina un aumento en el peso de la página (aumenta el tiempo de carga) y origina problemas de mantenimiento (por ejemplo, si se desea cambiar los colores hay que cambiar las imágenes).
• Al utilizar imágenes puede ocasionar problemas de accesibilidad o, al menos, molestar a los usuarios que empleen un lector de pantallas.

Acabo de encontrar Esquinas redondeadas sin emplear imágenes: sólo CSS y JavaScript. Se trata de una traducción de la página Nifty Corners Cube. Desde estas páginas nos podemos descargar un script en JavaScript que permite tener esquinas redondeadas (y algunas cosas más) sin tener que utilizar imágenes. Y si JavaScript no está disponible, no pasa nada, las esquinas salen cuadradas pero la página se ve bien.


Un ejemplo de página que usa este script:



¿Cómo se consigue? En Nifty Corners: rounded corners without images (la primera versión de este script) se explica el truco.

Lector de pantalla para teléfonos móviles

He encontrado esta noticia en el periódico El Mundo: 'Mobile Speak', una aplicación para personas ciegas que lee la pantalla del móvil. Según dice, es el primer lector de pantalla para teléfono móvil que se lanza en el mercado español. Parece que sólo está disponible para el sistema Symbian y supongo que también permitirá navegar con los navegadores integrados en los teléfonos móviles.

Control cerebral del ordenador

He encontrado esta noticia en el periódico El Mundo: Los discapacitados motrices podrían jugar en el mundo virtual de Second Life. La noticia nos cuenta que en la Universidad Keio de Japón (la misma que junto con el MIT y el INRIA fundaron el W3C a mediados de los noventa) están experimentando con un sistema que consiste en unos electrodos que se conectan al cuero cabelludo del usuario y le permite moverse por Second Life simplemente con el pensamiento.

Esta técnica se conoce como control cerebral o control neural. Evidentemente, no se tiene que limitar exclusivamente a Second Life, se puede emplear para cualquier otra tarea, como por ejemplo navegar por Internet.

Hay más gente que está trabajando en este tema e incluso ya hay algunas empresas que venden estos dispositivos, aunque por ahora no son muy precisos y requieren de un entrenamiento previo largo (que el ordenador aprenda a interpretar las señales que emite el cerebro). Algunso artículos sobre el tema:

• Control cerebral
• Casco de 'ondas cerebrales' controla un ordenador
• El reto del control remoto neural

JavaScript no molesto (4): separación del JavaScript

La entrada de ayer terminaba con la pregunta ¿No se puede separar el código JavaScript del código HTML como se hace con CSS?

Sí, sí que se puede. Una página web se puede construir mediante capas:

• Capa de contenido: la estructura y el contenido con etiquetas de XHTML.
• Capa de presentación: la presentación del contenido definida con CSS.
• Capa de comportamiento: el comportamiento del contenido (por ejemplo, la respuesta ante una acción del usuario) definido con JavaScript.

Con un diseño basado en capas logramos reducir el acomplamiento entre los distintos componentes (contenido, presentación y comportamiento), lo que se traduce en importantes beneficios: disminución de los errores, reducción en los costes de mantenimiento, etc. Pero además, una página web construida de esta forma (que se conoce como progressive enhancement) casi siempre es graceful degradation, y por tanto la página web funcionará correctamente aun en el caso de que falte algún tipo de componente (CSS o JavaScript).

¿Cómo se puede lograr esto? En el código HTML no vamos a escribir ni una sola línea de código JavaScript. Más aun, tampoco se van a emplear los manejadores de eventos como onclick, onblur, etc.

Desde JavaScript, se puede asignar código de JavaScript a un manejador de eventos con el siguiente código:

elemento.evento = acccion;

Para seleccionar un elemento de la página web (una celda en una tabla, un botón en un formulario, un enlace, etc.) se puede emplear:

• getElementById(id): selecciona el emento indicado por el id.
• Usar una combinación de getElementsByTagName(etiqueta) y getAttribute(atributo) para seleccionar elementos con un atributo específico.

En la entrada JavaScript no molesto (3): las ventanas emergentes se puso como ejemplo los enlaces que se abren en ventanas emergentes. Para indicar que un enlace es de este tipo, vamos a añadir al atributo class un valor que no se emplea en el CSS, pero que desde CSS nos va a permitir saber que se trata de una ventana emergente:

<a href="http://www.ua.es/" class="estilo popup">Universidad de Alicante</a>
En el atributo class, el valor estilo se emplea en el CSS para asignar una presentación concreta, mientas que el atributo popup se emplea en JavaScript para identificar los enlaces que se tienen que abrir en ventanas emergentes:

window.onload = prepareLinks;
function prepareLinks() {
  var links = document.getElementsByTagName("a");
  for (var i=0; i= 0) {
      links[i].onclick = function() {
        popUp(this.getAttribute("href"));
        return false;
      }
    }
  }

}

function popUp(winURL) {
  window.open(winURL,"popup","width=320,height=480");
}

En el código anterior se realizan los siguientes pasos:

1. Se asigna al evento onload la función prepareLinks: esta función será llamada automáticamente cuando la página termine de cargarse.
2. La función prepareLinks obtiene un array con todos los enlaces de la página web.
3. Para cada enlace, se comprueba si el atributo class contiene el valor popup.
4. Si el enlace está marcado como popup, le asigna una función de JavaScript al evento onclick.

Para más información sobre cómo lograr la separación del código JavaScript:

• DHTML no intrusivo
• Nociones básicas de JavaScript no intrusivo
• Behavioral Separation
• Unobtrusive Javascript
• Javascript no obstructivo, Manual de buenas maneras (traducción al español del anterior)
• 7 reglas de oro para hacer un javascript no obstructivo