Accesibilidad Web

José Luis Fuertes Castro y Loïc Martínez Normand

Universidad Politécnica de Madrid

La web, como un medio de comunicación más, también debe ser accesible para facilitar la integración de las personas con discapacidad en la Sociedad de la Información. Para ello es necesario que tanto los contenidos como las herramientas de autor y los navegadores proporcionen soporte para la accesibilidad. En este artículo se introduce el problema de la accesibilidad web y se describen las pautas de accesibilidad de contenidos web elaboradas por el Consorcio de la Web. Posteriormente se afronta la necesidad de realizar evaluaciones del grado de accesibilidad de los sitios web, evaluaciones que no pueden automatizarse en su totalidad. A modo de ejemplo se muestra la utilización de la herramienta HERA, que permite una evaluación semi-automática de la accesibilidad web. Finalmente el artículo rebate los mitos más habituales que circulan alrededor de la accesibilidad web.

palabras clave: personas con discapacidad, diseño para todos, accesibilidad, web.

The World Wide Web has become a new mass media and because of that it also has to be accessible to guarantee that the Information Society is inclusive and does not discriminate people with disabilities. To that end, accessibility support is needed in three levels: web content, authoring tools and user agents or browsers. This article first introduces the problem of web accessibility and then focuses on the web content accessibility guidelines of the World Wide Web Consortium. Later on, the article discuss the need of the evaluation of the accessibility level of web sites, evaluation that cannot be fully automated. An example of a semi-automatic tool for web accessibility evaluation, called HERA, is presented. Finally, as concluding remarks, some myths related to web accessibility are discussed and rebated.

keywords: people with disabilities, design for all, accessibility, web.

1. introducción

La web, como elemento más visible de Internet, puede considerarse como un medio de comunicación más que, de hecho, está cobrando cada vez mayor importancia. Tanto es así, que es uno de los pilares fundamentales de la llamada Sociedad de la Información. En este sentido es esencial que la web facilite la integración de todas las personas en esta nueva sociedad, evitando discriminar por razones de edad, conocimientos, idioma, formación, tecnología, cultura, religión, género y, por supuesto, discapacidad.

Así, puede definirse la accesibilidad de la web como el arte de garantizar que, tan amplia y extensamente como sea posible, la web esté disponible para las personas, tengan o no deficiencias de un tipo u otro (Berners-Lee, 2000).

Para lograr una web accesible para todos deben tenerse en cuenta tres grandes componentes. En primer lugar están los contenidos disponibles en la web, desarrollados por los diseñadores web. En segundo lugar están las aplicaciones informáticas que los usuarios utilizan para acceder a los contenidos web, llamados agentes de usuario o, más comúnmente, navegadores. En tercer y último lugar se encuentran los programas informáticos que permiten crear y gestionar los contenidos web, llamados herramientas de autor. Los tres componentes deben favorecer la accesibilidad. Así, debe cumplirse lo siguiente:

• Los contenidos deben ser accesibles. Para lo cual los diseñadores web deberán tener en cuenta criterios de accesibilidad durante su trabajo.

• Los navegadores deben ofrecer una interfaz accesible y, al mismo tiempo, tratar adecuadamente los contenidos accesibles. De esta forma se garantiza que todas las personas puedan acceder a los contenidos.

• Las herramientas de autor deben ofrecer una interfaz de usuario accesible y, simultáneamente, deben facilitar la creación de contenidos web accesibles. Por un lado el objetivo es facilitar la labor del diseño web accesible, pero por otro lado se trata de fomentar la participación de las personas con discapacidad como proveedores de contenidos y no como meros consumidores.

Este artículo se centrará en el primer componente: los contenidos web, por ser el componente de la accesibilidad más relevante en el diseño web. Cuando se construye un sitio web accesible existen distintos aspectos que deben considerarse. Estos aspectos vienen detallados en el documento Web Content Accessibility Guidelines (Chisholm et al., 1999), abreviado como WCAG y que ha sido definido por la Iniciativa de Accesibilidad Web (WAI, 2006) dentro del Consorcio de la Web (W3C, 2006).

Cabe destacar que, en los últimos años, el problema de la accesibilidad a la web ha tomado relevancia en todo el mundo (Cumbre Bilbao, 2005) (World Summit Tunisia, 2005). En la Unión Europea, por ejemplo, la mayoría de los estados miembro han creado una legislación para asegurar la accesibilidad de los sitios web de la administración pública. Por ejemplo, en España, la Ley de los Servicios de la Sociedad de la Información y del Comercio Electrónico (BOE, 2002) establece que las páginas de la administración pública deberían ser accesibles desde el 1 de enero de 2006. En cuanto al sector privado, en la Ley de Igualdad de Oportunidades, No Discriminación y Accesibilidad Universal de las Personas con Discapacidad (BOE, 2003) se plantean las bases para exigir su accesibilidad en los próximos años.

Un aspecto muy importante del diseño web accesible es la evaluación de la accesibilidad de un sitio web, que es una tarea compleja que requiere del conocimiento experto humano. La persona que lleva a cabo esta tarea necesita un conocimiento profundo y experiencia en diversas áreas técnicas relacionadas con el desarrollo web, y además debe estar acostumbrado al uso de las técnicas requeridas para evaluar el cumplimiento de cada uno de los puntos de control de la accesibilidad.

Hay dos formas de abordar la evaluación de la web: realizar una evaluación automática, que es rápida y exhaustiva pero no puede ser nunca completa (hay aspectos que no pueden evaluarse de manera automática), o bien realizar una evaluación manual, que es completa pero mucho más costosa en recursos.

Así pues, este artículo pretende ser una introducción al diseño web accesible y a la evaluación de la accesibilidad web. Para ello está organizado como sigue: en el apartado 2 se profundiza en el problema de la accesibilidad a la web; el apartado 3 presenta las 14 pautas de alto nivel que han de cumplirse para lograr un sitio web accesible, con ejemplos explicativos; el apartado 4 se centra en cómo puede revisarse la accesibilidad de la web, comentando detenidamente el funcionamiento de una herramienta para la revisión semi-automática; finalmente, el apartado 5 muestra algunas breves conclusiones finales.

2. necesidad de una web accesible

En los últimos años la web ha pasado a ser la mayor fuente de información gratuita disponible para todo el mundo y un medio destacado de participación en la sociedad. Se ha convertido en un recurso fundamental para distintas áreas, como por ejemplo:

• Búsqueda de empleo e interacción en el trabajo.

• Formación en el aula y a distancia.

• Noticias, información, comercio, ocio…

• Participación civil y servicios gubernamentales.

Tal cantidad de información y posibilidades disponible libremente han desplazado a las fuentes tradicionales de obtención de información. Algunas de estas fuentes tradicionales como las bibliotecas, material impreso, escuelas, etc. eran accesibles para personas con discapacidad, pero la mayoría no lo eran.

Con la llegada de la web se abre una posibilidad de acceso a la información sin precedentes para las personas con discapacidad, pues todas ellas, desde su casa, puesto de trabajo o lugar de estudio, podrían acceder a multitud de contenidos. Pero para que esto pueda ser una realidad, los sitios web tienen que haber sido diseñados teniendo en cuenta el modo de acceso al ordenador de este colectivo.

El considerado padre de la web, Tim Berners-Lee, dijo: El poder de la web está en su universalidad. Que todo el mundo pueda acceder, a pesar de la discapacidad, es un aspecto esencial. Esta cita está recogida en la página principal de WAI (WAI, 2006). El principal problema es que una gran mayoría de los sitios web no son accesibles a personas con discapacidad, teniendo graves problemas de accesibilidad. Los encargados de implantar la accesibilidad en la web son los diseñadores web, que muchas veces no tienen en cuenta ni los más mínimos requisitos de accesibilidad y sus responsables y clientes tampoco son conscientes del poco esfuerzo adicional que costaría hacer «bien» la web. En muchos casos, ni siquiera consideran que todas las personas somos diferentes y que cada una tiene unas necesidades distintas y que existe gran diversidad funcional. Puede afirmarse que no existe una conciencia colectiva para hacer cumplir los criterios de accesibilidad web, además de existir bastante desconocimiento general sobre lo que significa «accesibilidad web». No obstante, en los últimos años las administraciones públicas españolas están realizando grandes esfuerzos para conseguir sitios web accesibles a todos los ciudadanos, aunque todavía les queda un largo camino por recorrer.

3. pautas de accesibilidad al contenido web

La referencia comúnmente aceptada a nivel mundial cuando se habla de accesibilidad web es la proporcionada por el Consorcio de la Web (W3C, 2006) —abreviado como W3C, del inglés World Wide Web Consortium— a través de la Iniciativa para la Accesibilidad a la Web (WAI, 2006), abreviada como WAI, del inglés Web Accessibility Initiative). WAI ha desarrollado diversas guías y documentos para impulsar la creación de sitios web accesibles, tanto para los contenidos, como para las herramientas de autor y los agentes de usuario. Entre todos ellos, destacan las Pautas para la Accesibilidad al Contenido Web (Chisholm et al., 1999), abreviadas como WCAG, del inglés Web Content Accessibility Guidelines. La versión vigente de las WCAG es la 1.0, aunque a la hora de escribir estas líneas se está trabajando en una renovada versión 2.0 (Caldwell et al., 2006). WCAG 1.0 constituye la guía de referencia que incluye las características que debe cumplir una web para que sea accesible para todos. Además, ha servido como base para definir la norma técnica española de aenor une 139803:2004 (aenor, 2004).

WCAG 1.0 se encuentra organizado en 14 pautas de alto nivel y cada una de ellas, a su vez, se descompone en diversos puntos de control. En total, existen 65 puntos de control. Cada uno de estos puntos tiene asignado un nivel de prioridad o relevancia:

• Prioridad 1: El punto debe satisfacerse (must satisfy). En caso contrario, es imposible acceder a la web por algunos grupos de usuarios

• Prioridad 2: El punto debería cumplirse (should satisfy). En caso contrario, para algunos grupos de usuarios será muy difícil acceder

• Prioridad 3: El punto puede cumplirse (may address). En caso contrario, puede dificultar el acceso a ciertos usuarios, aunque no impedirá el acceso

El W3C ha definido tres niveles o grados de conformidad de los sitios web respecto a las WCAG. Según una página web cumpla todos los puntos de una misma prioridad, se le podrá asignar un grado de conformidad u otro. Así, cuando una web cumple con todos los puntos de control de prioridad 1 se dice que tiene un grado de cumplimiento «A» (simple-A). Cuando una web cumple con todos los puntos de control de prioridad 1 y todos los de prioridad 2 se dice que tiene un grado de cumplimiento «AA» (doble-A). Cuando una web cumple con los 65 puntos de control de WCAG se dice que tiene un grado de cumplimiento «AAA» (triple-A). Cada uno de estos grados de cumplimiento lleva asociado un icono de conformidad, definido por el W3C y que cada sitio web puede colocar en cuanto se cumplan los requisitos de accesibilidad pertinentes, con el fin de autodeclarar su grado de accesibilidad. Estos iconos se muestran en la Figura 1. Está comúnmente aceptado que para que un sitio web se considere adecuadamente accesible se debe alcanzar el grado de doble-A.

Las 14 pautas están dirigidas por dos grandes principios. El primero es el de «transformación elegante», que indica que las páginas web deben diseñarse para que se adapten de forma adecuada a las distintas posibilidades de navegación que pueden presentarse: tipos de dispositivos, tipos de navegadores, características de visualización, etc. Este primer principio agrupa a la mayoría de las pautas, desde la 1 a la 11. El segundo principio es que los contenidos deben ser fáciles de comprender y de navegar.

Figura 1. Iconos de los grados de cumplimiento de WCAG 1.0

En los siguientes apartados se van a resumir brevemente las 14 pautas del WCAG 1.0, indicando a modo de ejemplo alguno de los puntos de control pertenecientes a cada pauta. La Figura 2 presenta un resumen de los puntos de control correspondiente a cada una de las 14 pautas clasificados por niveles de prioridad.

Figura 2. Puntos de control por pauta, agrupados por prioridades

3.1 Pauta 1

El enunciado de la primera pauta es: «proporcione alternativas equivalentes para el contenido visual y sonoro». Esta pauta contiene un total de cuatro puntos de control de prioridad 1 y un punto de prioridad 3.

La idea que engloba esta primera pauta consiste en que el diseñador web debe proporcionar un contenido que, cuando sea presentado al usuario, cumpla esencialmente la misma función o propósito que el contenido visual o sonoro.

Un primer ejemplo es el punto 1.1: «debe proporcionarse un texto equivalente para todo elemento no textual». Por elemento textual se entiende cualquier imagen, representación gráfica del texto (incluyendo símbolos), áreas de mapas de imagen, animación, applet y objeto programado, ASCII art, marco, script, imagen usada como viñeta en las listas, espaciador, botón gráfico, sonido, archivo exclusivamente auditivo, pista sonora del vídeo y vídeo. Es importante destacar que el texto equivalente debe desempeñar la misma función, hasta el punto que sea posible, que el elemento no textual, es decir, transmitir la misma información.

Desde el punto de vista de medios audiovisuales, la pauta 1 considera que los subtítulos son textos alternativos para la pista sonora de contenidos multimedia e indica en el punto 1.4 que deben estar sincronizados con dicho contenido. Adicionalmente se incluye la recomendación de incluir audiodescripción en vídeos (punto 1.3).

Los tres puntos comentados son de prioridad 1 y son, por lo tanto, de una alta importancia para lograr sitios web accesibles.

3.2 Pauta 2

El enunciado de la segunda pauta es: «no confíe sólo en el color». Esta pauta contiene un punto de control de prioridad 1 y un punto de prioridad 2.

El sentido de esta segunda pauta es que el diseñador web debe asegurarse de que los textos y gráficos son comprensibles cuando se vean sin color.

Por un lado, el color no debe ser la única manera de representar información (punto 2.1) y, por otro, las combinaciones de colores deben ofrecer un contraste adecuado (punto 2.2). Así los contenidos serán adecuados para personas con deficiencias en la percepción de color o usuarios de pantallas monocromas.

3.3 Pauta 3

El enunciado de la tercera pauta es: «utilice marcadores y hojas de estilo, y hágalo apropiadamente». Esta pauta está formada por siete puntos de control de prioridad 2.

La idea principal de esta pauta es que el diseñador web tiene que marcar los documentos creados con los elementos estructurales apropiados. Además, debe controlar la presentación con hojas de estilo (Bos, 2006) en vez de con atributos y elementos de presentación, que están desaconsejados en HTML.

Ejemplo (punto 3.3): «deben utilizarse hojas de estilo para controlar la disposición y la presentación de la página web». La presentación se refiere a cualquier aspecto que influye en la forma en que se presenta un elemento, es decir, está formado por el conjunto de atributos que definen el formato, como los tipos de letra, colores, tamaños, etc. En resumen, una página web debe estar compuesta por el contenido y su estructura (especificado mediante los lenguajes HTML/XHTML) más la presentación o apariencia (especificada mediante el lenguaje CSS, abreviatura del inglés Cascading Style Sheets).

3.4 Pauta 4

El enunciado de la cuarta pauta es: «aclare el idioma usado». Esta pauta tiene un punto de control de prioridad 1 y dos de prioridad 3.

La idea básica de la pauta consiste en que el diseñador web tiene que utilizar el marcado para facilitar la pronunciación o interpretación del texto abreviado o en idioma extranjero y, además, escribir de forma correcta conforme a la ortografía y gramática del idioma correspondiente.

Ejemplo (punto 4.1): «deben identificarse claramente los cambios en el lenguaje natural del texto de un documento y de cualquier texto equivalente». Esto incluye también el texto equivalente de elementos multimedia, como por ejemplo leyendas y subtítulos. El objetivo es que cuando se acceda a la página con un navegador por voz, la síntesis pueda pronunciar adecuadamente cada texto en el idioma correcto.

3.5 Pauta 5

El enunciado de la quinta pauta es: «cree tablas que se transformen de forma elegante». Esta pauta posee un total de seis puntos de control, siendo dos de cada una de las prioridades.

La noción de la presente pauta estriba en que el diseñador web debe asegurarse de que las tablas tienen el marcado necesario para ser transformadas por navegadores accesibles y otras aplicaciones de usuario.

Ejemplo (punto 5.3): no deben utilizarse tablas para maquetar, a menos que el contenido de la tabla tenga sentido cuando se represente en forma lineal. De lo contrario, si la tabla no se entiende, ha de proporcionar un equivalente alternativo (que puede ser una versión lineal del contenido de la tabla). Existen técnicas para representar la información de forma tabular sin utilizar tablas, principalmente las hojas de estilo. Las tablas tienen que utilizarse únicamente para mostrar datos tabulares, no para obtener un efecto de formato específico. Si se usan tablas para maquetar se tiene una página menos accesible, más difícil de mantener (es muy complicado cambiar el diseño), de mayor tamaño (y por tanto con mayores tiempos de descarga) y que requiere más recursos para ser visualizada en un navegador (por el tiempo de proceso de las tablas respecto a las hojas de estilo).

3.6 Pauta 6

El enunciado de la sexta pauta es: «asegúrese de que las páginas que incluyen nuevas tecnologías se transforman elegantemente». Esta pauta engloba a tres puntos de control de prioridad 1 y dos de prioridad 2.

La intención de la pauta consiste en que el diseñador web ha de asegurarse de que las páginas son accesibles incluso cuando las tecnologías más recientes no son soportadas o se deshabilitan.

Ejemplo (punto 6.3): «las páginas deben poder seguir siendo usadas cuando los scripts, applets u otros objetos de programación se desconectan o no son soportados». Si esto no es posible, debe proporcionarse información equivalente en una página alternativa accesible. El problema estriba en que hay usuarios que navegan utilizando navegadores que no soportan estas tecnologías o que las tienen desactivadas, por lo que cualquier contenido que se muestre utilizando exclusivamente este medio no llegará jamás a este tipo de usuarios.

3.7 Pauta 7

El enunciado de la séptima pauta es: «garantice al usuario el control sobre los cambios del contenido temporizado». Esta pauta tiene un punto de control de prioridad 1 y cuatro de prioridad 2.

El propósito de la pauta consiste en que el diseñador web ha de asegurarse de que puedan ser pausados o detenidos los contenidos o páginas que se muevan, parpadeen, se desplacen o se actualicen automáticamente.

Ejemplo (punto 7.4): «no deben crearse páginas que periódicamente se autorefresquen». El autor de una página no puede predecir cuánto tiempo necesitará el usuario para leerla y el refresco prematuro puede desorientarlo. Esto además puede presentar problemas con algunos revisores de pantalla. Si es necesario actualizar la página, se debe permitir al usuario elegir cuándo desea obtener la siguiente información poniendo un enlace a tal efecto. Por ejemplo «refresque esta página». Otra opción es incluir un enlace a una versión que no se refresca automáticamente o una opción que permita «detener el refresco».

3.8 Pauta 8

El enunciado de la octava pauta es: «garantice la accesibilidad directa de las interfaces de usuario incrustadas». Esta pauta dispone únicamente de un punto de control que es de prioridad 1.

La idea de esta pauta es que el diseñador web debe asegurarse de que las interfaces de usuario siguen los principios del diseño accesible: acceso a la funcionalidad independiente del tipo de dispositivo, operabilidad a través del teclado, interfaz por voz, etc.

El único punto de esta pauta (punto 8.1) dice: «los elementos de programación tales como scripts y applets deben crearse de manera que sean directamente accesibles o compatibles con las ayudas técnicas».

3.9 Pauta 9

El enunciado de la novena pauta es: «diseñe para la independencia del tipo de dispositivo». Esta pauta engloba cinco puntos de control, uno de prioridad 1, dos de prioridad 2 y dos de prioridad 3.

Esta pauta se basa en que el diseñador web debe utilizar características que permitan la activación de los elementos de la página a través de diversos dispositivos de entrada. Lo fundamental es tener en cuenta que hay usuarios que pueden usar únicamente un teclado y que hay que ser compatibles con esa circunstancia.

Ejemplo (punto 9.2): «cualquier elemento que tenga su propia interfaz debe poderse manejar de forma independiente del tipo de dispositivo». Los controles de cualquier interfaz de usuario incrustada o simplemente relacionada con el contenido de un sitio web deben poder activarse tanto con el ratón como con el teclado o con cualquier equivalente lógico o físico. Los objetos de programación, vídeos, etc. deben contar con controles que puedan activarse tanto con el ratón como con el teclado.

3.10 Pauta 10

El enunciado de la décima pauta es: «utilice soluciones provisionales». Esta pauta incluye dos puntos de control de prioridad 2 y tres de prioridad 3.

En esta pauta se recomienda que se usen soluciones de accesibilidad provisionales, de manera que las ayudas técnicas y los navegadores antiguos puedan funcionar correctamente.

Ejemplo (punto 10.1): hasta que las aplicaciones de usuario permitan a los usuarios desactivar la generación de ventanas, no debe provocarse que aparezcan llamadas emergentes u otras ventanas y que no cambie el foco de la ventana actual sin informar antes al usuario. La apertura de una nueva ventana provoca un cambio del foco de la ventana actual a otra ventana, lo que puede confundir al usuario que se apoya en un lector de pantalla o navegador con conversor texto-voz, e incluso a los usuarios con menos experiencia en la navegación, aunque no usen ayudas técnicas. El control por parte del usuario puede suponer avisar al usuario para que confirme o cancele la generación de la ventana, controlar su tamaño o posición y cerrar la ventana. Por otro lado, en la actualidad muchos agentes de usuario pueden configurarse fácilmente para evitar que aparezcan ventanas emergentes o que los enlaces aparezcan como ventanas nuevas, por lo que cualquier esfuerzo del diseñador para lograr estos efectos se pierde antes estas configuraciones de usuario.

3.11 Pauta 11

El enunciado de la undécima pauta es: «utilice las tecnologías y pautas del Consorcio de la Web». Esta pauta incluye un punto de control de prioridad 1, dos de prioridad 2 y uno de prioridad 3.

Esta pauta insiste en que deben emplearse las tecnologías del W3C (de acuerdo con la especificación) para fomentar la interoperabilidad y seguir las pautas de accesibilidad. Cuando no sea posible utilizar una tecnología del W3C, o hacerlo da como resultado un material que no se transforma adecuadamente, se debe proporcionar una versión alternativa del contenido que sea accesible.

Ejemplo (punto 11.2): «no deben utilizarse elementos obsoletos de las tecnologías del W3C». En la versión 4.01 de HTML se consideran obsoletos los elementos: «listing», «plaintext» y «xmp» y los atributos: ‘colors’, ‘alignment’, ‘font’, ‘graphics’, etc. En la versión 4.01 de HTML se consideran desaconsejados los elementos: «applet», «basefont», «center», «dir», «font», «isindex», «menu», «s», «strike» y «u».

3.12 Pauta 12

Ésta es la primera pauta derivada del principio de facilitar la navegación y la comprensión. El enunciado de la duodécima pauta es: «proporcione información de contexto y orientación». Esta pauta tiene un punto de control de prioridad 1 y tres de prioridad 2.

La idea que subyace de esta pauta es que esta información adicional sirve para ayudar a los usuarios a entender los elementos o páginas complejas.

Ejemplo (punto 12.3): «hay que dividir los bloques de información largos en grupos más manejables cuando resulte natural y apropiado». Deben evitarse los párrafos especialmente largos. Los formularios deben tener agrupados sus elementos para mejorar la legibilidad y facilitar su rellenado. Se puede organizar la información de gran longitud estructurándola en secciones con su correspondiente encabezado («h1», «h2»... en HTML), utilizando el marcado de listas, agrupando los controles de formulario mediante «fieldset» y describiendo el grupo con «legend», utilizando tablas para datos tabulares y describiendo la tabla con «caption», etc.

3.13 Pauta 13

El enunciado de la decimotercera pauta es: «proporcione mecanismos de navegación claros». Esta pauta tiene diez puntos de control, cuatro de ellos de prioridad 2 y el resto de prioridad 3.

La idea principal de esta pauta es que el sitio web debe proporcionar mecanismos de navegación claros y consistentes —información de orientación, barras de navegación, mapa del sitio, etc.— para incrementar la probabilidad de que una persona encuentre lo que está buscando en el sitio.

Ejemplo (punto 13.1): «debe identificarse claramente el objetivo de cada enlace». El propio texto del enlace debe ser significativo y se debe poder comprender cuando se lee fuera de contexto. No se deben usar textos como enlaces cuyo único contenido es «pincha aquí», «ver más», etc. Puede asignarse un título al enlace para ofrecer información adicional sobre el objetivo del enlace.

3.14 Pauta 14

El enunciado de la decimocuarta pauta es: «asegúrese de que los documentos sean claros y sencillos». Esta pauta tiene un punto de control de prioridad 1 y dos de prioridad 3.

La idea de la última pauta es que el diseñador de contenidos web debe asegurarse de que los documentos sean claros y sencillos de manera que puedan ser más fácilmente comprendidos.

Ejemplo (punto 14.1): «debe emplearse el lenguaje más claro y sencillo que sea apropiado para el contenido de un sitio». Esta pauta no atañe únicamente al lenguaje escrito, sino que es extensible a los mensajes de voz reproducidos en la página web, que pudieran incluirse mediante clips de video, archivos de sonido, objetos flash, etc. La claridad y la sencillez del lenguaje cobran especial importancia en el caso de la Administración pública, cuya misión es informar a todas las personas, independientemente de su condición socio-cultural, o de las capacidades y discapacidades que tengan. Verificar la legibilidad y la facilidad de comprensión del lenguaje de un sitio es una tarea compleja, por lo que conviene que dicha tarea sea llevada a cabo por un experto.

4. revisión de la accesibilidad a la web

4.1 Necesidad de una revisión manual con soporte de herramientas

La evaluación de la accesibilidad de un sitio web es un aspecto de suma importancia, que no puede ser completamente automatizado, pues muchos de los puntos de control requieren del juicio humano para obtener un resultado. Por tanto, la revisión de la accesibilidad web constituye una tarea compleja que precisa de la experiencia humana y de la ayuda de herramientas (Abou-Zahra et al., 2006ª, Slatin et al., 2003). La persona encargada de esta tarea necesita un conocimiento profundo y experiencia en el desarrollo web y debe estar habituado al uso de las técnicas necesarias para evaluar la conformidad con cada uno de los puntos de control.

Evidentemente, el uso de una herramienta puede ayudar a finalizar esta tarea. Esta herramienta debe proporcionar rápido acceso al texto de los puntos de control y las pautas, puesto que incluso a los expertos les resulta difícil recordar las 14 pautas y los 65 puntos de control. Además, la herramienta debería proporcionar información sobre todos los elementos que han de ser evaluados en cada punto de control. También debería proporcionar formas de facilitar la detección visual de problemas en una página web o en el código fuente, resaltando de manera automática los elementos de la página. Por otro lado, la herramienta debe proporcionar a los usuarios la posibilidad de almacenar los resultados de evaluación. Y finalmente, la herramienta debe automatizar el máximo trabajo posible, detectando los puntos que no son aplicables a una determinada página, los correctos o los incorrectos.

Para evaluar la accesibilidad web con una herramienta se pueden utilizar dos enfoques: herramientas que realizan una revisión automática y herramientas que sirven para realizar una revisión manual.

Hay muchas herramientas automáticas para analizar una página web y proporcionar un índice de su nivel de accesibilidad (Abou-Zahra et al., 2006b). Entre todas, las tres herramientas gratuitas más relevantes son: Cynthia Says (ICDRI, 2006), TAW (CTIC, 2006) y WebXACT (Watchfire, 2006), de Watchfire.

Prácticamente no existen en el mercado herramientas gratuitas en línea que permitan realizar una revisión manual de la accesibilidad de una página web. HERA 1 (Sidar, 2003), desarrollada por la Fundación Sidar (Sidar, 2006), surgió como una herramienta para la revisión manual de la accesibilidad de una página web. Está disponible en varios idiomas.

Cada una de estas aproximaciones tiene sus ventajas y sus desventajas. Así pueden resumirse las ventajas de una revisión automática en los siguientes aspectos: las herramientas tienen un funcionamiento rápido y sistemático, se revisan muchos aspectos simultáneamente y ofrecen una calificación global de la accesibilidad de la página. En cambio, entre sus inconvenientes pueden citarse: la interpretación de resultados suele ser compleja (principalmente para novatos) y muchos aspectos precisan revisión manual complementaria.

En lo que respecta a las herramientas de revisión manual, entre sus aspectos positivos se encuentran: se comprenden mejor los problemas (son más intuitivas), se puede comparar la validez de distintas soluciones, es el único medio posible para algunos aspectos (por ejemplo, adecuación del texto alternativo y los títulos de los marcos), es adecuada para detectar inmediatamente los fallos principales de accesibilidad. Entre los aspectos negativos, destacan: son mucho más costosas en el tiempo necesario para evaluar una página web, requieren de otras herramientas o probar configuraciones distintas, exigen el juicio personal del revisor, el usuario tiene que conocer mejor los problemas, algunas cosas son difíciles de simular y pueden dejar sin detectar algunos fallos de accesibilidad.

Las herramientas puramente automáticas informan claramente al usuario de las limitaciones de la revisión automática e insisten en la existencia de problemas que tienen que ser verificados manualmente por un evaluador humano, pero normalmente no ofrecen ayuda para esta verificación manual.

Por tanto, la herramienta ideal debería tener tanto las ventajas de las herramientas automáticas como las de las manuales. Con este fin, surgió HERA 2 (Sidar, 2005). En el resto del apartado, se va a comentar su funcionamiento con el fin de que el lector pueda comprender mejor cómo son las herramientas que ayudan a evaluar la accesibilidad de sitios web.

4.2 HERA 1.0 y HERA 2.0

La versión 1.0 de HERA (Benavídez et al., 2004) fue publicada para el libre acceso gratuito de todo el mundo en 2003 con gran éxito. Era una herramienta en línea que proporcionaba ayuda para la evolución manual de la accesibilidad de las páginas web. Fue la primera herramienta en línea de este tipo que se publicó. La herramienta proporcionaba ayuda sobre el significado de cada uno de los puntos de control, instrucciones para la evaluación manual de cada punto, una vista modificada de la página utilizando CSS, una vista del código fuente, un sistema para apuntar los resultados de la evaluación de cada punto y, finalmente, una utilidad de generación de informes (Figura 3).

Esta primera versión de HERA usaba un conjunto de hojas de estilo escritas en CSS para identificar y resaltar ciertos elementos de la página, permitiendo al evaluador examinarlos y ver sus propiedades directamente utilizando esa vista especializada de la página, sin necesidad de inspeccionar el código fuente.

Sin embargo, la Fundación Sidar detectó una dificultad en el uso de HERA: la mayoría de los navegadores web no soportaban algunas de las características avanzadas de CSS 2 (Bos, 2006) utilizadas por HERA (como la generación de contenidos). De hecho, solamente el navegador Opera (Opera, 2006) interpretaba adecuadamente todas las hojas de estilo proporcionadas por HERA.

Además, existía también un segundo problema de eficiencia. La revisión manual con HERA de una página web llevaba una considerable cantidad de tiempo. Hay que tener en cuenta que el evaluador tenía que comprobar manualmente cada uno de los 65 puntos de control de WCAG 1.0.

Figura 3. Esquema de la arquitectura de HERA 1.0

Para solucionar estos problemas e incluir nuevos requisitos, la Fundación Sidar emprendió el rediseño e implementación, de tal manera que la versión 2 de HERA está disponible al público desde 2005. Tal como se muestra en la Figura 4, hay tres cambios importantes en esta nueva versión: un análisis automático preliminar (que proporciona un resumen de resultados para facilitar la navegación), la generación de vistas de páginas modificadas, que no dependen de características específicas de algunos navegadores y, finalmente, una mejora significativa en el módulo de generación de informes.

4.3 Funcionamiento de HERA 2

Seguidamente, se comentará brevemente la funcionalidad de cada uno de los módulos de HERA 2 (Benavídez et al., 2006), haciendo especial hincapié en los nuevos módulos.

Figura 4. Esquema de la arquitectura de HERA 2.0

Figura 5. Formulario inicial

4.3.1 Formulario Inicial

Este módulo se encarga simplemente de recoger la dirección de la página web que se desea analizar. La Figura 5 muestra una captura de su interfaz.

4.3.2 Análisis Automático Preliminar

Éste es uno de los módulos introducidos en la segunda versión de HERA. Este proceso inspecciona la página web y automáticamente asigna un valor a cada uno de los 65 puntos de control:

• Bien: la página web cumple el punto. Este resultado solo puede alcanzarse para un pequeño subconjunto de los puntos de WCAG. Por ejemplo, si la página web se ajusta a las gramáticas formales del lenguaje de marcas utilizado (HTML, XHTML, CSS…).

• Mal: la página web incumple el punto. Este resultado puede alcanzarse para un gran conjunto de puntos de WCAG. Por ejemplo, cuando un elemento de imagen carece del atributo «alt».

• No aplicable: el punto no es aplicable a la página web. Por ejemplo, si el punto hace referencia a los marcos y la página web no los utiliza; en este caso, no es necesario seguir analizando el punto.

• A verificar: HERA no pude tomar una decisión y el usuario tiene que evaluar manualmente el punto.

La Tabla 1 muestra un resumen de los puntos de control que HERA 2 puede evaluar automáticamente. Hay puntos (o partes de ellos) que pueden ser comprobados automáticamente, algunos que deben ser comprobados manualmente y otros en los que, aunque HERA realiza ciertas comprobaciones automáticas, los usuarios son los que deben tomar la decisión final basándose en su conocimiento y las páginas generadas por HERA. Esto significa que no siempre es posible llevar a cabo una evaluación automática completa para algunos puntos y el evaluador humano debe finalizar la revisión de dichos puntos de manera manual. Algunos puntos aparecen en más de una columna de la Tabla 1. Por ejemplo, el punto 1.1 (alternativas textuales) puede ser evaluado automáticamente como «Mal» si hay imágenes sin el atributo «alt»; como «no aplicable» si en la página no existen elementos no textuales (imágenes, objetos…); y como «a verificar» si hay imágenes con el atributo «alt» que requieren que la evaluación humana indique si el texto alternativo es adecuado para las imágenes. Por otro lado, en este punto jamás podrá ser evaluado automáticamente como «bien», puesto que el ordenador es incapaz de juzgar la adecuación de los textos alternativos.

4.3.1 Evaluación Manual

Tabla 1. Resumen de los puntos de control analizados automáticamente por HERA

Aunque HERA realiza una evaluación inicial y decide si algunos de los puntos se cumplen, se incumplen o no son aplicables, la responsabilidad final recae en el evaluador humano, que deberá verificar que todas las decisiones sean correctas.

Una vez finalizado el análisis preliminar, el usuario debe iniciar la evaluación manual de la página web, utilizando distintas estrategias de navegación (por prioridades, por puntos, por pautas…), para lo que dispondrá de una colección de utilidades proporcionada por HERA y que se explican a continuación.

4.3.2 Resumen de Resultados

El análisis preliminar proporciona un resumen de los resultados alcanzados, incluyendo algunas estadísticas del análisis (Figura 6) y, lo que es más importante, una tabla con el resumen de los resultados de la evaluación de los puntos de control (Figura 7). Esta tabla muestra, por cada nivel de prioridad, el número de puntos que requieren revisión manual, que cumplen el punto, que lo incumplen o que no son aplicables. Esta tabla puede usarse como el principal medio de navegación durante la revisión manual. Así mismo, conforme la revisión manual avanza, la tabla se va actualizando con las decisiones tomadas por el evaluador humano. En los ejemplos de estas figuras y siguientes se ha ocultado la identidad del sitio evaluado.

Figura 6. Estadísticas de una revisión

Figura 7. Resumen de los resultados de una revisión automática preliminar

4.3.3 Ayuda de los Puntos de control

HERA proporciona ayuda acerca del significado de cada uno de los puntos de control de WCAG, indicando el texto completo del punto de control que se está evaluando así como información adicional del punto de control (Figura 8).

Figura 8. Ayuda proporcionada acerca de uno de los puntos

4.3.4 Instrucciones para la Evaluación

HERA indica también información adicional sobre el objetivo de cada punto de control, proporcionando técnicas para la evaluación del punto de control, así como técnicas para una correcta implementación de dicho punto de control (Figura 9).

4.3.5 Vista Modificada de la Página

HERA 2 genera una versión nueva de la página analizada que contiene nuevos elementos que proporcionan la información necesaria por el avaluador. Para implementar esta funcionalidad de una manera independiente del navegador, se emplean tecnologías de servidor programadas con PHP.

La nueva vista modificada de la página generada por HERA se usa para resaltar con cajas, colores e iconos los elementos que tienen que ser estudiados, minimizando la necesidad de examinar el código fuente de la página web. La Figura 10 muestra un ejemplo de una página modificada en este sentido para resaltar las imágenes (se ve que la primera imagen carece de texto alternativo, mientras que en el resto habrá que comprobar si el texto alternativo es el adecuado).

Figura 9. Instrucciones para realizar la evaluación

Figura 10. Vista modificada de una página

4.3.6 Vista del Código

Cuando la vista modificada de la página no resulta suficiente para tomar una decisión acertada, HERA también puede mostrar el código fuente de la página, resaltando los elementos que deben ser estudiados con la misma combinación de colores e iconos a la empleada en la vista modificada de la página. Esta utilidad facilita la localización rápida de las partes del código fuente que requieren una inspección o modificación adicional. La Figura 11 muestra la vista de código para el ejemplo de la Figura 10 (de nuevo, se ve que la primera imagen carece de texto alternativo, mientras que en el resto habrá que comprobar si el texto alternativo es el adecuado).

Figura 11. Vista del código resaltado de una página

4.3.7 Resultados de la Evaluación

HERA permite almacenar los resultados de la evaluación para una posterior consulta. Para ello utiliza una serie de formularios (Figura 12) donde el usuario debe reflejar el resultado de la evaluación de cada punto de control así como comentarios explicando las razones del resultado final o cualquier otra explicación adicional que pueda ser apropiada.

4.3.8 Generación de Informes

HERA 2 proporciona un módulo de generación de informes ampliado y configurable. En estos informes puede proporcionarse información contextual sobre la página o la evaluación. El usuario puede elegir qué puntos de control aparecerán en el informe.

Figura 12. Formulario para introducir el resultado de la evaluación de un punto

El informe generado (Figura 13) incorpora la información proporcionada por el evaluador y los resultados de la evaluación (tanto manual como automática) de cada uno de los puntos de control, incluyendo los comentarios introducidos.

El informe puede generarse, además, en tres formatos: HTML, PDF o EARL RDF.

5. conclusiones: mitos y realidades

La accesibilidad de la web es un derecho de las personas con discapacidad y, al mismo tiempo, beneficia a muchos tipos de usuarios con diversidad cultural, de idioma, de tecnología de conexión, etc. De hecho, la accesibilidad web es un pilar fundamental en el camino de construcción de una Sociedad de la Información inclusiva. A pesar de todo existen una serie de mitos relacionados con la accesibilidad web que conviene desterrar.

En primer lugar, se suele proclamar sin razón que la accesibilidad web tiene un elevado coste, pero esto no es más que un mito. Todo depende en gran medida de la filosofía seguida al construir el sitio web. Evidentemente, si primero se diseña e implementa el sitio web sin tener en cuenta los criterios de accesibilidad, intentar arreglar los problemas a posteriori supondrá un alto coste de desarrollo, con gran cantidad de rediseño y reimplementación y, probablemente, con un resultado impredecible. En cambio, si se tienen en cuenta los criterios de accesibilidad desde el comienzo, desde el diseño del sitio web, las características de accesibilidad pasarán a ser parte de la rutina de trabajo, obteniéndose buenos resultados desde el principio y a un coste despreciable en comparación con el coste de construcción del sitio web completo. Sí que es cierto, en cambio, que los primeros desarrollos accesibles conllevan un coste de formación de personal (que dejará de existir en proyectos futuros) y que la falta de soporte de las herramientas de autor hace que muchas veces el trabajo de desarrollo accesible se vuelva más tedioso.

En segundo lugar, se suele afirmar que lograr un sitio web accesible es muy difícil. En primer lugar, sí es cierto que se necesitaría un mejor soporte por parte de las herramientas de autor y que algunos aspectos de la accesibilidad web relacionados con multimedia (subtítulos, doblaje, audiodescripción) suelen ser ajenos a los desarrolladores web (aunque para estos temas existen profesionales perfectamente cualificados en los medios de comunicación más tradicionales, como la televisión). Sin embargo, es extremadamente sencillo lograr que la mayoría de los elementos de un diseño web sean accesibles. Es tan sencillo como saber utilizar de forma adecuada las herramientas y tecnologías apropiadas (como XHTML y CSS).

Figura 13. Visión parcial de uno de los tipos de informes (PDF) que pueden generarse con HERA

Un tercer mito consiste en justificar la falta de accesibilidad en función del poco número de personas afectadas y esta afirmación es completamente falsa. En primer lugar, se considera que el 10% de personas de la Unión Europea tiene algún tipo de discapacidad. Si se trasladan esas cifras a España, el que se cuestione la amplitud del mercado de la accesibilidad debería plantearse si cerca de 4.000.000 de usuarios españoles es un nicho de mercado pequeño. Por otro lado, debe tenerse en cuenta que un sitio accesible será, por definición, más fácil de usar para todos, por lo que, en realidad, el beneficio de la accesibilidad abarca al 100% de la población.

El último mito habitual consiste en pensar que los usuarios con discapacidad no forman parte del mercado al cual va dirigido un sitio web. ¿Es eso cierto? En un principio puede parecer evidente, por ejemplo, que un ciego no va a usar nunca un sitio web de una auto-escuela. Pero, ¿y si esa persona ciega está buscando información sobre autoescuelas para matricular a su hijo? Por otro lado suele suceder que las personas con discapacidad están más motivadas para el uso de Internet y determinados servicios: así, el índice de penetración de Internet es mayor en hogares con personas con discapacidad y, además, esas personas tienen mayor actividad en comercio electrónico que la media nacional. Esto último es así dado que un sitio web de comercio electrónico que fuera accesible les permitiría realizar compras que en el mundo físico no podrían hacer sin ayuda (Clark, 2003).

Finalmente debe incidirse en la importancia de la evaluación de la accesibilidad de un sitio web, evaluación que debe realizarse tanto durante el desarrollo del mismo como de forma periódica una vez que este está en fase de explotación. En este artículo se ha mostrado a modo de ejemplo la herramienta HERA, que proporciona una ayuda importante para la revisión semiautomática de las páginas web.

Recibido en diciembre 2006

Aceptado en enero 2007

6. bibliografía

Abou-Zahra and participants of the Education and Outreach Working Group (EOWG) of WAI (2006a). Evaluating Web Sites for Accessibility: Overview [en línea]. World Wide Web Consortium, 2006. <http://www.w3.org/WAI/eval> [Consulta: 23-10-2006].

Abou-Zahra, S.; Chisholm, W.; Brewer, J. (2006b). Evaluation, Repair, and Transformation Tools for Web Content Accessibility [en línea]. World Wide Web Consortium, marzo 2006. <http://www.w3.org/WAI/ER/existingtools.html> [Consulta: 23-10-2006].

aenor (2004). Aplicaciones informáticas para personas con discapacidad. Requisitos de accesibilidad para contenidos en la web. Norma une 139803:2004. Asociación Española de Normalización y Certificación (aenor).

Benavídez, C.; Fuertes, J. L.; Gutiérrez, E.; Martínez, L. (2006). “Semi-Automatic Evaluation of Web Accessibility with HERA 2.0”. Lecture Notes in Computer Science nº 4061, Computers Helping People with Special Needs, julio, 2006, págs. 199-206.

Benavídez, C.; Gutiérrez, E. (2004). “HERA una herramienta para la revisión manual de la accesibilidad web.” Jornadas de Accesibilidad y Nuevas Tecnologías (JANT 2004), Bilbao, 2004.

Berners-Lee, T. (2000). Tejiendo la Red. El inventor del World Wide Web nos descubre su origen. Siglo XXI de España Editores, S.A.

BOE (2002). Ley 34/2002, de 11 de julio, de servicios de la sociedad de la información y de comercio electrónico. Boletín Oficial del Estado. 12 de julio de 2002.

BOE (2003). Ley 51/2003, de 2 de diciembre, de igualdad de oportunidades, no discriminación y accesibilidad universal de las personas con discapacidad. Boletín Oficial del Estado, 3 de diciembre 2003.

Bos, B. (2006). CSS: Cascading Style Sheets. [en línea] World Wide Web Consortium, septiembre de 2006. <http://www.w3.org/Style/CSS/> [Consulta: 23-10-2006].

Caldwell, B.; Chisholm, W.; Slatin, J.; Vanderheiden, G. (2006). Web Content Accessibility Guidelines 2.0 [en línea]. World Wide Web Consortium, abril de 2006. <http://www.w3.org/TR/WCAG20/> [Consulta: 23-10-2006].

Chisholm, W; Vanderheiden, G.; Jacobs, I. (1999). Web Content Accessibility Guidelines 1.0 [en línea] World Wide Web Consortium Recommendation, 5 de mayo de 1999 <http://www.w3.org/TR/WCAG10/> [Consulta: 23-10-2006].

Clark, J. (2003). Building Accesible Websites. New Riders, 2003.

CTIC: Fundación Centro Tecnológico de la Información y la Comunicación (2006). TAW: Test Accesibilidad Web [en línea]. Fundación CTIC, España, 2006. <http://www.tawdis.net/> [Consulta: 23-10-2006].

Cumbre Mundial sobre la Sociedad de la Información y el papel de las Autoridades Locales (2005). Declaración y Plan de Acción de Bilbao. 11 de noviembre de 2005. <http://www.it4all-bilbao.org/declaracion> [Consulta: 29-10-2006].

ICDRI (2006). Test your site now with Cynthia Says to see if it is accessible! [en línea] International Center for Disability Resources on the Internet, 2006. <http://www.icdri.org/test_your_site_now.htm> [Consulta: 23-10-2006].

Opera (2006). Opera Web Browser [en línea] Opera Software. <http://www.opera.com/> [Consulta: 23-10-2006].

Sidar (2003). Herramienta Hera Versión 1.0 [en línea]. Fundación Sidar – Acceso Universal <http://www.sidar.org/ex_hera/> [Consulta: 24-10-2006].

Sidar (2005) Herramienta Hera Versión 2.0 beta [en línea]. Fundación Sidar – Acceso Universal <http://www.sidar.org/hera/> [Consulta: 23-10-2006].

Sidar (2006) Fundación Sidar - Acceso Universal [en línea]. Fundación Sidar – Acceso Universal <http://www.sidar.org/> [Consulta: 24-10-2006].

Slatin, J. M.; Rush, S (2003). Maximum Accessibility: Making Your Web Site More Usable for Everyone. Addison Wesley Professional, Boston.

W3C «World Wide Web Consortium» [en línea] 2006 <http://www.w3c.org/> [Consulta: 23-10-2006].

WAI. Web Accessibility Initiative [en línea], World Wide Web Consortium, 2006. <http://www.w3c.org/WAI/> [Consulta: 23-10-2006].

Watchfire (2006). Watchfire WebXACT [en línea]. Watchfire. <http://webxact.watchfire.com/> [Consulta: 23-10-2006].

World Summit on the Information Society. Tunis Commitment [en línea], Documento WSIS-05/TUNIS/DOC/7-E. 18 de noviembre de 2005. Túnez. <http://www.itu.int/wsis/docs2/tunis/off/7.html> [Consulta: 23-10-2006].