Estándares y accesibilidad: mínimo indispensable (o Cómo convertirse en un estandarista en 15 horas): Prefacio

Cuando en la institución en la que trabajo me encargaron supervisar la accesibilidad de nuestras páginas, se me hizo evidente que redactar informes sobre páginas ya creadas era un proceso poco eficiente si los profesionales encargados de seguir mis indicaciones tenían que vérselas con una plétora de siglas crípticas como DTD, XHTML o DOM, y de mensajes arcanos al estilo de «la implementación de la funcionalidad de búsqueda del sitio es obstrusiva» o «el marcado de los documentos no cumple las pautas de accesibilidad y no es semántico». Eso sólo habría dado como resultado un cruce inacabable de correos electrónicos interdepartamentales.

En su lugar, propuse dar unas clases sobre estándares web y accesibilidad, para lograr un punto de partida común en cuanto a conocimientos, y para intentar —en la medida de lo posible— implicar a los responsables de cada etapa de desarrollo con el objetivo de crear un sitio accesible, además de hacerles conscientes de:

1. que desde los primeros bocetos de diseño, la accesibilidad y la estandarización ha de ser tenida en cuenta, por las consecuencias críticas que puede suponer su falta de implementación en cualquiera de las fases del desarrollo de un documento (no ya todo un sitio),
2. que la estandarización y la accesibilidad no son un obstáculo añadido a las presiones y problemas del trabajo diario, sino una herramienta para solucionar errores arrastrados de la época en la que teníamos que lidiar con las inconsistentes implementaciones de los estándares en años pasados.

En definitiva, la idea era pasar de un código como éste¹ —tal y como se encontraba a 18 de agosto de 2007—, a un código semántico, válido y accesible.

Así, preparé un curso y sus materiales. Pero por diversas circunstancias, mi iniciativa se fue posponiendo… hasta el día en que se nos avisó de que íbamos a ser sometidos a una auditoría, cuyo objetivo era determinar el grado de adecuación a las normativas españolas que exigen de las páginas pertenecientes a una entidad pública un mínimo de accesibilidad.

Mi sensei suele decir que el miedo es el peor motivo para actuar, pero hemos de reconocer que es el más poderoso. Sí, mi iniciativa prosperó, pero por desgracia, se vio muy condicionada por el plazo de tiempo disponile. Así, el curso duraría apenas quince horas, lo cual es, a todas luces, insuficiente.

Pero al menos es un comienzo.

Lo que presento en este curso relámpago es la versión corregida y ligeramente aumentada de los apuntes que empleé en la clase. Suponen un buen punto de partida para aquel que quiera desarrollar sitios web basándose en los estándares actuales y con la accesibilidad de sus contenidos como uno de los objetivos iniciales.

La estructura del curso —tras la introducción a XML—, sique el modelo teórico de la mejora progresiva (progressive enhancement), por el que un documento se considera el resultado final de una superposición de capas:

Diagrama del modelo teórico de la mejora progresiva

Este modelo enfatiza especialmente la accesibilidad, puesto que las capas sucesivas se aplican de manera que no menoscaben las capas inferiores, sino que añadan una mejora para los usuarios que puedan acceder a ellas, pero que no sean imprescindibles para acceder a los contenidos, ni necesarias para la funcionalidad básica de una página. Pongamos un par de ejemplos:

• Una hoja de estilo puede añadir claridad a un documento y resaltar la estructura semántica del mismo, además de añadirle valores estéticos, pero no de forma que la estructura y la claridad se basen en el estilo, puesto que un usuario puede estar empleando un dispositivo que no acepte esa hoja de estilo. Si mi capa inferior —el marcado—es semántica, aunque pierda el estilo se mantendrá la estructura del documento y por tanto su claridad.
• Un script que sirva para validar un formulario puede proporcionar al usuario información inmediata sobre un posible error en los datos antes de enviarlo, pero no puede hacerse que el envío del mismo dependa de aquel. Si así fuera, los usuarios sin soporte para el script no podrían enviar los datos, que es la funcionalidad básica de un formulario.

A medida que se siga el curso se comprenderá esto mucho mejor.

Por último, puesto que los contenidos del curso se basan en mis lecturas y mi propia experiencia como desarrollador, sería poco práctico tachonar el texto de referencias a las fuentes: los apuntes son una síntesis personal de lo que considero indispensable. Por ello, para ampliar la información de quien esté interesado, he preparado una bibliografía con los manuales que repaso constantemente.

Y creo que como introducción es suficiente. Mejor comencemos con el curso.

Aunque al redactar el contenido del curso he intentado dar por supuesto el menor conocimiento posible de código y programación web, siguen existiendo unos requisitos mínimos. Este curso está pensado para desarrolladores de contenidos que tienen experiencia creando documento en HTML, y unas nociones básicas de este lenguaje, es decir, los que no se han limitado a la interfaz de diseño del WYSIWYG de turno.

Notas

1. Como resulta más elegante juzgar el pecado y no al pecador, diré que esta página es una portada real, pero por mantener el anonimato de los creadores he sustituido todos los textos identificativos —incluyendo los nombres de secciones, los URL, los alt y title, etc.— y los he sustituido por un poco de lorem ipsum. Sin embargo, no he sustituido los nombres de clase, porque ilustran bien uno de los errores comunes a la hora de aplicar hojas de estilo. Si para el lector no son evidentes los fallos, aquí tiene una pista.