Sección: Capa de estructura del documento
1:
Técnicas de accesibilidad
Técnicas generales
En la lista siguiente describo las técnicas concretas dirigidas a satisfacer la mayor parte de las pautas del W3C que tienen que ver con el marcado del documento, pero no todas. El motivo de que no las haya incluido en su totalidad es que las Pautas fueron publicadas en 1999, y parte de su contenido se ha vuelto obsoleto. Así, he eliminado pautas que afectan a elementos que en la DTD de XHTML 1.1 han quedado depreciados, como las que se refieren a páginas con marcos, mapas del lado del servidor, marcos, etc.
También he eliminado los especialmente ambiguos, como por ejemplo la pauta 11.4 (inglés):
If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page.
[Si, después de haberlo intentado con verdadero empeño, no puede crear una página accesible, proporcione un vínculo a una página alternativa que use tecnologías del W3C, sea accesible, tenga información (o funcionalidad) equivalente y sea actualizada tan a menudo como la página (original) inaccesible.]
Como no estoy seguro de si se trata de que tengo que vincular a otro sitio —reconociendo mi incapacidad para hacer una página accesible—, o si acaso debo padecer de cierto tipo de esquizofrenia —para por un lado no poder hacer una
página accesible, y por otro desarrollar una alternativa que sí lo sea—, prefiero descartarla y pensar que si logro el mayor grado de accesibilidad posible ya la estaré cumpliendo.
Si alguien desea leer el documento completo, puede consultar el original de las Web Content Accessibility Guidelines 1.0 (inglés), o mi traducción de las mismas.
Dicho esto, las técnicas de accesibilidad generales son las siguientes:
- Estandarizar el código de las páginas, declarando la DTD de XHTML que se haya elegido. Hemos visto los motivos en «DTD y espacios de nombres».
- Emplear de los elementos de marcado XHTML según el significado estructural que les es propio, y no atendiendo a sus características de visualizado en los navegadores. Las pautas que indico abajo se refieren a las listas y a los elementos de cita, pero son extensibles a todo elemento.
- Se debe estructurar lógicamente el contenido, para permitir que un documento sea comprensible incluso con su hoja de estilo deshabilitada. Es decir, hay que crear el XHTML accesible y funcional, para después trabajar sobre su presentación por medio de CSS. Lo importante es, sobre todo, que no sólo se debe poder acceder al contenido, sino comprender la estructura. Si visualmente la jerarquía de una página y las relaciones entre distintos elementos son claras, pero el marcado subyacente no transmite esa misma jerarquía —por medio de encabezados, listas, párrafos, etc.—, no se está cumpliendo éste punto.
- Emplear en la redacción el lenguaje más claro posible, en virtud del perfil de usuario medio de la página.
- Aplicar los atributos
alt, title y longdesc en aquellos elementos que los necesiten. Es decir, hay que redactar alternativas textuales apropiadas para todo contenido no textual y que sea importante para la comprensión del documento. Sobre esto ver «Imágenes accesibles».
- Proporcionar alternativas textuales y auditivas para los contenidos multimedia. Actualmente esto significa subtitular los objetos audiovisuales, transcribir los contenidos exclusivamente sonoros, y ofrecer una audiodescripción de los contenidos que sean meramente visuales. Pienso que más adelante supondrá el marcado de las alternativas por medio de SMIL, cuando mejore el soporte de este lenguaje.
- Eliminar parpadeos y destellos de la pantalla o de elementos incluidos en el documento, así como contenidos móviles, salvo en el caso de que se proporcione algún mecanismo por el que el usuario pueda activarlos y desactivarlos. En el caso de un vídeo, por ejemplo, supone que sea el usuario el que decida cuándo debe reproducirse, y no servirlo de forma que lo haga automáticamente.
- Si el color de un elemento implica una información significativa, ésta debe transmitirse por algún otro medio aparte del color. Por ejemplo, no es suficiente que los vínculos sean de un color diferente, sino que se debe indicar su naturaleza con una fuente distinta, un estilo o una decoración diferente, o varios de estos métodos simultáneamente.
- Marcar la estructura de las tablas de datos por medio del conjunto de elementos definidores de su estructura:
thead, tbody y tfoot —si procede—, y th junto a tr y td —siempre—. Asimismo, para tablas complejas definir relaciones entre encabezados, filas y columnas por medio de los elementos colgroup y col, y los atributos headers y scope cuando y como sea preciso. Sobre este punto ver «Tablas accesibles».
- Proporcionar abreviaturas de los encabezados de tabla cuando sea necesario, es decir, emplear el atributo
abbr del elemento th. Sobre este punto ver «Tablas accesibles».
- Proporcionar resúmenes de las tablas de datos, bien a través del atributo
summary, bien a través del elemento caption.
- Empleo específico de los elementos
abbr y acronym en sus respectivos contextos, junto con la extensión de la abreviatura contenida en su atributo title, la primera vez que la abreviatura o el acrónimo aparezca en un documento. No obstante, sobre éste punto ver «Discusión bizantina: ¿abbr o acronym?».
- Empleo de los atributos
hreflang y xml:lang en los contextos que les son propios y cuando se dé un cambio en el idioma original del documento. Los códigos internacionales están recogidos en las ISO 639-1 e ISO 639-2.
- Proporcionar un vínculo para que los usuarios de un lector de pantalla puedan saltar los elementos redundantes de una página —cabecera y barra de navegación— y acceder directamente a su contenido.
- Proporcionar metadatos que añadan significado al documento, bien a través de los elementos
meta, bien a través de RDF (inglés).
- No abrir ventanas nuevas sin advertir al usuario previamente. Explicitar el comportamiento por medio de un texto que acompañe al vínculo, por medio de su
title, o por medio de un icono, en cuyo caso con su correspondiente texto alternativo. Puesto que en XHTML 1.1 el atributo target no es válido, para los casos lícitos en los que sea necesaria una nueva ventana se debe crear para el comportamiento un script no obstrusivo.
- Identificar claramente el destino de los vínculos incluidos en un documento. El fragmento delimitado por el elemento
a debe ser significativo por sí mismo y diferir de los demás. Si por algún motivo esto no es viable, se debe complementar su texto por medio de title.
- Organizar la navegación por medio de teclado de una forma lógica a través de vínculos, elementos de formulario y demás objetos de cada documento, por medio del marcado. Por los problemas que supone, es preferible no emplear el atributo
tabindex, además de que —como apunta Joe Dolson en Pseudo-Accessibility: Reinventing the Wheel (inglés)— por lo general cuando se emplea se está solucionando un síntoma (un orden de tabulacón que no es lógico…) pero no el problema (…que la estructura de la página no es lógica en su origen).
- Crear accesos de teclado para los vínculos principales de una página, por medio del atributo
accesskey, teniendo en cuenta que no deben entrar en conflicto con los atajos de teclado más comunes de tecnologías asistivas como por ejemplo los lectores de pantalla. En éste sentido, lo ideal es reducirlos al menor número posible, y destinarlos a la barra de navegación con las secciones principales o a los vínculos de ayuda.
- Emplear el atributo
for del elemento label para explicitar la relación de correspondencia entre cada elemento de formulario y su etiqueta identificativa. Sobre éste punto ver «Formularios accesibles».
- Incluir texto orientativo en los campos de formulario para facilitar la navegación a través de ellos. Esto incluye emplear el atributo
value de los elementos <input type="text" />, e incluir texto entre las etiquetas de apertura y cierre de textarea. Sin embargo, por los problemas que este texto puede suponer para los usuarios, mi recomendación es que ese texto sea un espacio en blanco que luego se elimine en el lado del servidor. Ver también «Formularios accesibles».
- No sustituir caracteres distintos de los del idioma principal de la página incrustando archivos GIF o JPEG, sino utilizar apropiadamente los elementos de marcado y las entidades de la codificación del estándar Unicode UTF-8 (inglés). Se hace extensible a cualquier elemento que tenga un lenguaje de marcado apropiado, en la medida en que los navegadores lo soporten de una manera consistente, como serán en el futuro MathML, SVG y otros.
- Proporcionar información en el propio documento de los contenidos y función de un objeto incrustado cuando éste no se encuentre disponible para el usuario. Ésto ya no se aplica a los applets, pero sí a los comportamientos de scripts o a objetos Flash si estos no se han hecho directamente accesibles.
- Dividir bloques extensos de información en unidades más manejables, siempre que sea posible. El ejemplo de la pauta se refiere a estructurar un formulario en bloques semánticos, pero su contenido es mucho más amplio. Tal como yo lo veo, se relaciona también con marcar secciones y subsecciones con encabezados apropiados, y a dividir un contenido en varios documentos si es demasiado extenso. Sobre esto último, es difícil indicar unos límites, pero si mi experiencia sirve de algo cuando me encuentro con que el contenido de un documento requiere encabezados de nivel cuatro, me pregunto siempre si acaso no necesitaré dividirlo en varios documentos.
Notas
- La capa de estructura incluye el marcado estructural —código XHTML— del documento, ajustado a los contenidos.
