Como solución han usado ReadSpeaker. No conozco esta solución en particular, pero intuyo que el resultado de estas herramientas está muy relacionado con el marcado de la información. A continuación podéis encontrar una imagen en la que se resalta el marcado usado en cada destacado o noticia:

Obviamente el marcado de la página es malo, usar <strong> cuando lo apropiado era <hX>, o que el párrafo debiera ser el cuerpo del destacado o la noticia en lugar del enlace + strong + texto, son sólo dos ejemplos. Podría seguir enumerando cosas que solucionan fácilmente si quien tiene que hacerlo sabe de que va eso de la accesibilidad y estándares web.

¿Qué obtenemos como resultado? Pues os animo a que escuchéis el audio. Entre lo que visualmente parece un título (“Ghirlandaio y el Renacimiento en Florencia, en el Museo Thyssen”), pero semánticamente no lo es según el código fuente (HTML), no hay ningún tipo de pausa. Recorriendo las demostraciones del producto en su sitio oficial podéis comprobar que tras un header (<hX>) seguido de un párrafo (<p>) hace la correspondiente pausa.

Esto me recuerda a una entrada que publiqué hace tiempo titulada Como los cangrejos. Cuánto más tiempo tiene que pasar para que la administración pública se de cuenta de que para hacer las cosas bien hay que contratar a profesionales.

A ver si ahora que lo dice INTECO se enteran de que la plataforma de validación y firma electrónica @firma que ahora impulsa el Ministerio de Administraciones Públicas incumple con la norma UNE:139803:2004. Para aquellos que nos queráis leer el documento (19 páginas), he rescatado un fragmento que no tiene desperdicio, especialmente cuando dice “choca” cuando quiere decir “incumple“:

El problema surge dado que para la lectura de estos certificados por parte de un portal Web se debe utilizar tecnología de ejecución dinámica, de mayor potencia que el lenguaje HTML estándar. Tal tecnología consiste en scripts, applets, objetos ActiveX u otros elementos que puedan ser ejecutados en el ordenador personal del usuario en el momento de la operación (para leer el certificado).

La ejecución de estos elementos choca con los requisitos de accesibilidad de la Norma UNE 139803:2004 que hace referencia a que las páginas deben poder utilizarse aunque los scripts y objetos de programación estén desconectados o no sean soportados.

Aquellos usuarios que tengan desactivada la ejecución de este tipo de tecnologías (o no dispongan de ellas) en sus ordenadores personales no podrán acceder a la aplicación. Esto supone, aplicando los criterios de accesibilidad expuestos, un incumplimiento de los mismos. Por lo que evita que la aplicación, y por extensión el portal, sean accesibles.  Respecto a este hecho se entiende que existe una barrera tecnológica que no es posible superar, dado que no hay forma de leer las claves de un usuario prescindiendo de este tipo de tecnologías.

No obstante, se recomienda, en cualquier caso, que frente a la posibilidad de realizar la citada operación online se permitan otras alternativas como por ejemplo posibilitar la realización presencial de la operación, incluir un formulario PDF accesible firmado digitalmente, posibilitar la tramitación telefónica, por correo postal, etc.

El uso de certificados digitales por parte del cuidadano, no el técnico ni el ciudadano con experiencia con los ordenadores, sino aquel ciudadano que por ejemplo se dedica al campo, vive en un medio rural y que quiere consultar el estado de una subvención que ha solicitado yendo a su capital de provincia para entregar un montón de documentos, no ha tenido el éxito. La forma en la que los trámites eléctrónicos requieren autenticarse para verificar que el ciudado es quien dice ser, debe cambiar. El diseño de iteracción ciudadano – administración electrónica tiene problemas técnicos y legales.

Que la página tarde en cargar 6.52 segundos es lógico, las imágenes que se muestran están escaladas (atributos width y height del tag img) por el propio nagevador y se transfieren en su formato (tamaño y profundida de color) original. Si alguien accediera a esta página con tecnología GPRS o 3G/HSDPA, ¿Cuánto le costería la broma? Quizás lo note cuando un aviso le indique que ha excedido la transferencia contratada.

Lo significativo es que este sitio web ha sido publicado recientemente.

A continuación algunas notas de las intervenciones que me parerieron más interesantes:

Acciones de INTECO para la promoción de estándares de Accesibilidad

• La verdad es que había oído hablar muy poco de INTECO. Para aquellos que no lo conozcan es el Instituto Nacional de Tecnologías de la Comunicación perteneciente al Ministerio de Industria, Turismo y Comercio.
• Parece ser que uno de los objetivos es crear un observatorio de la accesibilidad en España.
• En su sitio web podemos encontrar algunos informes interesantes e información muy útil sobre legislación y normativa.
• Creo que debería ser desde este observatorio desde el que se llamase la atención a aquellas administraciones públicas que esto de la accesibilidad y los estándares web lo tienen muy poco priorizado.

Accesibilidad y usabilidad en el Ayuntamiento de Madrid: apuesta por los estándares del W3C

• El resultado es muy bueno. Parece que ellos sí tienen aprendida la lección.
• Me hubiera gustado una presentación algo más técnica en la que se hubiera hablado de los retos que proyecto de esta embergadura tiene.

La Accesibilidad Web en Caixa Galicia

• Me resultó interesante conocer la impresión de uno de los responsables de la accesibilidad y estándares web de Caixa Galicia.
• Al parece el gran reto fue manejar el volumen tan elevado de información para su adaptación a la web.
• La apuesta está clara, prueba de ello son sus canales para dispositivos móviles.
• Están convencidos de que el uso de los estándares web se verá reflejado en una mejora de la satisfacción de sus clientes.

De la accesibilidad a la movilidad pasando por los estándares

• Fue una de las intervenciones más atractivas para mi especialmente porque se habló de W3C mobileOK y Mobile Best Practices.
• TAW amplia sus posibilidades añadiendo TAW mobileOK.
• Se hizo una breve presentación de la solución Merkur, que es un sistema de adaptación dinámica de contenidos web. Me hubiera gustado ver una demostración.
• A las referencias que allí se dieron añado dev.mobi y ready.mobi.

Experiencia de un proyecto desde cero: soitu.es

• Muy buena la versión móvil de soitu.es
• Gran parte de las herramientas han sido fruto de un desarrollo interno.
• Me encanta su actitud, liberan conocimiento.
• Usan soluciones libres como Apache y PostgreSQL, lenguajes como C, PHP y Perl.

Aplicaciones web – APIs y formatos para simplificar el desarrollo y mejorar su utilidad

• Una intervención de Charles McCathieNevile estupenda.
• Hizo una exposición sobre su visión de los estándares y de la gran cantidad de APIs que existen para trabajar en la web (dojo, prototype, etc.) y de la necesidad de estandarizar la forma en la que esas API trabajan para facilitar los desarrollos.
• Habló sobre HTML5 y dejo bien claro que esta “nueva versión” es una revisión de lo anterior con el fin de dejar lo que vale y añadir algunas cuestiones necesarias por el momento en el que se encuentran los agentes de usuario.
• Habló de otros estándares del W3C como MathML y SVG.

Tu ruta por la ciudad de Zaragoza: Aplicación de la web semántica en la Web del Ayuntamiento de Zaragoza

• La presencia del Ayuntamiento de Zaragoza en eventos comienza a resultar un poco aburrida sin embargo llevan unos años haciendo muy bien las cosas y están marcando una diferencia con el resto de administraciones.
• Con base en la web semántica han construido un servicio para ofrecer rutas turísticas. El servicio integra modelos semánticos procedentes de bases de datos (monumentos, restaurantes, etc.), agenda de actividades y datos espaciales (Google Maps y IDEZar).
• Un proyecto más donde el uso de estándares web es crucial para garantizar la interoperabilidad entre múltiples sistemas y que posteriormente la información pueda ser consumida.

Esto sólo han sido algunas notas que me traje del evento. Si alguien quiere las transparencias de las intervenciones puede encontrarlas en la página web del evento.

C/ Torricelli, 26
41092
Isla de la Cartuja
Sevilla

El temario que he preparado es el siguiente:

1. Introducción a la Accesibilidad Web
   1. ¿Qué es?
   2. ¿Para qué sirve?
   3. Factores que intervienen en la forma en que se accede a la Web
   4. Cómo utilizan la Web las personas con discapacidad
2. W3C. World Wide Web Consortium
   1. Presentación
   2. W3C WAI (Web Accesibility Initiative)
   3. Pautas de Accesibilidad al Contenido en la Web (WCAG 1.0)
   4. Puntos de verificación para las Pautas de Accesibilidad al Contenido en la Web ( WCAG 1.0)
   5. Técnicas para Pautas de Accesibilidad al Contenido en la Web (WCAG 1.0)
   6. ¿Qué hay de las Pautas de Accesibilidad al Contenido en la Web, WCAG 2.0?
3. Marco legal sobre Accesibilidad Web
4. Evaluación de la Accesibilidad Web
   1. Métodos y técnicas
   2. Herramientas
   3. Caso práctico
5. Recomendaciones para la elaboración de contenidos Web
6. Accesibilidad Web y gestores de contenidos de software libre
7. La moda de las pegatinas y las certificaciones

Para más información sobre el curso, acceder a la página oficial.

Viendo la agenda, he comprobado que Yaco Sistemas participará con una presentación de 20 minutos titulada: “El reto de Yaco: Estandares abiertos en un mercado liderado por lo propietario y cerrado“.

Tras el evento procuraré escribir algunas impresiones.

El rediseño que se ha realizado en el sitio web del Gobierno de Aragón deja mucho que desear, tiene errores demasiado graves, sin embargo, lo que más me sigue llamando la atención es como en la administración pública siguen sucediendo estas cosas. ¿Por qué seguimos teniendo estos resultados tras un concurso público?

Durante el día de hoy he estado preparando una implementación partiendo de la idea original, simplemente me he limitado a aplicar buenas práticas que existen alrededor de los estándares web. La propuesta es muy mejorable, pero si yo que no me dedico a esto he conseguido este resultado durante un domingo lluvioso, ¿Qué no puede llegar a conseguir un desarrollador especializado en interfaces web?

Recientemente se ha publicado el sitio web del Ayuntamiento de Lepe. Este proyecto ha sido realizado por la empresa en la que actualmente trabajo y tengo que reconocer el excelente trabajo que mis compañeros han realizado. Evidentemente hay cosas que se pueden mejorar, pero bueno, ahora por fin sé que no era una cuestión de Plone. Hoy por hoy estoy convencido de que se pueden conseguir buenos interfaces de usuario haciendo uso de estándares web y buenas prácticas en accesibilidad web. En esta ocasión se ha comprobado la interfaz de usuario en multitud de agentes de usuario y con distintas configuraciones (versiones, sistemas operativos, etc) y el escalado de la fuente es uno de sus puntos fuertes.

Para los que no estamos acostumbrados a trabajar con leyes, normas o reales decretos ayuda bastante que alguien nos guíe y nos diga exactamente en que se resume esto de la accesibilidad web desde un punto de vista legal. Para ello, lo más conveniente es que accedáis a la norma UNE 139803:2004 donde se explica que usan como referencia las pautas de accesibilidad publicadas por el grupo de trabajo WCAG-WG del W3C y se indica el objeto y campo de aplicación de dicha norma. Sin avanzar más, comentar los siguientes puntos:

1. La norma trabaja sobre unas pautas cuya última revisión se realizó el 5 de mayo de 1999. Sólo tenéis que hacer un esfuerzo de imaginación y recordar qué era y cómo era la web, y por extesión internet, en aquella época y compararlo con la actualidad.
2. La norma aplica a cualquier contenido disponible en redes informáticas con especial énfasis en los contenidos web que son accedidos mediante aplicaciones de usuario. Si no me equivoco, entiendo que aquí entran tanto aplicaciones web (RIA o no) como sitio web con contenidos de carácter informativo, divulgativo, docente, institucional, etc. Es decir, lo que muchos denominados sitios web (portales). Por ser más explícito, esta norma debe aplicarse tanto a una aplicación RIA para un sistema GIS como al sitio web de una consejería.

Teniendo en cuenta que la ley dice lo que dice, os expongo algunas situaciones que esto viendo. Si un organismo público licita la creación de un sitio web me parece estupendo que se indique de forma clara que es de obligado cumplimiento la legislación española en cuanto a accesibilidad se refiere. En el caso de un sitio web, ¿Qué implicaciones tiene esto para la empresa adjudicataria? Básicamente, el que exista una ley que oblige a que se cumplan una serie de pautas puede garantizar un cierto nivel de accesibilidad web. En este sentido, la empresa si tiene experiencia y profesionales correctamente formandos en la materia, no tendrá el más mínimo problema. Hoy por hoy, los estándares web y unas buenas prácticas en el desarrollo web, garantizan niveles optimos de accesibilidad. Esta claro que el hecho de que existan leyes al respecto es un paso, pero, ¿Es el paso correcto?. Algunas de las situaciones que he vivido:

1. Si la página valida según no sé qué herramienta mi sitio web es accesible. Hay que recordar que los validadores sólo son una herramienta de ayuda, pero luego hay mucho trabajo por hacer.
2. Antes de poner el sitio web en producción hay más preocupación porque se vea bien el logotipo del W3C que de comprobar que el lenguaje de marcado modela una semantica correcta, que se han realizado pruebas de renderizado en los navegadores descritos en el catálogo de requisitos no funcionales, el peso de las página, etc.
3. Como hay una ley y ésta aplica a todo contenido web, incluye también a aplicaciones del tipo visores GIS, herramientas colaborativas, webmail, calendarios, etc. Y es aquí donde desde mi punto de vista se comete el principal error. Por regla general el conjunto de usuarios para el que se desarrolla un sitio web es mucho más amplio y variado que el conjunto de usuarios que van a usar por ejemplo una herramienta corporativa como por ejemplo un webmail o un calendario corporativo. Entiendo además que los requisitos que se pueden establecer para ambos tipos de contenidos web pudieran ser los mismos, sin embargo, determinados requisitos en el caso de las aplicaciones web pueden ayudar a mejorar mucho las experiencias de usuario y la usabilidad de las mismas. Ahora bien, ¿Qué pasa si intentamos aplicar la legislación vigente al desarrollo de un visor GIS o un calendario corporativo? Está claro que técnicamente se puede definir alternativas que faciliten el acceso a la información, pero en el caso de las aplicaciones web eso tiene un coste importante. Sin embargo, en los sitio web no tiene por qué.
4. Tengo la sensación de que la accesibilidad web se percibe como una propiedad de los proyectos web, es decir, una propiedad total que establece si algo es o no es accesible. Desde siempre he creído que resulta complejo medir el grado de accesibilidad y que es algo en lo que siempre se puede seguir trabajando y mejorando. Es como medir la calidad del software, es cierto que existen unos indicadores para medir ciertas cuestiones, sin embargo, sólo son eso, indicadores. En la accesibilidad eso indicadores podrían ser la semántica del marcado (eliminando capa de representación y comportamiento), peso de la página, compatibilidad con agentes de usuarios, etc.
5. Después de meses desarrollando una aplicación RIA donde se han solicitado comportamientos de arrastrar y soltar, actualización de contenidos en tiempo real, etc. te dicen, “todo esto funcionará si desactivamos javascript, ¿no?” “Y se podrá usar desde un dispositivo móvil, ¿no?” Es importantísimo fijar este tipo de requisitos desde el principio, y cuando surjan esas cuestiones hacer ver que su implementación requiere usar otro de soluciones más propias de las aplicaciones web tradicionales y que eso conlleva un coste importante. Sino, que les pregunten a los de Google, cuando les ha costrado hacer la versión dual de GMail. Y si me apuras, una tercera versión para móviles.

A continuación algunas cuestiones que considero interesantes para debatir:

1. Si una administración publica necesita hacer un visor GIS, ¿Qué tiene que hacer para cumplir la ley en vigor? ¿Cómo se proporciona alternativa a un visor de esas características? Y en caso de hacerlo, ¿A qué coste?
2. Entiendo que si el W3C WAI distingue entre contenido web y aplicaciones web será porque a ambas cosas, aunque compartan cosas y tengan similutides, no se les pueden aplicar las mismas pautas y buenas prácticas. Copio literalmente de la página del W3C WAI:
   1. WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.
3. Al igual que se pretenden concienciar a la gente de que no todos somos iguales, de que accedemos a la información de formas distintas, de que tenemos necesidades diferentes y de que existe gente que por circunstancias posee una discapacidad (puntual o de por vida) veo también necesario concienciar a las administraciones públicas sobre las implicaciones que tienen las leyes que están desarrollando. Las implicaciones afectan a los tiempo de entrega de los proyectos, a los costes, la calidad de los mismos, etc.
4. Los requisitos técnicos que requiere un sitio web son muy distintos de los que requiere una aplicación web, y máxime si se quieren emplear soluciones que potencien las bondades de los agentes de usuario modernos.

Creo que son cuestiones importantes y que mucho tienen que ver con los resultados que nos encontramos, algunos muy buenos y otros muy malos. Yo entiendo que para la administración pública sea difícil redactar un pliego de prescripciones técnicas donde todas estas cuestiones queden recogidas, pero también hay que pensar que igual de difícil es para aquellas empresas que quieren preprarar una buena oferta y que en muchos casos se ven abocados a cruzar los dedos y esperar a ver como se desarrolla el proyecto.