Inicio

La única versión normativa de este documento es la versión original en inglés que se encuentra en el sitio web del W3C http://www.w3.org/TR/2000/NOTE-WCAG10-CORE-TECHS-20001106/.

Ninguna parte del presente documento en castellano es normativa aunque se especifique lo contrario.

Copyright © 1999-2000 W3C ® (MIT, INRIA, Keio), Todos los Derechos Reservados. Son aplicables las reglas del W3C sobre  obligaciones, marcas registradas, utilización de documentos y licencias de software.

Traductores: Carlos Egea, Alicia Sarabia, Alan Chuter

[indice]  

W3C

Técnicas Fundamentales para las Pautas de Accesibilidad al Contenido en la Web 1.0

Nota de 6 noviembre de 2000 de W3C

Esta versión en inglés:
http://www.w3.org/TR/2000/NOTE-WCAG10-CORE-TECHS-20001106/
Última versión en inglés:
http://www.w3.org/TR/WCAG10-CORE-TECHS/
Versión previa en inglés:
http://www.w3.org/TR/2000/NOTE-WCAG10-CORE-TECHS-20000920/
Editores:
Wendy Chisholm, W3C;
Gregg Vanderheiden, Trace R & D Center University of Wisconsin -- Madison;
Ian Jacobs, W3C

Copyright ©1999 - 2000 W3C® (MIT, INRIA, Keio), Reservados todos los derechos. Se aplican las normas concernientes a responsabilidad, marca, uso de documento y licencia de software de W3C.

Resumen

Este documento describe las técnicas para crear contenido accesible que pueda aplicarse con cualquier tecnología. Está destinado a ayudar a los autores de contenido en la  Web, que desean declarar su adecuación a las "Pautas de Accesibilidad al Contenido en la Web 1.0" ("Web Content Accessibility Guidelines 1.0") ([WCAG10]). Las técnicas de este documento pueden ayudar a los autores de contenido en la Web a adecuarse a las "Pautas de Accesibilidad al Contenido en la Web 1.0" ("Web Content Accessibility Guidelines 1.0"), pero estas técnicas no garantizan la adecuación ni son la única forma de que un autor pueda producir contenido adecuado.

Este documento es parte de una serie de documentos sobre técnicas para crear contenidos accesibles para la Web. Para información sobre otros documentos de la serie, por favor recurra al "Técnicas para las Pautas de Accesibilidad al Contenido en la Web 1.0" [WCAG10-TECHS].

Estatus de este documento

Esta versión se publica para corregir algunos vínculos truncados de la versión anterior.

La versión de 6 de noviembre 2000 de este documento es una Nota, de una serie de Notas, producidas y suscritas por el (Grupo de Trabajo de las Pautas de Accesibilidad al Contenido en la Web) (WCAG WG). Esta Nota no ha sido revisada ni suscrita por los Miembros de W3C. La serie de documentos sustituyen al documento único (Nota del 5 de mayo de 1999 Técnicas para las Pautas de Accesibilidad al Contenido en la Web 1.0). Los temas del documento anterior han sido separados en documentos para cada tecnología específica, que pueden evolucionar de forma independiente. Los documentos más cortos para cada tecnología específica permiten a los autores centrarse en una tecnología concreta.

En tanto que la Recomendación "Pautas de Accesibilidad al Contenido en la Web 1.0" ("Web Content Accessibility Guidelines 1.0" Recommendation) [WCAG10]  es un documento estable, se espera que esta serie de documentos conjuntos evolucione según cambian las tecnologías y los desarrolladores de contenidos descubren técnicas más efectivas para el diseño de contenido Web accesible.

Está disponible el (histórico de cambios en la serie de documentos), así como la (lista de temas abiertos y cerrados). Animamos a los lectores a comentar el documento y proponer soluciones a los temas actuales. Por favor, envíe los comentarios detallados sobre este documento al Grupo de Trabajo a w3c-wai-gl@w3.org; están disponibles los archivos públicos (public archives).

La versión en inglés de esta especificación es la única versión normativa. Pueden estar disponibles en traducciones de este documento.

La lista de errores conocidos de este documento está disponible en "Errores en las Pautas de Accesibilidad al Contenido en la Web". Por favor, informe sobre los errores en este documento a  wai-wcag-editor@w3.org.

La Iniciativa para la Accesibilidad en la Web - WAI del Consorcio World Wide Web W3C tiene disponibles una variedad de recursos sobre accesibilidad en la Web. Las Pautas de Accesibilidad WAI son producidas como parte de la Actividad Técnica de la WAI. Los objetivos del Grupo de Trabajo de las Pautas de Accesibilidad al Contenido en la Web están descritos en los estatutos.

Está disponible una lista de las actuales Recomendaciones y otros documentos técnicos de W3C.

Índice

1 Estructura contra presentación

Puntos de revisión en esta sección:

Cuando se diseña un documento o una serie de documentos, en primer lugar, los desarrolladores de contenidos deben esforzarse en identificar la estructura que desean dar a sus documentos, antes de pensar en cómo se presentarán los mismos al usuario. Distinguir la estructura del documento de la forma en que se presenta el contenido ofrece varias ventajas, incluido un aumento de la accesibilidad, facilidad de gestión y portabilidad.

La identificación de lo que es estructura y lo que es presentación puede ser un reto a veces. Por ejemplo, muchos desarrolladores consideran que una línea horizontal comunica una división estructural. Esto puede ser cierto para usuarios con una visión normal, pero para usuarios sin visión o sin navegadores gráficos, una línea horizontal no significa prácticamente nada. Por ejemplo, en HTML, los desarrolladores deberían usar los elementos de encabezamiento (H1 - H6) de HTML 4.01[HTML4] para identificar nuevas secciones. Estos pueden ser complementados con indicaciones visuales o de otro tipo tales como  líneas horizontales, pero no deben ser reemplazados por ellos.

A la inversa también: los desarrolladores no deben usar elementos estructurales para lograr efectos de presentación. Por ejemplo, en HTML, aunque el elemento BLOCKQUOTE puede crear sangrías de texto en algunos navegadores, está diseñado para identificar una cita, no para crear efectos secundarios de presentación. Los elementos BLOCKQUOTE usados para sangrías confunden a los usuarios y los robots de búsqueda, que esperan que el elemento se utilice para señalar una cita.

La separación de presentación y estructura es inherente a los documentos XML. Tal como afirma la Norman Walsh en "A Guide to XML" [WALSH],

Los navegadores HTML son, en su mayoría, programados con el soporte HTML incrustado. Un encabezamiento de primer nivel aparece en tal modo porque el navegador reconoce la etiqueta H1. De nuevo, puesto que los documentos XML no tienen fijadas etiquetas, este enfoque no funcionará. La presentación de un documento XML depende de una hoja de estilo. 

¡Test rápido! Para determinar si el contenido es estructural o de presentación, cree una vista esquema de su documento. Cada punto de la jerarquía denota un cambio estructural. Utilice etiquetas estructurales para marcar esos cambios y etiquetas de presentación para hacerlos más aparentes visual o auditivamente. Observe que las líneas horizontales no aparecerán en esta vista esquema y por tanto no son estructurales sino de presentación. Nota: Este test rápido se aplica a la estructura de capítulo, sección y párrafo. Para determinar la estructura dentro de las frases, busque abreviaturas, cambios en el idioma, definiciones y ítems de lista.

2 Equivalentes textuales

Puntos de revisión en esta sección:

El texto se considera accesible para prácticamente todos los usuarios si puede ser manejado por lectores de pantalla, navegadores no visuales y lectores braille. Puede ser presentado visualmente, agrandado, sincronizado con un vídeo para crear un subtítulo, etc. Durante el diseño de un documento que contenga información no textual (imágenes, applets, sonidos, presentaciones multimedia, etc.), complemente esa información con textos equivalentes siempre que sea posible.

Cuando se presente al usuario un equivalente textual, éste cumple esencialmente la misma función (en la medida de lo posible) que el contenido original. Para contenidos simples, un equivalente textual puede sólo necesitar describir la función o propósito del contenido. Para contenidos complejos (gráficas, gráficos, etc.) el texto equivalente puede ser más largo e incluir información descriptiva.

Deben proporcionarse textos equivalentes para los logotipos, fotografías, botones de envío, applets, viñetas en listas, ASCII art y en todos los vínculos contenidos en un mapa de imagen, así como en las imágenes invisibles usadas para maquetar una página.

¡Test rápido! Un buen test para determinar si un texto equivalente es útil es imaginar que se está leyendo en voz alta el documento por teléfono. ¿Qué diría sobre lo que encuentra en esta imagen para hacerla comprensible al interlocutor?

2.1 Panorámica de las tecnologías

Cómo se ha de especificar un texto equivalente dependerá del lenguaje del documento.

Por ejemplo, dependiendo del elemento, HTML permite al desarrollador especificar textos equivalentes a través de atributos ("alt" o "longdesc") o en el contenido del elemento (el elemento "OBJECT").

Los formatos de vídeo, como QuickTime, permiten al desarrollador incluir una variedad de bandas visuales y sonoras alternativas. SMIL ([SMIL]) permite al desarrollador sincronizar trozos (clips) de imagen y sonido, y archivos de texto alternativos entre si.

Cuando cree DTDs XML, asegúrese de que los elementos que podrían necesitar una descripción tienen alguna manera de asociarse por sí mismos a dicha descripción.

Algunos formatos de imagen permiten texto interno en el archivo de datos junto con la información de la imagen. Si un formato de imagen soporta este texto (por ejemplo, Portable Network Graphics, ver [PNG]), los desarrolladores de contenidos también pueden proporcionar información allí.

2.2 Compatibilidad con lo anterior

Los desarrolladores de contenidos deben tener en consideración la compatibilidad con lo anterior cuando diseñen páginas o sitios Web, puesto que:

Por tanto, cuando se diseñe para tecnologías más antiguas, considere estas técnicas:

3 Páginas alternativas

Puntos de revisión en esta sección:

Si bien es posible hacer accesible la mayor parte del contenido, puede ocurrir que toda o parte de una página permanezca inaccesible. Algunas técnicas adicionales para crear alternativas accesibles incluyen:

  1. Permita al usuario navegar a otra página diferente que sea accesible, que contenga la misma información que la página inaccesible y que sea actualizada con la misma frecuencia que la página inaccesible.
  2. En lugar de páginas alternativas estáticas, sitúe en el servidor scripts que generen versiones accesibles de la página solicitada. 
  3. Consulte los ejemplos para Marcos y Scripts.
  4. Proporcione un número de teléfono, fax, dirección de correo electrónico o postal donde la información esté disponible y accesible, preferentemente las 24 horas del día.

He aquí dos técnicas para vincular a una página accesible:

  1. Proporcione vínculos al principio tanto de la página principal como de la alternativa, para permitir al usuario moverse entre ellas. Por ejemplo, al principio de una página gráfica incluya un vínculo con la página sólo-texto, y en el principio de ésta incluya un vínculo hacia la página gráfica. Asegúrese de que estos vínculos son una de las primeras cosas que el usuario va a percibir, situándolo al principio de la página, antes que otros vínculos.
  2. Use meta-información para diseñar documentos alternativos. Los navegadores deberían presentar la página alternativa automáticamente basándose en el tipo y preferencias del navegador del usuario.

Puntos de revisión en esta sección:

No todos los usuarios tienen un entorno gráfico con un ratón u otro dispositivo para apuntar. Algunos usuarios dependen del teclado, teclado alternativo o entrada de voz para navegar entre vínculos, activar los controles de formulario, etc... Los desarrolladores de contenido deben asegurarse de que los usuarios puedan interactuar con una página mediante otros dispositivos que los dispositivos para apuntar. Una página diseñada para el acceso desde el teclado (además del acceso con ratón) será normalmente accesible a los usuarios con otros dispositivos de entrada. Aun más, diseñar una página para el acceso a través del teclado mejorará también habitualmente el conjunto de su diseño.

El acceso desde el teclado a los vínculos y los controles de formulario puede ser especificado de varias maneras:

Vínculos en los mapas de imagen.
Proporcione textos equivalentes para cada área de los mapas de imagen de cliente, o proporcione vínculos de texto redundantes para los mapas de imagen del lado del servidor. Consultar los ejemplos de la sección de mapas de imagen.
Atajos de teclado.
Proporcione atajos de teclado de forma que los usuarios puedan combinar pulsaciones de teclas para navegar los vínculos o los controles de formulario en una página. Nota: Los atajos de teclado - especialmente la tecla utilizada para activar el atajo - pueden ser implementados de forma diferente por los diferentes sistemas operativos. En ordenadores Windows, las teclas "alt" y "ctrl" son las más utilizadas, mientras que con los de Macintosh, es la tecla "manzana" ("apple") o "trébol". Consulte las secciones acceso desde el teclado a los vínculos y acceso desde el teclado a los formularios para ver ejemplos.
Orden de tabulación.
El orden de tabulación describe un orden (lógico) para navegar de vínculo a vínculo o de control de formulario a control de formulario (habitualmente presionando la tecla de tabulación "tab", de aquí el nombre). Consultar ejemplos en la sección Acceso desde el teclado a los formularios.

3.1 Control independiente del dispositivo para interfaces incrustadas

Algunos elementos importan objetos (por ejemplo applets o reproductores multimedia) cuyas interfaces no pueden ser controladas a través del lenguaje de marcado. En tales casos, los desarrolladores deben proporcionar equivalentes alternativos con interfaces accesibles si los propios objetos importados no los proporcionan.

4 Navegación

Puntos de revisión en esta sección:

Un estilo de presentación coherente entre las páginas permite a los usuarios localizar los mecanismos de navegación más fácilmente, pero también permite saltar más rápidamente los mecanismos de navegación para encontrar los contenidos más importantes. Esto ayuda a las personas con discapacidad para el aprendizaje y la lectura, pero también facilita la navegación a todos los usuarios. Si la navegación es mas predecible, esto aumentará la probabilidad de que la gente encuentre la información en un sitio o la evite si así lo desean.

Ejemplos de estructuras que pueden aparecer en el mismo lugar en distintas páginas:

  1. barras de navegación
  2. contenido básico de una página
  3. publicidad

Un mecanismo de navegación crea un conjunto de caminos que el usuario puede seguir en un sitio. El hecho de proporcionar barras de navegación, mapas del sitio y funciones de búsqueda, aumentará la probabilidad de que el usuario consiga la información que busca en un sitio. Si un sitio es en sí mismo altamente visual, resultaría más difícil navegar por la estructura si el usuario no puede hacerse un mapa mental de hacia dónde se dirige o dónde ha estado. Para ayudarlo, los desarrolladores de contenidos deberían describir los mecanismos de navegación. Es crucial que las descripciones y guías de los sitios sean accesibles, pues los usuarios que se han perdido en un sitio dependerán mucho de ellos.

Cuando proporcionan funcionalidad en la búsqueda, los desarrolladores de contenidos deberían ofrecer mecanismos de búsqueda que satisfagan diferentes niveles de habilidad y distintas preferencias. La mayoría de las buscadores piden al usuario que introduzca palabras clave para buscar términos. Los usuarios con dificultades para deletrear o los no familiarizados con el idioma del sitio, tendrán dificultades para encontrar lo que necesitan si la búsqueda requiere una ortografía perfecta. Los mecanismos de búsqueda deberían incluir un revisor de ortografía, ofrecer alternativas de "la mejor opción", búsquedas mediante preguntas, búsquedas por similitud, etc.

5 Comprensión

Puntos de revisión en esta sección:

Las secciones siguientes exponen técnicas para facilitar la comprensión de una página o sitio.

5.1 Estilo de redacción

Las siguientes sugerencias sobre estilos de redacción podrían ayudar a hacer el contenido de un sitio más fácil de leer para todos, y especialmente para las personas con discapacidades para la lectura y/o cognitivas. Muchas guías (incluyendo [HACKER]) exponen éstos y otros aspectos del estilo de redacción con más detalle.

  1. Esfuércese para que los encabezamientos y las descripciones de los vínculos sean claras y precisas. Ello incluye utilizar como vínculos frases concisas que tengan sentido cuando se lean fuera del contexto o como parte de una serie de vínculos (algunos usuarios navegan saltando de vínculo a vínculo y leyendo sólo el texto de estos vínculos). Utilice encabezamientos informativos, de forma que los usuarios puedan revisar rápidamente una página para hallar la información, en lugar de tener que leerla con detalle.
  2. Sitúe el contenido básico al principio de la frase o párrafo (esto es denominado "colocación inicial"). Ello ayudará tanto a la gente que está mirando superficialmente, como a los que usan sintetizadores de voz. "Hojear", aplicado a la voz, significa habitualmente que el usuario salta de encabezamiento a encabezamiento, o de párrafo a párrafo, y escucha sólo las palabras suficientes como para establecer si el trozo de información (encabezamiento, párrafo, vínculo, etc.) le interesa. Si la idea principal del párrafo está en medio o al final del mismo, los usuarios de sintetizadores de voz tendrán que escuchar casi todo el documento para encontrar lo que buscan. Dependiendo de lo que el usuario esté buscando, y de cuánto sepa sobre el tema, las características de búsqueda pueden también ayudar a los usuarios a localizar el contenido más rápidamente.
  3. Limítese a un concepto principal por párrafo.
  4. Evite el uso de argot, jergas y significados particulares de palabras comunes, a no ser que las defina en el propio documento.
  5. Prefiera las palabras de uso común. Por ejemplo, utilice "empezar" mejor que "comenzar" o "intentar" mejor que "procurar".
  6. Utilice verbos en su forma activa mejor que en pasiva.
  7. Evite frases de estructura complicada.

Para ayudar a determinar si su documento es fácil de leer, contemple la posibilidad de usar el índice de dificultad de lectura ("Fog") de Gunning (descrito en [SPOOL] con ejemplos y el algorítmo en [TECHHEAD]). Este algoritmo generalmente produce una puntuación menor cuando el contenido es más fácil de leer. Como demuestra el ejemplo, la Biblia, Shakespeare, Mark Twain y la Guía de Televisión tienen todos un índice Fog de alrededor de 6. El índice Fog medio de los periódicos Time, Newsweek y Wall St. Journal es de alrededor de 11. [NdT].

5.2 Equivalentes multimedia

Para las personas que no leen bien o que no leen en absoluto, los equivalentes multimedia (no textuales) pueden ayudar a facilitar la comprensión. No obstante, tenga en cuenta que las presentaciones multimedia no siempre hacen el texto más comprensible. En ocasiones pueden hacerlo más confuso.

Ejemplos de multimedia que complementan al texto:

  1. Un esquema de los datos complejos, tales como las cifras de negocios del año fiscal anterior.
  2. Una traducción del texto a una presentación animada en lenguaje de señas. El lenguaje de señas es muy diferente de los idiomas verbales. Por ejemplo, algunas personas que pueden comunicarse a través del lenguaje de señas americano, no son capaces de leer inglés americano.
  3. Los sonidos pre-grabados de música, discursos hablados o efectos sonoros pueden también ayudar a los no-lectores que pueden percibir presentaciones auditivas. Si bien el texto puede convertirse en discurso a través del sintetizador de voz, los cambios del tono de la voz del discurso grabado proporcionan información que con el sintetizador de voz se pierde.

6 Negociación del contenido

Puntos de revisión en esta sección:

Hay varias estrategias para permitir al usuario seleccionar el contenido apropiado:

  1. Incluya vínculos a otra versiones del contenido, tales como traducciones. Por ejemplo, el vínculo "Ver la versión francesa de este documento" vincula con la versión en francés.
  2. Indique el tipo de contenido o el idioma a través de marcadores (por ejemplo, en HTML, utilice "type" y "hreflang").
  3. Utilice la negociación del contenido para proporcionar el contenido según lo solicite el cliente. Por ejemplo, proporcione la versión francesa de un documento a los clientes que la piden en francés.

7 Actualización automática de la página

Puntos de revisión en esta sección:

A veces, los desarrolladores de contenidos crean páginas que se renuevan o cambian sin que lo pida el usuario. Esta actualización automática puede resultar muy desorientadora para algunos usuarios. En lugar de ello, los autores deberían (en orden de preferencia):

  1. Configurar el servidor para que utilice el código de estatus HTTP apropiado (301). Es preferible utilizar encabezamientos HTTP porque reduce el tráfico de Internet y el tiempo de descarga, puede ser aplicado a documentos que no sean HTML y puede ser utilizado por aplicaciones que sólo solicitan una petición de HEAD (por ejemplo, los revisores de vínculos). Del mismo modo, los códigos de estado del tipo 30x proporcionan información del tipo "traslado permanente" ("moved permanently") o "traslado temporal" ("moved temporarily"), lo cual no puede ser dado con una actualización desde los META.
  2. Sustituir la página que sería redirigida por una página estática que contenga un vínculo normal a la nueva página.

Nota. Tanto el punto de revisión 7.4 como en el 7.5 tratan problemas con las aplicaciones de usuario antiguas. Las más modernas aplicaciones de usuario deberían desactivar la actualización y sustituirla por un vínculo a la nueva información en el principio de la página.

Encontrará ejemplos desaconsejados en el documento "Técnicas para las Pautas de Accesibilidad al Contenido en la Web 1.0" ("Techniques for Web Content Accessibility Guidelines 1.0" [WCAG10-TECHS]).

8 Destello en la pantalla

Puntos de revisión en esta sección:

Una pantalla parpadeante o con destello puede provocar ataques en usuarios con epilepsia fotosensitiva; por eso, los desarrolladores de contenidos deben evitar causar destello de la pantalla. Los ataques pueden ser provocados por vibraciones o destellos de frecuencia entre 4 y 59 destellos por segundo (hertzios), con una cumbre de sensibilidad en 20 destellos por segundo, así como cambios rápidos de la oscuridad a la luz (como las luces estroboscópicas).

9 Documentos empaquetados

Puntos de revisión en esta sección:

Los documentos empaquetados pueden facilitar la lectura sin conexión. Para crear un paquete coherente:

10 Validación

Esta sección comenta estrategias y técnicas para revisar los documentos Web y determinar los temas de accesibilidad que han sido resueltos y los que no. Estas pruebas deberían resaltar la mayoría de los temas de accesibilidad y son valiosas para reducir un gran número de barreras de accesibilidad. No obstante, algunas de estas estrategias de comprobación sólo reproducen condiciones causadas por una discapacidad; no simulan la experiencia integral que un usuario con discapacidad podría tener. En situaciones reales, sus páginas pueden ser menos manejables de lo que esperaba. Así pues, una de las estrategias recomienda que el desarrollador de contenidos observe a personas con diferentes discapacidades mientras intentan usar una página o sitio.

Si después de completar las siguientes pruebas y reajustar su diseño conforme a ellas, todavía encuentra que su página no es accesible, probablemente debería crear una página alternativa que sea accesible.

Nota. Superar estas pruebas no garantiza su adecuación a las "Pautas de Accesibilidad al Contenido en la Web 1.0".

10.1 Validadores automáticos

Un validador puede verificar la sintaxis de sus páginas (por ejemplo, HTML, CSS, XML). Una sintaxis correcta ayudará a eliminar parte de los problemas de accesibilidad, puesto que el programa procesará más fácilmente los documentos bien formados. Igualmente, algunos validadores pueden advertirle de algunos problemas de accesibilidad basados sólo en la sintaxis (por ejemplo, un documento que haya perdido un atributo o propiedad importante para la accesibilidad). Tenga en cuenta, no obstante, que una correcta sintaxis no garantiza que el documento será accesible. Por ejemplo, usted puede proporcionar un texto equivalente para una imagen de acuerdo con las especificaciones lingüísticas, pero el texto puede ser inexacto o insuficiente. Por tanto, algunos validadores pueden hacerle preguntas y conducirle a aspectos más subjetivos del análisis. Algunos ejemplos de validadores automáticos incluyen:

  1. Una herramienta automatizada de validación de la accesibilidad, tal como Bobby (consultar [BOBBY]).
  2. Un servicio de validación HTML, como el Servicio de validación de HTML de W3C (consultar [HTMLVAL]).
  3. Un servicio de validación de hojas de estilo, como el Servicio de validación de CSS de W3C (consultar [CSSVAL]).

10.2 Herramientas de corrección

Los validadores, normalmente, indican qué aspectos hay que resolver y, a menudo, ofrecen ejemplos de cómo resolverlos. Normalmente no ayudan al autor a afrontar cada problema y resolverlo modificando el documento de forma interactiva. El Grupo de Trabajo de Evaluación y Reparación de WAI ([WAI-ER]) está trabajando para desarrollar una batería de herramientas que ayuden a los autores no sólo a identificar los problemas, sino a resolverlos interactivamente.

10.3 Casos de usuarios

Tenga en cuenta que la mayoría de las aplicaciones de usuario (navegadores) y sistemas operativos permiten a los usuarios cambiar la configuración, los sonidos y la funcionalidad. Con la variedad de aplicaciones de usuario que existen, diferentes usuarios tendrán experiencias muy distintas con la Web. Por tanto:

  1. Revise sus páginas con un navegador sólo-texto como Lynx ([LYNX]) o un simulador de Lynx como el Lynx Viewer ([LYNXVIEW]) o Lynx-me ([LYNXME]).
  2. Utilice varios navegadores gráficos con:
    • sonidos e imágenes cargadas,
    • imágenes no cargadas,
    • sonidos no cargados,
    • sin ratón,
    • marcos, scripts, hojas de estilo y applets no cargados.
  3. Utilice varios navegadores antiguos y nuevos. Nota: Algunos sistemas operativos o navegadores no permiten la instalación múltiple de navegadores en la misma máquina. También puede ser difícil encontrar programas antiguos de navegación.
  4. Utilice otras herramientas, tales como un navegador por voz (por ejemplo [PWWEBSPEAK] y [HOMEPAGEREADER]), un lector de pantalla (por ejemplo [JAWS] y [WINVISION]), programas de ampliación, un dispositivo pequeño, un teclado de pantalla, un teclado alternativo, etc. Nota: Si un sitio Web es usable con uno de estos productos esto no es garantía de que sea usable con otros productos. Para más información sobre una lista detallada de ayudas técnicas utilizadas para acceder a la Web consulte ([ALTBROWSERS]).

10.4 Revisión ortográfica y gramatical

Una persona que lea una página con un sintetizador de voz, puede ser incapaz de comprender la interpretación del sintetizador de una palabra con errores ortográficos. Los revisores gramaticales ayudan a asegurar que el texto de su página es correcto. Ello ayudará a los lectores cuya lengua materna no es la del documento y los que están todavía aprendiendo el idioma del documento. Así ayudará a incrementar la comprensión de su página.

11 Soporte del navegador

Nota: En el momento de escribir este texto, no todos las aplicaciones de usuario soportan algunos de los (nuevos) atributos y elementos de HTML 4.01 [HTML4] que pueden incrementar significativamente la accesibilidad de las páginas Web.

Por favor, consulte el sitio Web de W3C ([WAI-UA-SUPPORT]) para información sobre navegadores y otras aplicaciones de usuario que soportan características de accesibilidad.

En general, tenga en cuenta que las aplicaciones de usuario HTML ignoran los atributos que ellas mismas no reconocen y muestran el contenido de los elementos que no soportan.

12 Evaluación de tecnologías en cuanto a la accesibilidad

Puntos de revisión en esta sección:

Las "Pautas de Accesibilidad al Contenido en la Web 1.0" sugieren utilizar tecnologías W3C en tanto que han sido revisadas teniendo en cuenta la accesibilidad y, además, han sido construidas con características de accesibilidad. Las últimas tecnologías W3C están disponibles en la (página Informes Técnicos y Publicaciones W3C).

Breve panorámica de las actuales tecnologías W3C:

13 Audio y vídeo

[NdT]

14 Información sonora

Puntos de revisión en esta sección:

Las presentaciones sonoras deben ir acompañadas por transcripciones del texto, equivalentes textuales de los eventos sonoros. Cuando estas transcripciones se presentan de forma sincronizada con la presentación visual, se denominan subtítulos [NdT] y son utilizados por las personas que no pueden escuchar la banda sonora del material visual.

Algunos formatos de medios (por ejemplo, QuickTime 3.0 y SMIL) permiten añadir subtítulos y descripciones de las imágenes a los clips multimedia. SAMI permite que se añadan subtítulos. El ejemplo siguiente demuestra que los subtítulos deberían incluir los diálogos y otros sonidos ambientales que ayuden a los espectadores a entender lo que está ocurriendo.

Ejemplo.

Subtítulos para una escena de "E.T.". El teléfono suena tres veces y entonces es respondido.

[suena el teléfono]

[ring]

[ring]

¿Dígame?"

Fin del ejemplo.

Hasta que el formato que está usando soporte bandas alternativas, podría ofrecer dos versiones de la película, una con subtítulos y descripción de las imágenes y otra sin ello. Algunas tecnologías, como SMIL y SAMI, permiten archivos sonoros y visuales separados para combinarlos con los archivos de texto a través del archivo de sincronización para crear audio y películas subtitulados.

Algunas tecnologías también permiten al usuario elegir diferentes tipos de subtítulos para adecuarlos a sus capacidades lectoras. Para más información, vea las especificaciones SMIL 1.0 ([SMIL]).

Pueden proporcionarse equivalentes para los sonidos en forma de una frase de texto en la página, que vincula a una trascripción del texto o una descripción del archivo de sonido. El vínculo hacia la transcripción debería aparecer en un lugar claramente visible, como el principio de la página. De todas maneras, si un script incorpora automáticamente un sonido, debería también disponer de una indicación visual de que el sonido está siendo reproducido y proporcionar una descripción o trascripción del sonido.

Nota: Esta técnica está rodeada de alguna controversia, porque el navegador debería cargar la forma visual de la información en lugar de la forma sonora si así lo han determinado las preferencias del usuario. No obstante, las estrategias deben también funcionar con los navegadores existentes hoy en día.

Para más información, por favor consulte [NCAM].

15 Información visual y movimiento

Puntos de revisión en esta sección:

Las descripciones sonoras de la banda visual proporcionan una narración de los elementos visuales claves sin interferir con el sonido o el diálogo de una película. Los elementos visuales clave incluyen acciones, escenarios, lenguaje corporal, gráficos y el texto mostrado. Las descripciones auditivas son utilizadas, primordialmente, por las personas ciegas para seguir la acción y la información no auditiva en el material visual.

Ejemplo.

He aquí un ejemplo de una trascripción textual completa de una escena de "El Rey León", (disponible en [DVS]). Observe que el narrador proporciona una descripción auditiva de la banda visual y que la descripción ha sido integrada en la transcripción.

Simba: ¡Eh!

Narrador: Simba sale corriendo, seguido por sus padres. Sarabi sonríe y empuja suavemente a Simba hacia su padre. Ambos, uno al lado del otro, observan el amanecer dorado.

Mufasa: Mira, Simba, todo lo que toca la luz es nuestro reino.

Simba: ¡Guau!.

Fin del ejemplo.

Nota. Si no hay información visual importante, por ejemplo, una cabeza parlante animada que describe (a través de discurso pregrabado) cómo utilizar el sitio, no es necesaria una descripción sonora.

Para películas, proporcione descripciones sonoras que estén sincronizadas con el sonido original. Consulte la sección información sonora para más información sobre formatos multimedia.

16 Trascripción textual completa 

Las trascripciones textuales completas permiten el acceso de las personas con discapacidades tanto visuales como auditivas. También proporcionan a cualquier persona la posibilidad de indexar y buscar información contenida en materiales audiovisuales.

Las trascripciones textuales completas incluyen diálogos hablados, así como cualquier otro sonido significativo, aparezca o no en pantalla: música, risas, aplausos. etc. En otras palabras, todo el texto que aparece en subtítulos, así como las descripciones que se proporcionan en la narración sonora.

17 Referencias

Para ver la última versión de cualquier especificación W3C, por favor, consulte la lista de Informes Técnicos de W3C (W3C Technical Reports) en http://www.w3.org/TR.

[HTML4]
"HTML 4.01 Recommendation". Editores: D. Raggett, A. Le Hors e I. Jacobs. 24 de diciembre de 1999. Puede encontrar la Recomendación HTML 4.01 en http://www.w3.org/TR/1999/REC-html401-19991224/.
[PNG]
"PNG (Portable Network Graphics) Specification". Editor: T. Boutell. Contribuyó a la edición: T. Lane. 1 de octubre de 1996. La última versión de PNG 1.0 está disponible en http://www.w3.org/TR/REC-png.
[SMIL]
"Synchronized Multimedia Integration Language (SMIL) 1.0 Specification". Editor: P. Hoschka. 15 de junio de 1998. Puede encontrar la Recomendación SMIL 1.0 en http://www.w3.org/TR/1998/REC-smil-19980615/. La última versión de SMIL 1.0 está disponible en http://www.w3.org/TR/REC-smil.
[WCAG10]
"Web Content Accessibility Guidelines 1.0", Editores W. Chisholm, G. Vanderheiden e I. Jacobs, 5 de mayo de 1999. Puede encontrar esta Recomendación WCAG 1.0 en http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/.
[WCAG10-TECHS]
"Techniques for Web Content Accessibility Guidelines 1.0". Editores W. Chisholm, G. Vanderheiden e I. Jacobs. Este documento explica como aplicar los puntos de revisión definidos en las "Pautas de Accesibilidad al Contenido en la Web 1.0" (Web Content Accessibility Guidelines 1.0). El último borrador de las técnicas esta disponible en http://www.w3.org/TR/WCAG10-TECHS/.

18 Recursos

Nota: W3C no puede garantizar la estabilidad de cualquiera de las siguientes referencias que se encuentran fuera de su control. Estas referencias están incluidas por conveniencia. Las referencias a estos productos no suponen un respaldo a los mismos.

18.1 Otras pautas

[HACKER]
Hacker, Diana. (1993). A Pocket Style Manual. St. Martin's Press, Inc. 175 Fifth Avenue, New York, NY 10010.
[SPOOL]
Spool, J.M., Sconlong, T., Schroeder, W., Snyder, C., DeAngelo, T. (1997). Web Site Usability: A Designer's Guide User Interface Engineering, 800 Turnpike St, Suite 101, North Andover, MA 01845.
[UWSAG]
"The Unified Web Site Accessibility Guidelines", G. Vanderheiden, W. Chisholm, eds. The Unified Web Site Guidelines fue compilado por Trace R & D Center en la Universidad de Wisconsin con financiación del National Institute on Disability and Rehabilitation Research (NIDRR),  U.S. Dept. of Education.
[WALSH]
Walsh, Norman. (1997). "A Guide to XML." En "XML: Principles, Tools, and Techniques." Editor Dan Connolly. O'Reilly & Associates, 101 Morris St, Sebastopol, CA 95472. pp 97-107.

18.2 Aplicaciones de usuario y otras herramientas

El sitio de WAI en la Web mantiene una lista de navegadores Web alternativos (ayudas técnicas y otras aplicaciones de usuario diseñadas para la accesibilidad).

[ALTBROWSERS]
"Alternative Web Browsing". Esta página incluye un listado de algunas características de accesibilidad (incluidas las ayudas técnicas) que algunas aplicaciones de usuario proporcionan. La página está disponible en http://www.w3.org/WAI/References/Browsing.
[BOBBY]
Bobby es una herramienta de validación automática de la accesibilidad desarrollada por Cast.
[CSSVAL]
Servicio de validación de hojas de estilo de W3C (W3C CSS Validation Service).
[HOMEPAGEREADER]
Home Page Reader de IBM.
[HTMLVAL]
Servicio de validación de código HTML de W3C (W3C HTML Validation Service).
[JAWS]
Lector de pantalla JAWS de Freedom Scientific.
[LYNX]
Lynx es un navegador sólo texto.
[LYNXME]
Lynx-me es un emulador de Lynx.
[LYNXVIEW]
Lynx Viewer es un emulador de Lynx.
[PWWEBSPEAK]
El pwWebSpeak de Productivity Works.
[WAI-UA-SUPPORT]
Apoyo para la accesibilidad de las aplicaciones de usuario (User Agent Support for Accessibility).
[WINVISION]
WinVision de Artic.

18.3 Recursos de accesibilidad

[DVS]
DVS Descriptive Video Services.
[NCAM]
El National Center for Accessible Media incluye información sobre subtitulado y audio descripción en la Web.
[TECHHEAD]
Tech Head proporciona alguna información sobre el Fog Index descrito en [SPOOL].
[WAI-ER]
Grupo de Trabajo de Evaluación y Reparación de WAI (WAI Evaluation and Repair Working Group).

19 Agradecimientos

Co-directores del Grupo de Trabajo de las Pautas del Contenido:
Jason White, University of Melbourne
Gregg Vanderheiden, Trace Research and Development
Contacto con el equipo W3C:
Wendy Chisholm
Nuestro agradecimiento a las siguientes personas que han contribuido con su tiempo y sus valiosos comentarios a dar forma a estas pautas:
Harvey Bingham, Kevin Carey, Chetz Colwell, Neal Ewers, Geoff Freed, Al Gilman, Larry Goldberg, Jon Gunderson, Eric Hansen, Phill Jenkins, Leonard Kasday, George Kerscher, Marja-Riitta Koivunen, Josh Krieger, Chuck Letourneau, Scott Luebking, William Loughborough, Murray Maloney, Charles McCathieNevile, MegaZone (Livingston Enterprises), Masafumi Nakane, Mark Novak, Charles Oppermann, Mike Paciello, David Pawson, Michael Pieper, Greg Rosmaita, Liam Quinn, Dave Raggett, T.V. Raman, Robert Savellis, Jutta Treviranus, Steve Tyler y Jaap van Lelieveld

Icono conformidad nivel Triple-A, pautas de Accesibilidad en la Web 1.0 W3C-WAI Validado XHTML 1.0! Validado CSS.