Accesibilidad, mitos y pautas (2)

Mitos y leyendas

De todos los despropósitos, exageraciones, malentendidos e imprecisiones acaecidos en torno a este tema hay uno que puede catalogarse sin paliativos como error histórico: la versión "sólo texto". La única razón real para justificar su inclusión es la de compensar una pésima utilización del lenguaje HTML. Esa doble versión de un sitio, que es totalmente innecesaria si se hacen las cosas correctamente, es uno de los ingredientes de ciertas "creencias populares" que relacionan directamente accesibilidad con texto plano y trabajo extra. Lo cierto es que la simple separación de estructura y apariencia, tarea muy sencilla que sólo precisa utilizar los estándares, es suficiente para olvidarse de tales locuras.

Otra confusión bastante común es la de renunciar a lo nuevo con el fin de asegurar la viabilidad de un sitio en cualquier circunstancia, lo cual roza el absurdo cuando se está hablando de tecnologías con compatibilidad "hacia atrás", como el HTML. En realidad es prácticamente una visión algo menos retrógrada y restrictiva que la de la versión "sólo texto".

En cuanto al aumento de costes y trabajo que supone mantener un sitio accesible también se podría discutir mucho. Es evidente que arreglar un sitio inaccesible ya existente supone un gasto, pero si hablamos de un nuevo desarrollo todo consiste en seguir una metodología adecuada, que no se traduce en un aumento de trabajo, pero que sí requiere un mínimo de formación para conocer las tecnologías implicadas y cómo afectan a los diferentes usuarios. Incluso la aplicación de adaptaciones específicas (teclas de acceso rápido, descripciones detalladas de elementos visuales, etc.), tampoco supone una tarea titánica.

Mucho se ha escrito también sobre los scripts en el lado del cliente, más concretamente sobre JavaScript, sobre su presunta indispensabilidad en la confección de sitios y sobre sus problemas de accesibilidad. El tema de la idoneidad de los scripts podría alimentar otro debate diferente, y el de las técnicas para crear scripts accesibles podría ser el tema de un taller. Por tanto aquí tampoco nos detendremos en esto como si fuera algo especial. Simplemente plantear un ejemplo de aplicación por todos conocido. JavaScript ha tenido un protagonismo vital en ciertas técnicas denominadas HTML dinámico. No es ningún secreto que muchas de las páginas que las utilizan son totalmente inaccesibles en determinadas situaciones. Sin embargo, lo cierto es que no lo son por sí mismas, sino por haber utilizado ciertas tecnologías de forma errónea e incluso poco responsable. Dicho en otras palabras: lo dinámico no está reñido con lo accesible. Es nuevamente una cuestión de pautas.

Beneficios colaterales

Trabajar con criterios de accesibilidad tiene ventajas en otros ámbitos diferentes. La separación entre estructura y contenido facilita en gran medida el mantenimiento del sitio; el uso de tecnologías estándar garantiza la interoperabilidad; la precisión sintáctica simplifica la detección de problemas o errores; y la corrección semántica potencia la gestión eficiente de contenidos.

Pero es dentro del propio campo donde podemos encontrar ventajas con las que no contábamos. La accesibilidad no debe verse como una consideración hacia las minorías, sino como una apertura a toda la audiencia, con todas las implicaciones mediáticas, educativas y comerciales que ello supone.

Usuarios que han visto este tema también han visto...

- Las encuestas de opinión no son adecuadas para la evaluación de la usabilidad
- Lo que no se debe hacer con un ordenador
- Boletines. Por qué y para qué
- Gestión de contenidos desde cero
- La LSSI y tú

- Versión imprimible de este documento

- Enviar por e-mail este documento