ACTIVIDADES APLICACIONES SOFTWARE

RECURSOS ONLINE Y EN PAPEL

DOCUMENTOS

Deja tus comentarios haciendo clic en nuestro Libro de Visitas o a través de nuestro Blog

Puedes contactar con nosotros en la siguiente dirección:

ardilladigital

@hotmail.com

[D]
Diseño Accesible de Páginas Web.

Web accesible - Portada -  Introducción - Pautas.

Pautas de Accesibilidad del Contenido en la Web 1.0

RECOMENDACIÓN W3C de 5 de mayo de 1999.

Esta versión, original en inglés:

• http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505.

Editores:

• Wendy Chisholm, Trace R & D Center, University of Wisconsin - Madison.
• Gregg Vanderheiden, Trace R & D Center, University of Wisconsin - Madison.
• Ian Jacobs, W3C.

Nota de los traductores:

Esta traducción ha recibido contribuciones de algunos de los miembros del Grupo de Expertos del Seminario de Iniciativas sobre Discapacidad y Accesibilidad en la Red (SIDAR).

Para comunicar errores de esta traducción o proponer comentarios a la misma, envíe un mensaje a los traductores.

Copyright (c) 1999 W3C ( MIT, INRIA , Keio), Reservados todos los derechos.

RESUMEN.

Este es un documento de referencia en cuanto a principios de accesibilidad e ideas de diseño. Algunas de las estrategias planteadas en este documento tratan ciertos temas concernientes a la Internacionalización de la Web y al acceso desde dispositivos móviles. Sin embargo, este documento se centra en la accesibilidad y no trata totalmente lo relacionado con otras Actividades del W3C. Por favor consulte la página principal de las Actividades de Acceso des de Dispositivos Móviles de W3C y la página principal de Actividades de Internacionalización de la W3C para mayor información.

Este documento está concebido para ser definitivo, y por tanto no proporciona información específica sobre soportes de navegador para las diferentes tecnologías, puesto que esta información cambia rápidamente. En su lugar, la "Iniciativa de Accesibilidad a la Web - WAI" proporciona esa información (consulte [WAI-UA-SUPPORT]).

Este documento incluye un apéndice que organiza todos los puntos de verificación por temas y prioridad. Los puntos de verificación en el apéndice enlazan con sus definiciones en el presente documento. Los temas identificados en el apéndice incluyen imágenes, multimedia, tablas, marcos, formularios y scripts. El apéndice esta disponible tanto en forma de tabla resumen de puntos de verificación, como en forma de una simple lista de puntos de verificación.

Un documento a parte, titulado "Técnicas para las Pautas de Accesibilidad del Contenido en la Web 1.0" ([TECHNIQUES]), explica como aplicar los puntos de verificación definidos en este documento. El documento de Técnicas trata cada punto de verificación con más detalle y proporciona ejemplos usando el Lenguaje de Marcado de Hipertexto (HTML), las Hojas de Estilo en Cascada (CSS), el Lenguaje de Integración Multimedia Sincronizada (SMIL) y el Lenguaje de Marcado Matemático (MathML). El documento de Técnicas también incluye técnicas para la validación y análisis de documentos y un índice de elementos y atributos de HTML (y cuales son las técnicas para usarlos). El documento de Técnicas ha sido diseñado para seguir los cambios en la tecnología y es de esperar que sea renovado con más frecuencia que el presente documento.

NOTA: No todos los navegadores y herramientas multimedia pueden soportar las características descritas en estas pautas. En particular, las nuevas características de HTML 4.0, CSS 1 y CSS 2 pueden no ser soportadas.

Este documento es parte de una serie de pautas de accesibilidad publicadas por la Iniciativa para la Accesibilidad de la Web. Esta serie incluye también las Pautas de Accesibilidad de las Aplicaciones de Usuario [WAI-USERAGENT] y las Pautas de Accesibilidad para Herramientas de Autor [WAI-AUTOOLS].

ESTATUS DE ESTE DOCUMENTO.

La versión inglesa de esta especificación es la única versión normativa. Sin embargo, traducciones en otras lenguas pueden verse en:
http://www.w3.org/WAI/GL/WAI-WEBCONTENT-TRANSLATIONS .

La lista de errores conocidos de este documento (en inglés) está disponible en:
http://www.w3.org/WAI/GL/WAI-WEBCONTENT-ERRATA .

Por favor, remita los errores que detecte en este documento a:
wai-wcag-editor@w3.org .

La lista de las actuales Recomendaciones del W3C y otros documentos técnicos pueden encontrarse en:
http://www.w3.org/TR .

Este documento ha sido producido como parte de la Iniciativa para la Accesibilidad de la Web del W3C. El objetivo del Grupo de Trabajo de las Pautas de Contenido en la Web se explica en los estatutos de constitución del Grupo de Trabajo .
 
 

TABLA DE CONTENIDOS.

Estatus del documento.

1. Introducción.
2. Motivos del diseño accesible.

2.1 Asegurar una transformación airosa.
2.2 Hacer comprensible y navegable el contenido.
3. Cómo están organizadas las pautas.

3.1 Convenciones del documento.
4. Prioridades.
5. Conformidad.
6. Pautas de Accesibilidad del Contenido en la Web. 

1- Proporcione alternativas para los contenidos visuales y auditivos.
2- No se base sólo en el color.
3- Utilice marcadores y hojas de estilo y hágalo apropiadamente.
4- Identifique el lenguaje natural usado.
5- Cree tablas que se transformen correctamente.
6- Asegure que las páginas que incorporen nuevas tecnologías se transformen correctamente.
7- Asegure al usuario el control sobre los cambios de los contenidos tempo-dependientes.
8- Asegure la accesibilidad directa de las interfaces incrustadas.
9- Diseñe teniendo en cuenta diversos dispositivos.
10- Utilice soluciones provisionales.
11- Utilice las tecnologías y pautas W3C.
12- Proporcione información de contexto y orientación.
13- Proporcione mecanismos claros de navegación.
14- Asegurar que los documentos sean claros y simples.

El apéndice con la lista de puntos de verificación esta disponible como una tabla resumen de puntos de verificación o como una lista simple de puntos de verificación.

1. INTRODUCCIÓN.

• Pueden no ser capaces de ver, escuchar, moverse o pueden no ser capaces de procesar algunos tipos de información fácilmente o en absoluto.
• Pueden tener dificultad en la lectura o comprensión de un texto.
• No tienen porqué tener o ser capaces de usar un teclado o un ratón.
• Pueden tener una pantalla que sólo presenta texto, una pantalla pequeña o una conexión lenta a INTERNET.
• Pueden no hablar o comprender con fluidez la lengua en la que esté redactado el documento.
• Pueden encontrarse en una situación en la que sus ojos, oídos o manos estén ocupados u obstaculizados (Ej. conduciendo un automóvil, trabajando en un entorno ruidoso,...)
• Pueden tener una versión anterior del navegador, un navegador completamente diferente, un navegador de voz o un sistema operativo distinto.

Las pautas tratan los aspectos de accesibilidad y proporcionan soluciones de diseño accesibles. Indican situaciones habituales (similares al ejemplo de estilo de fuentes) que puedan suponer problemas a los usuarios con ciertas discapacidades. Por ejemplo, la primera pauta explica como los desarrolladores pueden crear imágenes accesibles. Algunos usuarios pueden no ser capaces de ver imágenes, otros utilizar navegadores basados en formato texto que no soportan imágenes, en tanto que otros pueden haber desconectado el soporte para imágenes (por ejemplo, debido a una conexión lenta con INTERNET). Las pautas no sugieren que se eviten las imágenes como medio para mejorar la accesibilidad, sin embargo, explican como proporcionando un texto equivalente de la imagen se hará accesible.

¿Cómo hace accesible a la imagen un texto equivalente? Ambas palabras "texto equivalente" son importantes.

• El contenido del texto puede ser presentado al usuario como una voz sintetizada, en braille y en texto visiblel. Cada uno de estos tres mecanismos utiliza un sentido diferente (oído para la síntesis de voz, tacto para el braille o vista para el texto visible) haciendo la información accesible a grupos representativos de una variedad de discapacidades sensoriales y otras.
• A fin de ser útil, el texto debe transmitir la misma función o propósito de la imagen. Por ejemplo, consideremos el texto equivalente para una imagen fotográfica de la Tierra vista desde el espacio. Si el propósito de la imagen es simplemente decorativo, el texto equivalente "Fotografía de la Tierra vista desde el espacio" podría cumplir con la función requerida. Si el propósito de la fotografía es ilustrar una información específica sobre geografía mundial, el texto equivalente debería transmitir esa información. Si la fotografía ha sido diseñada para hacer que el usuario seleccione la imagen (Ej. pulsando sobre ella) para acceder a la información sobre la Tierra, el texto equivalente debería ser "Información sobre la Tierra". De ese modo, si el texto transmite la misma función o propósito para el usuario con discapacidad como la imagen lo hace con el resto de usuarios, puede ser considerado un texto equivalente.

Mientras que los desarrolladores de contenidos en la Web deben proporcionar texto equivalente para las imágenes y para otros contenidos multimedia, es responsabilidad de las Aplicaciones de Usuario (Ej. navegadores y ayudas técnicas tales como lectores de pantalla , dispositivos braille, etc.) presentar la información al usuario.

Los equivalentes no textuales al texto (Ej. iconos, locuciones pregrabadas o un vídeo de una persona traduciendo el texto a lenguaje de señas) pueden hacer un documento accesible a personas que pueden tener dificultades para acceder al lenguaje escrito, incluyendo muchos individuos con discapacidades cognitivas, de aprendizaje o sordera. Los equivalentes no textuales del texto pueden ayudar también a los analfabetos. Una descripción auditiva es un ejemplo de equivalente no textual de la información visual. Una descripción auditiva de la pista visual de una presentación multimedia beneficia a las personas que no pueden ver la información visual.

2. MOTIVOS DEL DISEÑO ACCESIBLE.

2.1-Asegurar una transformación airosa.

• Separe el contenido de la estructura y de la presentación (consultar la diferencia entre contenido, estructura y presentación ).
• Proporcione textos (incluidos textos equivalentes). Los textos pueden ser interpretados por la inmensa mayoría de los mecanismos de navegación y accesibles a la inmensa mayoría de usuarios.
• Cree documentos que funcionen incluso si el usuario no puede verlos y/u oírlos. Proporcione información que sirva al mismo propósito y función tanto en audio como en vídeo para que se disponga de un canal sensorial alternativo. Esto no significa crear una versión pregrabada de audio de todo el sitio para hacerlo accesible a los usuarios ciegos. Los usuarios ciegos pueden usar lectores de pantalla para interpretar toda la información textual de una página.
• Cree documentos que no sólo funcionen con un tipo determinado de hardware. Las páginas pueden ser usadas por personas que no dispongan de ratón, con pantallas pequeñas, de baja resolución, en blanco y negro, sin pantallas, o sólo con salida de voz o texto, etc.

2.2 Hacer comprensible y navegable el contenido.

El motivo para hacer el contenido comprensible y navegable se recoge en las pautas 12 a 14.

3. CÓMO SE ORGANIZAN LAS PAUTAS.

• Número de pauta.
• Exposición de la pauta.
• Vínculos de navegación de la pauta. Tres vínculos permiten la navegación hacia la siguiente pauta (icono de flecha hacia la derecha), la pauta anterior (icono de flecha hacia la izquierda) o la posición de la pauta actual en la tabla de contenidos (icono de flecha hacia arriba).
• El fundamento que sustenta la pauta y algunos grupos de usuarios que se benefician de ella.
• Una lista de definiciones de los puntos de verificación.

• Número del punto de verificación.
• Explicación del punto de verificación.
• La prioridad del punto de verificación. Los puntos de verificación de Prioridad 1 están resaltados en negrita.
• Notas informativas opcionales, ejemplos aclaratorios y referencias cruzadas a pautas o puntos de verificación relacionados.
• Un vínculo a una sección del Documento de Técnicas [TECHNIQUES] donde se tratan la ejecución y ejemplos del punto de verificación.

3.1 Convenciones del documento.

• Los nombres de los elementos están en mayúsculas.
• Sus atributos están en minúsculas.

4. PRIORIDADES.

[Prioridad 1]

[Prioridad 2]

[Prioridad 3]

Algunos puntos de verificación tienen especificado un nivel de prioridad que puede variar bajo ciertas condiciones (indicadas).

5. ADECUACIÓN

• Adecuación de nivel A (A): se satisfacen todos los puntos de verificación de prioridad 1.
• Adecuación de nivel Doble A (AA): se satisfacen todos los puntos de verificación de prioridad 1 y 2.
• Adecuación de nivel Triple A (AAA): se satisfacen todos los puntos de verificación de prioridad 1, 2 y 3.

La afirmación de adecuación a este documento debe usarse una de las dos formas siguientes:

Forma 1: Especifique:

• Título de las pautas: "Pautas de Accesibilidad al Contenido en la Web 1.0".
• La URL: http://www.W3.org/TR/1999/WAI-WEBCONTENT-19990505.
• El nivel de adecuación satisfecho: "A", "doble A" o "triple A".
• El alcance cubierto por la afirmación (Ej. página, sitio o parte definida de un sitio).

"Esta página se adapta a las "Pautas de Contenido Accesible en Web 1.0" del W3C, disponible en http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505, nivel Doble A".

Forma 2: Incluir, en cada página para la que se pida conformidad, uno de los tres iconos proporcionados por W3C y un vínculo hacia la explicación sobre la adecuación proporcionada por W3C. La información sobre los iconos y como insertarlos en las páginas está disponible en [WCAG-ICONS].

6. PAUTAS DE ACCESIBILIDAD AL CONTENIDO DE LA WEB.

PAUTA 1- "Proporcione alternativas equivalentes de contenido visual y auditivo".

| 

Si bien algunas personas no pueden utilizar imágenes, películas, sonidos, applets, etc directamente, sí pueden utilizar páginas que incluyen información equivalente a los contenidos visuales o auditivos. La información equivalente debe cumplir la misma finalidad que los contenidos visuales o auditivos. Así un texto equivalente para la imagen de una flecha ascendente que vincule con una tabla de contenidos, podría ser "Ir a tabla de contenidos". En algunos casos, un equivalente debería describir la apariencia del contenido visual (Ej. para tablas complejas, carteles o diagramas) o el sonido del contenido auditivo (Ej. para los ejemplos sonoros usados en educación).

Esta pauta enfatiza la importancia de aportar textos equivalentes para los contenidos no textuales (Ej. imágenes, sonido pregrabado, vídeo...). La importancia del texto equivalente radica en su capacidad para ser interpretada por vías que son accesibles para personas pertenecientes a diversos grupos de discapacidad usando diversa tecnología. El texto puede ser interpretado por sintetizadores de voz o dispositivos braille y puede ser presentado visualmente (en varios tamaños) en visualizadores de ordenador y papel. El sintetizador de voz es esencial para personas ciegas y para las que tienen dificultades de lectura que a menudo acompañan a discapacidades cognitivas, de aprendizaje o sordera. El braille es esencial para personas sordo-ciegas, tanto como para muchos individuos que solamente son ciegos. La salida visual de texto beneficia a los usuarios sordos tanto como a la mayoría de usuarios de la Web.

Proporcionar equivalentes no textuales (dibujos, videos, sonido) del texto es también beneficioso para algunos usuarios, especialmente los analfabetos o personas con dificultad para la lectura. En las películas o presentaciones visuales, la acción representada, tal como el lenguaje corporal u otras pistas visuales, podrían no estar acompañadas de suficiente información auditiva como para transmitir la misma información. A menos que se proporcionen descripciones verbales de las acciones representadas, las personas que no puedan ver (o visualizar) el contenido visual, no podrán percibirlo.

Puntos de verificación:

1.1 Proporcione un texto equivalente para todo elemento no textual (Ej. a través de "alt", "longdesc" o en el contenido del elemento). Esto incluye: imágenes, representaciones gráficas del texto, mapas de imagen, animaciones (Ej. GIFs animados), "applets" y objetos programados, "ASCII art", marcos, scripts, imágenes usadas como viñetas en las listas, espaciadores, botones gráficos, sonidos (ejecutados con o sin interacción del usuario), archivos exclusivamente auditivos, banda sonora del vídeo y vídeos [Prioridad 1] .

Por ejemplo, en HTML:

• Utilice "alt" para los elementos IMG, INPUT y APPLET o proporcione texto equivalente en el contenido de los elementos OBJECT Y APPLET.
• Para contenidos complejos (Ej. las gráficas) en los que el texto del atributo "alt" no es suficiente, proporcione una descripción adicional usando, por ejemplo "longdesc" con IMG o FRAME, un enlace dentro de un elemento OBJECT o un enlace descriptivo en el documento.
• Para mapas de imagen, use el atributo "alt" con AREA o el elemento MAP con elementos A (y otro texto) como contenido.

Técnicas para el punto de verificación 1.1.

1.2 Proporcione enlaces redundantes en formtao texto con cada zona activa de un mapa de imagen del servidor [Prioridad 1].

Consultar también punto de verificación 1.5 y punto de verificiación 9.1.

Técnicas para el punto de verificación 1.2.

1.3 Hasta que las aplicaciones de usuario puedan leer automáticamente el texto equivalente de la pista visual, proporcione una descripción auditiva de la información importante de la pista visual de una presentación multimedia [Prioridad 1] .

Sincronice la descripción auditiva con la banda sonora como en el punto de verificación 1.4.

Consultar también punto de verificación 1.1 , para información sobre textos equivalentes en el contenido visual.

Técnicas para el punto de verificación 1.3.

1.4 Para toda presentación multimedia tempodependiente (Ej. una película o animación) sincronice alternativas equivalentes (Ej. subtítulos o descripciones de la banda de visual) con la presentación [Prioridad 1].

Técnicas para el punto de verificación 1.4.

1.5 Hasta que las aplicaciones de usuario interpreten el texto equivalente para los enlaces de los mapas de imagen de cliente, proporcione enlaces en formto texto redundantes para cada zona activa del mapa de imagen de cliente [Prioridad 3].

Consultar también punto de verificación 1.2 y punto de verificación 9.1.

Técnicas para el punto de verificación 1.5.

PAUTA 2: No basarse sólo en el color.

| | 

Si el color por sí mismo se usa para transmitir información, las personas que no puedan diferenciar ciertos colores, y los usuarios que no tengan pantallas en color o utilicen dispositivos de salida no visuales, no recibirán la información. Cuando los colores de primer plano y de fondo tienen un tono similar, pueden no proporcionar suficiente contraste en las pantallas monocromáticas, así como a las personas con diferentes tipos de deficiencias de percepción de los colores.

Puntos de verificación:

2.1 Asegure que toda la información transmitida a través de los colores también esté disponible sin color, por ejemplo mediante el contexto o por marcadores [Prioridad 1].

Técnicas para el punto de verificación 2.1.

2.2 Asegure que las combinaciones de los colores de fondo y primer plano tengan suficiente contraste para que sean percibidas por personas con deficiencias de percepción de color o por pantallas en blanco y negro [Prioridad 2 para las imágenes. Prioridad 3 para los textos].

Técnicas para el punto de verificación 2.2.

PAUTA 3: Utilice marcadores y hojas de estilo y hágalo apropiadamente.

| | 

Usando marcadores de forma inapropiada (es decir, no de acuerdo con las especificaciones) se dificulta la accesibilidad. El mal uso de marcadores para una presentación (Ej. Utilizando una tabla para maquetar o un encabezado - etiqueta H - para cambiar el tamaño de la fuente) dificulta que los usuarios con software especializado entiendan la organización de la página o cómo navegar por ella. Mas aún, utilizando los marcadores de presentación en lugar de marcadores estructurales para transmitir estructura (Ej. Construir lo que parece una tabla de datos con un elemento HTML PRE) se hace difícil interpretar una página de forma inteligible a otros dispositivos (Consultar la descripción de diferencia entre contenido, estructura y presentación ).

Los desarrolladores de contenidos pueden sentir la tentación de usar (o usar mal) construcciones que aseguren el formato deseado en los navegadores antiguos. Deben darse cuenta de que estas prácticas causan problemas de accesibilidad y deben considerar si el formato es tan importante como para hacer el documento inaccesible a algunos usuarios.

En el otro extremo, los desarrolladores de contenidos no deben sacrificar el marcador apropiado porque un determinado navegador o ayuda técnica no pueda procesarlo correctamente. Por ejemplo, es apropiado usar el elemento TABLE en HTML para marcar información tabular aunque algunos lectores de pantalla antiguos no manejen correctamente el texto contiguo (consultar el punto de verificación 10.3 ). Usando el elemento TABLE correctamente y creando tablas que se transformen adecuadamente (consultar la pauta 5 ) hace posible al software interpretar tablas de otra forma que como rejilla en dos dimensiones.

Puntos de verificación

3.1 Cuando exista un marcador apropiado, use marcadores en vez de imágenes para transmitir la información [Prioridad 2].

Por ejemplo, utilice MathML para marcar ecuaciones matemáticas y hojas de estilo para el formato de texto y el control de la maquetación. Igualmente, evite la utilización de imágenes para representar textos. Utilice en su lugar texto y hojas de estilo.

Consultar también pauta 6 y pauta 11 .

Técnicas para el punto de verificación 3.1.

3.2 Cree documentos que estén validados por las gramáticas formales publicadas [Prioridad 2].

Por ejemplo, incluya en la declaración del tipo de documento, al comienzo del mismo, la referencia a una DTD publicada (Ej. la DTD HTML 4.0 estricto).

Técnicas para el punto de verificación 3.2.

3.3 Utilice hojas de estilo para controlar la maquetación y la presentación [Prioridad 2].

Por ejemplo, utilice la propiedad 'font' de CSS en lugar del elemento HTML FONT para controlar el estilo de las fuentes.

Técnicas para el punto de verificación 3.3.

3.4 Utilice unidades relativas en lugar de absolutas al especificar los valores en los atributos del de lenguaje de marcadores y en los valores de las propiedades de las hojas de estilo [Prioridad 2].

Por ejemplo, en CSS, utilice 'em' o medidas porcentuales, en vez de 'pt' (puntos) o 'cm' (centímetros), que son unidades absolutas. Si se usan unidades absolutas, valide que el contenido presentado es utilizable. (Consultar la sección de validación).

Técnicas para el punto de verificación 3.4.

3.5 Utilice elementos de encabezado para transmitir la estructura lógica y utilícelos de acuerdo con la especificación [Prioridad 2].

Por ejemplo, en HTML, utilice H2 para indicar una subsección de H1. No utilice encabezados para hacer efectos de fuente.

Técnicas para el punto de verificación 3.5.

3.6 Marque correctamente las listas y los ítem de las listas [Prioridad 2].

Por ejemplo, en HTML, anide los elementos de listas OL, VL y DL adecuadamente.

Técnicas para el punto de verificación 3.6.

3.7 Marque las citas. No utilice el marcador de citas para efectos de formato tales como sangrías [Prioridad 2].

Por ejemplo en HTML, utilice los elementos Q y BLOCKQUOTE para marcar citas cortas y largas, respectivamente.

Técnicas para el punto de verificación 3.7.

PAUTA 4. Identifique el lenguaje natural usado.

| | 

Cuando los desarrolladores de contenido especifican los cambios en el lenguaje natural de un documento, los sintetizadores de voz y los dispositivos braille pueden cambiar automáticamente al nuevo lenguaje, haciendo el documento más accesible a usuarios multilingües. Los desarrolladores de contenido deberían identificar el idioma predominante del contenido de un documento (a través de un marcador o en el encabezado HTTP). Deberían también proporcionar la expansión de las abreviaturas y los acrónimos.

Además para las ayudas técnicas, la identificación del lenguaje natural usado permite a los motores de búsqueda localizar las palabras claves e identificar los documentos en el idioma deseado. Los marcadores de lenguaje natural mejoran también la legibilidad de la Web para todo el mundo, incluso para aquellos con discapacidades de aprendizaje, cognitivas o sordera.

Cuando los cambios en las abreviaturas y el lenguaje natural no son identificados, pueden ser indescifrables para los lectores de pantalla y los dispositivos braille.

Puntos de verificación:

4.1 Identifique claramente los cambios en el lenguaje natural del texto del documento y en cualquier texto equivalente (Ej. leyendas) [Prioridad 1] .

Por ejemplo en HTML, utilice el atributo "lang". En XML, utilice "xml:lang".

Técnicas para el punto de verificación 4.1.

4.2 Especifique la expansión de cada abreviatura o acrónimo cuando aparezcan por primera vez en el documento [Prioridad 3].

Por ejemplo, en HTML, use el atributo "title" de los elementos "ABBR" y "ACRONYM". Proporcionando la expansión en el cuerpo principal del documento y también en los documentos de ayuda.

Técnicas para el punto de verificación 4.2.

4.3 Identifique el lenguaje natural principal de un documento [Prioridad 3].

Por ejemplo, en HTML, coloque el atributo "lang" en el elemento HTML. En XML, utilice "xml:lang". Los operadores de servidores podrían configurar sus servidores para aprovechar los mecanismos de transferencia del contenido del protocolo HTTP ([RFC2068], sección 14.13), de forma que los clientes puedan recibir automáticamente los documentos en el idioma seleccionado.

Técnicas para el punto de verificación 4.3.

PAUTA 5. Cree tablas que se transformen correctamente.

| | 

Las tablas deberían utilizarse solamente para marcar la información tabular ("tablas de datos"). Los desarrolladores de contenidos deberían evitar usarlas para maquetar páginas ("tablas de composición"). Las tablas para cualquier uso presentan también especiales dificultades para los usuarios de lectores de pantalla (consultar punto de verificación 10.3 ).

Algunas aplicaciones de usuario navegan entre las celdas de las tablas y acceden a los encabezamientos y otras informaciones de las celdas. A menos que marquemos apropiadamente las tablas, éstas no proporcionaran a la aplicación de usuario la información necesaria (consultar también la pauta 3 ).

Los siguientes puntos de verificación beneficiarán directamente a las personas que accedan a la tabla por medios auditivos (por ejemplo un lector de pantalla o un PC automóvil), o a aquellos que sólo visualicen una parte de la página cada vez (Ej. los usuarios ciegos o de escasa visión que utilicen un sistema auditivo o un dispositivo braille u otros usuarios de dispositivos con visualizadores pequeños, etc.).

Puntos de verificación.

5.1 En las tablas de datos, identifique los encabezamientos de fila y columna [Prioridad 1] .

Por ejemplo, en HTML, use TD para identificar las celdas de datos y TH para los encabezamientos.

Técnicas para el punto de verificación 5.1.

5.2 Para las tablas de datos que tienen dos o más niveles lógicos de encabezamientos de fila o columna, utilice marcadores para asociar las celdas de encabezamiento y las celdas de datos [Prioridad 1] .

Por ejemplo, en HTML, utilice THEAD, TFOOT, y TBODY, para agrupar las filas, COL y COLGROUP para agrupar las columnas y los atributos "axis", "scope" y "headers" para describir relaciones más complejas entre los datos.

Técnicas para el punto de verificación 5.2.

5.3 No utilice tablas para maquetar, a menos que tabla tenga sentido cuando se transcriba línea a línea. Por otro lado, si la tabla no tiene sentido, proporcione una alternativa equivalente (la cual debe ser una versión que pueda ser leída línea a línea) [Prioridad 2].

NOTA.- Una vez que las aplicaciones de usuario soporten el posicionamiento mediante hojas de estilo, las tablas no se deben utilizar para maquetar.

Consultar también punto de verificación 3.3 .

Técnicas para el punto de verificación 5.3 .

5.4 Si se utiliza una tabla para maquetar, no utilice marcadores estructurales para representar un formateo visual [Prioridad 2].

Por ejemplo, en HTML no utilice elemento TH para hacer que el contenido de una celda (que no sea de encabezamiento de tabla) se visualice centrado y en negrita.

Técnicas para el punto de verificación 5.4.

5.5 Proporcione resúmenes de las tablas [Prioridad 3].

Por ejemplo, en HTML, use el atributo "summary" en el elemento TABLE.

Técnicas para el punto de verificación 5.5.

5.6 Proporcione abreviaturas para las etiquetas de encabezamiento [Prioridad 3].

Por ejemplo, en HTML, use el atributo "abbr" en el elemento TH.

Técnicas para el punto de verificación 5.6.

Consultar también punto de verificación 10.3.

PAUTA 6. Asegure que las páginas que incorporan nuevas tecnologías se transformen correctamente.

| | 

Si bien se alienta a los desarrolladores de contenidos a usar nuevas tecnologías que superen los problemas que proporcionan las tecnologías existentes, deberán saber como hacer para que sus páginas funcionen con navegadores más antiguos, y para quienes decidan desconectar esta característica.

Puntos de verificación.

6.1 Organice el documento de forma que pueda ser leído sin hoja de estilo. Por ejemplo, cuando un documento HTML es interpretado sin asociarlo a una hoja de estilo, tiene que ser posible leerlo [Prioridad 1] .

Cuando el contenido está organizado lógicamente, es interpretado de forma que la organización continúa siendo clara incluso cuando se desconecten o no se soporten las hojas de estilo.

Técnicas para el punto de verificación 6.1.

6.2 Asegure que los equivalentes de un contenido dinámico son actualizados cuando cambia el contenido dinámico [Prioridad 1].

Técnicas para el punto de verificación 6.2.

6.3 Asegure que las páginas sigan siendo utilizables cuando se desconecten o no se soporten los scripts, applets u otros objetos de programación. Si esto no es posible, proporcione información equivalente en una página alternativa accesible [Prioridad 1] .

Por ejemplo, asegure que los enlaces que lanzan scripts funcionan cuando estos se desconecten o no se soporten (Ej. no utilizar un "javascript" como objetivo de un enlace). Si no es posible hacer la página utilizable sin scripts, proporcione un texto equivalente con el elemento NOSCRIPT o utilice un script del servidor en lugar de un script de cliente o proporcione una página alternativa accesible como para el punto de verificación 11.4. Consultar también la pauta 1 .

Técnicas para el punto de verificación 6.3.

6.4 Para los scripts y applets, asegure que los manejadores de evento sean entradas independientes del dispositivo [Prioridad 2].

Consultar la definición de independencia del dispositivo.

Técnicas para el punto de verificación 6.4.

6.5 Asegure que los contenidos dinámicos son accesibles o proporcione una página o presentación alternativa [Prioridad 2].

Por ejemplo en HTML, utilice NOFRAMES al final de cada 'frameset'. Para algunas aplicaciones, los scripts del servidor son más accesibles que los del cliente.

Técnicas para el punto de verificación 6.5.

Consultar también punto de verificación 11.4.

PAUTA 7. Asegure al usuario el control sobre los cambios de los contenidos tempo-dependientes.

| | 

Algunas personas con discapacidades cognitivas o visuales son incapaces de leer textos que se mueven con la suficiente rapidez o en absoluto. El movimiento puede también distraer de tal manera que el resto de la página se vuelve ilegible para las personas con discapacidades cognitivas. Los lectores de pantalla son incapaces de leer textos móviles. Las personas con discapacidades físicas podrían no ser capaces de moverse tan rápida o certeramente como para interactuar con objetos móviles.

NOTA: Todos los puntos de verificación que siguen, implican alguna responsabilidad por parte del desarrollador del contenido hasta que las aplicaciones de usuario proporcionen adecuados mecanismos de control de la característica.

Puntos de verificación.

7.1 Hasta que las aplicaciones de usuario permitan controlarlo, evite provocar parpadeo en la pantalla [Prioridad 1] .

Nota: Los usuarios con epilepsia fotosensitiva pueden tener ataques desencadenados por parpadeos o destellos que oscilen entre los 4 y los 59 destellos por segundo (hertzios), con un nivel máximo a los 20 destellos por segundo, así como con los cambios rápidos de oscuridad a iluminación (como las luces estroboscópicas).

Técnicas para el punto de verificación 7.1.

7.2 Hasta que las aplicaciones de usuario permitan controlarlo, evite el parpadeo del contenido (por ejemplo, cambio de presentación en periodos regulares, tal como el encendido y apagado) [Prioridad 2].

Técnicas para el punto de verificación 7.2.

7.3 Hasta que las aplicaciones de usuario permitan congelar el movimiento de los contenidos, evite los movimientos en las páginas [Prioridad 2].

Cuando una página incluye contenido móvil, proporcione un mecanismo dentro de un script o un applet que permita a los usuarios congelar el movimiento o actualización. El uso de las hojas de estilo con scripts que creen movimiento, permite a los usuarios desconectar u obviar el efecto más fácilmente.

Consultar también la pauta 8.

Técnicas para el punto de verificación 7.3.

7.4 Hasta que las aplicaciones de usuario proporcionen la posibilidad de detener las actualizaciones, no cree páginas que se actualicen automáticamente de forma periódica [Prioridad 2].

Por ejemplo, en HTML, no cree páginas que se actualicen automáticamente con "HTTP EQUIV=refresh" hasta que las aplicaciones de usuario permitan desconectar esta característica.

Técnicas para el punto de referencia 7.4.

7.5 Hasta que las aplicaciones de usuario proporcionen la posibilidad de detener el redireccionamiento automático, no utilice marcadores para redirigir las páginas automáticamente. En su lugar, configure el servidor para que ejecute esta posibilidad [Prioridad 2].

Técnicas para el punto de referencia 7.5.

Nota: Los elementos BLINK y MARQUEE no están definidos en ninguna especificación W3C HTML, y no deberían ser utilizados. Consultar también la pauta 11.

PAUTA 8. Asegure la accesibilidad directa de las interfaces de usuario incrustadas.

| | 

Cuando un objeto incrustado tiene su "propia interfaz", ésta (al igual que la interfaz de su navegador) debe ser accesible. Si la interfaz del objeto incrustado no puede hacerse accesible, debe proporcionarse una solución alternativa accesible.

Nota: Para información sobre interfaces accesibles, por favor consulte las Pautas de Accesibilidad a las Aplicaciones de Usuario [WAI-USERAGENT] y las Pautas de Accesibilidad para las Herramientas de Autor [WAI-AUTOOL].

Punto de verificación.

8.1 Haga los elementos de programación, tales como scripts y applets, directamente accesibles o compatibles con las ayudas técnicas [ Prioridad 1 Si la funcionalidad es importante y no se presenta en otro lugar; de otra manera, Prioridad 2].

Consultar también la pauta 6.

Técnicas para el punto de referencia 8.1.

PAUTA 9. Diseñe con independencia del dispositivo.

| | 

El acceso a través de dispositivos independientes significa que el usuario puede interactuar con la aplicación de usuario o el documento con un dispositivo de entrada (o salida) preferido - ratón, teclado, voz, puntero de cabeza (licornio) u otro. Si, por ejemplo, un control de formulario sólo puede ser activado con un ratón u otro dispositivo de apuntamiento, alguien que use la página sin verla, con entrada de voz, con teclado o quien utilice otro dispositivo de entrada que no sea de apuntamiento, no será capaz de utilizar el formulario.

Nota: Proporcionando textos equivalentes para los mapas de imagen o las imágenes usadas como vínculos, se hace posible a los usuarios interactuar con ellos sin un dispositivo de apuntamiento. Consultar también la pauta 1 .

Generalmente, las páginas que permiten la interacción a través del teclado son también accesibles a través de una entrada de voz o una serie de comandos.

Puntos de verificación.

9.1 Proporcione mapas de imagen controlados por el cliente en lugar de por el servidor, excepto donde las zonas sensibles no puedan ser definidas con una forma geométrica [Prioridad 1].

Consultar también punto de verificación 1.1, punto de verificación 1.2 y punto de verificación 1.5.

Técnicas para el punto de verificación 9.1.

9.2 Asegure que cualquier elemento que tiene su propia interfaz pueda manejarse de forma independiente del dispositivo [Prioridad 2].

Consultar la definición de independencia del dispositivo.

Consultar también la pauta 8.

Técnicas para el punto de verificación 9.2.

9.3 Para los "scripts", especifique manejadores de evento lógicos en vez de manejadores de evento dependientes de dispositivos [Prioridad 2].

Técnicas para el punto de verificación 9.3.

9.4 Cree un orden lógico para navegar con el tabulador a través de vínculos, controles de formulario y objetos [Prioridad 3].

Por ejemplo, en HTML, especifique el orden de navegación con el tabulador a través del atributo "tabindex" o asegure un diseño de página lógico.

Técnicas para el punto de verificación 9.4.

9.5 Proporcione atajos de teclado para los vínculos más importantes (incluidos los de los mapas de imagen de cliente), los controles de formulario y los grupos de controles de formulario [Prioridad 3].

Por ejemplo, en HTML, especifique los atajos a través del atributo "accesskey".

Técnicas para el punto de verificación 9.5.

PAUTA 10. Utilizar soluciones provisionales.

| | 

Por ejemplo, los navegadores antiguos no permiten al usuario navegar a cuadros de edición vacíos. Los antiguos lectores de pantalla leen las listas de vínculos consecutivos como un solo vínculo. Estos elementos activos tienen, por tanto, difícil o imposible el acceso. Igualmente, cambiar la ventana actual o hacer aparecer inesperadamente nuevas ventanas, puede ser muy desorientador para los usuarios que no pueden ver lo que está ocurriendo.

Nota: Los siguientes puntos de verificación se aplican hasta que las aplicaciones de usuario (incluidas las ayudas técnicas) solucionen estos problemas. Estos puntos de verificación están clasificados como "provisionales" mientras que el Grupo de Trabajo de las Pautas de Contenido en la Web los considere validos y necesarios para la accesibilidad de la Web a partir de la publicación de este documento. Sin embargo, el Grupo de Trabajo espera que estos puntos de verificación no sean necesarios en un futuro, una vez que las tecnologías de la Web hayan incorporado las características y capacidades esperables.

Puntos de verificación.

10.1 Hasta que las aplicaciones de usuario permitan desconectar la apertura de nuevas ventanas, no provoque apariciones repentinas de nuevas ventanas y no cambie la ventana actual sin informar al usuario [Prioridad 2].

Por ejemplo, en HTML, evite usar un marco cuyo objetivo es una nueva ventana.

Técnicas para el punto de verificación 10.1.

10.2 Hasta que las aplicaciones de usuario soporten explícitamente la asociación entre control de formulario y etiqueta, para todos los controles de formularios con etiquetas asociadas implícitamente, asegure que la etiqueta está colocada adecuadamente [Prioridad 2].

La etiqueta debe preceder inmediatamente a su control en la misma línea (se permiten más de una etiqueta/control por línea) o estar en la línea que precede al control (con sólo una etiqueta y un control por línea). Consultar también punto de verificación 12.4.

Técnicas para el punto de verificación 10.2.

10.3 Hasta que las aplicaciones de usuario (incluidas las ayudas técnicas) interpreten correctamente los textos contiguos, proporcione un texto lineal alternativo (en la página actual o en alguna otra) para todas las tablas que maquetan texto en paralelo, columnas envoltorio de palabras [Prioridad 3].

Nota: Por favor, consulte la definición de tabla alineada. Este punto de verificación beneficia a aquellos que tienen aplicaciones de usuario (como algunos lectores de pantalla) que son incapaces de manejar bloques de texto contiguo; el punto de verificación no debe desanimar a los desarrolladores de contenidos en el uso de tablas para presentar información tabular.

Técnicas para el punto de verificación 10.3.

10.4 Hasta que las aplicaciones de usuario manejen correctamente los controles vacíos, incluya caracteres por defecto en los cuadros de edición y áreas de texto [Prioridad 3].

Por ejemplo, en HTML, haga esto con TEXTAREA e INPUT.

Técnicas para el punto de verificación 10.4.

10.5 Hasta que las aplicaciones de usuario (incluidas las ayudas técnicas) interpreten claramente los vínculos contiguos, incluya caracteres imprimibles (rodeados de espacios), que no sirvan como vínculo, entre los vínculos contiguos [Prioridad 3].

Técnicas para el punto de verificación 10.5.

PAUTA 11. Utilice las tecnologías y pautas W3C.

| | 

Las actuales pautas recomiendan las tecnologías W3C (Ej. HTML, CSS, etc.) por varias razones:

• Las tecnologías W3C incluyen características accesibles "incorporadas".
• Las especificaciones W3C pronto serán revisadas para asegurar que los temas de accesibilidad se consideren en la fase de diseño.
• Las especificaciones W3C están desarrolladas en un proceso abierto de laborioso consenso.

Incluso cuando se utilicen tecnologías W3C, deben ser usadas de acuerdo con las pautas de accesibilidad. Cuando utilice nuevas tecnologías, asegure que se transforman correctamente (Consultar también la pauta 6).

Nota: Convirtiendo los documentos (desde PDF, Postscript, RTF, etc.) a lenguajes de marcado W3C (HTML, XML) no siempre se crea un documento accesible. Por tanto, valide cada página respecto a la accesibilidad y utilidad después del proceso de conversión (consulte la sección de validación ). Si una página no se convierte de forma legible, reviese la página hasta que su presentación original se convierta adecuadamente o bien proporcione una versión en HTML o en texto plano.

Puntos de verificación.

11.1 Utilice tecnologías W3C cuando estén disponibles y sean apropiadas para la tarea, y use las últimas versiones cuando sean soportadas [Prioridad 2].

Consulte la lista de referencias para información sobre donde encontrar las últimas especificaciones W3C y [WAI-UA-SUPPORT].para información sobre las aplicaciones de usuario soportados por las tecnologías W3C.

Técnicas para el punto de verificación 11.1.

11.2 Evite características desfasadas de las tecnologías W3C [Prioridad 2].

Por ejemplo, en HTML, no utilice el elemento desfasado FONT; use en su lugar hojas de estilo (por ejemplo, la propiedad "font" en CSS).

Técnicas para el punto de verificación 11.2.

11.3 Proporcione la información de modo que los usuarios puedan recibir los documentos según sus preferencias (Ej. lenguaje, tipo de contenido, etc.) [Prioridad 3].

Nota: Use la negociación de contenidos donde sea posible.

Técnicas para el punto de verificación 11.3.

11.4 Si, después de los mayores esfuerzos, no puede crear una página accesible, proporcione un vínculo a una página alternativa que use tecnologías W3C, sea accesible, tenga información equivalente (o funcional) y sea actualizada tan a menudo como la página (original) inaccesible [Prioridad 1] .

Técnicas para el punto de verificación 11.4.

Nota: Los desarrolladores de contenido sólo deben enviar a páginas alternativas cuando otras soluciones fallen, porque las páginas alterativas se actualizan con menor frecuencia que las páginas primarias. Una página no actualizada puede ser tan frustrante como una página inaccesible, puesto que en ambos casos, la información de la página original no está disponible. La generación automática de páginas alternativas puede conducir a actualizaciones más frecuentes, pero los desarrolladores de contenidos deben asegurar que las páginas generadas siempre tengan sentido y que los usuarios puedan navegar por el sitio siguiendo los vínculos de las páginas primarias, las páginas alternativas o ambas. Antes de enviar a una página alternativa, reconsidere el diseño de la página original; haciéndola accesible es probable que mejore para todos los usuarios.

PAUTA 12. Proporcione información de contexto y orientación.

| | 

Agrupar los elementos y proporcionar información contextual sobre la relación entre elementos puede ser útil a todos los usuarios. Las relaciones complejas entre las partes de una página pueden resultar difíciles de interpretar a personas con discapacidades cognitivas o visuales.

Puntos de verificación.

12.1 Titule cada marco para facilitar la identificación y navegación de los mismos [Prioridad 1].

Por ejemplo, en HTML, utilice el atributo "title" en los elementos FRAME.

Técnicas para el punto de verificación 12.1.

12.2 Describa el propósito de los marcos y como estos se relacionan entre sí, si no resulta obvio solamente con el título del marco [Prioridad 2].

Por ejemplo, en HTML, utilice "longdesc" o un vínculo descriptivo.

Técnicas para el punto de verificación 12.2.

12.3 Divida los bloques largos de información en grupos más manejables donde sea natural y apropiado [Prioridad 2].

Por ejemplo, en HTML, utilice OPTGROUP para agrupar los elementos OPTION dentro de un SELECT; agrupe controles de formulario con FIELDSET y LEGEND; utilice listados anidados cuando sea apropiado; utilice encabezamientos para estructurar documentos, etc. Consultar también a la pauta 3 .

Técnicas para el punto de verificación 12.3.

12.4 Asocie explícitamente las etiquetas con sus controles [Prioridad 2].

Por ejemplo, en HTML, utilice LABEL y su atributo "for".

Técnicas para el punto de verificación 12.4.

PAUTA 13. Proporcione mecanismos claros de navegación.

| | 

Los mecanismos de navegación claros y consistentes son importantes para las personas con discapacidad cognitiva o ceguera y benefician a todos los usuarios.

Puntos de verificación.

13.1 Identifique claramente el objetivo de cada vínculo [Prioridad 2].

El texto del vinculo tiene que tener significado suficiente cuando sea leído fuera de contexto (por sí mismo o como parte de una secuencia de vínculos). También debe ser conciso.

Por ejemplo, en HTML, escriba "información sobre la versión 4.3" en lugar de "pincha aquí". Además de texto del vínculo claros, los desarrolladores de contenidos deben clarificar el objetivo de un vínculo con un título informativo del mismo (por ejemplo, en HTML, el atributo "title"),

Técnicas para el punto de verificación 13.1.

13.2 Proporcione metadatos para añadir información semántica a las páginas y sitios [Prioridad 2].

Por ejemplo, use RDF ([RDF]) para indicar el autor de los documentos, el tipo de contenido, etc.

Nota: Algunas aplicaciones de usuario de HTML pueden construir herramientas de navegación a partir de las relaciones entre documentos descritas en el elemento HTML LINK y los atributos "rel" o "rev" (por ejemplo rel=siguiente; rel=anterior; rel=índice, etc.). Consultar también punto de verificación 13.5 .

Técnicas para el punto de verificación 13.2.

13.3 Proporcione información sobre la maquetación general de un sitio (por ejemplo, mapa del sitio o tabla de contenidos) [Prioridad 2].

En la descripción de la maquetación del sitio, destaque y explique las características de accesibilidad disponibles.

Técnicas para el punto de verificación 13.3.

13.4 Utilice los mecanismos de navegación de forma consistente [Prioridad 2].

Técnicas para el punto de verificación 13.4.

13.5 Proporcione barras de navegación para destacar y dar acceso al mecanismo de navegación [Prioridad 3].

Técnicas para el punto de verificación 13.5.

13.6 Agrupe los vínculos relacionados, identifique el grupo (para las aplicaciones de usuario) y, hasta que las aplicaciones de usuario lo hagan, proporcione una manera de evitar el grupo [Prioridad 3].

Técnica para el punto de verificación 13.6.

13.7 Si proporciona funciones de búsqueda, permita diferentes tipos de búsquedas para diversos niveles de habilidad y preferencias [Prioridad 3].

Técnicas para punto de verificación 13.7.

13.8 Localice la información destacada al principio de los encabezamientos, párrafos, listas, etc. [Prioridad 3].

Nota: Esto es comúnmente denominado "front-loading" (colocar al frente) y es especialmente útil para los que acceden a la información con dispositivos seriales como un sintetizador de voz.

Técnicas para el punto de verificación 13.8.

13.9 Proporcione información sobre las colecciones de documentos (por ejemplo, los documentos que comprendan múltiples páginas) [Prioridad 3].

Por ejemplo, en HTML, especifique las colecciones de documentos con el elemento LINK y los atributos "rel" y "rev". Otro modo de crear una colección es construyendo un archivo (por ejemplo con zip, tar and gzip, stuffit, etc..) de las páginas múltiples.

Nota: La mejora en la presentación ganada por un procesamiento fuera de línea (offline) puede hacer la navegación mucho menos costosa a las personas con discapacidad que puedan estar navegando lentamente.

Técnicas para el punto de verificación 13.9 .

13.10 Proporcione un medio para saltar sobre un ASCII art de varias líneas [Prioridad 3].

Consultar punto de verificación 1.1 y el ejemplo de ASCII art en el glosario.

Técnicas para el punto de verificación 13.10 .

Pauta 14. Asegure que los documentos sean claros y simples.

| 

La maquetación de páginas consistentes, gráficos reconocibles y lenguaje fácilmente comprensible beneficia a todos los usuarios. En particular, ayudan a personas con discapacidades cognitivas o con dificultades en la lectura. (Por tanto, asegure que las imágenes tienen textos equivalentes para los ciegos, los de baja visión o para cualquier usuario que no puede o ha elegido no ver los gráficos. Consulte también la pauta 1 ).

La utilización de un lenguaje claro y simple promueve una comunicación efectiva. El acceso a la información escrita puede ser difícil para personas con discapacidades cognitivas o de aprendizaje. La utilización de un lenguaje claro y simple también beneficia a las personas cuyo primer lenguaje es diferente al suyo propio, incluidos aquellos que se comunican principalmente mediante lengua de signos.

Puntos de verificación.

14.1 Utilice el lenguaje apropiado más claro y simple para el contenido de un sitio [Prioridad 1].

Técnicas para el punto de verificación 14.1.

14.2 Complemente el texto con presentaciones gráficas o auditivas donde ello facilite la comprensión de la página [Prioridad 3].

Consultar también la pauta 1.

Técnicas para el punto de verificación 14.2.

14.3 Cree un estilo de presentación que sea consistente en todas las páginas [Prioridad 3].

Técnicas para el punto de verificación 14.3.
 

APENDICE A: Validación.

Comience a utilizando métodos de validación desde los primeros estadios del desarrollo. Los problemas de accesibilidad identificados de forma temprana son más fáciles de corregir y evitar.

A continuación se exponen algunos importantes métodos de validación, expuestos con más detalle en la sección de validación del Documento Técnicas.

1. Utilice una herramienta de accesibilidad automática y una herramienta de validación del navegador. Por favor, compruebe que el software de las herramientas trata todos los problemas de accesibilidad, como la significación del texto del vínculo, la aplicabilidad de un texto equivalente, etc.
2. Valide la sintaxis (Ej. HTML, XML, etc.).
3. Valide las hojas de estilo (Ej. CSS).
4. Utilice un navegador sólo-texto o un emulador.
5. Utilice varios navegadores gráficos con:

• Sonidos y gráficos cargados.
• Gráficos no cargados.
• Sonidos no cargados.
• Sin ratón.
• Marcos, scripts, hojas de estilo y applets no cargados.

6. Utilice varios navegadores, viejos y nuevos.
7. Utilice un navegador por voz, un lector de pantallas, un software de magnificación, un visualizador pequeño, etc.
8. Utilice verificadores de ortografía y gramática. Quien lea la página con un sintetizador de voz puede no ser capaz de descifrar lo que reproduce el sintetizador por un error ortográfico. Eliminando problemas gramaticales se incrementa la comprensión.
9. Revise el documento para obtener claridad y simplicidad. Las estadísticas de legibilidad, tales como las generadas por algunos procesadores de textos, pueden ser útiles indicadores de claridad y simplicidad. Mejor aún, pida a un experimentado editor (humano) que revise la claridad del texto escrito. Los editores pueden también incrementar la utilidad de un texto identificando potenciales problemas interculturales que pueden surgir a causa del lenguaje o los iconos usados.
10. Invite a personas con discapacidad a revisar los documentos. Usuarios discapacitados expertos y noveles proporcionarán una retroalimentación valiosa sobre la accesibilidad o los problemas de uso y su gravedad.

APENDICE B. Glosario.

Accesible.

El contenido es accesible cuando puede ser usado por alguien con discapacidad.

Aplicación de usuario.

Software para acceder al contenido de la Web, incluyendo navegadores gráficos de escritorio, de texto, de voz, teléfonos móviles, sistemas multimedia, plug-ins y algún software de ayudas técnicas utilizado conjuntamente con navegadores, tales como lectores de pantalla, magnificadores de pantallas y software de reconocimiento de voz.

Applet.

Un programa insertado en una página Web.

ASCII art.

Se refiere a los caracteres de texto y símbolos que son combinados para crear una imagen. Por ejemplo, ";-)" es el emoticono de sonrisa. A continuación podemos ver una figura ASCII que muestra la relación entre la frecuencia de destello y la respuesta fotocompulsiva en pacientes con los ojos abiertos y cerrados [saltar sobre la figura ASCII o consultar la descripción del gráfico].

  %   __ __ __ __ __ __ __ __ __ __ __ __ __ __   
100 |             *                             |
 90 |                *  *                       |
 80 |          *           *                    |
 70 |             @           *                 |
 60 |          @                 *              |
 50 |       *        @              *           |
 40 |                   @              *        |
 30 |    *  @              @  @           *     |
 20 |                                           |
 10 |    @                       @  @  @  @     |
      0  5 10 15 20 25 30 35 40 45 50 55 60 65 70
      Frecuencia de parpadeo (Hertzios)

Asistente Digital Personal (PDA).

Es un pequeño dispositivo de informática portátil. La mayoría de los PDA se usan para seguir la pista de datos personales como agendas, contactos y correos electrónicos. Generalmente es un instrumento de mano con una pequeña pantalla que permite la entrada desde varios orígenes.

A través de dispositivos independientes .

Los usuarios deben poder interactuar con una aplicación de usuario (y el documento que interpreta) utilizando los dispositivos de entrada y salida de su elección y acordes a sus necesidades. Los dispositivos de entrada pueden incluir dispositivos de apuntamiento, teclados, dispositivos braille, punteros de cabeza, micrófonos y otros. Los dispositivos de salida pueden incluir monitores, sintetizadores de voz y dispositivos braille. Por favor, tenga en cuenta que el "soporte independiente del dispositivo" no significa que las aplicaciones de usuario tengan que soportar todos los dispositivos de entrada y salida. Las aplicaciones de usuario deben ofrecer mecanismos de entrada y salida redundantes para cada dispositivo que sea soportado. Por ejemplo, si una aplicación de usuario soporta entradas de teclado y ratón, los usuarios deben poder interactuar con toda la presentación utilizando cualquier teclado o ratón.

Ayuda técnica.

Software o hardware que está especialmente diseñado para ayudar a personas con discapacidad para realizar sus actividades diarias. Las ayudas técnicas incluyen sillas de ruedas, maquinas lectoras, dispositivos para agarrar, etc. En el área de la Accesibilidad a la Web, las ayudas técnicas más corrientes basadas en el software incluyen lectores y magnificadores de pantalla, sintetizadores de voz y software de entrada de voz que opera junto con navegadores gráficos (entre otras aplicaciones de usuario). Las ayudas técnicas del hardware incluyen teclados alternativos y dispositivos de apuntamiento.

Braille.

Utiliza seis puntos en relieve en diferentes posiciones para representar letras y números que los ciegos leen con los dedos. La palabra "accesible" en braille es:

Un dispositivo braille, comúnmente llamado "dispositivo dinámico braille", eleva o baja las pautas de puntos mediante un dispositivo electrónico, normalmente un ordenador. El resultado es una línea de braille que puede cambiar a intervalos. El braille dinámico presenta la hilera en tamaño que abarca desde líneas de una celda (seis u ocho puntos) hasta una línea de 80 celdas, los más usados tienen entre 12 y 20 celdas por línea.

Compatible con lo atrasado.

Diseños que continúan funcionando con versiones anteriores de un lenguaje, programa, etc.

Contenido, estructura y presentación del documento.

El contenido de un documento se refiere a lo que dice el usuario a través del lenguaje natural, las imágenes, los sonidos, las películas, las animaciones,... La estructura de un documento es cómo se organiza lógicamente (Ej. en capítulos, con una introducción y una tabla de contenidos, etc.). Un elemento (Ej. en HTML los elementos P, STRONG, BLOCKQUOTE) que especifica la estructura de un documento es llamado un elemento estructural. La presentación de un documento es como éste es interpretado (Ej. como dibujo, como una presentación gráfica bidemensional, como una presentación sólo texto, como un sonido sintetizado, como braille, etc.). Un elemento que especifica la presentación de un documento (Ej. B, FONT, CENTER) es llamado elemento de presentación.

Consideremos, por ejemplo, un encabezamiento. El contenido de éste es lo que el encabezamiento dice (Ej. "Veleros"). En HTML, el encabezamiento es un elemento estructural marcado, por ejemplo, con un elemento H2. Finalmente, la presentación de un encabezamiento puede ser un texto en mayúsculas negritas alineada al margen, una línea de texto centrada, un título dicho con cierto tono de voz (como una fuente auditiva), etc.

Desarrolladores de contenidos.

Cualquier autor de páginas o diseñador de sitios Web.

Desaconsejado.

Un elemento o atributo desfasado es aquel que ha quedado anticuado por la aparición de nuevos construcciones. Los elementos desfasados quedarán obsoletos en futuras versiones de HTML. El índice de elementos y atributos de HTML en el Documento de Técnicas indica cuales son los elementos y atributos desfasados en HTML 4.0. Los autores deben evitar el uso de elementos y atributos desfasados. Las aplicaciones de usuario deben continuar soportándolos en razón de la compatibilidad con lo atrasado.

Elemento.

Este documento utiliza el término "elemento" tanto en el estricto sentido de SGML (un elemento es una construcción sintáctica) como en el más general de significar un tipo de contenido (tal como vídeo o sonido) o una construcción lógica (tal como un encabezamiento o una lista). El segundo sentido enfatiza que una pauta inspirada en HTML puede aplicarse fácilmente a otro lenguaje de marcado.

Tenga en cuenta que algunos elementos (SGML) tienen contenido que es interpretado (Ej. los elemento en HTML, P, LI o TABLE), algunos son remplazados por un elemento externo (Ej. IMG) y algunos afectan al procesamiento (Ej. STYLE y SCRIPT generan información que se procesará por las hojas de estilo o el motor del script). Un elemento que genera caracteres de texto formando parte del documento es llamado elemento de texto.

Equivalente.

Un contenido es "equivalente" a otro cuando ambos cumplen esencialmente la misma función o propósito sobre la presentación al usuario. En el contexto de este documento, el equivalente debe cumplir esencialmente la misma función para la persona con discapacidad (al menos en la medida que sea posible, dada la naturaleza de la discapacidad y el estado de la tecnología) como el contenido primario hecho para personas sin ninguna discapacidad. Por ejemplo, el texto "Luna llena" debe transmitir la misma información que una imagen de la luna llena cuando se presenta al usuario. Tenga en cuenta que la información equivalente se centra en cumplir la misma función. Si la imagen es parte de un vínculo y la comprensión de la imagen es crucial para conocer el objetivo del vínculo, un equivalente también debe dar al usuario una idea de este objetivo. Proporcionar información equivalente para contenidos inaccesibles es una de las maneras principales con las que el autor puede hacer accesibles sus documentos a las personas con discapacidad.

Como parte del cumplimiento de la misma función del contenido un equivalente debe suponer una descripción de lo que contiene (Ej. que el contenido se vea o se oiga). Por ejemplo, para que un usuario comprenda la información transmitida por una gráfica compleja, los autores deben describir la información visual de la misma.

Desde que un contenido textual puede ser presentado al usuario a través de un sintetizador de voz, braille o un texto mostrado visualmente, estas pautas requieren texto equivalente para los gráficos y la información auditiva. Los textos equivalentes deben ser escritos de manera que transmitan todo lo esencial del contenido. Los equivalentes no textuales (Ej. una descripción auditiva de una presentación visual, un vídeo de una persona contando una historia utilizando el lenguaje de signos como un equivalente para la historia escrita, etc.) también mejoran la accesibilidad para personas que no pueden acceder a la información visual o al texto escrito, incluyendo muchos individuos ciegos, con discapacidades cognitivas o de aprendizaje y los sordos. La información equivalente debe proporcionarse por otras formas, incluyendo los atributos (Ej. un texto para el atributo "alt" en HTML y SML), como parte del contenido del elemento (Ej. OBJECT en HTML), como parte del propósito del documento o como un vínculo a un documento (Ej. utilizando el atributo "longdesc" en HTML o con un enlace descriptivo). Dependiendo de la complejidad del equivalente, puede ser necesaria la combinación de técnicas (Ej. utilice "alt" para un equivalente abreviado, útil para los lectores conocidos, junto con "longdesc" como vínculo para una información más completa, útil para los nuevos lectores). El detalle de cómo y cuándo proporcionar información equivalente es parte del Documento de Técnicas ([TECHNIQUES]).

Una trascripción de texto es un texto equivalente de una información de audio que incluye palabras habladas y sonidos no hablados, como los efectos de sonido. Una leyenda (caption) es una trascripción de texto de la banda sonora de una presentación de vídeo que esta sincronizada con el vídeo y la banda sonora. Las leyendas son generalmente interpretadas por superposición sobre el vídeo, lo cual beneficia a los sordos o duros de oído y a aquellos que no puedan oír la parte sonora (Ej. cuando estamos en una habitación abarrotada). Una trascripción de texto compilada combina (compilaciones) de leyendas con descripciones textuales de la información visual (descripciones de la acción, lenguaje corporal, gráficos y cambios de escena en la banda de vídeo). Este texto equivalente hace accesible las presentaciones a personas sordo-ciegas y a quienes no pueden ejecutar las películas, animaciones, etc. También hace disponible la información a maquinas de búsqueda.

Un ejemplo de un equivalente no textual es una descripción auditiva de los elementos en clave visual de una presentación. La descripción es tanto una voz humana pregrabada como una voz sintetizada (grabada o generada en el momento). Las descripciones auditivas están sincronizadas con la banda sonora de la presentación, habitualmente durante una pausa natural en la misma. Las descripciones auditivas incluyen información sobre acciones, lenguaje corporal, gráficos y cambios de escena.

Hasta que las aplicaciones de usuario...

En la mayoría de los puntos de verificación, a los desarrolladores de contenidos se les pide que aseguren la accesibilidad de sus páginas y sitios. De todas maneras, hay necesidades de accesibilidad que serían más apropiadamente satisfechas por una aplicación de usuario (incluyendo las ayuda técnica). Hasta la publicación de este documento, no todos las aplicaciones de usuario o ayudas técnicas proporcionan el control de accesibilidad que el usuario requiere (por ejemplo, algunas aplicaciones de usuario pueden no permitir a los usuarios desconectar los contenidos que parpadean o algunos lectores de pantalla pueden no manejar bien las tablas). Los puntos de verificación que contienen la frase "hasta que las aplicaciones de usuario..." requieren que los desarrolladores de contenidos proporcionen soporte adicional para la accesibilidad hasta que la mayoría de las aplicaciones de usuario tengan disponible para sus usuarios las necesarias características de accesibilidad.

NOTA. El sitio en la Web del W3C WAI (consulte [WAI-UA-SUPPORT]) proporciona información sobre las características de accesibilidad que soportan las aplicaciones de usuario. Los desarrolladores de contenidos son instados a consultar estas páginas regularmente para actualizar la información.

Herramientas de autor.

Los editores HTML, las herramientas de conversión de documentos, las que generan contenidos Web desde bases de datos, son todas herramientas de autor. Para información sobre herramientas accesibles en vías de desarrollo, consultar la Pautas de Accesibilidad para Herramientas de Autor ([WAI-AUTOOLS]).

Hojas de estilo.

Una hoja de estilo es un conjunto de instrucciones que especifican la presentación de un documento. Pueden tener tres orígenes diferentes: pueden estar escritas por los que proporcionan el contenido, creadas por los usuarios o construidas en las aplicaciones usuarias. En CSS ([CSS2]), la interacción entre el proveedor del contenido, el usuario y la aplicación usuaria de una hoja de estilo se denomina cascada.

Marcador de presentación: es un marcador que realiza un efecto estilístico (mas que estructura), como los elementos B e I en HTML. Tenga en cuenta que los elementos "STRONG" y "EM" no se consideran marcadores de presentación puesto que transmiten información que es independiente de un estilo de fuente particular.

HTML dinámico (DHTML).

DHTML es en nombre de mercado aplicado a la mezcla de estándares que incluye HTML, hojas de estilo, Document Object Model [DOM1] y "scripting". Sin embargo, no hay una especificación de W3C que defina formalmente el DHTML. Muchas pautas deben ser aplicables a aplicaciones que usan DHTML, sin embargo las siguientes pautas centran los problemas relacionados con el "scripting" y las hojas de estilo: pauta 1 , pauta 3, pauta 6, pauta 7 y pauta 9.

Imagen.

Cualquier presentación gráfica.

Importante.

Una información en un documento es importante si su comprensión es crucial para la comprensión del documento.

Información tabular.

Cuando las tablas se utilizan para presentar la relación lógica entre datos (texto, números, imágenes, etc.), esa información se llama "información tabular" y las tablas se llaman "tablas de datos". Las relaciones expresadas mediante una tabla pueden ser interpretadas visualmente (normalmente en una parrilla bidimensional), auditivamente (a menudo con información de encabezamiento precediendo a las celdas) o en otros formatos.

Lector de pantalla.

Es un programa de software que lee en voz alta al usuario el contenido de la pantalla. Lo usan principalmente los ciegos. Habitualmente los lectores de pantalla pueden leer textos que estén impresos, no pintados.

Lenguaje natural.

Lenguaje humano hablado, escrito o de señas como el francés, japonés, lenguaje de señas americano o braille. El lenguaje natural del contenido debe ser indicado con el atributo "lang" en HTML ([HTML 40], sección 8.1) y el atributo "xml:lang" en XML [XML], sección 2.12).

Magnificador de pantalla.

Es un programa de software que amplia una parte de la pantalla, para que pueda ser vista más fácilmente. Lo usan principalmente las personas de escasa visión.

Mapa de imagen.

Una imagen que ha sido dividida en zonas con acciones asociadas. Pinchar en una zona activa provoca una acción.

Cuando el usuario pincha en una zona activa del mapa de cliente, la aplicación de usuario calcula en qué zona se ha pinchado y sigue el vínculo asociado a esa zona. Pinchando en una zona activa de un mapa de servidor genera las coordenadas que se envían al servidor, que realizará cierta acción.

Los desarrolladores de contenidos pueden hacer los mapas de cliente accesibles proporcionando acceso independiente del dispositivo a los mismos vínculos asociados con las zonas del mapa. Los mapas de cliente permiten a la aplicación de usuario proporcionar retroalimentación inmediata sobre si el puntero del usuario está o no sobre una zona activa.

Mecanismos de navegación.

Es cualquier medio por el cual un usuario puede navegar una página o sitio. Algunos mecanismos típicos incluyen:

Barras de navegación: es una colección de vínculos hacia las partes más importantes de un documento o sitio.

Mapa del sitio: proporciona una visión global de la organización de una página o sitio

Tabla de contenidos: generalmente, lista de (y vínculos a) las secciones mas importantes de un documento.

Tabla que pueda ser leída línea a línea.

Proceso de interpretación de una tabla donde los contenidos de una celda se convierten en una serie de párrafos uno tras otro (Ej. página abajo). Los párrafos se sucederán en le mismo orden que las celdas definían en el documento original. Las celdas deben tener sentido cuando se lean en orden e incluyan elementos estructurales (que generan párrafos, encabezamientos, listas, etc.), así la página tendrá sentido tras su transformación para ser leída línea a línea.

Texto del vínculo.

Contenido textual de un vínculo.

Reconocimientos.

• Chuck Letourneau, Straling Access Servicies.

• Gregg Vanderheiden , Trace Research and Development.

• Judy Brewer y Daniel Dardailler.

• 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, 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, Jaap van Lelieveld y Jason White

Referencias.

[CSS1]

Otros documentos de este libro:

• Preguntas más frecuentes sobre las "Pautas de Accesibilidad al Contenido en la Web 1.0".

• Guía breve para crear sitios Web accesibles.

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

• Tabla de puntos de Verificación para las Pautas de Accesibilidad al Contenido en la Web 1.0.

Volver a la portada del libro.
Volver al comienzo de la página.

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