Ir directamente al contenido de esta página
La única versión normativa de este documento es el original en inglés del W3C.
Para aquellos que no estén familiarizados con temas de accesibilidad relacionados con el diseño de páginas web, consideren que muchos usuarios pueden estar operando en contextos muy diferentes de los suyos:
Los desarrolladores de contenido deben considerar todas estas diferentes situaciones en la fase de diseño de sus páginas. En la medida en que hay muchas situaciones a considerar, cada decisión de diseño accesible generalmente beneficiará a uno o varios grupos de discapacitados en particular y a la comunidad web en general. Por ejemplo, con el uso de hojas de estilo para controlar el aspecto de las fuentes y la eliminación del elemento font, los autores de HTML obtendrán más control sobre sus páginas, de la misma forma que las harán más accesibles para personas con problemas de visión, y, por el hecho de que las hojas de estilos se comparten, reducirán los tiempos de descarga para todos los usuarios.
Las pautas tratan temas de accesibilidad y proporcionan soluciones para un diseño accesible. También presentan escenarios típicos —similares al ejemplo de los estilos de fuentes— que pueden suponer problemas para usuarios con discapacidades. Por ejemplo, la primera de las pautas explica cómo los desarrolladores de contenidos pueden hacer accesibles las imágenes. Algunos usuarios pueden no ser capaces de ver tales imágenes, otros pueden emplear navegadores basados en texto que no soportan imágenes, y otros pueden haber deshabilitado tal soporte —por ejemplo, por motivo de una conexión lenta—. Las pautas no sugieren que se omita el uso de imágenes como medio de mejorar la accesibilidad. En lugar de eso, explican que proporcionar un texto equivalente de la imagen la hará accesible.
¿Cómo hace accesible a una imagen un texto equivalente? Ambas palabras en la expresión texto equivalente son importantes:
Tenga en cuenta que, además de los beneficios para los usuarios discapacitados, los textos equivalentes pueden ayudar a todos los usuarios a encontrar las páginas más rápidamente, en la medida en que los robots de búsqueda pueden emplear tales textos a la hora de indexar las páginas.
En la misma medida en que los desarrolladores de contenidos web son responsables de proporcionar textos equivalentes para imágenes y otros contenidos multimedia, es responsabilidad de los agentes de usuario —por ejemplo, navegadores y tecnologías asistentes tales como lectores de pantalla, dispositivos braille, etc.— presentar la información al usuario.
Equivalentes no textuales de texto —por ejemplo, iconos, discursos grabados o vídeos de traducción del texto al lenguaje de signos— puede volver los documentos accesibles para personas que pueden tener problemas para acceder al texto escrito, lo que incluye individuos con discapacidades cognitivas, dificultades de aprendizaje, o sordera. Equivalentes no textuales del texto pueden ser también útiles para usuarios analfabetos. Una audiodescripción de una presentación visual supone beneficios para quienes no pueden ver la información mostrada.
Estas guías tratan dos temas generales: asegurar una conversión satisfactoria, y hacer el contenido inteligible y navegable.
Siguiendo estas guías los desarrolladores de contenidos web pueden crear páginas que se conviertan satisfactoriamente1. Las páginas que se convierten satisfactoriamente permanecen accesibles a pesar de todas las limitaciones descritas en la introducción, incluyendo en ellas las discapacidades físicas, sensoriales y cognitivas, limitaciones de contexto de trabajo, y barreras tecnológicas. Aquí tiene algunas claves para diseñar páginas que se conviertan satisfactoriamente:
La conversión satisfactoria se trata principalmente en las pautas 1 a 11.
Los desarrolladores de contenidos deberían hacer estos inteligibles y navegables. Esto supone no sólo emplear una expresión clara y simple, sino también proporcionar mecanismos lógicos e intuitivos para la navegación en y entre páginas. Proporcionar herramientas de navegación e información orientativa en las página maximiza la accesibilidad y la usabilidad. No todos los usuarios pueden hacer uso de las guías visuales, como por ejemplo los mapas de imagen, barras de scroll, marcos, o gráficos diseñados para los navegadores visuales. Los usuarios también pierden información contextual cuando solamente pueden ver una parte de la página, bien porque están accediendo a ella palabra por palabra —como es el caso del acceso por medio de sintetizadores de voz o dispositivos braille—, o bien porque sólo pueden apreciar una sección restringida —por medio de un dispositivo pequeño o por medio de dispositivos de ampliación—. Sin información orientativa los usuarios no serán capaces de entender tablas extensas, listas, menús, etc.
Los temas de inteligibilidad y navegación se tratan principalmente en las pautas 12 a 14.
Este documento incluye catorce pautas o principios generales para un diseño accesible. Cada una incluye:
Las definiciones de puntos clave explican cómo se aplica la pauta en escenarios típicos de desarrollo de contenidos. Cada definición de punto clave incluye:
Se pretende que cada punto clave sea lo bastante específico para que cualquiera que esté revisando un sitio o una página web pueda verificar si el punto clave ha sido satisfecho.
Se han aplicado las siguientes convenciones al contenido de este documento:
samp).accesskey).Cada punto clave tiene un nivel de prioridad asignado por el Grupo de Trabajo, basado en el impacto que ese punto clave tiene sobre la accesibilidad:
Esta sección define tres niveles de conformidad con respecto a este documento:
Nota: Los niveles de conformidad deben recogerse en la página por medio de un texto que pueda ser interpretado claramente al ser convertido en un enunciado.
La declaración de conformidad con respecto a este documento pueden adoptar una de estas dos formas:
«Esta página ha sido creada conforme a las Web Content Accesibility Guidelines 1.0 del W3C, disponible en http://www.w3.org/TR/WAI-WEBCONTENT/, con un nivel de accesibilidad Doble-A.»
Proporcione contenidos que, una ver presentados al usuario, cumplan esencialmente la misma función o propósito que un contenido visual o sonoro.
A pesar de que algunas personas no puedan acceder a los contenidos de imágenes, vídeos, sonidos, applets, etc., aún pueden acceder a las informaciones equivalentes en la página. La información equivalente debe servir para el mismo propósito que el contenido visual o sonoro. De esta manera, un texto equivalente para la imagen de una flecha que apunte hacia arriba —a la tabla de contenidos— podría ser Ir a la tabla de contenidos. En algunos casos, el equivalente deberá también describir el aspecto del contenido visual —por ejemplo, para gráficas complejas o diagramas— o el contenido de un elemento de audio —por ejemplo, para ejemplos de audio empleados en educación.
Esta guía hace hincapié en la importancia de proporcionar textos equivalentes de contenidos no textuales —imágenes, grabaciones de audio, vídeos—. La importancia de los textos equivalentes reside en el hecho de que son fácilmente interpretables para volverse accesibles a personas con diferentes discapacidades que emplean diversas tecnologías de acceso. El texto puede ser interpretado por medio de sintetizadores de voz y dispositivos braille, y puede presentarse visualmente —en diferentes tamaños— tanto en soportes informáticos como en papel. Los sintetizadores de voz son indispensables para individuos ciegos, así como para personas con problemas de lectura que a veces pueden estar acompañados de discapacidades cognitivas, de aprendizaje y sordera. El braille es esencial para individuos que son sordos y ciegos, y también para aquellos cuya discapacidad es solamente la ceguera. El texto desplegado visualmente beneficia también a usuarios sordos, así como a los usuarios web en general.
Proporcionar equivalentes no textuales —por ejemplo, imágenes, vídeos, grabaciones de audio— al texto es también una medida que favorece a algunos usuarios, especialmente a individuos analfabetos o a personas con dificultades para la comprensión lectora. En vídeos o presentaciones visuales, las acciones visibles como lenguaje corporal u otras pistas visuales pueden no ir suficientemente acompañadas de información sonora como para proporcionar la misma información. A menos que se proporcionen descripciones verbales de esa misma información visual, las personas que no puedan ver el contenido no serán capaces de percibirlo.
1.1. Proporcione un texto equivalente para todo elemento no textual —por ejemplo, por medio de alt, longdesc, o algún elemento de contenido—. Esto incluye: imágenes, representaciones gráficas de texto —incluyendo símbolos—, regiones de mapas de imagen, animaciones —por ejemplo, GIF animados—, applets u objetos de programación, arte ASCII, marcos, scripts, imágenes empleadas como viñetas, espaciadores, botones gráficos, sonidos —reproducidos con o sin interacción—, archivos de audio independientes, pistas de audio de vídeos y vídeos. [Prioridad 1]
Por ejemplo, en HTML:
alt para los elementos img, input y applet, o proporcione un texto equivalente para los contenidos de los elementos object y applet.alt no proporcione un texto equivalente completo, proporcione una descripción adicional por medio de, por ejemplo, longdesc para img o frame, un vínculo dentro del elemento object, o un vínculo a una descripción.alt para area, o emplee un elemento map con elementos a —y otros textos— como contenido.1.2. Proporcione textos redundantes para los vínculos de cada región activa de un mapa de imagen del lado del servidor. [Prioridad 1]
1.3. A pesar de que los agentes de usuario pueden leer automáticamente el texto equivalente de una fuente visual, proporcione una audiodescripción de la información importante de un vídeo o una presentación multimedia. [Prioridad 1]
Sincronice la audiodescripción con la pista de audio tal como se describe en el punto clave 1.4. Vésase también el punto clave 1.1 para obtener información sobre los textos equivalentes a contenidos visuales.
1.4. Para cualquier presentación multimedia basada en tiempo —por ejemplo, vídeo o animación—, sincronice las alternativas equivalentes —por ejemplo, audiodescripciones de la pista de vídeo— con la presentación. [Prioridad 1]
1.5. A pesar de que los agentes de usuario interpretan los textos equivalentes de los vínculos de los mapas de imagen del lado del cliente, proporcione información redundante para los vínculos de cada región activa. [Prioridad 3]
Asegúrese de que el texto y los gráficos son comprensibles incluso si se visualizan sin su color.
Si el color es el único medio por el que está transmitiendo algún tipo de información, las personas que no puedan diferenciar entre ciertos colores y los usuarios que no empleen dispositivos en color o visuales de ninguna clase no recibirán tal información. Cuando el color de fondo y de primer plano son demasiado similares, no proporcionan suficiente contraste en dispositivos monocromáticos o con diversos déficits de color.
2.1. Asegúrese de que toda la información que proporciona por medio del color está también disponible sin ese color, por ejemplo por medio del contexto o del marcado. [Prioridad 1]
2.2. Asegúrese de que las combinaciones de colores de primer plano y de segundo plano tienen contraste suficiente para personas que acceden con deficiencias para percibir el color o por medio de pantallas en blanco y negro. [Prioridad 2 para imágenes, prioridad 3 para textos]
Marque los documentos con los elementos estructurales apropiados. Controle su presentación con hojas de estilo en lugar de con elementos y atributos de presentación.
Emplear el marcado inapropiadamente —en desacuerdo con su especificidad— deteriora la accesibilidad. El empleo incorrecto del marcado para obtener efectos de presentación —por ejemplo, emplear una tabla para distribuir los contenidos, o un encabezado para aplicar tamaños de fuente— dificulta que los usuarios con un software especializado comprendan la organización de la página o que naveguen por ella. Más aún, el empleo de marcado de presentación en lugar del marcado estructural para establecer una estructura —por ejemplo, una construcción que se asemeje en pantalla a una tabla de datos por medio del elemento pre— la hace más difícilmente interpretable por otros dispositivos —véase la descripción de las diferencias entre contenido, estructura y presentación.
Los desarrolladores de contenidos pueden sentirse tentados a emplear —o emplear mal— constructores que permitan dotar de ciertos efectos de formato en navegadores antiguos. Deben tener en cuenta que estas prácticas causan problemas de accesibilidad y deberían sopesar si el efecto de formato deseado es tan esencial como para compensar el hecho de el documento se vuelva inaccesible para algunos usuarios.
En el otro extremo, los desarrolladores de contenidos no tienen que sacrificar un marcado apropiado por el simple motivo de que ciertos navegadores o tecnologías asistivas no lo procesen correctamente. Por ejemplo, es correcto emplear el elemento table para marcar información de datos incluso cuando los lectores de pantalla antiguos no puedan interpretar correctamente las correlaciones entre columnas —véase el punto 10.3—. El empleo de table correctamente y la creación de tablas que se conviertan satisfactoriamente —véase la pauta 5— permite que el software apropiado interprete correctamente tablas, más allá de las simples cuadrículas bidimensionales.
3.1. Cuando exista un lenguaje de marcado apropiado, empléelo preferiblemente antes que imágenes para proporcionar la información. [Prioridad 2]
Por ejemplo, utilice MathML para marcar ecuaciones matemáticas, y hojas de estilos para dar formato al texto y para controlar su disposición espacial. Además, evite emplear imágenes que representen textos —emplee texto y hojas de estilo en su lugar—. Véase también las pautas 6 y 11.
3.2. Cree documentos válidos con respecto a gramáticas formales públicas. [Prioridad 2]
Por ejemplo, incluya una declaración de tipo de documento al principio de su página que se refiera a una DTD, como por ejemplo la DTD HTML 4.0 estricta.
3.3. Emplee hojas de estilo para controlar la disposición de los elementos y la presentación de su documento. [Prioridad 2]
Por ejemplo, emplee los estilos de fuentes apropiados en una CSS en lugar del elemento font para controlar el aspecto del texto.
3.4. Emplee para el marcado unidades relativas antes que unidades absolutas, y por medio de valores de las propiedades de las hojas de estilo. [Prioridad 2]
Por ejemplo, en la CSS, emplee unidades em o tamaños en porcentajes antes que puntos (pt) o centímetros (cm), que son unidades absolutas. Si emplea unidades absolutas, verifique que una vez interpretado el contenido será usable (véase más adelante la sección sobre validación).
3.5. Emplee encabezados para otorgar su estructura al documento, y empléelos de acuerdo con su especificación. [Prioridad 2]
Por ejemplo, en HTML, utilice h2 para indicar una subsección de h1. No emplee los encabezados para lograr efectos de presentación en los textos.
3.6. Marque las listas apropiadamente como elementos de lista. [Prioridad 2]
Por ejemplo, en HTML, anide las listas ol, ul y dl correctamente.
3.7. Marque las citas como tales. No emplee el marcado de citas para lograr efectos de formato tales como las sangrías. [Prioridad 2]
Por ejemplo, en HTML, utilice los elementos q y blockquote para marcar citas en línea y en bloque respectivamente.
Utilice marcado que facilite la pronunciación o la interpretación de abreviaturas o de texto en idiomas extranjeros.
Cuando los desarrolladores de contenido marcan cambios de idioma en un documento, los sintetizadores de voz y los dispositivos braille cambian automáticamente al nuevo idioma, haciendo más accesible el documento para usuarios políglotas. Los desarrolladores de contenidos deberían identificar el idioma original del contenido de un documento —a través del marcado o de la cabecera HTTP—. Los desarrolladores de contenidos también deberían proporcionar expansiones para las abreviaturas y los acrónimos.
Además de ayudar a las tecnologías asistivas, el marcado del idioma original del documento permite a los motores de búsqueda encontrar palabras clave e identificar documentos en un idioma determinado. El marcado del idioma original también mejora la legibilidad de los contenidos en la Web para todas las personas, incluso aquellos con discapacidades para el aprendizaje, cognitivas o aquejados de sordera.
Cuando las abreviaturas y los cambios en el idioma original no se identifican, pueden volverse indescifrables al interpretarse en braille o por medio de voz sintetizada.
4.1. Identifique claramente los cambios en el idioma original del texto de un documento y de cualquier texto equivalente (por ejemplo, títulos). [Prioridad 1]
Por ejemplo, en HTML emplee el atributo lang; en XML, emplee xml:lang.
4.2. Especifique la expansión de cada abreviatura o acrónimo en el primer caso en que aparezcan. [Prioridad 3]
Por ejemplo, en HTML, utilice el atributo title para los elementos abbr y acronym. Proporcionar la expansión en el cuerpo principal del documento también mejora la usabilidad del mismo.
4.3. Identifique el idioma original del documento. [Prioridad 3]
Por ejemplo, en HTML emplee el atributo lang; en XML, emplee xml:lang. Los encargados de los servidores deberían configurar los mismos para sacar partido de los mecanismos de negociación de los contenidos HTTP —según lo especificado para HTTP/1.1 (inglés)— para que los clientes puedan obtener automáticamente los documentos de un idioma específico.
Asegúrese de que las tablas cuentan con suficientes elementos de marcado como para ser convertidas satisfactoriamente por parte de navegadores y otros agentes de usuario.
Las tablas deberían emplearse para marcar auténtica información tabulada —tablas de datos—. Los desarrolladores de contenidos deberían evitar emplear tablas para estructurar la disposición visual de los contenidos de un documento —tablas de diseño—. En ambos casos, sin embargo, presentan problemas especiales para los usuarios de lectores de pantallas (véase el punto clave 10.3).
Algunos agentes de usuario permiten navegar por celdas de tablas y acceder de las cabeceras de las mismas a la información de las celdas. Pero a menos que se marque correctamente, las tablas no proporcionarán a los agentes de usuario la información apropiada (véase la pauta 3).
Los puntos clave siguientes beneficiarán directamente a aquellas personas que accedan a una tabla por medios sonoros, o que sólo puedan ver una porción de la pantalla de una vez (por ejemplo, usuarios con ceguera o capacidad visual mermada que empleen sintetizadores de voz o dispositivos braille, usuarios que empleen dispositivos de pantallas pequeñas, etc.).
5.1. Para tablas de datos, identifique las cabeceras de filas y columnas. [Prioridad 1]
Por ejemplo, en HTML, emplee td para identificar celdas de datos y th para identificar cabeceras.
5.2. Para tablas de datos que contengan dos o más niveles lógicos de cabeceras de filas o columnas, emplee marcado para asociar celdas de datos y celdas de cabeceras. [Prioridad 1]
Por ejemplo, en HTML, emplee thead, tfoot y tbody para agrupar filas, col y colgroup para agrupar columnas, y los atributos axis, scope y headers para describir relaciones más complejas entre datos.
5.3. No emplee las tablas para maquetar a menos que el contenido tenga sentido si se presenta linearizado. De otra forma, si la tabla no tiene sentido, proporcione una alternativa equivalente (que debería ser una versión lineal). [Prioridad 2]
Nota: Cuando que los agentes de usuario soporten posicionamientos por medio de hojas de estilo, las tablas no deberían usarse para maquetar. Véase el punto clave 3.3.
5.4. Si emplea tablas para maquetar, no emplee ningún marcado estructural para propósitos de formato visual. [Prioridad 2]
Por ejemplo, en HTML, no emplee el elemento th para hacer que un contenido —que no sea una cabecera de tabla— se presente centrado y en negrita.
5.5. Proporcione resúmenes de las tablas. [Prioridad 3]
Por ejemplo, en HTML, emplee el atributo summary del elemento table.
5.6. Proporcione abreviaturas para los elementos de las cabeceras. [Prioridad 3]
Por ejemplo, en HTML, utilice el atributo abbr para el elemento th.
Asegúrese de que las páginas son accesible incluso cuando las nuevas tecnologías no estén soportadas o estén deshabilitadas.
A pesar de que los desarrolladores de contenidos estén deseando emplear nuevas tecnologías con características que resuelvan problemas intrínsecos de las tecnologías existentes, deberían saber cómo hacer que sus páginas aún funcionen en navegadores antiguos o para personas que hayan elegido deshabilitar tales características.
6.1. Organice los documentos de forma que puedan leerse sin necesidad de las hojas de estilo. Por ejemplo, cuando un documento se interprete sin aplicársele la hoja de estilo correspondiente, aún debería ser posible leerlo. [Prioridad 1]
Cuando el contenido se organiza lógicamente, será interpretado en un orden significativo incluso en situaciones en que las hojas de estilo no se soporten o hayan sido deshabilitadas.
6.2. Asegúrese de que actualiza los equivalentes a contenidos dinámicos una vez que el contenido dinámico haya sido modificado. [Prioridad 1]
6.3. Asegúrese de que las páginas siguen funcionando cuando los scripts, applets u otros elementos de programación han sido deshabilitados o no son soportados. Si esto no es posible, proporcione información equivalente o una página accesible alternativa. [Prioridad 1]
Por ejemplo, asegúrese de que los vínculos que lanzan un script funcionan cuando los scripts han sido deshabilitados o no son soportados —por ejemplo, no emplee javascript: como objetivo de un vínculo—. Si no es posible hacer que la página funcione sin scripts, proporcione un texto equivalente por medio del elemento noscript, o emplee un script del lado del servidor en lugar de uno del lado del cliente, o proporcione una página alternativa accesible de acuerdo con el punto clave 11.4. Véase también la pauta 1.
6.4. Para scripts y applets, asegúrese de que los manejadores de los mismos son independientes del dispositivo de entrada. [Prioridad 2]
Véase la definición de independiente de dispositivo del glosario.
6.5. Asegúrese de que el contenido dinámico es accesible o proporcione una presentación o página alternativa. [Prioridad 2]
Por ejemplo, en HTML, utilice noframes al final de cada grupo de marcos. Para algunas aplicaciones, los scripts del lado del servidor pueden ser más accesibles que los del lado del cliente.
Véase también el punto clave 11.4.
Asegúrese de que los objetos o páginas móviles, parpadeantes, dotados de scroll o que se actualicen automáticamente pueden ser pausados o detenidos.
Algunas personas con discapacidades cognitivas o visuales son incapaces de leer texto en movimiento lo suficientemente rápido, o no son capaces de leerlo en absoluto. El movimiento además puede provocar distracción sobre el resto de la página de manera que ésta se vuelve ilegible para personas con discapacidades cognitivas. Los lectores de pantalla son incapaces de leer texto móvil. Personas con discapacidad motriz podrían no ser capaces de moverse lo suficientemente rápido o con la suficiente precisión como para interactuar correctamente con objetos móviles.
Nota: Todos los puntos clave presentados a continuación son responsabilidad del desarrollador de contenidos hasta que los agentes de usuario proporcionen mecanismos adecuado para su control.
7.1. Hasta que los agentes de usuario permitan a los usuarios controlar el parpadeo, evite hacer que la pantalla parpadee. [Prioridad 1]
Nota: Las personas con epilepsia fotosensitiva pueden sufrir ataques por parpadeos o resplandores con entre 4 y 59 parpadeos por segundo, con un punto crítico de sensibilidad a los 20 parpadeos por segundo, así como con cambios bruscos de oscuridad a luz (como en el caso de las luces estroboscópicas).
7.2. Hasta que los agentes de usuario permitan a los usuarios controlar las intermitencias, evite los elementos intermitentes (por ejemplo, aquellos que cambien de aspecto a un ritmo regular, apareciendo y desapareciendo). [Prioridad 2]
7.3. Hasta que los agentes de usuario permitan detener los contenidos móviles, evite el movimiento en sus páginas. [Prioridad 2]
Cuando una página incluya contenidos móviles, proporcione un mecanismo por medio de un script o applet que permita al usuario detener el movimiento o las actualizaciones. Emplear hojas de estilo y scripts para crear movimientos permite a los usuarios detener los efectos más fácilmente. Véase también la pauta 8.
7.4. Hasta que los agentes de usuario proporcionen un medio de detener el refresco de pantalla, no emplee el refresco automático periódico en sus páginas. [Prioridad 2]
Por ejemplo, en HTML, no emplee http-equiv="refresh" para actualizar automáticamente sus páginas hasta que los agentes de usuario permitan deshabilitar esta funcionalidad.
7.5. Hasta que los agentes de usuario permitan detener el redireccionado automático, no redireccione sus páginas por medio del marcado. En lugar de ello, configure su servidor para que se encargue del redireccionado de páginas. [Prioridad 2]
Nota: Los elementos blink y marquee no han sido definidas en ninguna especificación HTML del W3C, y no deberían emplearse. Véase también la pauta 11.
Asegúrese de que la interfaz de usuario sigue los principios del diseño accesible: acceso funcional independiente de dispositivo, interacción por medio de teclado, etc.
Cuando un objeto incrustado (embedded) tiene su propia interfaz, tal interfaz —igual que la interfaz del propio navegador— debe ser accesible. Si la interfaz del objeto incrustado no puede hacerse accesible, se debe proporcionar una alternativa que sí lo sea.
Nota: Para obtener información sobre interfaces accesibles, consulte las Pautas de Accesibilidad de Agentes de Usuario (inglés) y las Pautas de Accesibilidad de Herramientas de Autor (inglés).
8.1. Programe elementos como scripts y applets para que sean directamente accesibles para las tecnologías asistivas. [Prioridad 1 si la funcionalidad que proporciona la interfaz es importante y no aparece presente en ningún otro elemento; en los demás casos, prioridad 2]
Véase también la pauta 6.
Emplee características que permitan que los elementos de la página se mantengan funcionales para la mayor cantidad posible de dispositivos de acceso.
Acceso independiente de dispositivo significa que el usuario puede interactuar con el documento con el dispositivo de entrada —o salida— que prefiera —ratón, teclado, voz, licornio u otros—. Si, por ejemplo, el control de un formulario depende de un ratón u otro dispositivo de puntero, alguien que no sea capaz de ver la página, que no pueda interactuar con ella mediante voz o mediante el teclado, o que esté empleando cualquier otro dispositivo de entrada que no disponga de puntero, no podrá emplear correctamente el formulario.
Nota: Proporcionar textos equivalentes para los mapas de imagen o para las imágenes empleadas como vínculos hace posible que los usuarios interactúen con ellos sin necesidad de un puntero. Véase también la pauta 1.
Por lo general, las páginas que permiten interacción por medio de teclado también son accesibles a través de entrada de voz o interfaces de línea de comandos.
9.1. Proporcione mapas de imagen del lado del cliente en lugar de mapas del lado del servidor, excepto en aquellos casos en que las regiones no puedan definirse con una forma geométrica disponible. [Prioridad 1]
9.2. Asegúrese de que los elementos dotados de su propia interfaz son interactivos con independencia del dispositivo de entrada. [Prioridad 2]
Véase independiente de dispositivo en el glosario. Véase también la pauta 8.
9.3. Para los scripts, especifique manejadores de eventos lógicos en lugar de manejadores de eventos dependientes del dispositivo. [Prioridad 2]
9.4. Cree un orden lógico de navegación a través de vínculos, controles de formulario y objetos a través de la tecla Tab. [Prioridad 3]
Por ejemplo, en HTML, especifique el orden del desplazamiento por medio de la tecla Tab a través del atributo tabindex, o asegúrese de que el diseño de su página es lógico.
9.5. Proporcione atajos de teclado para los vínculos importantes —incluyendo aquellos situados en los mapas de imagen del lado del cliente—, controles de formularios y grupos de controles de formularios. [Prioridad 3]
Por ejemplo, en HTML, especifique atajos por medio del atributo accesskey.
Emplee soluciones de accesibilidad provisionales para que las tecnologías asistivas y los navegadores antiguos puedan operar correctamente sobre su documento.
Por ejemplo, los navegadores antiguos no permiten que sus usuarios naveguen por cajas de texto vacías. Los lectores de pantalla antiguos leen las listas de vínculos como un único vínculo. Estos elementos activos pueden dificultar o hacer imposible el acceso. De la misma forma, cambiar de ventana o lanzar popups puede desorientar a los usuarios que no puedan ver qué ha ocurrido.
Nota: Los puntos clave que vienen a continuación se aplican hasta que los agentes de usuario —incluyendo las tecnologías asistivas— puedan solventar estos problemas. Estos puntos clave has sido clasificados como provisionales, lo que quiere decir que el Grupo de Trabajo de las Pautas de Contenido Web los considera válidos y necesarios para permitir la accesibilidad en el momento de la publicación de este documento. Aún así, el Grupo de Trabajo espera que tales puntos clave dejen de ser necesarios en un futuro, en la medida en que las tecnologías web hayan incorporado las capacidades previstas.
10.1. Hasta que los agentes de usuario permitan deshabilitar las ventanas emergentes, no haga que popups u otras ventanas aparezcan ni cambie de ventana activa sin informar previamente al usuario. [Prioridad 2]
Por ejemplo, en HTML, evite utilizar vínculos cuyo objetivo sea una nueva ventana emergente.
10.2. Hasta que los agentes de usuario soporten asociaciones explícitas entre elementos y controles de formularios, asegúrese que los elementos están situados apropiadamente para todos los controles de formularios con elementos asociados implícitamente. [Prioridad 2]
El elemento debe preceder inmediatamente a su control en la misma línea —permitiendo que haya más de un elemento/control por línea— o debe situarse en la línea inmediatamente anterior al control —con un solo control por línea—. Véase también el punto clave 12.4.
10.3. Hasta que los agentes de usuario —incluyendo las tecnologías asistivas— interpreten el texto de lado a lado correctamente, proporcione un texto lineal alternativo —en la misma página o en otra— para todas las tablas que dispongan el texto en paralelo asociado a columnas. [Prioridad 3]
Nota: Por favor, consulte la definición de tabla lineal en el glosario. Este punto clave beneficia a las personas con agentes de usuario —como lectores de pantalla— que no pueden manejar bloques o texto presentado de lado a lado; este punto clave no debería disuadir a los desarrolladores de contenidos de emplear tablas para presentar datos tabulares.
10.4. Hasta que los agentes de usuario manejen correctamente controles vacíos, incluya caracteres por defecto en las cajas o áreas de texto editables. [Prioridad 3]
Por ejemplo, en HTML, hágalo para los elementos textarea e input.
10.5. Hasta que los agentes de usuario —incluyendo las tecnologías asistivas— interpreten los vínculos adyacentes correctamente, incluya caracteres imprimibles fuera de los vínculos —rodeados de espacios— entre vínculos adyacentes. [Prioridad 3]
Aplique las tecnologías del W3C —de acuerdo con sus especificaciones— y siga las pautas de accesibilidad. Donde no sea posible emplear tecnologías del W3C, o que hacerlo suponga que su material no se convierta satisfactoriamente, proporcione una versión alternativa del contenido que sí sea accesible.
En estas pautas se recomienda el uso de tecnologías del W3C —por ejemplo, HTML, CSS, etc.— por varias razones:
Muchos formatos que no son tecnologías del W3C —por ejemplo, PDF, Shockwave, etc.— requieren plugins o aplicaciones independientes para ser visualizados. En algunas ocasiones estos formatos no son visibles o navegables para agentes de usuario estándar —lo que incluye las tecnologías asistivas—. Evitar formatos o características no estándar —elementos de código propietario, atributos, propiedades y extensiones— hará sus páginas más accesibles para más gente que emplee una mayor variedad de hardware y software. Cuando deba emplear tecnologías no accesibles —propietarias o no— debe proporcionar páginas accesibles equivalentes.
Incluso en el caso de que se empleen tecnologías del W3C, debe hacerse de acuerdo con las pautas de accesibilidad. Cuando emplee nuevas tecnologías, asegúrese de que sus contenidos se convierten satisfactoriamente (véase también la pauta 6).
Nota: Convertir documentos —de PDF, PostScript, RTF, etc.— a lenguajes de marcado del W3C —HTML, XML— no siempre da como resultado documentos accesibles. Siendo así, valide la accesibilidad y la usabilidad de cada página después del proceso de conversión —véase más adelante la sección sobre validación—. Si una página no se convierte correctamente, revise la misma hasta que su presentación original se transforme apropiadamente o proporcione una versión HTML o de sólo-texto.
11.1. Emplee tecnologías del W3C cuando estén disponibles y sean apropiadas para una tarea, y emplee las últimas versiones cuando ya sean soportadas. [Prioridad 2]
Véase la lista de referencias (inglés) para obtener información sobre las últimas especificaciones, y la página acerca del soporte a la accesibilidad de los agentes de usuario (inglés) para obtener información sobre el soporte de los agentes de usuario a las tecnologías del W3C.
11.2. Evite las características depreciadas de las tecnologías W3C. [Prioridad 2]
Por ejemplo, en HTML, no emplee el elemento depreciado font; utilice hojas de estilo en su lugar (por ejemplo, las propiedades font- de CSS).
11.3. Proporcione información que permita a los usuarios obtener documentos acordes con sus preferencias (por ejemplo, idioma, tipo de contenido, etc.). [Prioridad 3]
Nota: Emplee contenidos negociables cuando sea posible.
11.4. Si, después de todos sus esfuerzos, no puede crear una página accesible, proporcione un vínculo a una página alternativa construida con tecnologías W3C, que sea accesible, que contenga una información —o funcionalidad— equivalente, y que se actualice con la misma periodicidad que la página inaccesible original. [Prioridad 1]
Nota: Los desarrolladores de contenidos sólo deberían recurrir a páginas alternativas cuando todas las demás soluciones fallen, porque las páginas alternativas se suelen actualizar con menos frecuencia que las páginas principales. Una página desactualizada puede ser tan frustrante como una inaccesible, puesto que, en ambos casos, la información presente en la página original sigue sin estar disponible. Generar por medios automáticos páginas alternativas puede llevar a actualizaciones más frecuentes, pero los desarrolladores de contenidos aún deben asegurarse de que las páginas generadas tienen sentido, y de que los usuarios pueden navegar por el sitio siguiendo los vínculos de las páginas principales, de las páginas alternativas, o de ambas. Antes de recurrir a una página alternativa, reconsidere el diseño de la página original; hacer ésta accesible la mejorará para todos los usuarios.
Proporcione información sobre contexto y orientación que ayude a los usuarios a comprender páginas o elementos complejos.
Agrupar elementos y proporcionar información contextual sobre las relaciones entre los mismos es útil para todos los usuarios. Las relaciones complejas entre las partes de una página pueden ser difíciles de interpretar para personas con discapacidades cognitivas o visuales.
12.1. Asigne un título a cada marco para facilitar su identificación y la navegación. [Prioridad 1]
Por ejemplo, en HTML, utilice el atributo title para el elemento frame.
12.2. Describa el propósito de los marcos y cómo los marcos se relacionan entre sí, si no es obvio por medio del título. [Prioridad 2]
Por ejemplo, en HTML, utilice longdesc, o un vínculo descriptivo.
12.3. Divida los bloques de información extensos en grupos más manejables, en aquellos puntos en los que sea natural y apropiado. [Prioridad 2]
Por ejemplo, en HTML, emplee optgroup para agrupar elementos option dentro de select; agrupe controles de los formularios por medio de fieldset y legend; utilice listas anidadas donde corresponda; utilice encabezados para estructurar documentos, etc. Véase también la pauta 3.
12.4. Asocie elementos explícitamente a sus controles. [Prioridad 2]
Por ejemplo, en HTML, utilice label y su atributo for.
Proporcione mecanismos de navegación claros y consistentes —información orientativa, barras de navegación, un mapa del sitio, etc.— para incrementar la facilidad con la que una persona encuentre aquello que está buscando en su sitio.
Los mecanismos de navegación claros y consistentes son importantes para las personas con discapacidades cognitivas o ceguera, y benefician a todos los usuarios.
13.1. Identifique claramente el objetivo de cada vínculo. [Prioridad 2]
El texto de un vínculo debería ser suficientemente significativo como para tener sentido leído incluso fuera de su contexto —en sí mismo o como parte de una secuencia de vínculos—. El texto de un vínculo también debería ser preciso.
Por ejemplo, en HTML, escriba Información sobre la versión 4.3 en lugar de Pinche aquí. Además del texto de vínculo significativo, los desarrolladores de contenidos deberían clarificar aún más el objetivo del vínculo con un título informativo (por ejemplo, en HTML, por medio del atributo title).
13.2. Proporcione metadatos para añadir información semántica a páginas y sitios. [Prioridad 2]
Por ejemplo, emplee RDF —véase la recomendación (inglés) y la última versión (inglés)3— para indicar el autor del documento, el tipo de contenido, etc.
Nota: Algunos agentes de usuario en HTML pueden construir herramientas de navegación entre documentos a partir de las relaciones descritas por medio del elemento link de HTML y sus atributos rel o rev —por ejemplo, rel="next", rel="previous", rel="index", etc.—. Véase también el punto clave 13.5.
13.3. Proporcione información sobre la disposición general de su sitio (por ejemplo, un mapa del sitio o una tabla de contenidos). [Prioridad 2]
Al describir la disposición general de su sitio, destaque y explique las características de accesibilidad disponibles.
13.4. Utilice los mecanismos de navegación de manera consistente. [Prioridad 2]
13.5. Proporcione barras de navegación para destacar y permitir el acceso a los mecanismos de navegación. [Prioridad 3]
13.6. Agrupe los vínculos que estén relacionados, identifique el grupo —para los agentes de usuario—, y, hasta que los agentes lo hagan por sí mismos, proporcione un medio para superar el grupo. [Prioridad 3]
13.7. Si se proporciona alguna funcionalidad de búsqueda, habilite distintos tipos de búsqueda para diferentes niveles de habilidad o preferencias. [Prioridad 3]
13.8. Coloque información distintiva al principio de encabezados, párrafos, listas, etc. [Prioridad 3]
Nota: Esto es lo que normalmente se denomina carga frontal y es especialmente útil para las personas que acceden a la información con dispositivos seriales tales como sintetizadores de voz.
13.9. Proporcione información sobre colecciones de documentos (por ejemplo, documentos que comprendan varias páginas). [Prioridad 3]
Por ejemplo, en HTML, especifique las colecciones de documentos por medio del elemento link y los atributos rel y rev. Otra forma de relacionar colecciones de documentos es crear un archivo —por ejemplo, .zip, .tar, .gzip, etc.— para el conjunto de las páginas.
Nota: Se logra una mejora de ejecución por medio de procesos offline, puesto que se reduce el esfuerzo de navegación para personas con discapacidades que les obliguen a navegar lentamente.
13.10. Proporcione medios para saltar por encima del arte ASCII de varias líneas. [Prioridad 3]
Véase el punto clave 1.1. y el ejemplo de arte ASCII del glosario.
Asegúrese de que los documentos son claros y simples para que sean fáciles de comprender.
Una disposición consistente de la página, unos gráficos reconocibles y un lenguaje comprensible benefician a todos los usuarios. En particular, ayudan a las personas con discapacidades cognitivas o que tengan dificultades de lectura (aun así, asegúrese de que las imágenes tienen textos equivalentes para las personas ciegas o con visión disminuida, o para aquellos usuarios que no pueden o han elegido no ver gráficos; véase también la pauta 1).
El empleo de un lenguaje claro y simple proporciona efectividad a la comunicación. El acceso a la información escrita puede presentar dificultades para las personas con discapacidades cognitivas o de aprendizaje. El empleo de un lenguaje sencillo también beneficia a las personas cuyo primer idioma es distinto del suyo, lo que incluye a personas que tengan que comunicarse principalmente por medio de signos.
14.1. Utilice el lenguaje más claro y simple que sea apropiado para el contenido de su sitio. [Prioridad 1]
14.2. Complemente el texto con presentaciones gráficas o sonoras donde puedan facilitar la comprensión de la página. [Prioridad 3]
Véase también la pauta 1.
14.3. Cree un estilo de presentación que se mantenga consistente a través de las diferentes páginas. [Prioridad 3]
Valide la accesibilidad por medio de herramientas automáticas y revisión humana. Los métodos automáticos son por lo general rápidos y convenientes, pero no pueden identificar todas las cuestiones de accesibilidad. La revisión humana ayuda a asegurar la claridad del lenguaje y la facilidad de navegación.
Empiece a aplicar métodos de validación desde las primeras fases de desarrollo de sus documentos. Los problemas de accesibilidad que se identifican pronto son más fáciles de subsanar y evitar.
A continuación se indican algunos métodos importantes de validación, discutidos con más detalle en la sección de validación del documento de técnicas (inglés).
El arte ASCII es una combinación de caracteres de texto y símbolos para crear una imagen. Por ejemplo, ;-) es el emoticón sonriente. La figura siguiente en ASCII muestra la relación entre la frecuencia de parpadeo y la respuesta fotoconvulsiva en pacientes con ojos abiertos y cerrados:
% __ __ __ __ __ __ __ __ __ __ __ __ __ __
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 (Herzios)
p, strong o blockquote en HTML— que especifica la estructura de un documento se conoce por el nombre de elemento estructural. La presentación de un documento es la forma en que el documento es interpretado —por ejemplo, como impresión, como una presentación bidimensional gráfica, como una presentación de sólo-texto, como voz sintetizada, como braille, etc.—. Un elemento que especifica la presentación de un documento —por ejemplo, b, font o center— se conoce por el nombre de elemento de presentación.h2. Finalmente, la presentación del encabezado sería un bloque de texto en negrita al margen, una línea de texto centrada, un título leído con una cierta entonación —a través de una fuente aural—, etc.p, li o table en HTML—, algunos son reemplazados por contenidos externos —por ejemplo, img—, y algunos afectan a procesos —por ejemplo, style o script causan que cierta información sea procesada como una hoja de estilo o un motor de script—. Un elemento que causa que caracteres de texto formen parte de un documento recibe el nombre de elemento de texto.alt en HTML o SMIL—, como parte del contenido del elemento —como en el caso de object en HTML—, como parte de la redacción del documento, o por medio de un documento vinculado —por ejemplo, designado por medio del atributo longdesc en HTML—. Dependiendo de la complejidad del equivalente, puede que sea necesario combinar varias de estas técnicas —por ejemplo, el empleo de alt para un equivalente abreviado, útil para lectores familiarizados con él, además de longdesc para un vínculo a información más detallada, útil para aquellos que se enfrenten al contenido por primera vez—. Los detalles de cómo y cuándo proporcionar información equivalente son parte del documento de técnicas (inglés).lang de HTML —véase su recomendación (inglés), y la última versión (inglés)8— y el atributo xml:lang en XML —véase la recomendación (inglés), y la última versión (inglés)9.b o i de HTML. Observe que los elementos strong y em no se consideran marcado de presentación en la medida en que proporcionan información sobre el énfasis puesto en un contenido, y que es independiente de un estilo de fuente en particular.
El texto original se encuentra en http://www.w3.org/TR/WAI-WEBCONTENT/ (inglés), y los derechos pertenecen al W3C (MIT, INRIA, Keio).
Esta traducción pertenece a su autor, y está sometida a las restricciones de esta licencia de Creative Commons.
(cc) CodexExempla.org, 2007–2025 Mapa del sitio | XHTML | CSS | AA