A continuación podéis ver dos capturas de pantalla de una misma página web, realizadas con UploadScreenshot en Chrome 10.0.648.205 y Firefox 3.6.16, ambos sobre Ubuntu 9.

Captura de pantalla realizada en Chrome

Captura de pantalla realizada en Firefox

Las propiedades CSS de la hoja de estilos aplicada al párrafo en cuestión son:

1
2

font-size: 0.9em; /* aplicada explícitamente al párrafo */
font: 10pt Arial,Helvetica,sans-serif /* heredada desde body */

Usando la herramienta para desarrolladores que incorpora Chrome podemos ver los estilos que realmente se están aplicando al párrafo. Se han eliminado algunas propiedades que nada tienen que ver:

1
2
3
4
5
6
7
8
9

color: #555;
font-family: Arial, Helvetica, sans-serif;
font-size: 12px;
font-style: normal;
font-variant: normal;
font-weight: normal;
line-height: normal;
text-align: left;
vertical-align: baseline;

Usando el plugin Firebug en Firefox se comprueba que las propiedades que se aplican realmente son:

1
2
3
4
5
6
7
8
9
10
11
12
13

font-family: Arial,Helvetica,sans-serif
font-size: 12px
font-weight: 400
font-style: normal
color: #555555
text-transform: none
text-decoration: none
letter-spacing: normal
word-spacing: 0
line-height: 16px
text-align: left
vertical-align: baseline
white-space: normal

Está claro que algo se me tiene que estar pasando, pero parece que a otros también porque cuando Javier Cañada me dio a conocer filmin pude comprobar como el layout tenía problemas en Chrome. Y digo problemas porque había textos que dejaban de leerse al quedar ocultados por otros elementos.

¿Alguna idea? Yo mientras tanto prometo seguir investigando.

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 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.

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.

Del 3 al 5 de Octubre de 2007, Gijón, Asturias (ESPAÑA)

Este año no podré asistir porque me coincide con un curso, una lástima. Confío en que los blogs de los asistentes se inunden de comentarios, opiniones, etc.

Ayer precisamente escribía un comentario en el blog de Luis Villa sobre su post titulado Grandes mentiras: la accesibilidad no es un coste añadido. Es evidente que si ponemos como ejemplo al sitio web que estoy comentando, la accesibilidad tiene un coste añadido. Por un lado hacerlo mal con un coste de casi 14 millones de euros , y por otro lado, hacerlo bien. Sospecho que el importe por el que se ha adjudicado el concurso público incluye otras cosas a parte del sitio web. Con independencia de la partida presupuestaria dedicada a la ejecución del nuevo sitio web, lo que si tengo claro es que se ha hecho con dinero público y el resultado es lamentable. Personalmente creo que se ha mal gastado dinero público y deberían dar explicaciones.

Después de estas impresiones creo que es el momento de aportar algunas cuestiones técnicas que justiquen por qué pienso que el resultado es lamentable. Como he comentado, sólo voy a enumerar algunas cuestiones relacionadas con estándares web y accesibilidad, justo las que me de tiempo antes de comenzar a cenar. Porque no es justo que encima les hagamos el trabajo a la UTE adjudicataria. Menuda pareja.

1. El layout es fijo a 800 pixeles y centrado. Inicialmente esto no tiene por qué ser un problema, aunque para este tipo de contenidos un layout elástico hubiera resultado más interesante teniendo en cuenta la disparidad de configuraciones que los usuarios usan. Precisamente las consultorías previas están para este tipo de cosas, para obtener indicadores con los que posteriormente tomar decisiones. ¿Habrán realizado algún estudio sobre los agentes de usuario, resoluciones, sistemas operativos, javascript habilitado, java habilitado, etc…?
   A pesar de haber elegido este tipo de layout, a una resolución de 800 pixeles de ancho aparece la barra de desplazamiento horizontal cuando no es necesario porque el contenido ocupa 765 pixeles. Evidentemente, el layout está mal implementado.
   
2. Viendo la cabecera HTTP se comprueba que detrás de todo esto hay un producto comercial, en este caso de Oracle. Tampoco tiene nada de malo, pero parece contradictorio que haya tantas iniciativas y proyectos relacionadas con el software libre o de fuente abierta subvencionados por la administración pública y que luego se opte por soluciones comerciales para un sitio web como este. ¿Quizás el software libre sea argumento con fines únicamente políticos? En fin, esto es otra batalla.
   Lo que pretendía comentar es que el servidor HTTP está devolviendo información con una codificación UTF-8 y sin embargo en el Content-type indica que es text/html; charset=windows-1252. Además lo indica cuatro veces. Pensaba que este meta se definía una única vez en la sección <head>.
   
3. El documento que recibe nuestro navegador web no es un documento HTML, es algo que parece ser un documento HTML por las etiquetas de marcado que usan pero desde luego dista mucho de ser un documento HTML bien formado. No son son muchas las ocasiones en las que uno se encuentra una declaración de documento (DOCTYPE) en la línea 665, y en la línea 787, y en la 877, y en la 1409, y en la 1582. Un total de 5 apariciones. Desde luego se han tomado al pie de la letra el concepto de componente con los portlets.
   
4. El layout está implementado usando tablas.
5. Acopamiento máximo entre el contenido y su representación.
6. Malas prácticas en el uso las hojas de estilo en cascada. No sólo no aprovechan su potencial, sino que la estrategia que han seguido les dificultará muchísimo el mantenimeinto. Más de 400 clases CSS y estilos inline lo dicen todo.
7. Mínima accesibilidad en las URL del sitio web. ¿Qué sentido (semántico, claro está) tiene está URL: http://www.congreso.es/portal/page/portal/Congreso/Congreso? ¿Qué sentido tiene? Que nos encontramos en el congreso, que a su vez está el congreso en un nivel superior, que es un portal, que el portal es una página, que pertece a un portal, y todo ello en el nombre de dominio www.congreso.es. Desde luego existen otras URL que el gestor de contenidos genera que son un jeroglífico. ¿Dónde están esas URLs de la forma: http://www.dominio.es/seccion, http://www.dominio.es/noticias/54, http://www.dominio.es/contenido/2007/05/01?
8. Carencia de contenido sindicado. Está claro que proporcionar canales alternativos de comunicación facilitan el acceso a la información. ¿Y eso no tiene algo que ver con la accesibilidad?
9. Carencia absoluta de definición semántica de abreviaciones y acróminos.
10. Ausencia de textos alternativos, descripciones contextuales (title, lengdesc) y otros elementos que ayuden al acceso de la información.
11. Uso indiscriminado de javascript a lo largo de todos los documentos.
12. Mal funcionamiento de los sistemas de caché por el uso inline tanto de las hojas de estilo como del código javascript.

Habría otras muchas cuestiones que comentar pero no voy a dedicarle más tiempo. Otros compañeros también lo han comentado:

• Daniel Torres Burriel
• Andrés Nieto Porras
• usalo.es

Me pregunto qué pasa con la Legislación Española sobre Accesibilidad para la Sociedad de la Información. En fin, algo no va bien.

Como no puede ser de otra forma me parece una iniciativa estupenda y más cuando se celebra por el sur de España. En alguna que otra ocasión he hecho constar la carencia de formación que muchas empresas del sector tienen en lo que estándares web se refiere. Esperemos que iniciativas como esta hagan que las empresas tomen medidas al respecto. Particularme “no me importa demasiado” que los productos o servicios que estas empresas ofrecer hagan un uso correcto de los estándares web, sin embargo, estas empresas pueden tener como cliente a la administración pública. Y ahí, sí me puedo ver afectado como usuario final.

Viendo el perfil de los ponentes observo que los estándares web que se tratarán serán los que normalmente se suelen tratar en eventos de este tipo. Quizás echo en falta otros estándares web que no se “ven” tanto, pero que no son menos importantes. En el desarrollo web no todo es la capa de representación e interacción, hay más cositas por detrás.

El jueves pasado terminó una nueva edición del curso sobre estándares web que he impartido en la Universidad de Sevilla. Para esta nueva edición no he preparado transparencias nuevas, usé las mismas que en la edición anterior [PDF|ODP]. Sin embargo, sí se han preparado nuevos ejemplos básicos (textos, listas, tablas, etc…) y se han revisado los 5 layouts de la edición anterior. Este material está disponible en un sistema de control de versiones. Los datos para acceder son:

• SCM: Subversion
• HOST: https://svn.scenesp.org/repos/EstandaresWeb/trunk
• USER: anonymous
• PASSWORD: anonymous

Esta edición se ha desarrollado durante tres jornadas de 5 horas. El guión del curso ha sido:

Primera jornada: Introducción

• ¿Qué son los estándares web? ¿Qué debemos entender por estándares web?
• La importancia de independizar contenido/estructura, forma/representación/aspecto y comportamiento/interacción.
• ¿Por qué y para qué debemos usar estándares web?
• Metodología, una propuesta para alcanzar nuestros objetivos con estándares web.
• Herramientas (Aptana IDE y algunas extensiones para Firefox)

Segunda jornada: Lenguaje de marcado

• Estructura global de un documento HTML y XHTML.
• Importancia del DOCTYPE, opciones y recomendaciones
• Texto
• Listas
• Tablas
• Vínculos
• Importancia de una semántica correcta.

Tercera jornada: Hojas de estilo

• Selectores
• Modelo de caja
• Contenido generado, numeración automática y listas
• Colores y fondos
• Fuentes
• Textos

En esta edición hice bastante hincapié en la importancia que tiene que nuestros documentos sean sintáctica y semánticamente correctos. Para la sintaxis nos ayudamos del servicio de validación del W3C para lenguaje de marcado y de la extensión Tidy Validator, sin embargo para la semántica hicimos varios ejercicios y visitamos algunas páginas sobre las que discutir acerca de su marcado. Una vez que se vieron las etiquetas a partir de las cuales íbamos a construir nuestras páginas, tratamos cuestiones como por ejemplo:

• Por qué si estamos maquetando un artículo es conveniente que el títular esté marcado como <hx>.
• Por qué es correcto usar una lista para implementar un menú de navegación.
• Por qué etiquetas como <i> o <font> están definidas como no recomendadas.
• Por qué atributos como “align” en las tablas no deben usarse.
• XHTML como una formalización de HTML. Principales diferencias desde el punto de vista sintáctico.

Una vez vistos los conceptos teóricos comenzamos con algo de práctica. El primer ejercicio consistía en implementar el siguiente layout:

Les entregué el layout impreso en un A4 y les propuse que cogiesen un bolígrafo y que marcasen la información que tenían delante de ellos en el A4. El objetivo del ejercicio era hacerles pensar qué etiquetas debían usar y cómo usarlas. Creo que fue un ejercio muy interesante porque ellos mismos se preguntaban si el hecho de que el título estuviera centrado era contenido o forma o si la imagen iba dentro del párrafo. Tras resolver algunas dudas y debatir sobre algunas cuestiones, nos dispusimos a transladar el marcado que habíamos definido sobre el papel a un documento XHTML. A continuación un ejemplo del marcado sobre el papel:

Tras la implementación vinieron las preguntas: ¿Cómo centro el título? ¿Por qué la imagen descuadra el texto y no sale donde la he colocado? Antes de comenzar con esas cuestiones les enseñe el ejercicio resuelto (XHTML + CSS) y les mostré como todo lo que tenía que ver con la representación y la forma, iba en la hoja de estilos. Haciendo uso de la extensión de Firefox, Web Developer, desactivé la hoja de estilos del ejemplo y lo que vieron era justo lo que ellos habían hecho.

Con este ejercicio les intenté mostrar esa separación entre contenido y forma de la que habíamos hablamos y la importancia de definir una semántica correcta, entre otras cosas, para que agentes de usuario como los lectores de pantalla puedan funcionar correctamente. Les planteé la siguiente cuestión: “Si el título del artículo en lugar de marcarlo como <h1> lo hubieramos marcado como <p>, ¿Qué implicaciones tendría?”

La verdad es que si en ediciones futuras tengo la oportunidad y los medios para grabar algunos ejercicios, lo haré. Creo que puede ser un material muy didáctico e interesante para transmitir los conceptos básicos sobre estándares web.

En cuanto tenga un hueco os hablaré sobre un nuevo juguete para virtualizar llamado Xen que un compañero de trabajo me ha enseñado y sobre el que estamos montando cositas.