Logo de Mosaic
Accesibilidad
Conceptos básicos de accesibilidad

25. Conceptos básicos de accesibilidad

Tom Hughes-Croucher. 26 de septiembre del 2008. Última modificación: 1 de agosto de 2017 (equipo docente del grado de Multimedia). Publicado en: wcag, alt, 508, sección, legal.

Cuándo creéis un sitio web, la accesibilidad (conseguir que todo el mundo lo pueda utilizar, sean cuales sean sus capacidades o discapacidades) debería ser una de las preocupaciones más importantes. En este curso, hasta ahora la accesibilidad ha estado siempre implícita en todos los ejemplos que hemos visto, incluso aunque no os dierais cuenta. En este apartado, sin embargo, hablaremos de ello explícitamente para que podáis entender bien qué es, por qué es importante, cómo se garantiza que los sitios sean accesibles y qué directrices existen para definir los sitios accesibles.

Antes de hablar concretamente de la accesibilidad en la web, empezaremos hablando de la accesibilidad en general; al fin y al cabo, la accesibilidad no es sólo una cuestión asociada a los sitios web; es un aspecto que, potencialmente, debe tener en cuenta todos los servicios, objetos o tecnologías con los que os encontréis.

Nota

Tened en cuenta que un tema asociado sobre el que os deberíais informar es WAI ARIA: la iniciativa Web Accessibility Initiative's Accessible Rich Internet Applications, que es básicamente una metodología que permite la creación de aplicaciones con Ajax/JavaScript más accesibles. Podéis encontrar un artículo muy bueno de introducción al ARIA en dev.opera.com.

Los contenidos de este apartado son los siguientes:

25.1. ¿Qué es la accesibilidad?

Mirad a vuestro alrededor. Es muy posible que veáis a otras personas; si no es así, ¿por qué no vais a dar un paseo rápido? Probablemente lo disfrutaréis y os sentará bien. Todas las personas que veréis serán diferentes: algunas tienen el pelo castaño, otras no. Algunas tienen los ojos azules, otras no. Otras llevan gafas, otras no. No hay dos personas exactamente iguales. Algunas diferencias, como el color del pelo o de los ojos, son puramente estéticas; es decir, no afectan de ninguna manera importante a nuestra vida. Algunas diferencias, como el hecho de llevar gafas, sí que la afectan. La accesibilidad es algo muy sencillo, una filosofía, aunque en algunos países también forma parte de la ley.

La accesibilidad es tratar a todo el mundo igual, sean cuales sean sus capacidades.

Somos muy conscientes de que esta afirmación está abierta a interpretación. La mayoría de las discusiones sobre accesibilidad empiezan hablando sobre la discapacidad. Esto implica que las personas con alguna discapacidad merecen un tratamiento especial. Pero la accesibilidad no es eso; en realidad es un síntoma del modo como la gente ha construido tradicionalmente edificios, sitios web y muchas otras cosas.

Cuando se construyen cosas presuponiendo que todo el mundo es igual que nosotros, podéis estar seguros de que siempre funcionarán mal para algunas personas. La gente presupone que la accesibilidad es ayudar a las personas con alguna discapacidad, ya que la accesibilidad añadida es algo muy presente en nuestra sociedad. Por ejemplo, muchos edificios que se construyeron sólo con escaleras han incorporado de repente unas rampas baratas y muy feas. Pero la accesibilidad ha sido durante mucho tiempo una cuestión importante en el diseño militar. ¿Por qué? Pues porque a menudo es vital para la supervivencia; con unas fuerzas g muy elevadas, los pilotos de los aviones de combate no pueden hacer lo mismo que hacen cuando están en el suelo. Si los diseñadores no tuvieran en cuenta las necesidades de los pilotos en entornos tanto de gravedad alta como baja, habría muchos más accidentes de avión.

Pero ¿qué significa esto para los desarrolladores de sitios web? La respuesta rápida es que debéis intentar ser más conscientes de las necesidades de todo el público potencial que puede visitar vuestro sitio web. Una respuesta más larga implicaría, por vuestra parte, ser mínimamente conscientes de los diferentes niveles de capacidades que puede tener la gente y del uso que hacen de los ordenadores. Aplicando las técnicas que se describen en este apartado y en otros apartados relacionados podréis crear unos sitios web que funcionen bien con muchas formas de interacción. Vuestros sitios web deben poder ser utilizados por personas:

De momento, no es necesario que os preocupéis por los detalles concretos de estas interacciones; ya los iremos viendo paso a paso.

25.2. ¿Por qué es importante la accesibilidad?

La accesibilidad es importante por una razón principal y por muchas otras razones pequeñas. La principal es que todos somos diferentes pero todos tenemos el mismo derecho a utilizar los sitios web, pero hay muchas otras razones por las que deberíais tener en cuenta la accesibilidad a la hora de crear sitios web:

Ahora pasaremos a ver algunos de estos puntos más detalladamente.

25.2.1. Los aspectos legales de la accesibilidad

Nota

Es muy importante entender los fundamentos de los aspectos legales, pero si no es que sois abogados y sabéis bien de qué estáis hablando, sería necesario que fuerais con mucho cuidado a la hora de dar una opinión sobre cuestiones legales.

En el Reino Unido, según la DDA, es ilegal discriminar a las personas discapacitadas a la hora de contratar trabajadores y ofrecer servicios o educación. La discriminación se define como no hacer "ajustes razonables" para dar apoyo a todo el mundo, sean cuales sean sus capacidades o discapacidades. Esto se aplica, evidentemente, a los servicios y la educación disponibles a través de sitios web.

En Estados Unidos y en la Unión Europea también hay exigencias para los sitios web gubernamentales. En Estados Unidos, los sitios web del gobierno federal (y de algunos gobiernos estatales) deben cumplir la Sección 508. La Sección 508 es un documento que intenta definir los requisitos mínimos para conseguir la accesibilidad. La Sección 508 no afecta sólo a los sitios web, sino que también hace referencia a cualquier otra tecnología que puedan utilizar los empleados federales. En Europa, la Comisión Europea ha reconocido la web Accessibility Initiative (WAI) de W3C y recomienda su uso a todos los Estados miembros. La WAI publica directrices para sitios web, fabricantes de herramientas de creación de webs y navegadores web (por ejemplo, el WCAG, del que hablaremos más adelante).

25.2.2. Mercados potenciales

Si creáis sitios web (o cualquier otra cosa) para un tipo de personas concretas, estaréis excluyendo otros tipos de personas incluso aunque no os deis cuenta de ello, y toda esta gente excluida puede representar fácilmente una cuota de mercado importante (o incluso mayoritaria). En el año 2000, la cadena de supermercados Tesco del Reino Unido puso en marcha un proyecto para crear una versión diferente de su sitio de comestibles en línea pensado específicamente para las personas con discapacidades visuales. Julie Howell, de RNIB, comentó que "El trabajo realizado por Tesco.com para conseguir que su servicio de comestibles fuera más accesible para las personas ciegas ha dado como resultado un aumento de los ingresos de 13 millones de libras anuales, unos ingresos que no estaban al alcance de la compañía cuando el sitio web no era accesible para los clientes ciegos". Así pues, si Tesco no hubiera pensado en la gente con discapacidades visuales, no habría llegado nunca a un mercado de clientes con un valor de 13 millones de libras como mínimo.

La lección que debemos extraer es que todo el mundo, sean cuales sean sus capacidades, necesita los mismos servicios: comestibles, taxis, electricidad, etc. y deben poder disfrutar de las mismas cosas: películas, música, bares, etc. Presuponer que la situación vital personal de alguien hace que cambien sus capacidades o sus deseos de participar en todos los aspectos de la sociedad se ha demostrado una y una otra vez como un gran error.

25.2.3. Motores de búsqueda

Los motores de búsqueda no son personas. A menudo, cuando alguien crea un sitio web lo hace sin tener en cuenta cómo se podrá encontrar en Google, Yahoo!, etc. Los motores de búsqueda son sólo programas informáticos y para indexar la página sólo pueden utilizar la información que pueden entender. Eso les hace ser muy similares a los lectores de pantalla que pueden utilizar las personas con alguna discapacidad visual.

El ejemplo más obvio de los efectos que esto tiene sobre el diseño de webs son las imágenes. Los ordenadores muestran imágenes a partir de una lista con los colores que deben tener todos los píxeles y envían esta información al monitor. Si ponéis en una página web una imagen que contiene texto, como por ejemplo un logotipo, el ordenador no tiene ni idea de qué dice el texto y ni siquiera sabe que la imagen contiene texto. En HTML, el elemento de imagen contiene una manera de describir con texto el contenido de una imagen, que es el atributo alt. Debéis ofrecer un texto para describir todas las imágenes no decorativas de vuestro sitio, y nunca deberíais representar párrafos completos como imágenes (o Flash); las personas ciegas y los motores de búsqueda no tendrán ni idea de qué dice el texto. Como resultado, la posición en un motor de búsqueda (es decir, la facilidad de encontrar vuestro sitio web con motores de búsqueda como Google) se verá afectada y quedaréis innecesariamente fuera de un mercado muy valioso.

25.2.4. Ética y marcas

Todo el mundo debería tener en cuenta la accesibilidad, pero esto no quiere decir que todo el mundo lo haga. Si tenéis en cuenta la accesibilidad, estaréis actuando en beneficio de la comunidad. Eso es algo de lo que os podréis enorgullecer; si demostráis que tenéis en cuenta a todos los que integran nuestra sociedad, conseguiréis mejorar mucho vuestra imagen de marca. Como profesionales, nuestra obligación es intentar conseguir los resultados de la mejor calidad posible. En una sociedad que nos valora como personas individuales, es importante no excluir a alguien por el hecho de que tenga unas necesidades diferentes.

Si seguís unos principios responsables y demostráis de una manera genuina que los aplicáis, podréis crear una imagen de marca extraordinariamente positiva. Las compañías que demuestran que se preocupan por sus clientes los fidelizarán mucho más que las que no lo hacen.

25.3. Diseñar pensando en la accesibilidad

La clave para la accesibilidad es pensar en un problema y decidir solucionarlo para más de un tipo de usuarios.

Si pretendéis tratar la accesibilidad como algo que ya añadiréis una vez que hayáis acabado todos los demás trabajos, sólo conseguiréis tener algo mal hecho y mal integrado. Necesitaréis más tiempo, no funcionará bien y tendrá un aspecto horrible.

La mejor manera de conseguir una solución bien hecha es diseñar la web teniendo en cuenta todas las necesidades desde el primer momento. Eso no quiere decir que no podáis cambiar vuestros planes o añadir algo que os hubiera pasado por alto, pero deberíais intentar ser conscientes de cuál es el problema general que pretendéis solucionar con vuestro diseño. En el caso de los sitios web, eso implica crear una solución usable por todos los usuarios, incluyendo a quienes quizá no pueden utilizar un ratón, un teclado, un monitor, etc.

25.4. Requisitos de interoperabilidad

Los requisitos de interoperabilidad pueden variar mucho de una situación a otra:

Cuando queráis construir sitios para la web pública, por lo tanto, deberéis incorporar una cierta interoperabilidad con una combinación muy variada de usuarios y tecnologías. Hay cuatro enfoques posibles:

En las intranets, la compatibilidad con versiones anteriores y la variedad son un problema mucho más pequeño. Una organización concreta puede garantizar, por ejemplo, que todos los empleados con discapacidades tengan acceso a una tecnología de asistencia que acepte bien el DHTML. En estas circunstancias, y con las pruebas pertinentes con la tecnología de asistencia ofrecida, sería razonable tomar el JavaScript como mínimo.

Sin embargo, la compatibilidad con versiones posteriores y la compatibilidad entre plataformas sí que siguen siendo un problema, por lo que se deberían preferir las tecnologías abiertas y estándar sobre las tecnologías propietarias y no estándares.

Podríais desarrollar, por ejemplo, una aplicación de formación de la intranet para una gran corporación. Os han pedido que garanticéis que la aplicación sea accesible, pero no os han especificado ningún estándar al que os debáis adaptar. Habláis con el departamento de informática y descubrís que todo el mundo tiene la última versión de la Internet Explorer con el JavaScript habilitado y Flash instalado y activado, y también que todo el mundo dispondrá de la tecnología de asistencia moderna necesaria para poder utilizar todos estos programas. Aunque la compañía pase a una plataforma Unix, seguirá habiendo la tecnología de asistencia necesaria para el JavaScript, pero el texto y los controles en Flash sólo son accesibles desde Windows. Podríais hacer que el script y el Flash fueran una referencia obligatoria para vuestra aplicación. Pero decidís utilizar el Flash sólo para reproducir vídeo y construir los grupos de controles para el vídeo Flash a partir de los estándares web, ya que la tecnología de asistencia sólo puede acceder a los controles del Flash desde la plataforma Windows. Así, la aplicación continuaría siendo accesible aunque la compañía migrara a Unix.

Las políticas de TI de la organización pueden cambiar, y todos los esfuerzos mejor intencionados para hacer que las funciones JavaScript sean operativas y para explotar los grupos de funciones de accesibilidad de los conectores pueden fallar; por lo tanto, continúa siendo una buena idea realizar una mejora progresiva de la referencia tecnológica a partir de una capa HTML básica.

25.5. Características de una página web accesible

En este subapartado explicaremos las funciones de accesibilidad diferentes de un sitio web; es decir, qué debe contener un sitio web accesible. Explicaremos cada una de ellas con detalle.

25.5.1. Estructura semántica

Una de las bases de los estándares de la web es el uso de la estructura semántica en el HTML. La estructura semántica también es sumamente importante para la accesibilidad. Es así porque ofrece un marco de referencia para la información de la página. Cuando la gente no puede ver el estilo visual de la página, la estructura semántica ayuda a explicarles varias cosas. Les puede indicar su posición en la jerarquía del documento y los modos como pueden interactuar con los diferentes elementos de la página; también ofrece énfasis en el contenido textual en los lugares adecuados.

Un buen ejemplo de la importancia de la estructura semántica de un documento para la accesibilidad es la navegación. Un menú de navegación bien estructurado es una lista de puntos. Podéis etiquetarlo como una lista HTML:

<ul>
   <li>Entrada del menú 1</li>
   <li>Entrada del menú 2</li>
   <li>Entrada del menú 3</li>
</ul>

Con unos menús de navegación estructurados como listas, los usuarios de lectores de pantalla podrán saber muy fácilmente que es una lista aunque no la puedan ver. Eso es así porque los lectores de pantalla les dicen que es una lista. Si no utilizáis el etiquetado de lista, entonces el lector de pantalla no tiene ninguna manera de saber que es una lista y no lo puede decir al usuario.

Ved también

Podéis encontrar más información sobre el uso de la semántica correcta en vuestro HTML en muchos de los apartados anteriores de este curso, básicamente en los que hablan del HTML.

25.5.2. Contenido alternativo

Tal como se menciona en el subapartado sobre los motores de búsqueda, es esencial que haya una alternativa accesible al contenido y la navegación. El texto se considera la moneda universal del contenido, pero al respecto hay que hacer una advertencia, tal como veréis más adelante. Un lector de pantalla puede leer el texto sin ninguna dificultad, se puede hacer más pequeño o más grande, se puede modificar el contraste muy fácilmente y se pueden hacer muchas más transformaciones. Como el texto es tan fácil de manipular, todas las formas más exóticas de contenido deberían tener siempre una alternativa basada en texto. Algunos formatos, como las versiones más modernas de Flash, ya integran el acceso en texto con el fin de poder acceder directamente a su contenido textual directamente sin necesidad de tener que ofrecer una alternativa para todo el soporte.

Ved también

Podéis ver los motores de búsqueda en el subapartado 25.2.3 de este módulo.

El único grupo con discapacidad para el que una alternativa de texto puede no tener ninguna utilidad es el grupo de personas con discapacidades cognitivas.

La dificultad que presentan las personas con discapacidades cognitivas es que normalmente necesitan un contenido diferente y no el mismo contenido en un soporte diferente. Con eso no queremos decir que no haya que hacerlo. La simplificación del lenguaje y de la terminología utilizada en vuestro sitio web representará un beneficio para todo el mundo. Algunos grupos, como la Plain Language Commission, recomiendan un enfoque de "lenguaje sencillo" para el material que utilizan las compañías para dar a sus clientes la información importante, como los requisitos legales y los términos y las condiciones. Estos grupos ofrecen un léxico muy sencillo que contiene los términos que se pueden utilizar para una comunicación efectiva utilizando el lenguaje más simple posible.

¿Cómo podéis incluir alternativas de texto en vuestro sitio web? El primer paso es identificar los elementos que todavía no son texto. En el HTML hay muchos elementos que todavía no son texto. Las imágenes son el ejemplo más evidente de esto.

Aquí tenéis un ejemplo de uso accesible de una imagen:

<p>An interesting piece of art is Michelangelo's "God creates
Adam" <img src="images/adam.jpg" alt="A painting of a man
reaching up to touch God's hand reaching down. It is cracked with age."
longdesc="adam.html">.</p>

La imagen de este ejemplo forma parte integral del contenido. El atributo alt contiene una breve descripción de la imagen para las personas (o para los motores de búsqueda) que quizá no pueden verla correctamente. El atributo longdesc permite enlazar con una página HTML que contiene una descripción completa de la imagen. Esto se utiliza normalmente sólo para describir imágenes complejas que se utilizan como parte importante del contenido. Y también tiene el inconveniente de que los navegadores no lo aceptan completamente. La mayoría de las veces sólo utilizaréis el atributo alt.

Al usar las imágenes para cosas diferentes que no son contenidos, como la navegación o simplemente como decoración visual, las deberíais tratar diferente de las imágenes de contenido. Las imágenes utilizadas para hacer más atractivos los botones o la navegación de la página deben tener un atributo alt que coincida con el texto de la imagen. El atributo alt funciona sencillamente como una manera simple para permitir que el ordenador lea el texto contenido en la imagen (y lo lea a un usuario de un lector de pantalla).

En el caso de las imágenes puramente decorativas, las imágenes utilizadas para el seguimiento de anuncios o cualquier otra imagen que no tenga en principio ningún interés para el usuario o con el que no tenga que interactuar, el atributo alt debería quedar vacío. Esto no quiere decir que se deba omitir este atributo, sino que se debe definir como alt="". Esto es así a causa de una táctica que utilizan los lectores de pantalla para ayudar a sus usuarios a hacer frente a páginas muy inaccesibles. Cuando una imagen no tiene ningún atributo alt, especialmente cuando forma parte de un enlace, el lector de pantalla lee la URL de la imagen al usuario. Lo hace así para que los usuarios puedan saber que es la imagen a partir de la URL, por ejemplo si la imagen tiene un nombre similar a anadir_al_carrito.gif. Así pues, deberíais definir alt="" para las imágenes que sepáis que no tendrán ningún interés para el usuario, de manera que los lectores de pantalla no lean todas y cada una de las URL de las imágenes, lo cual podría llegar a ser muy frustrante para el usuario del lector de pantalla.

No todas las formas de contenido son tan simples como una imagen. Los soportes más complejos, como Flash (los archivos Flash pueden ser sitios web enteros en sí mismos) o las películas exigen unas descripciones más complejas. Las versiones más recientes de Flash permiten ofrecer alternativas de texto para los elementos de una película Flash, igual que en el HTML.

25.5.3. Definir la interacción

Muchas webs actuales implican el uso de tecnologías más allá del HTML. Incluso algo tan básico como el CSS se puede utilizar de maneras que hagan que una página o una interacción sean mucho menos accesibles.

La clave para la accesibilidad de la interacción se encuentra en el hecho de empezar con las interacciones más sencillas y utilizarlas como componentes básicos para las interacciones más complejas.

Nota

Tened en cuenta que el objetivo de este ejemplo es haceros ver la función que tienen los diferentes elementos de las páginas web. Para garantizar que sean accesibles, deben ser semánticamente solventes en términos tanto de los elementos HTML como de las metáforas visuales que se utilicen. Si lo encontráis todo un poco confuso, podéis volver a leer el ejemplo unas cuantas veces y mirad también unos cuantos menús y otros componentes de páginas web mientras vais comprobando no sólo si se utiliza el HTML correcto, sino también si el aspecto del componente tiene sentido en relación con su función. No podéis esperar nunca que un visitante de una página web realice una búsqueda con un cuadro de texto que se llama "Introducid vuestra dirección electrónica para suscribiros a nuestro boletín informativo", ni tampoco podéis esperar que un visitante vidente pueda localizar contenido de interés si todos los títulos tienen el mismo estilo que el texto normal (de manera similar, tampoco podéis esperar que un usuario ciego localice contenido de interés si todos los "títulos" son en realidad sólo otros párrafos con un tamaño de texto más grande aplicado con el CSS o elementos font).

Un buen ejemplo de ello es la metáfora visual tan utilizada de las pestañas. La metáfora de las pestañas se ha extraído de las carpetas de anillas con clasificadores de temas. Eso se ha trasladado a los ordenadores para permitir que una única área de la pantalla pueda mostrar información de varios temas representados por pestañas conectadas al área. Hasta aquí todo es razonablemente sencillo. El problema son las tecnologías utilizadas para crear las pestañas, que normalmente se aplican con JavaScript.

En cuanto las pestañas se utilizan como parte de una interacción más compleja que el simple hecho de permitir que el usuario seleccione la información, la metáfora original queda rota, pero a menudo se sigue utilizando el mismo código para representar las pestañas. En el siguiente ejemplo, el HTML muestra el aspecto de un control de pestaña que muestra información:

<div class="tabcontrol">
   <div class="hd">
      <ul>
         <li><a href="#dogs" class="selected">Dogs</a></li>
         <li><a href="#cats">Cats</a></li>
         <li><a href="#fish">Fish</a></li>
      </ul>
   </div>
   <div class="bd">
      <p id="dogs" class="selected">Some information about dogs.
      He dogs tab is the default tab.</p>
      <p id="cats">Some information about cats.</p>
      <p id="fish">Some information about fish.</p>
      </div>
</div>

En este ejemplo, la clase selected se utilizaría para especificar qué pestaña debe mostrar el gráfico de "pestaña frontal"; por ejemplo, podéis consultar la pestaña "Artículos" de la parte superior de esta página que utiliza este método.

Esta estructura es adecuada para el contenido que transmite información. En este ejemplo, la class de selected se utilizaría para indicar qué pestaña es la activa, es decir, la que está abierta y muestra su información; las demás estarían cerradas (es decir, sus párrafos estarían ocultos) hasta el momento de hacer clic en sus enlaces correspondientes. La pestaña "Dogs" es la pestaña activa por defecto, tal como muestra la figura 1.

Control por pestañas que muestra la pestaña 'Dogs' activa por defecto

Figura 1. Un control para pestañas muy sencillo que muestra la pestaña 'Dogs' como la pestaña activa por defecto.

Cuando se hace clic en otro enlace (tal como muestra la figura 2), se utilizará el JavaScript para mover dinámicamente class="selected" hasta ese enlace; en este momento se aplicará el estilo a esta pestaña para mostrarla, y la que se mostraba previamente se ocultará.

Control por pestañas que muestra una pestaña nueva activa después de hacer clic en su enlace

Figura 2. Ahora se ha hecho clic en un enlace diferente y su pestaña correspondiente pasa a ser la pestaña activa.

También es muy habitual utilizar pestañas para permitir que los usuarios seleccionen tipos diferentes de búsquedas. En este caso, si intentáis reutilizar el estilo de código del ejemplo previo, el concepto se empieza a descomponer:

<div class="tabcontrol">
   <div class="hd">
      <ul>
         <li><a href="#dogs" class="selected">Dogs</a></li>
         <li><a href="#cats">Cats</a></li>
         <li><a href="#fish">Fish</a></li>
      </ul>
   </div>
   <div class="bd">
      <form id="dogs" class="selected" action="search.html"
       method="GET"><div><label for="dogsearch"><input type="text"
       name="dogsearch" id="dogsearch"><input type="submit"
       value="Search for Dogs"></div></form>
      <form id="cats" action="search.html" method="GET"><div><label
       for="catsearch"><input type="text" name="catsearch"
       id="catsearch"><input type="submit" value="Search for
       cats"></div></form>
      <form id="fish" action="search.html" method="GET"><div>
      <label for="fishsearch"><input type="text" name="fishsearch"
       id="fishsearch"><input type="submit" value="Search for
       fish"></div></form>
   </div>
</div>

El uso de la misma estructura de código ya no tiene ningún sentido; en este caso, están los mismos elementos form repetidos una y otra vez para que todo encaje con el concepto de sustituir el contenido, lo que es un despilfarro de etiquetado. En lugar de pensar visualmente, lo importante es pensar en la interacción en sí. En este ejemplo, más que seleccionar información nueva para ver las pestañas, deberíais cambiar la interacción del usuario con el formulario de búsqueda. De hecho, lo único que debe hacer una pestaña es seleccionar el tipo de animal que busca el usuario. Si lo ponéis en práctica, podréis crear una interacción mucho mejor para todos los usuarios del sitio con un etiquetado más limpio y más sencillo de mantener:

<form action="search.html" method="GET">
   <fieldset>
      <legend>Search within:</legend>
       <ul>
        <li><label for="dogs">Dogs</label><input id="dogs" type="radio"
         name="animal" value="dog" checked></li>
        <li><label for="cats">Cats</label><input id="cats" type="radio"
         name="animal" value="cat"></li>
        <li><label for="fish">Fish</label><input id="fish" type="radio" 
         name="animal" value="fish"></li>
        </ul>
   </fieldset>
   <input type="text" id="searchfield" name="search">
   <input type="submit" value="Search">
</form>

Si se crea primero la interacción, el etiquetado es más limpio y todos los usuarios del sitio obtendrán la mejor experiencia posible. Cuando hemos empezado ampliando una metáfora visual hemos roto rápidamente la interacción y hemos creado un etiquetado horrible basado en los supuestos del ejemplo previo. Si hubiéramos utilizado AJAX para insertar el contenido en lugar de tenerlo todo en la página, el resultado habría sido aún peor. Los usuarios sin JavaScript habrían tenido que cargar una página totalmente nueva para pasar al formulario de búsqueda para gatos o peces. Si pensamos primero en la interacción básica (más que en el aspecto visual), el problema será mucho más sencillo. Ahora podemos seguir manteniendo la metáfora de las pestañas (aunque con unos cuantos estilos y scripts) y utilizar un único formulario para todas las búsquedas.

Esto es básico para entender cómo se debe crear una interacción accesible. Uno de los puntos positivos de HTML es que el trabajo más pesado de conseguir que las interacciones en HTML sean accesibles ya está hecho. Si no utilizáis tecnologías con HTML para romper la metáfora, podréis conseguir que la mayoría de las cosas funcionen sin muchos esfuerzos para la mayor parte de las personas.

25.6. Estándares de accesibilidad

En este subapartado revisaremos algunos de los estándares y directrices disponibles que pretenden definir la accesibilidad de la web y ayudar a los desarrolladores web a crear sitios accesibles. La mayoría de estos sistemas incluyen algún tipo de sistema de lista de control para que los desarrolladores puedan comprobar si sus sitios cumplen los diferentes criterios de accesibilidad.

25.6.1. Directrices de accesibilidad del contenido web 1.0

El W3C es uno de los principales organismos de estándares de Internet. Su Web Accessibility Initiative (WAI) publicó la primera versión de sus directrices para unos sitios web accesibles en el mes de mayo de 1999. Las directrices de accesibilidad del contenido web (WCAG) son el estándar más utilizado para la accesibilidad de la web. Varios organismos gubernamentales, que incluyen a la UE y al gobierno italiano, recomiendan o exigen el uso de las WCAG 1.0.

Las WCAG 1.0 son un grupo de 14 directrices que intentan resumir los objetivos necesarios para hacer que una página sea accesible.

Cada una de las directrices incluye varios puntos de control, que son la esencia real del documento. Las directrices explican los conceptos que los autores querían transmitir, pero la validación se hace con los puntos de control. Cada uno de los puntos de control está clasificado con una prioridad del 1 al 3 para identificar su importancia. Con el fin de ajustarse a las WCAG 1.0 hay que cumplir todos los puntos de control de prioridad 1. El cumplimiento de todos los puntos de control de prioridad 1 da una clasificación de conformidad "A". Si, además, se cumplen todos los puntos de control de prioridad 2, entonces el nivel de conformidad es "AA". Si se cumplen todos los puntos de control de prioridad 1, 2 y 3, entonces el nivel de conformidad será "AAA", que es la clasificación más elevada.

Sin embargo, en realidad, las WCAG 1.0 ya se han quedado un poco anticuadas. Muchas compañías empiezan con una clasificación de conformidad "A" o "AA" y entonces se dedican a añadir otras directrices, como por ejemplo la See it Right de RNIB. Las WCAG 1.0 son un buen punto de partida, pero también deberíais tener en cuenta otros estándares más actuales, especialmente si utilizáis mucho JavaScript u otras tecnologías surgidas después del año 1999, que fue cuando se publicaron las WCAG 1.0.

Otro dato importante que hay que tener en cuenta sobre el estándar WCAG 1.0 es que fue diseñado como parte de un conjunto de 3 documentos. Otro hacía referencia a los "agentes de usuario", que describe a los navegadores (como Opera) y otras tecnologías adicionales que la gente puede necesitar para utilizar la web (como lectores de pantalla). El tercero cubría las herramientas de autoría, como Dreamweaver o los sistemas de gestión de contenido; su objetivo es conseguir que estas herramientas hagan una buena parte del trabajo necesario para acabar teniendo unas páginas web accesibles. Desafortunadamente, esta visión no ha cuajado y el único estándar de estos tres que se ha adoptado de una manera generalizada es el WCAG 1.0. Esto significa que a menudo no se cumplen las expectativas del WCAG 1.0 con respecto a los agentes de usuario, y que las herramientas de autoría hacen una parte muy pequeña del trabajo para conseguir unos sitios web accesibles. Esto no quiere decir que no podáis utilizar el WCAG 1.0; sencillamente significa que sólo hace referencia a una parte de los criterios de accesibilidad y que no es la solución completa.

25.6.2. Directrices de accesibilidad del contenido web 2.0

Una vez publicadas las directrices WCAG 1.0, el W3C ya empezó a trabajar con las WCAG 2.0.

Nota

En el momento de escribir este apartado, esta versión actualizada del estándar se encuentra todavía en la fase de borrador. Teniendo en cuenta el proceso que sigue el W3C, es muy probable que este estándar se publique a principios del 2009.

Las WCAG 2.0 son un poco diferentes, ya que intenta no centrarse tanto en una tecnología concreta como las WCAG 1.0; es decir, que se puede aplicar a HTML, CSS, Flash, etc. las WCAG 2.0 se basan en 4 principios de accesibilidad. Éstos son:

Perceptibilidad
Las personas deben poder acceder al contenido por medio de un soporte que tengan a su disposición. Por ejemplo, las personas con problemas deben poder escuchar el contenido.
Operatividad
Las personas deben poder interactuar con la aplicación o el contenido de la web.
Comprensibilidad
Las personas que utilicen el contenido y la interfaz de usuario los deben entender.
Robustez
Cualquier solución ofrecida debería estar disponible en diferentes plataformas o sistemas. Con esto se pretende evitar que se inventen soluciones que la mayoría de las personas no podrán utilizar porque el hardware/software está restringido o es muy caro.

Aquí es importante decir que no se espera que los sitios web cumplan todos estos requisitos. La tecnología de que dispone el usuario también debería hacer parte del trabajo. Por ejemplo, se supone que las personas que lo necesiten ya tendrán un lector de pantalla, y por lo tanto no es necesario que todos los sitios web ofrezcan una versión de audio del contenido. Pero sí que se supone que el sitio web debe ofrecer unas páginas que se puedan leer utilizando la tecnología de lectura de pantalla más habitual con el fin de hacerlo posible. Esta diferencia es importante, igual que lo es la diferencia entre un sitio web con "widgets de accesibilidad" (como por ejemplo un botón para aumentar el tamaño de la letra) y una página web que funcionará en muchas situaciones diferentes (por ejemplo, varios navegadores y dispositivos que serían imposibles de prever).

Las WCAG 2.0 también son diferentes de las WCAG 1.0 por su enfoque hacia la tecnología. Como el estándar es más agnóstico con respecto a la tecnología y hace referencia a conceptos sobre accesibilidad en lugar de concretar detalles técnicos, es importante prestar atención a los documentos que acompañan el estándar. El documento "estándar" de WCAG 2.0 ofrecerá "la información básica", pero el documento "técnicas" ofrece datos sólidos y aplicables al desarrollador. Éste se divide en técnicas "generales" (ambiguas con respecto a la tecnología) y en detalles concretos para las tecnologías individuales del W3C. El W3C no escribe documentos para tecnologías propietarias, por lo que deberéis encontrar técnicas para tecnologías como Flash y Silverlight en otros sitios.

25.6.3. Otros estándares

Otro estándar importante desarrollado por el W3C es el estándar WAI-ARIA. Estas siglas son el acrónimo de Web Accessibility Initiative-Accessible Rich Internet Applications. Se trata de una serie de documentos que definen la manera de hacer accesibles las aplicaciones web complejas que utilizan tecnologías como HTML, JavaScript y AJAX.

Hay muchos otros estándares para la accesibilidad de la web; demasiado numerosos para hablar de ellos con detalle. El W3C mantiene una lista excelente de políticas internacionales relativas a la accesibilidad de la web; éste es un recurso muy importante para poder encontrar los documentos de políticas de todos los gobiernos locales.

Resumen

La accesibilidad es una cuestión importante por razones tanto económicas como sociales. No es una característica de un sitio web, sino una medida de la calidad con la que se creó. Si tenéis en cuenta el público de vuestro sitio mientras lo vais creando (y antes de hacerlo), construiréis unas páginas más accesibles con todas las ventajas que eso supone. Hay varias directrices muy conocidas que os pueden ayudar y si os ajustáis a ellas, podréis garantizar que lo que hayáis construido satisfará a los criterios de los expertos para hacer que vuestras páginas sean accesibles.

Preguntas de repaso

  1. Dad 3 razones por las que es importante crear sitios web accesibles.

  2. Utilizad Internet para ver cuáles son las leyes sobre accesibilidad de vuestro país y elaborad una lista de todas las leyes que creéis que serían aplicables a vuestros sitios web. Vuestra lista también debería incluir si estas leyes os exigen que utilicéis algunos estándares de la web, como WCAG o la Sección 508.

  3. Explicad de qué manera la accesibilidad es importante para la optimización de los motores de búsqueda.

  4. Cread un ejemplo de un uso accesible de contenido alternativo utilizando parte de vuestro contenido propio, como por ejemplo una fotografía.

  5. Utilizad Internet para ver cómo podríais conseguir que una tecnología como Flash o Silverlight sea accesible y escribid una comparación entre hacerlas accesibles y cómo se hace accesible el HTML.

  6. Explicad cómo diseñaríais una interacción de una página web para que sea accesible. Escribid unas instrucciones paso a paso para crear un control de árbol (no es necesario que lo acabéis creando realmente).

Logo Creative Commons
Los contenidos recogidos en este artículo están sujetos a una licencia Creative Commons
Reconocimiento, No comercial - Compartir bajo la misma licencia 3.0 No adaptada.
: Ir al índice :