Traducciones:Esta traducción se concluyó, el 9 de abril de 2001.
Los posibles errores presentes en este documento, debidos a la traducción, son responsabilidad de la traductora y no son achacables en modo alguno al W3C. Para cualquier comentario sobre la traducción dirigirse a Emmanuelle Gutiérrez y Restrepo.
La única versión normativa oficial de este documento es la versión original (en inglés):
http://www.w3.org/TR/2000/NOTE-WCAG10-CORE-TECHS-20001106/
Copyright ©1999 - 2000 W3C® (MIT, INRIA, Keio), Todos los derechos reservados. W3C responsabilidad, marca registrada, uso del documento y normas de aplicación de la licencia de software .
Este documento describe técnicas para crear contenido accesible, que pueda usarse con distintas tecnologías. Intenta ayudar a los autores de contenido Web que desean reivindicar la conformidad con las "Pautas de Accesibilidad del Contenido Web 1.0" ([WCAG10]). En tanto que las técnicas en este documento pueden ayudar a los autores de contenido Web a ajustarse a las "Pautas de Accesibilidad del Contenido Web 1.0", estas técnicas ni garantizan la conformidad ni son la única manera de que un autor pueda producir contenido conformado.
Este documento es parte de una serie de documentos sobre técnicas para la autoría de contenido Web accesible. Para obtener información sobre los otros documentos de la serie vea, por favor, las "Técnicas para aplicar las Pautas de Accesibilidad del Contenido Web 1.0" [WCAG10-TECHS].
Esta versión ha sido publicada para corregir algunos enlaces truncados de la versión anterior.
La versión del 6 de noviembre de 2000 de este documento es una Nota en una serie de Notas producidas y firmadas por el Web Content Accessibility Guidelines Working Group (WCAG WG). Esta nota no ha sido revisada o firmada por miembros del W3C. Las series de documentos reemplazan al documento único 5 May 1999 W3C Note Techniques for Web Content Accessibility Guidelines 1.0. Los temas del documento anterior han sido separados en documentos específicos para cada tecnología, y pueden evolucionar independientemente. Los documentos cortos y específicos para cada tecnología permiten a los autores centrarse en una tecnología particular.
Mientras que las "Web Content Accessibility Guidelines 1.0" Recommendation [WCAG10] son un documento estable, se espera que esta serie de documentos agregados evolucione según cambian las tecnologías y los desarrolladores de contenido descubren técnicas más efectivas para el diseño de contenido Web accesible.
El historial de cambios de la serie de documentos así como la lista de temas abiertos y cerrados están disponibles. Se alienta a los lectores a comentar el documento y proponer soluciones a los problemas actuales. Envíe, por favor, los comentarios detallados sobre este documento al Grupo de Trabajo a w3c-wai-gl@w3.org; los archivos públicos están disponibles.
La versión inglesa de esta especificación es la única versión normativa. Hay traducciones de este documento disponibles.
La lista de errores conocidos de este documento está disponible en "Erratas en Pautas para la accesibilidad del contenido Web." Por favor, informe sobre los errores que encuentre en este documento a wai-wcag-editor@w3.org.
La Web Accessibility Initiative (WAI) del World Wide Web Consortium (W3C) ofrece una variedad de recursos sobre accesibilidad de la Web. Las Pautas de Accesibilidad del WAI forman parte de la producción de la WAI Technical Activity. El objetivo del Grupo de Trabajo sobre Pautas de Accesibilidad del Contenido Web se describe en los estatutos.
Una lista de Recomendaciones actuales del W3C y de otros documentos técnicos está disponible.
Puntos de control en esta sección:
Al diseñar un documento o una serie de documentos, los desarrolladores de contenidos deben esforzarse en identificar primero la estructura deseada para sus documentos, antes de pensar sobre cómo será presentado el documento al usuario. Distinguir la estructura de cómo se presenta el contenido ofrece numerosas ventajas, incluyendo la mejora de la accesibilidad, manejabilidad y su uso en distintas plataformas.
Identificar qué es estructura y qué es presentación puede ser un desafío a veces, por ejemplo, muchos desarrolladores de contenido consideran que una línea horizontal comunica una división estructural. Esto puede ser cierto para los usuarios que ven, pero para los usuarios ciegos o con navegadores no gráficos una línea horizontal puede no significar nada. Por ejemplo, los desarrolladores de contenido en HTML deben usar los elementos de encabezado de HTML 4.01 [HTML4] para identificar nuevas secciones. Esto puede ser complementado por indicadores visuales o de otro tipo tales como líneas horizontales, pero no debe ser reemplazado por ellos.
Y viceversa: los desarrolladores de contenidos no deben usar elementos estructurales para conseguir efectos de presentación. Por ejemplo, aunque en HTML el elemento BLOCKQUOTE provoca un sangrado del texto en algunos navegadores, está diseñado para identificar una cita, no para crear un efecto de presentación. Utilizar el elemento BLOCKQUOTE para sangrar confunde a los usuarios y robots de búsqueda, los cuales esperan que el elemento se haya usado para marcar un bloque de texto que contiene una cita.
En los documentos XML la separación entre presentación y estructura es inherente. Tal como declara Norman Walsh en "Guía de XML" [WALSH],
Los programas lectores de HTML son muy inflexibles. Un título de primer nivel aparece de esta manera debido a que los navegadores reconocen la etiqueta H1. Por el contrario, puesto que los documentos XML no tienen ninguna etiqueta fija puesta, ese planteamiento no funcionará. La presentación de un documento XML depende de una hoja de estilos.
¡Breve Test! Para determinar si el contenido es estructural o de presentación, cree una sinopsis de su documento. Cada punto en la jerarquía denota un cambio estructural. Emplee marcadores estructurales para marcar esos cambios y marcadores de presentación para hacerlos más aparentes sonora y visualmente. Advierta que las líneas de división horizontal no aparecen en esa sinopsis y además no son estructurales sino elementos de presentación. Nota. Este pequeño test presenta la estructura en capítulos, secciones y párrafos. Para determinar la estructura entre frases, busque las abreviaturas, cambios de idioma, definiciones e ítems de lista.
Puntos de control en esta sección:
El texto se considera accesible para la mayoría de los usuarios ya que puede ser manejado por los lectores de pantalla, navegadores no visuales, y lectores de braille. Puede ser representado visualmente, agrandado, sincronizado con un vídeo para crear un subtítulo, etc. Cuando diseñe un documento que contiene información no textual (imágenes, applets, sonidos, presentaciones multimedia, etc.) complemente esa información con equivalentes en formato texto siempre que sea posible.
Cuando al usuario se le presenta un equivalente en formato texto, éste cumple esencialmente la misma función, en lo posible, que el contenido original. Para un contenido simple, un equivalente textual sólo necesita describir la función o propósito del contenido. Para un contenido complejo (diagramas, gráficas, etc.), el texto equivalente puede ser más largo e incluir información descriptiva.
Es indispensable proporcionar equivalentes en formato texto para logotipos, fotos, botones de aceptación, applets, viñetas en listas, ASCII art, y para todos los enlaces en un mapa de imagen, así como para las imágenes invisibles usadas para disponer la presentación de la página.
¡Breve test! Un buen test para determinar si un equivalente en formato texto es útil, es imaginarse leyendo el documento a alguien a través del teléfono. ¿Qué diría usted cuando encuentra esa imagen para hacer comprensible la página a quien le escucha?
Cómo se especifica un equivalente en formato texto depende del lenguaje del documento.
Por ejemplo, dependiendo del elemento, HTML permite a los desarrolladores de contenido especificar un equivalente textual a través de los atributos ( "alt" o "longdesc") o en el contenido del elemento (el elemento OBJECT).
Los formatos de vídeo, tales como QuickTime, permitirán a los desarrolladores incluir una variedad de pistas alternativas de audio y vídeo. SMIL ([SMIL]) permite a los desarrolladores sincronizar clips alternativos de audio y vídeo, y archivos de texto con cada uno.
En la creación de DTDs en XML, asegúrese de que los elementos que pueden necesitar una descripción, tienen alguna manera de ser asociados con la descripción.
Algunos formatos de imagen permiten integrar texto en el fichero de datos, junto con la información de la imagen. Si un formato de imagen soporta tal texto (Ej., vea Portable Network Graphics [PNG]) los desarrolladores de contenido pueden suministrar información ahí también.
Los desarrolladores de contenido deben considerar la compatibilidad retroactiva cuando diseñan páginas Web o sitios, ya que:
Consecuentemente, cuando diseñe teniendo en cuenta viejas tecnologías, considere estas técnicas:
Puntos de control en esta sección:
A pesar de que es posible hacer accesible la mayoría del contenido, puede ocurrir que parte o toda la página permanezca inaccesible. Otras técnicas para crear alternativas accesibles incluyen:
Presentamos dos técnicas para enlazar con una página alternativa:
Puntos de control en esta sección:
No todos los usuarios tienen un entorno gráfico con ratón u otro dispositivo apuntador. Algunos usuarios dependen del teclado, del teclado alternativo o de la voz, para activar los enlaces de navegación, los controles de formularios, etc. Los desarrolladores de contenido deben asegurarse de que los usuarios pueden interactuar con una página con dispositivos distintos a los dispositivos apuntadores. Una página diseñada para el acceso por teclado (además del acceso por ratón) será, generalmente, accesible a los usuarios con otro tipo de dispositivos de entrada. Lo que es más, diseñando una página para acceder con el teclado, usualmente mejorará también su diseño en general.
El acceso a los enlaces y controles de formulario por teclado puede ser especificado de varias maneras:
Algunos elementos importan objetos (Ej., applets o programas multimedia) cuyas interfaces no pueden ser controladas a través del lenguaje de marcado. En tales casos, los desarrolladores de contenido deben proporcionar equivalentes alternativos con interfaces accesibles, si los objetos importados no pueden ofrecer interfaces accesibles ellos mismos.
Puntos de control en esta sección:
Un estilo de presentación consistente en cada página, permite a los usuarios localizar mecanismos de navegación más fácilmente y también saltarse fácilmente los mecanismos de navegación para encontrar el contenido importante. Esto ayuda a las personas con problemas de aprendizaje y lectura, pero también hace la navegación más fácil para todos los usuarios. La predecibilidad incrementará la probabilidad de que las personas encuentren información en su sitio o evitarla cuando lo deseen.
Ejemplos de estructuras que pueden aparecer en el mismo lugar en todas las páginas:
Un mecanismo de navegación crea una serie de rutas que el usuario puede tomar a través de su sitio. Proporcionando barras de navegación, mapas del sitio, y sistemas de búsqueda, se incrementa la posibilidad de que un usuario alcance la información que está buscando en su sitio. Si su sitio es de naturaleza altamente visual, la estructura puede ser difícil de navegar si el usuario no puede formarse un mapa mental de hacia dónde está yendo o de dónde está. Para ayudarle, los desarrolladores de contenido deben describir algún mecanismo de navegación. Es crucial que las descripciones y las guías del sitio sean accesibles, ya que las personas que están perdidas en su sitio dependen mucho de ello.
Cuando se ofrecen funcionalidades de búsqueda, los desarrolladores de contenido deben ofrecer mecanismos de búsqueda que satisfagan varios de niveles de habilidad y preferencias. La mayoría de las utilidades de búsqueda requieren que el usuario indique palabras clave para buscar términos. Los usuarios con dificultades para deletrear y aquellos para los que no les es familiar el lenguaje de su sitio, tendrán dificultades a la hora de encontrar lo que necesitan si el buscador exige una ortografía perfecta. Los procesadores de búsqueda deben incluir un revisor ortográfico, ofrecer la "mejor presunción" como alternativa, ejemplos de búsquedas, búsquedas por similitud, etc.
Puntos de control en esta sección:
La siguiente sección examina técnicas para ayudar a la comprensión de una página o sitio.
Las siguientes sugerencias de estilo de escritura pueden ayudar a hacer el contenido de su sitio fácil de leer para cualquiera, especialmente para personas con discapacidad para la lectura o cognitiva. Algunas guías (incluyendo [HACKER]) examinan estos y otros problemas de estilo de escritura más detalladamente.
Para ayudarle a determinar si su documento es fácil de leer, considere usar el medidor de lectura Gunning-Fog (que se describe en [SPOOL] con ejemplos y el algoritmo disponible en Internet en [TECHHEAD]). Este algoritmo produce generalmente una puntuación baja cuando el contenido es fácil de leer. Como ejemplo, los resultados de la Biblia, Shakespeare, Mark Twain, y la Guía de Televión obtienen un índice "Fog" cercano al 6. Los diarios Time, Newsweek y el Wall St. Journal obtienen un índice Fog promedio cerano al 11.
Para las personas que no leen bien o nada en absoluto, los equivalentes multimedia (sin texto) pueden ayudar facilitando la comprensión. Tenga en cuenta que las presentaciones multimedia no siempre hacen fácil de entender el texto, a veces, pueden hacerlo más confuso.
Ejemplos de multimedia que el texto complementa:
Puntos de control en esta sección:
Hay una variedad de estrategias para permitir a los usuarios seleccionar el contenido apropiado:
Puntos de control en esta sección:
A veces los desarrolladores de contenido crean páginas que se refrescan o cambian sin que los usuarios lo soliciten. Este refresco automático puede ser muy desorientador para algunos usuarios. En vez de ello, en orden de preferencia, los autores pueden:
Nota. Tanto el punto de control 7.4 como el punto de control 7.5 se aplican a problemas heredados del navegador. Los nuevos navegadores pueden deshabilitar el refresco y sustituirlo por un enlace a nueva información en la parte superior de la página.
En las "Técnicas para las Pautas de Accesibilidad del Contenido Web 1.0" se proporcionan ejemplos desaprobados. [WCAG10-TECHS].
Puntos de control en esta sección:
Una pantalla parpadeante o destellante puede causar ataques en usuarios con epilepsia foto sensitiva y por eso los desarrolladores de contenidos deben evitar causar que la pantalla parpadee. Los ataques pueden ser desencadenados por parpadeos o destellos con un rango de 4 a 59 destellos por segundo (Hercios) con un pico de sensibilidad en los 20 destellos por segundo, así cómo por los cambios rápidos de oscuridad a luz (como con las luces estroboscópicas).
Puntos de control en esta sección:
Enlazar los documentos puede facilitar la lectura sin conexión a Internet. Para crear un paquete coherente:
Esta sección plantea estrategias y técnicas para examinar documentos Web y determinar los problemas de accesibilidad que han sido resueltos y aquellos que no lo han sido. Estas pruebas deben destacar los principales problemas de acceso y son valiosas para la reducción de numerosas barreras de accesibilidad. Sin embargo, algunos de estos escenarios de prueba sólo replican condiciones causadas por una discapacidad; no simulan la experiencia completa que puede tener un usuario con discapacidad. En la vida real sus páginas pueden ser menos usables de lo que usted espera. Por eso, una de las estrategias recomendadas es que los desarrolladores de contenidos observen a personas con diferentes discapacidades intentando usar una página o sitio.
Si después de terminar la siguiente prueba y de ajustar su diseño de acuerdo a ella, encuentra que una página sigue siendo no accesible, es probable que usted deba crear una página alternativa que sea accesible.
Nota. Pasar estas pruebas no garantiza la conformidad con las "Pautas de Accesibilidad del Contenido Web 1.0".
Un revisor puede verificar la sintaxis de sus páginas (Ej., HTML, CSS, XML). Una sintaxis correcta ayudará a eliminar numerosos problemas de accesibilidad pues los programas pueden procesar más fácilmente documentos bien formados. También, algunos revisores pueden advertirle sobre algunos problemas de accesibilidad basados sólo en la sintaxis (Ej., un documento que carece de un atributo o propiedad que es importante para la accesibilidad). Advierta, sin embargo, que la sintaxis correcta no garantiza que un documento sea accesible. Por ejemplo, si usted ofrece un texto equivalente para una imagen acorde con la especificación de lenguaje, pero el texto es inadecuado o insuficiente. Algunos revisores le preguntarán y le guiarán a través de partes subjetivas del análisis. Algunos ejemplos de revisores automáticos incluyen:
Los revisores normalmente informan sobre los problemas que hay que resolver y hasta dan ejemplos de cómo resolverlos. Normalmente no ayudan al autor guiándole a través de cada problema y ayudándole a modificar el documento interactivamente. El Grupo de Trabajo de Evaluación y Reparación del WAI ([WAI-ER]) está trabajando para desarrollar una serie de herramientas que ayudarán a los autores no sólo a identificar los problemas sino también a resolverlos interactivamente.
Mantener en mente que la mayoría de las aplicaciones de usuario (navegadores) y los sistemas operativos, permiten a los usuarios configurar características que cambian la apariencia de los programas, los sonidos, y funcionamientos. Con la variedad de navegadores existentes, distintos usuarios tendrán experiencias muy diferentes con la Web. Por tanto:
Una persona leyendo una página con un sintetizador de voz, puede no ser capaz de descifrar la mejor predicción del sintetizador sobre una palabra que tiene un error ortográfico. Los revisores de gramática ayudarán a garantizar que el contenido textual de su página sea correcto. Esto ayudará a lectores para los que su documento no está escrito en su lengua nativa o a personas que están aprendiendo el idioma del documento. De este modo usted ayudará a incrementar la comprensión de su página.
Note. En el momento en que esto se escribe, no todos los navegadores soportan algunos de los atributos y elementos de HTML 4.01 [HTML4] que pueden incrementar significativamente la accesibilidad de las páginas Web.
Por favor, vaya al sitio Web del W3C ([WAI-UA-SUPPORT]) para obtener información sobre soporte de características de accesibilidad de navegadores y otras aplicaciones.
En general, no deje de tener en cuenta que los navegadores ignoran los atributos HTML que no soportan y que, representan el contenido de elementos no soportados.
Puntos de control en esta sección:
Las "Pautas de Accesibilidad del Contenido Web 1.0" sugieren utilizar las tecnologías del W3C ya que han considerado problemas de accesibilidad y además han sido construidas con características de accesibilidad. Las últimas versiones de las tecnologías del W3C están disponibles en la página sobre Informes técnicos y publicaciones del W3C.
Relación concisa de las actuales tecnologías del W3C:
Puntos de control en esta sección:
Las presentaciones sonoras deben ir acompañadas de transcripciones en texto, equivalentes textuales de los eventos sonoros. Cuando esas transcripciones se presentan sincrónicamente con una presentación en vídeo se llaman subtítulos y son utilizadas por personas que no pueden oír la pista de audio del material de vídeo.
Algunos formatos de multimedia (Ej., QuickTime 3.0 y SMIL) permiten añadir subtítulos y descripciones de vídeo a los fotogramas de la presentación multimedia. SAMI permite añadir subtítulos. El siguiente ejemplo demuestra que los subtítulos deben incluir tanto la voz como otros sonidos de ambiente que ayudan a quienes los ven a entender qué está pasando.
Ejemplo.
Subtítulos para una escena de "E.T.". El teléfono suena tres veces, entonces es respondido.
[repique del teléfono]
[ring]
[ring]
¿Diga?"
Fin del ejemplo.
Hasta que el formato que usted usa soporte pistas alternativas, puede habilitar dos versiones de la película, una con subtítulos y descripción de vídeo y otra sin ellos. Algunas tecnologías tales como SMIL y SAMI, permiten combinar ficheros separados de audio/vídeo y ficheros de texto, a través de un archivo de sincronización para crear subtítulos de audio y películas.
Algunas tecnologías también permiten al usuario elegir entre múltiples series de subtítulos de acuerdo con su destreza en la lectura. Para más información vea la especificación de SMIL 1.0 ([SMIL]).
Los equivalentes sonoros se pueden ofrecer en forma de frases en la página, que enlazan con una transcripción o descripción del fichero sonoro. El enlace a la transcripción debe aparecer en un lugar visiblemente destacado, tal como al principio de la página. Sin embargo, si un script descarga automáticamente un sonido, debe también ser capaz de descargar, automáticamente, una indicación visual de que el sonido se está ejecutando, y ofrecer una descripción o transcripción del sonido.
Nota. Esta técnica está envuelta en alguna controversia, debido a que el navegador debería descargar la forma visual de la información en vez de la forma sonora, si las preferencias de usuario han sido configuradas para hacerlo así. Sin embargo, las estrategias deben funcionar también con los navegadores de hoy en día.
Para más información refiérase a [NCAM].
Puntos de control en esta sección:
Las descripciones sonoras de la pista visual, proporcionan una narración de los elementos visuales clave, sin interferir con el sonido o los diálogos de una película. Los elementos visuales clave incluyen las acciones, puesta en escena, lenguaje del cuerpo, gráficos y texto representado. Las descripciones sonoras, las usan principalmente personas ciegas para seguir la acción y otras informaciones no sonoras en el material de vídeo.
Ejemplo.
Aquí hay un ejemplo de transcripción textual intercalada de una escena de "El Rey León" (disponible en [DVS]). Advierta que quien describe está proporcionando la descripción sonora de la pista de vídeo y que la descripción ha sido integrada en la transcripción.
Simba: Yeah!
Descriptor: Simba sale corriendo, seguido por sus padres. Sarabi sonríe y empuja suavemente con el codo a Simba hacia su padre. Los dos, sentados uno junto al otro, cotemplan la dorada puesta de sol.
Mufasa: Mira Simba, todo lo que está iluminado es nuestro reino.
Simba: ¡Oh!.
Fin del ejemplo.
Nota. Si no hay información visual importante, por ejemplo, un busto parlante animado que describe (a través de un discurso pre grabado) cómo usar el sitio, entonces, una descripción sonora es innecesaria.
Para las películas, proporcione descripciones sonoras sincronizadas con el audio original. Véase la sección sobre información sonora para obtener más información sobre formatos multimedia.
Las transcripciones textuales intercaladas permiten el acceso por parte de personas con discapacidades tanto visuales como auditivas. También proporcionan a cualquiera la posibilidad de indexar y buscar información contenida en materiales audiovisuales.
Las transcripciones textuales intercaladas incluyen los diálogos hablados, así como cualquier otro sonido significativo incluyendo los sonidos en pantalla y en off, la música, risas, aplausos, etc. En otras palabras, todo el texto que aparece en los subtítulos así como todas las descripciones que proporciona la descripción sonora.
Para ver la última versión de cualquier especificación del W3C consulte, por favor, la lista de Informes Técnicos del W3C en http://www.w3.org/TR.
Nota: El W3C no garantiza la estabilidad de ninguna de las siguientes referencias que están fuera de su control. Estas referencias se incluyen por comodidad. Las referencias de productos no significan un respaldo a los mismos.
En el sitio Web del WAI se mantiene una lista de Navegadores Web alternativos (tecnologías adaptativas y otras aplicaciones de usuario diseñadas para la accesibilidad).
