Web accesible - Documentos para el diseño accesible... - Introducción - Técnicas - Técnicas fundamentales
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
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.
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].
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.
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.
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?
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í.
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:
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:
He aquí dos técnicas para vincular a una página accesible:
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:
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.
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:
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.
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.
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.
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].
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:
Puntos de revisión en esta sección:
Hay varias estrategias para permitir al usuario seleccionar el contenido apropiado:
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):
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]).
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).
Puntos de revisión en esta sección:
Los documentos empaquetados pueden facilitar la lectura sin conexión. Para crear un paquete coherente:
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".
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:
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.
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:
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.
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.
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:
[NdT]
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].
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.
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.
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.
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.
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).
Principal - Accesibilidad - Artículos - CIF - Legislación - Recomendamos - Recursos - Web accesible - Acerca de... - El autor
Este sitio trata de ser accesible para todos. Si encuentras
problemas al navegarlo, no dudes en ponerte en contacto con nosotros en:
disweb2000@ono.com.
Dirección de esta página: http://usuarios.discapnet.es/disweb2000/WCAG2003/tecnicas/core/WCAG10-CORE-TECHS-20001106.html