Estudio completo: [Tabla de Contenido] [Sección Anterior] [Sección Siguiente]

Símbolo de Accesibilidad a la Red para Personas con DiscapacidadD

Estudio de Accesibilidad a la Red

Apéndice 1. Criterios de accesibilidad WAI (traducidos al castellano)

Aviso: este documento ha quedado obsoleto.
Se recomienda visitar la versión más reciente traducida por Carlos Egea y Alicia Sarabia
.

Traducido por la Unidad de Investigación Acceso de la Universitat de València Estudi General.
Ver notas sobre la traducción y el copyright.

Versiones en castellano:
Esta versión:
http://acceso.uv.es/accesibilidad/estudio/PAGEAUTH.htm
traducción de la versión original en inglés http://www.w3.org/TR/1998/WD-WAI-PAGEAUTH-0414.html
La última versión disponible la encontrará siempre en:
http://www.sidar.org
Las versiones anteriores:
no existen.

W3C   WD-WAI-PAGEAUTH-0414

Criterios de accesibilidad WAI: 
Creación de páginas

Borrador de Trabajo del W3C     14-Abril-1998

Aviso: este documento ha quedado obsoleto.
Se recomienda visitar la versión más reciente.

Versiones originales en inglés:
Esta versión:
http://www.w3.org/TR/1998/WD-WAI-PAGEAUTH-0414.html
La última versión:
http://www.w3.org/TR/WD-WAI-PAGEAUTH.html
Las versiones anteriores:
http://www.w3.org/WAI/GL/WD-WAI-PAGEAUTH-0413.html
http://www.w3.org/WAI/GL/WD-WAI-PAGEAUTH-0410.html
http://www.w3.org/WAI/GL/WD-WAI-PAGEAUTH-0203.html
Editores:
Gregg Vanderheiden, Trace Research and Development
Wendy Chisholm, Trace Research and Development
Ian Jacobs, W3C
 
Por favor, véase la sección de Reconocimientos del Apéndice para obtener una lista completa de los contribuyentes.

Estado de este documento. obsoleto.

Este es un Borrador de Trabajo del W3C para la revisión por parte de los miembros del W3C y de otros grupos interesados. Este es un documento borrador y puede ser actualizado, sustituido o declarado obsoleto a partir de otros documentos en cualquier momento. Es inapropiado utilizar los Borradores de Trabajo del W3C como material de referencia o citarlos como otra cosa que no sea "trabajo en curso". Esto es un trabajo en curso y no implica ningún tipo de aprobación o de consenso por parte, bien del W3C o de los miembros del Grupo de Trabajo WAI GL.

Este documento ha sido elaborado como parte de la Actividad de la WAI del W3C, y pretende que sirva de borrador para una Propuesta de Recomendación destinada a la creación de páginas Web accesibles. El objetivo del Grupo de trabajo WAI-GL es debatir según nuestro documento de constitución.

Resumen

Este documento es una lista de criterios de marcado que los autores de HTML deberían seguir con el fin de hacer más accesibles las páginas Web para personas con discapacidad y más útiles para las herramientas de indexado. A continuación de esta lista de criterios, se presenta un lista de comprobación que los autores y los encargados de sitios Web deberían emplear para verificar la accesibilidad de las páginas. Las herramientas que generan los documentos en HTML (herramientas de autor, paquetes de conversión de archivos u otros productos) deberían producir documentos que siguiesen estos criterios. Este documento forma parte de una serie de documentos sobre accesibilidad publicados por la Iniciativa sobre Accesibilidad Web (Web Accessibility Initiativ, WAI).

Comentarios

Por favor, envie los comentarios de manera detallada sobre este documento a w3c-wai-gl@w3.org. Los comentarios públicos sobre los criterios de creación de la WAI pueden también remitirse a esta lista de distribución.

Observación.  Algunas personas han hallado problemas de impresión en esta página debido al uso de hojas de estilo. Hemos intentado corregir el problema pero solicitamos que nos ayudéis a investigar sobre otras posibles soluciones.


Tabla de Contenidos

Introducción
Valoración y clasificación
1. Estilo y estructura
2. Imágenes y mapas interactivos
3. Mini-aplicaciones y guiones
4. Audio y vídeo
5. Tablas
6. Enlaces
7. Marcos
8. Formularios de entrada de datos por parte del usuario
9. Si todo lo demás falla...
10. Buenas costumbres para el diseño de sitios Web
Apéndice A - Ejemplos de tablas
Apéndice B - Criterios sobre el uso de texto alternativo
Lista de comprobación
Reconocimientos
Referencias

Introducción

Este documento recomienda algunos criterios que los autores de HTML deberían seguir con el fin de mejorar la accesibilidad de las páginas. Algunos de estos criterios se aprovechan de las características de HTML 4.0, pero muchos de éstos son también aplicables a versiones anteriores del lenguaje.

Las medidas para mejorar la accesibilidad se clasifican más o menos en las categorías siguientes:

Estructura
Los documentos HTML que contienen muchas etiquetas para el marcado de la maquetación y no suficientes etiquetas de marcado para transmitir la estructura plantean problemas de accesibilidad para los usuarios ciegos o con problemas visuales. Los autores deberían utilizar etiquetas de marcado HTML referentes a la estructura con el fin de transmitir el significado y hojas de estilo para transmitir el formato y la maquetación de las páginas.
Navegación
Los autores deberían habilitar la navegación mediante el solo uso del teclado (acceso a los hiperenlaces, la navegación entre los enlaces, la navegación entre los campos de formulario, la navegación en el interior y entre las páginas) y páginas de diseño que promuevan una fácil orientación (las listas numeradas, los títulos, etc.).
Formato alternativo
Los autores deberían también proporcionar modos alternativos para acceder a la información que se presente, ya sea mediante imágenes, sonidos, mini-aplicaciones, y guiones. Por ejemplo, los subtítulos y las transcripciones proporcionan información sonora de forma accesible a personas que no pueden oirla. Una sustitución de tipo texto de un gráfico, bien mediante una descripción de su contenido o funcción, proporciona información en un formato accesible para aquellas personas que no la pueden ver.

Las secciones siguientes ofrecen criterios específicos que los autores de HTML deberían utilizar para mejorar la accesibilidad de sus páginas.


Valoración y Clasificación

A cada criterio se acompaña de una valoración que describe su importancia:

[Obligado]
Obligado, de lo contrario será imposible que la página sea comprendida por uno o más grupos de usuarios.
[Recomendado]
Hace que la página sea más fácil de comprender y de utilizar.

Cada criterio puede ser implementado mediante una o más "estrategias" en HTML (y posiblemente mediante el lenguaje de hojas de estilo CSS). Cada estrategia puede ser clasificada según la urgencia de su aplicación:

[Provisional]
Esta estrategia es necesaria para hacer que las páginas sean más accesibles para los visualizadores y las tecnologías asistentes de hoy en día.
[Nueva]
Esta estrategia se aprovecha de las características que se están introduciendo en los visualizadores y en la tecnología asistente del mañana (que incorporan las recomendaciones de la WAI).

Las estrategias que no se encuentran clasificadas bajo ninguna de las estrategias anteriores funcionan para versiones de HTML anteriores a HTML 4.0, y para visualizadores antiguos o nuevos.


1. Estilo y estructura

  1. [Obligado]
      Utilice elementos y atributos que estén de acuerdo con la Definición de Tipo de Documento ( Document Type Definition, DTD) HTML 4.0 y CSS-1.
    El W3C ofrece un servicio de validación del lenguaje HTML en  http://validator.w3.org/ que puede emplearse para determinar si un sitio cumple con una de las DTDs de HTML 4.0 (existen tres: estricta, transitoria y fija según el marco definido - véase el servicio de validación para más información). Se recomienda, pero no se considera por el momento obligatorio, que las páginas se ajusten a la definición estricta.
  2. [Obligado] 
      Asegúrese que las páginas son legibles y funcionales sin el uso de hojas de estilo
    para los visualizadores que no las soportan o para los usuarios que las desactivan. Como las hojas de estilo son una característica nueva, los visualizadores más antiguos no las soportarán y los nuevos visualizadores todavía tardarán un poco hasta que las soporten de manera estándar.
  3. [Obligado]
      Anide los títulos de forma adecuada.
    Como algunos usuarios hojean un documento desplazándose a través de sus títulos, es importante que se incrementen los niveles de título de forma correcta (H1 seguido de H2, mas bien que H1 seguido de H3). Los títulos que se utilizan para otros propósitos, como, por ejemplo, para dar formato al texto en un tamaño de fuente más grande, pueden desorientar a los usuarios; utilice las hojas de estilo para dar formato. Observación.  Véanse los ítems 9 y 10 en esta sección.
  4. [Obligado]
      Codifique la estructura de las listas y los ítems de lista de forma adecuada.
    Los elementos de lista HTML (DL, UL, OL, LI) deberían solamente utilizarse para crear listas. Evite utilizar los elementos de lista para efectos de presentación tales como el indetado.

    [Nueva] Utilice hojas de estilo antes que los atributos HTML para controlar el espaciado entre los ítems. Observación. Véase ítem 7 en esta sección.

  5. [Obligado]
      Evite el texto parpadeante o que se desplaza.
    [Provisional] Los autores deberían evitar los elementos BLINK y MARQUEE. Ante todo, estos elementos no forman parte del HTML 4.0 (éstos son extensiones propietarias y deberían evitarse. Véase ítem 1). En segundo lugar, el texto parpadeante y que se desplaza se lee de forma incorrecta o no puede leerse a través de los lectores de pantalla, puede afectar de forma desfavorable a las personas con discapacidad de tipo cognitivo y es a menudo molesto para las personas en general (véase el libro de Jared Spool, "Web Site Usability"). Los autores deberían utilizar las hojas de estilo para llamar la atención en el texto de manera diferente, como el uso de fuentes, tamaños o colores diferentes.
  6. [Recomendado]
      Utilice hojas de estilo mas bien que la conversión del texto a imágenes.
    Por ejemplo, el texto estilizado sobre un fondo coloreado puede crearse mediante las hojas de estilo en vez de mediante una imagen. Esto proporciona flexibilidad para las personas que deseen visualizar el texto de una forma que sea más legible para ellos incluyendo la ampliación de caracteres, en una combinación particular de colores como blanco sobre negro, o en una fuente particular.
  7. [Recomendado]
    Utilice hojas de estilo mas bien que imágenes invisibles o transparentes para forzar la maquetación de la página.
    Observación. Los visualizadores actuales (abril de 1998) todavía no soportan el uso de hojas de estilo para algunos tipos de posicionamiento, tal como el absoluto.
  8. [Recomendado]
     Evite el uso de elementos y atributos de presentación desaprobados (al igual que B y I).
    Los autores deberían utilizar hojas de estilo en vez de elementos de presentación (TT y FONT) y atributos ("align" y "background") que controlen la presentación visual. Se anima a los autores a utilizar elementos (tales como STRONG, EM, H1, H2, ABBR, etc.) que añaden estructura a los documentos.  Los documentos que utilizan las hojas de estilo para la presentación permiten a los usuarios ajustar el aspecto del documento ( p.e., letras más grandes, mayor contraste de color, etc.) a través de las hojas de estilo personal o de las configuraciones del visualizador.
  9. [Recomendado]
      Utilice elementos y atributos que transmitan la estructura de forma adecuada.
    Los elementos de frase incluyen: EM, STRONG, DFN, CODE, SAMP, KBD, VAR, CITE, ABBR, y ACRONYM
    Los elementos estructurales:  H1, H2, etc.
    Los elementos estructurales imponen consistencia a los documentos y proporcionan información a otras herramientas (p.e. herramientas de indexado, motores de búsqueda, programas que transfieren tablas a una base de datos, a los visualizadores que utilizan elementos de encabezado ( H1, H2, etc.) para generar herramientas de navegación, etc.).
  10. [Recomendado]
      No utilice de manera incorrecta los elementos y atributos estructurales para propósitos de maquetación. 
    Por ejemplo, no utilice el elemento BLOCKQUOTE para indentar un párrafo que no sea una cita; utilice las hojas de estilo. No utilice PRE para crear una presentación de texto en forma de tabla; utilice para ello las tablas.
  11. [Recomendado]
      No utilice de forma inadecuada los elementos de presentación para propósitos de estructura.
    Por ejemplo, mientras una regla horizontal (HR) podría transmitir un cambio de estructura a algunos usuarios, puede que no sea así para todos ellos. En su lugar, especifique la estructura con DIV y SPAN. Por ejemplo:
    <DIV class="navigation-bar">
    <HR title="Navigation bar">
    [ <A rel="Next" href="next.html">Next page</A> |
      <A rel="Previous" href="previous.html">Previous page</A> |
      <A rel="First" href="first.html">First page</A> ]
    </DIV>
  12. [Recomendado]
      Proporcione títulos para reglas horizontales, acrónimos y abreviaciones.
    Por ejemplo:
    <HR title="new section">
    <ABBR title="Idaho">ID</ABBR>
    <ACRONYM title="World Wide Web">WWW</ACRONYM>

Consejos y trucos

Para más información:

  1. Hojas de estilo - Capítulo 14 en el Documento de Referencia Central
  2. Hojas de estilo - la especificación HTML 4.0
  3. Hojas de estilo en cascada, nivel 2 -- Borrador de trabajo del Consorcio World Wide Web
  4. Texto - Capítulo 9 en el Documento de Referencia Central
  5. Texto - la especificación HTML 4.0
  6. Listas y formato - Capítulo 10 en el Documento de Referencia Central
  7. Listas - la especificación HTML 4.0

2. Imágenes y mapas interactivos

Por favor, consulte también la sección sobre enlaces.

  1. [Obligado] 
    Proporcione texto alternativo para todas las imágenes y mapas interactivos.

    Cada imagen debería poseer texto alternativo que represente la función del gráfico. Utilice una etiqueta funcional basada en el contexto en el cual se utiliza, mas bien que una descripción visual. Un buen test para determinar si el texto alternativo es útil es imaginar la lectura del documento en voz alta a través del teléfono. ¿Qué diría si encontrase esta imagen con el fin de hacer la página comprensible al oyente? Posibles estrategias para proporcionar texto alternativo incluyen:
    1. El atributo "alt" es obligado para los elementos AREA y IMG. Debería también utilizarse para los botones usados como botones de envío en formularios (elementos INPUT y BUTTON). Por ejemplo: <IMG src="magnifyingglass.gif" alt="Search">. Sin embargo, las recomendaciones para texto alternativo varían dependiendo de cómo se utilice el gráfico (decoración, botón, viñeta, ilustración, etc.).  Por favor véase el Apéndice B - Criterios para el uso de texto alternativo para más información.
    2. [Nueva] Si el elemento OBJECT se utiliza, el texto puede proporcionarse en el cuerpo del elemento OBJECT.  Por ejemplo:

    3. <OBJECT data="magnifyingglass.gif">Search</OBJECT>

    Observación. Se deben proporcionar descripciones más largas para el aspecto de una imagen. Véase la siguiente recomendación sobre estrategias que pueden servir de solución.

  2. [Obligado] 
    Proporcione una descripción más larga para los gráficos que presenten información importante (sobre todo gráficos, tablas y diagramas). 

    El texto alternativo (véase la estrategia 2.1 arriba) es normalmente corto y define el propósito esencial de un elemento gráfico. Para describir el gráfico mismo con más detalle, proporcione una descripción más larga con uno de los siguientes mecanismos (la mayoría de estos métodos enlazan con información adicional):
    1. [Provisional] Proporcione un enlace de descripción (enlace D) al lado del gráfico.  El enlace D enlaza con una página o una frase en la parte inferior de la página con una descripción más larga del gráfico. Por ejemplo:
      <IMG src="97sales.gif" alt="Sales for 1997">
      <A href="sales.html" title="Description of 1997 sales figure">D</A>
    2. [Nueva] Utilice el atributo "longdesc" del elemento IMG. Por ejemplo:
      <IMG src="97sales.gif" alt="Sales for 1997" longdesc="sales.html">
    3. [Nueva] Proporcione texto dentro del cuerpo del elemento OBJECT:
      <OBJECT data="sales.gif">
      Sales in 1997 were down subsequent to ...
      </OBJECT>
    4. Incluya texto interno en un archivo de imagen cuando el formato de éste lo soporte, por ejemplo PNG.
  3. [Obligado] 
      Asegúrese que la información del mapa interactivo es accesible y navegable mediante el teclado.

    La manera más fácil de satisfacer esta recomendación es utilizar un mapa interactivo de tipo cliente, ya que los visualizadores que no muestran los gráficos pueden utilizar los valores del atributo "alt" o "title" de los elementos AREA para presentar una lista de enlaces en lugar de un gráfico que represente un mapa interactivo. El desplazamiento mediante el teclado a áreas dentro del mapa interactivo es también posible si el visualizador conoce las coordenadas de las áreas definidas.

    Cuando se deba utilizar un mapa interactivo de tipo servidor, los autores deberían proporcionar una lista alternativa de las opciones contenidas en la imagen del mapa. Si una lista alternativa de enlaces sigue al mapa interactivo, los autores deberían indicar con el atributo "alt" del elemento IMG la existencia y el lugar de la lista alternativa. Una solución más inmediata, aunque más reciente y menos compatible con los navegadores anteriores, sería la de incluir enlaces alternativos dentro del cuerpo de un elemento OBJECT (Véase ejemplos abajo). Una última posibilidad es la de crear una página alternativa que sea accessible.

    Para mapas interactivos de tipo cliente, existen diversas estrategias de solución:

    1. Si el elemento MAP se ha utilizado con AREA, fije el atributo "alt" del elemento AREA. Por ejemplo, con el elemento IMG:

      <IMG src="welcome.gif" alt="Image map of areas in the library"
           usemap="#map1">
      <MAP name="map1">
        <AREA shape="rect" coords="0,0,30,30" href="reference.html" 
              alt="Reference">
        <AREA shape="rect" coords="34,34,100,100" href="media.html"
              alt="Audio Visual lab">
      </MAP>
    2. [Nueva] La misma idea, esta vez utilizando la información: elemento OBJECT con flexibilidad para incluir más información.

      <OBJECT data="welcome.gif" usemap="#map1">
       There are several areas in the library  including 
       <A href="reference.html">Reference</A>
       and <A href="media.html"> the Audio VisualLab</A>.  
       More text can follow or precede.
      <MAP name="map1">
         <AREA shape="rect" coords="0,0,30,30" 
               href="ref.html" alt="Reference">
         <AREA shape="rect" coords="34,34,100,100" 
               href="media.html" alt="Audio Visual Lab">
      </MAP></OBJECT>
    3. [Nueva] El elemento MAP puede usarse con elementos A para especificar las coordenadas de las regiones activas y proporcionar información contextual.

      <OBJECT data="navbar1.gif" type="image/gif" usemap="#map1">
      <MAP name="map1">
      <P>Navigate the site:
       <A href="guide.html" 
          shape="rect" coords="0,0,118,28">Access Guide</a> |
       <A href="shortcut.html" 
          shape="rect" coords="118,0,184,28">Go</A> |
       <A href="search.html" 
          shape="circle" coords="184,200,60">Search</A> |
       <A href="top10.html" 
          shape="poly" coords="276,0,373,28,50,50">Top Ten</A>
      </MAP>
      </OBJECT>

      Observe en este ejemplo que el elemento MAP es el contenido del elemento OBJECT para que los enlaces alternativos se muestren solamente si el mapa interactivo (navbar1.gif) no está presente.

  4. [Recomendado] 
    Proporcione títulos descriptivos para las imágenes utilizadas como enlaces. 

    Utilice el atributo "title" del elemento A para proporcionar más información sobre las imágenes utilizadas como enlaces. Por ejemplo:
    <A href="home.html" title="Search the whole XYZ company site">
       <IMG src="magnifyingglass.gif" alt="Search">
    </A>
  5. [Recomendado] 
    Evite el uso de caracteres ASCII como representaciones gráficas. Sustitúyalos por una imagen y texto alternativo.
    Los caracteres tipográficos de uso común a evitar son los 'smileys' o emoticones y las flechas consistentes en guiones y signos de mayor a menor (p.e., -->), etc.

Para más información:

  1. Del Documento de Referencia Central
  2.  
    1. 13.1 Introducción a los temas
    2. 13.2 Recomendaciones generales
    3. 13.3 Visualización e interacción con imágenes estáticas y mapas interactivos
  3. Objetos, imágenes y mini-aplicaciones - la especificación HTML 4.0

3. Mini-aplicaciones (applets) y guiones (scripts)

  1. [Obligado] 
     Proporcione presentaciones alternativas de contenido para cada guión y mini-aplicación que transmita algún tipo de información.
    1.   [Nueva] El elemento NOSCRIPT permite a los autores proporcionar presentaciones alternativas del contenido para los guiones. Por ejemplo:
      <SCRIPT type="text/tcl">
      ...some Tcl script to show a billboard of sports scores...
      </SCRIPT>
      <NOSCRIPT>
      <P>Results from yesterday's games: 
      Bulls 91, Sonics 80  <A href="bullsonic.html">Bulls v. Sonics game recap</A>
      ...more scores...
      </NOSCRIPT>
    2. [Provisional] Proporcione una descripción como contenido del elemento APPLET.
      <APPLET code="Press.class" width="500" height="500"

              alt="Java applet: how temperature affects pressure.">
      As temperature increases the molecules in the balloon...
      </APPLET>

      Observación. Se desaconseja el uso del elemento APPLET en HTML 4.0.

    3. [Nueva] Proporcione una descripción como contenido del elemento OBJECT.
      <OBJECT classid="java:Press.class" width="500" height="500"

              title="Java applet: how temperature affects pressure.">
      As temperature increases the molecules in the balloon...
      </OBJECT>

      Una versión más compleja se aprovecha del hecho de que los elementos OBJECT pueden insertarse dentro de otros para proporcionar representaciones alternativas de la información:

      <!-- First, try the pressure applet -->
      <OBJECT title="How temperature affects pressure"
              classid="java:Press.class" width="500" height="500">
         <!-- Else, try the MPEG video -->
         <OBJECT data="pressure.mpeg" type="video/mpeg">
            <!-- Else, try the GIF image -->
            <OBJECT data="Pressure.gif">
               <!-- Else render the description and an alternative -->
               As temperature increases the molecules in the balloon...
      </OBJECT></OBJECT></OBJECT>
  2. [Obligado] 
      Proporcione mecanismos alternativos para cada guión y mini-aplicación que realice una función importante, diferente a la presentación de información. 

    Por ejemplo, una mini-aplicación recoge información para una base de datos. Los mecanismos para la recogida de información como un formulario de entrada de datos del usuario, la dirección de correo electrónico, el número de teléfono o fax deberían proporcionarse dentro del contenido, bien de los elementos APPLET o de los elementos OBJECT.
  3. [Obligado] 
      Si una mini-aplicación requiere la interacción del usuario (p.e., la habilidad para manipular un experimento de física) y no puede ser traducida a un formato alternativo, haga que la mini-aplicación sea directamente accesible.

    Se dispone de más información a través de la página de Accesibilidad Java en el Trace Center.
  4. [Obligado]
      Proporcione un mecanismo para el usuario que paralice todo objeto en movimiento o que parpadee, en especial aquellos que contienen texto. 
    En un ejemplo creado por Mark Novak, si el usuario pulsa la tecla de Escape mientras la mini-aplicación Java está en activo, el texto se mostrará de forma estática. Visualice el ejemplo.
  5. [Recomendado]
      Proporcione texto alternativo para cada mini-aplicación.
    Proporcionar el contenido dentro del cuerpo del elemento APPLET o OBJECT (ítem 1 en esta sección) es el método preferido para proporcionar texto alternativo, ya que es compatible con versiones o especificaciones anteriores.
    1. [Provisional] Utilice el atributo "alt" del elemento APPLET, como en :

      <APPLET code="Duke.class" width="50" height="50" 
              alt="Java applet: Duke waving.">
      </APPLET>

      Observación. El elemento APPLET se desaconseja en HTML 4.0.

    2. [Nueva] Cuando se utilice el elemento OBJECT, especifique texto alternativo dentro del atributo "title" o dentro del cuerpo del elemento OBJECT (véase ítem 1 en esta sección):

      <OBJECT classid="Duke.class" width="50" height="50" 
              title="Java applet: Duke waving.">
      </OBJECT>
  6. [Recomendado]
      Haga que los guiones y las mini-aplicaciones puedan funcionar mediante el teclado.

Observación. Se necesita más investigación en este área. Por favor, manténgase al corriente.

Para más información:

  1. Del Documento de Referencia Central
    1. 13.1 Introducción a los temas
    2. 13.2 Recomendaciones generales
    3. 13.4 Mini-aplicaciones
    4. 18 Guiones
  2. Objetos, Imágenes y mini-aplicaciones - la especificación HTML 4.0
  3. Guiones - la especificación HTML 4.0
  4. Criterios de IBM para la creación de aplicaciones accesibles utilizando Java 100% puro -- Sistemas IBM para Necesidades Especiales

4. Audio y vídeo

  1. [Obligado]
      Proporcione una transcripción en formato texto de toda la información sonora.
    Las transcripciones sonoras completas incluyen tanto el diálogo como cualquier otro sonido significativo incluyendo sonidos que se reflejan o no en la pantalla, música, carcajadas, aplausos, etc. Cuando estas transcripciones se presentan de forma sincrónica con una presentación de vídeo se denominan "subtítulos" y se utilizan por personas que no pueden oir la pista de sonido del material de vídeo.
  2. [Obligado]
      Proporcione descripciones de toda la información de vídeo en forma sonora, sincronizadas con el canal de audio. 
    Las descripciones de vídeo se utilizan fundamentalmente por personas ciegas con el fin de seguir la acción y otra información de carácter no auditivo incluida en el material de vídeo. La descripción proporciona la narración de los elementos visuales principales sin interferir con el sonido o el diálogo de la película. Los elementos visuales clave incluyen acciones, escenarios, lenguaje gestual, gráficos, y texto mostrado.
  3. [Obligado]
      Proporcione descripciones de toda la información de vídeo en formato texto.
    Una transcripción texto de las descripciones de vídeo proporciona la misma información como se indica en la recomendación 4.2, pero en formato texto. 
    Esta transcripción de texto, en combinación con la transcripción sonora completa (4.1), permite su acceso a personas tanto con deficiencias visuales como auditivas. Esto proporciona también a todos la habilidad de indexar y buscar la información contenida en materiales de tipo audiovisual.
  4. [Obligado]
      Sincronice la descripción del texto y del vídeo con la información de audio y vídeo, bien directamente o a través de un fichero de sincronización.
    Algunos formatos multimedia, como QuickTime 3.0, permiten añadir subtítulos y descripciones de vídeo al clip multimedia.
    1. [Provisional] Hasta que el formato en cuestión soporte pistas alternativas, se podrían proporcionar dos versiones de la película, una con subtítulos y con vídeo descriptivo y otra sin estos.
    2. [Nueva] Las tecnologías del futuro permitiran separar los ficheros sonoros y visuales para combinarlos con archivos de texto a través de un fichero de sincronización con el fin de crear películas y sonido con subtítulos. También permitirá al usuario elegir entre múltiples juegos de subtítulos con el fin de acomodarse a sus habilidades de lectura. Para más información véase la especificación SMIL.
  5. [Recomendado]
      Proporcione un aviso de tipo visual de aquellos sonidos que se reproducen de forma automática. 
    Esto se puede proporcionar en forma de una frase textual en la página que enlace a una transcripción o descripción tipo texto del archivo de sonido. El enlace a la transcripción debería aparecer en un lugar altamente visible como la parte superior de la página. Sin embargo, si un guión carga de forma automática un sonido, debería también ser capaz de cargar automáticamente un aviso visual indicando que el sonido se está reproduciendo en ese momento y proporciona una descripción o transcripción del sonido. La problemática que envuelve esta recomendación es que el visualizador debería cargar la forma visual de la información en vez de la forma sonora si las preferencias del usuario así lo especifican. Sin embargo, las estrategias deben también funcionar con los visualizadores de hoy en día.
  6. [Recomendado]
      Utilice el atributo "title" para proporcionar una breve descripción de un sonido muy corto.
    Por ejemplo: <A href="mittens.wav" title="meow">Calico says "hello"</A>

Para más información:

  1. Del Documento de Referencia Central
    1. 13.1 Introducción a los temas
    2. 13.2 Recomendaciones generales
    3. 13.5 Audio y vídeo
  2. Objetos, imágenes y mini-aplicaciones - la especificación HTML 4.0
  3. Ejemplos de NCAM

5. Tablas

  1. [Obligado]
      Asocie las celdas de las tablas con etiquetas correspondientes a la fila y a la columna de manera explícita.
    Los futuros visualizadores y las tecnologías asistentes podrán traducir automáticamente las tablas en secuencias lineales si las tablas se etiquetan de forma adecuada. [Nueva] Una forma de etiquetar las celdas es con los atributos "headers" y "scope". Por favor refiérase a los primeros dos ejemplos de tabla en el apéndice.
  2. [Obligado]
      Evite el uso de tablas para formatear documentos de texto en columnas.
  3. [Recomendado]
      Para las tablas de texto y números, proporcione una página alternativa que presente la información de la tabla de forma lineal. 
  4. [Recomendado]
      Evite utilizar las tablas para maquetar una página. 
    [Nueva] Los autores deberían utilizar hojas de estilo para posicionar los gráficos y el texto.
  5. [Recomendado]
      Proporcione abreviaciones para etiquetas de fila o columna extensas.
    [Nueva] Las abreviaciones para el encabezado de la fila y la columna (el atributo "abbr") debería ser corto pero significativo. Esto será especialmente útil para las tecnologías del habla futuras que leeran las etiquetas de fila y columna para cada celda. Las abreviaciones reducen el tiempo de lectura y evitan la repetición. Por favor, refiérase a los ejemplos en el apéndice.
  6. [Recomendado]
      Proporcione resúmenes de las tablas.
    [Nueva] Los resúmenes de la estructura de la tabla y de su propósito (el atributo "summary" del elemento TABLE) son especialmente útiles para los usuarios ciegos. Por favor, refiérase a los ejemplos en el apéndice.
  7. [Recomendado]
      Para tablas más complejas, agrupe la información en categorías.
    [Nueva] Los futuros visualizadores permitirán a los usuarios seleccionar los datos de una tabla filtrando éstos en base a unas categorías. Por favor, refiérase al tercer ejemplo (el atributo "axis") en el apéndice.
  8. [Recomendado]
      Asegúrese que el texto alternativo no pasa a la tabla siguiente cuando se utiliza ésta para posicionar los gráficos. 
    [Provisional] Compruebe que no se produce este efecto utilizando un tamaño de ventana equivalente que puede ampliarse para caber en un monitor de 15 pulgadas utilizando una resolución estándar como 800x600 píxeles.
  9. [Recomendado]
      Proporcione un número de teléfono, un número de fax o una dirección de correo electrónico si las tablas no pueden hacerse accesibles. 

 

Consejos y trucos

Para más información:

  1. Tablas - Capítulo 11 en el Documento de Referencia Central
  2. Tablas - la especificación HTML 4.0

6. Enlaces

Por favor, consulte también la sección sobre mapas interactivos.

  1. [Recomendado]
      Cree frases para los enlaces que tengan sentido cuando se lean en voz alta fuera de contexto, pero que no sean demasiado densas. 
    Los usuarios que son ciegos a menudo saltan de un enlace a otro cuando están hojeando una página o buscando información. Cuando hacen esto, sólo se lee el texto del enlace ("link text"). Por tanto, es importante que el texto del enlace tenga sentido cuando se lea sin el texto que lo rodea. Por ejemplo, los autores no deberían utilizar "haga clic aquí" como enlace tipo texto varias veces en la misma página; esto requiere que un usuario hojee la página con un lector de pantalla saltando a través de cada enlace y que lea el texto que lo rodea para poder determinar la función del enlace. En su lugar, el texto del enlace debería contener la información suficiente, tal como en "bájase este documento en formato de texto ASCII," "visualice la versión completa en HTML," o "para la versión sólo texto, seleccione este enlace."
  2. [Recomendado]
      Sitúe caracteres no hipertexto, pero imprimibles (rodeados por espacios) entre los enlaces que se suceden de forma consecutiva con el fin de mantener de forma separada los enlaces y así evitar que sean leídos como uno solo por los lectores de pantalla (p.e., " | ").
    [Provisonal] Por favor consulte el ejemplo proporcionado en el criterio 5.3.
  3. [Recomendado]
    Proporcione accesos mediante el teclado para los enlaces.
    El atributo "accesskey" de los elementos LABEL, A, CAPTION, y LEGEND permiten a un autor asociar un acceso de teclado con la frase. Por ejemplo, cuando se asocia con un enlace, esto lleva al usuario al documento asociado.  <A accesskey="C" href="doc.html">XYZ company home page</A>

Para más información:

  1. Enlaces - Capítulo 12 en el Documento de Referencia Central
  2. Enlaces - la especificación HTML 4.0

7. Marcos

  1. [Obligado]
      Asegúrese que las páginas son leíbles y funcionales sin marcos. 
    [Nueva] Los autores deberían incluir un elemento NOFRAMES al final de cada FRAMESET. Por favor, refiérase al ejemplo en el Documento de Referencia Central.
  2. [Obligado]
    No incluya una imagen directamente en un marco -- póngala en un documento separado.
    [Nueva] De otra forma, si el contenido del marco cambia, el título del marco -- el único texto alternativo disponible en este caso -- ya no tendrá sentido. Si se incluye la imagen en su propio fichero permite a los autores especificar texto alternativo con los elementos IMG o OBJECT.
  3. [Obligado]
      Dé a cada marco un título.
    [Nueva] Las personas que acceden a la página de manera oral podrán tener conocimiento más fácilmente de cuántos marcos y cual es el marco actual. Por ejemplo:
    <FRAMESET cols="10%,90%" title="Our library of electronic documents">
    <FRAME src="nav.html" title="Navigation bar">
    <FRAME src="doc.html" title="Documents">
    <NOFRAMES><A href="lib.html" title="library link">
                 Select to go to the electronic library</A>
    </NOFRAMES>
    </FRAMESET>
  4. [Recomendado]
    Describa la maquetación y el propósito de los marcos y cómo se relacionan múltiples marcos con el resto.
    [Nueva] Utilice el atributo "longdesc" en los elementos FRAME y IFRAME para designar una descripción larga.

Para más información:

  1. Marcos - Capítulo 16 en ek Documento de Referencia Central
  2. Marcos - la especificación HTML 4.0

8. Formularios de entrada de datos por parte del usuario

  1. [Obligado]
      No utilice mapas interactivos para crear botones de "enviar" gráficos.
    En su lugar, utilice los elementos BUTTON o INPUT con texto alternativo.
  2. [Obligado]
      Asocie etiquetas con sus controles de formulario.
    Las etiquetas puede estar asociadas de manera explícita utilizando el atributo "for" del elemento LABEL.

    [Nueva] El atributo "for" del elemento LABEL permite la asociación explícita. Por ejemplo:

    <FORM action="http://somesite.com/adduser" method="post">
      <FIELDSET>
        <LEGEND>Personal information</LEGEND>
        <LABEL for="firstname">First name:</LABEL>
        <INPUT type="text" id="firstname" tabindex="1">
        <LABEL for="lastname">Last name:</LABEL>
        <INPUT type="text" id="lastname" tabindex="2">
        ...more personal information...
      </FIELDSET>
      <FIELDSET>
        <LEGEND>Medical History</LEGEND>
        ...medical history information...
      </FIELDSET>
    </FORM>
  3. [Obligado]
      Proporcione texto alternativo para las imágenes utilizadas como botones "enviar".
    Por ejemplo: <INPUT type="image" name="submit" src="button.gif" alt="Submit">
  4. [Recomendado]
      Especifique un orden de tabulado lógico entre los controles de formulario. 
    [Nueva] El atributo "tabindex" especifica el orden de la navegación mediante tabulador entre los controles de formulario. Por ejemplo:
    <INPUT tabindex="1" type="text" name="field1">
    <INPUT tabindex="2" type="text" name="field2">
    <INPUT tabindex="3" type="submit" name="submit">
  5. [Recomendado]
      Agrupe controles relacionados semánticamente y etiquete cada grupo.
    [Nueva] El nuevo elemento FIELDSET agrupa los controles de formulario mientras que el elemento LEGEND etiqueta cada grupo. Por favor, véase el ejemplo en el criterio 10.2.
  6. [Recomendado]
    Para listas largas de selecciones, agrupe los ítemes de forma jerárquica.
    [Nueva] En el futuro próximo, los visualizadores mostrarán listas agrupadas con niveles de detalle que se expanden y se contraen. Para agrupar ítems, utilce el elemento OPTGROUP (con el elemento SELECT). Por ejemplo:
    <FORM action="http://somesite.com/prog/someprog"
          method="post">
    <P><SELECT name="ComOS">
    <OPTGROUP label="Comm Servers">
    <OPTGROUP label="PortMaster 3">
    <OPTION label="3.7.1" value="pm3_3.7.1">PortMaster 3 with ComOS 3.7.1
      <OPTION label="3.7" value="pm3_3.7">PortMaster 3 with ComOS 3.7
      <OPTION label="3.5" value="pm3_3.5">PortMaster 3 with ComOS 3.5
    </OPTGROUP>
    <OPTGROUP label="PortMaster 2">
      <OPTION label="3.7" value="pm2_3.7">PortMaster 2 with ComOS 3.7
      <OPTION label="3.5" value="pm2_3.5">PortMaster 2 with ComOS 3.5
    </OPTGROUP>
    </OPTGROUP>
    <OPTGROUP label="Routers">
    <OPTGROUP label="IRX">
      <OPTION label="3.7R" value="IRX_3.7R">IRX with ComOS 3.7R
      <OPTION label="3.5R" value="IRX_3.5R">IRX with ComOS 3.5R
    </OPTGROUP>
    </OPTGROUP>
    </SELECT>
    </FORM>
  7. [Recomendado]
      Incluya caracteres por defecto que ocupen parte del espacio correspondiente a los cuadros de edición y áreas de texto.. [Provisional]
  8. [Recomendado]
      Incluya un número de teléfono, un número de fax, la dirección de correo electrónico, o la dirección postal como modo alternativo para enviar la información. [Provisional]
  9. [Recomendado]
      Proporcione acceso mediante teclado para elementos de formulario.
    [Nueva] Los acceso mediante teclado se asignan con el atributo "accesskey". Este ejemplo asigna a una "U" la tecla de acceso. Si se teclea la "U" queda en posición activa la etiqueta, que, a su vez, activa el control pudiendo el usuario introducir texto.
    <FORM action="submit" method="post">
    <LABEL for="user" accesskey="U">user name</label>
    <INPUT type="text" name="user">
    </FORM>

Para más información:

  1. Formularios - Capítulo 17 en el Documento de Referencia Central
  2. Formularios - la especificación HTML 4.0

9. Si todo lo demás falla...

Si, después de los mejores esfuerzos, todavía hay alguna página que resulta inaccesible, proporcione un enlace a una página alternativa que sea accesible, que contenga información equivalente y que se mantenga con la misma frecuencia que la página inaccesible. Las páginas alternativas no se consideran como práctica recomendada ya que el costes de mantenimiento aumente la probabilidad que las páginas alternativas queden desfasadas. Si las páginas alternativas se crean, éstas se deben actualizar de forma tan frecuente como las páginas principales y proporcionar información equivalente.

  1. Métodos para enlazar páginas alternativas:
    1. [Provisional] Proporcione un enlace en la parte superior de cada página para permitir al usuario desplazarse hacia atrás y hacia adelante entre el gráfico y las versiones alternativas de la página.
    2. [Nueva] Proporcione la información apropiada en el encabezado de la página principal (con el elemento LINK) para que el visualizador la cargue automáticamente. Si el usuario ha fijado su tipo de formato multimedia como "sonoro", "braille," o "tty" el agente del usario debería cargar la página alternativa automáticamente. Por ejemplo:

      <HEAD>
      <TITLE>Welcome to the Virtual Mall!</TITLE>
      <LINK title="Text-only version"
            rel="alternate" href="text_only.html"
            media="aural, braille, tty">
      </HEAD>

10. Buenas costumbres en el diseño de sitios Web

Siguiendo los criterios generales de diseño del sitio mejorará todavía más la accesibilidad.

  1. Cree un estilo consistente para las páginas.
  2. Utilice una estructura de navegación clara y consistente.
  3. Ofrezca barra de navegación para el acceso fácil a la estructura de navegación.
  4. Proporcione una descripción de la maquetación general del sitio, las características de acceso, y cómo utilizarlas.
  5. Ofrezca un mapa del sitio.
  6. Ofrezca diferentes tipos de búsquedas para diferentes niveles de habilidades y preferencias.
  7. Asegúrese que nada dentro del sitio impide el manejo del teclado.
  8. Asegúrese que los colores del texto y del fondo o de los diseños contrastan bien. (Un buen test es imprimir la página con una impresora en blanco y negro).
  9. Utilice una herramienta de diseño que soporte características de diseño (y que no elimine las características de accesibilidad cuando Ud. cierre, o vuelva a abrir su página utilizando la herramienta).
  10. Coloque información relevante al comienzo de los títulos, párrafos, listas, etc., para disminuir la cantidad de filtrado que deben realizar los lectores de pantalla para encontrar información importante. Esto se conoce normalmente como "carga frontal" y es especialmente útil para las personas que acceden a la información de forma secuencial.
  11. Cree un sólo fichero que pueda cargarse para aquellos documentos compuestos de una serie de hojas separadas. Esto ayuda a que las personas puedan leer los documentos sin estar conectados. Actualmente, se precisa un programa de compresión o compactación para crear ese fichero único. En el futuro próximo, los agentes de usuario podrán filtrar hojas separadas basándose en la información que figura en los encabezados de la página. El ejemplo siguiente muestra cómo indicar donde se encuentra la primera página del manual de referencia al igual que la página que sigue a la actual.
    <HEAD><TITLE>Reference manual -- Chapter 1</TITLE>
       <LINK rel="Start" title="The first page of the manual"
             type="text/html" 
             href="http://someplace.com/manual/start.html">
       <LINK rel="Next" title="Chapter 2" 
             type="text/html" 
             href="http://someplace.com/manual/ch2.html">
    </HEAD>
  12. Compruebe el sitio con al menos:
  13. Puede ser también útil comprobar un sitio con un visualizador de voz (como PWWebspeak)
  14. Valide las páginas con herramientas como:

Para más información:

Buenas costumbres en el diseño de sitios Web - Capítulo 25 en el Documento de Referencia Central


Apéndice A - Ejemplos de tablas

  1. "headers" - El siguiente ejemplo muestra cómo asociar la información del encabezado con el atributo "headers".  El atributo "headers" especifica una lista de celdas de encabezado (etiquetas de fila y columna) asociadas con la celda de datos actual. Esto requiere que cada celda de encabezado tenga un "id".
    <TABLE border="border" summary="This table charts the number of cups of 
    coffee consumed by each senator, the type of coffee (decaf or regular), 
    and whether taken with sugar.">
    <CAPTION>Cups of coffee consumed by each senator</CAPTION>
    <TR>
    <TH id="t1">Name</TH>
    <TH id="t2">Cups</TH>
    <TH id="t3" abbr="Type">Type of Coffee</TH>
    <TH id="t4">Sugar?</TH>
    <TR>
    <TD headers="t1">T. Sexton</TD>
    <TD headers="t2">10</TD>
    <TD headers="t3">Espresso</TD>
    <TD headers="t4">No</TD>
    <TR>
    <TD headers="t1">J. Dinnen</TD>
    <TD headers="t2">5</TD>
    <TD headers="t3">Decaf</TD>
    <TD headers="t4">Yes</TD>
    </TABLE>

    Un sintetizador de voz reproduciría lo siguiente:

               Caption: Cups of coffee consumed by each senator
               Summary: This table charts the number of cups of coffee
                        consumed by each senator, the type of coffee
                        (decaf or regular), and whether taken with sugar.
               Name: T. Sexton, Cups: 10, Type: Espresso, Sugar: No
               Name: J. Dinnen, Cups: 5, Type: Decaf, Sugar: Yes
  2. "scope" - El siguiente ejemplo asocia la misma información de encabezado y datos como en el ejemplo anterior, pero utiliza el atributo "scope" mas bien que "headers."  "Scope" debe tener uno de los valores siguientes: row, col, rowgroup o colgroup.  Scope especifica el juego de celdas de datos a ser asociada con la celda de encabezado actual. Este método es especialmente útil para las tablas simples. Este ejemplo podría ser reproducido por un sintetizador de voz como el ejemplo anterior.

    <TABLE border="border" 
    summary="This table charts the number of cups of coffee consumed by each senator, the
    type of coffee (decaf or regular), and whether taken with sugar.">
    <CAPTION>Cups of coffee consumed by each senator</CAPTION>
    <TR>
    <TH scope="col">Name</TH>
    <TH scope="col">Cups</TH>
    <TH scope="col" abbr="Type">Type of Coffee</TH>
    <TH scope="col">Sugar?</TH>
    <TR>
    <TD>T. Sexton</TD>
    <TD>10</TD>
    <TD>Espresso</TD>
    <TD>No</TD>
    <TR>
    <TD>J. Dinnen</TD>
    <TD>5</TD>
    <TD>Decaf</TD>
    <TD>Yes</TD>
    </TABLE>
  3. "axis" - El siguiente ejemplo muestra cómo crear categorias en el interior de una tabla.

    <TABLE border="border">
    <CAPTION> Travel Expense Report </CAPTION>
    <TR>
    <TH></TH>
    <TH id="a2" axis="expenses">Meals</TH>
    <TH id="a3" axis="expenses">Hotels</TH>
    <TH id="a4"
    axis="expenses">Transport</TH><TD>subtotals</ TD>
    </TR>
    <TR>
    <TH id="a6" axis="location">San Jose</TH>
    <TH></TH><TH></TH><TH></TH><TD> </TD>
    </TR>
    <TR>
    <TD id="a7" axis="date">25-Aug-97</TD>
    <TD headers="a6 a7 a2">37.74</TD>
    <TD headers="a6 a7 a3">112.00</TD>
    <TD headers="a6 a7 a4">45.00</TD><TD></TD>
    </TR>
    <TR>
    <TD id="a8" axis="date">26-Aug-97</TD>
    <TD headers="a6 a8 a2">27.28</TD>
    <TD headers="a6 a8 a3">112.00</TD>
    <TD headers="a6 a8 a4">45.00</TD><TD></TD>
    </TR>
    <TR>
    <TD>subtotals</TD><TD>65.02</TD><TD>224.00&
    </TD><TD>90.00</TD><TD>379.02</TD>
    </TR>
    <TR>
    <TH id="a10" axis="location">Seattle</TH>
    <TH></TH><TH></TH><TH></TH><TD> </TD>
    </TR>
    <TR>
    <TD id="a11" axis="date">27-Aug-97</TD>
    <TD headers="a10 a11 a2">96.25</TD>
    <TD headers="a10 a11 a3">109.00</TD>
    <TD headers="a10 a11 a4">36.00</TD><TD></TD>
    </TR>
    <TR>
    <TD id="a12" axis="date">28-Aug-97</TD>
    <TD headers="a10 a12 a2">35.00</TD>
    <TD headers="a10 a12 a3">109.00</TD>
    <TD headers="a10 a12 a4">36.00</TD><TD></TD>
    </TR>
    <TR>
    <TD>subtotals</TD><TD>131.25</TD><TD>218.00
    </TD><TD>72.00</TD><TD>421.25</TD>
    </TR>
    <TR>
    <TH>Totals</TH><TD>196.27</TD><TD>442.00
    </TD><TD>162.00</TD><TD>800.27</TD>
    </TR> 
    </TABLE>

Apéndice B - Criterios para el uso de texto alternativo

Recomendación general

En general, los autores deberían especificar texto alternativo que describa la función del gráfico o imagen y no su aspecto visual. Los autores deberían preguntarse esta pregunta: si estuvieses leyendo el documento en voz alta a través del teléfono, ¿qué dirías si encontrase esta imagen o gráfico para hacer la página comprensible al oyente?

Existen tres atributos de IMG que pueden usarse para proporcionar información textual sobre una imagen:

Observación.  El proporcionar texto alternativo para las imágenes dentro del elemento OBJECT es otro tema diferente y se cubrirá en el futuro.

 

Gráficos decorativos

Proporcione una equivalencia textual breve de la imagen. Proporcionar texto alternativo se considera obligado, mientras que el proporcionar una descripción más extensa es recomendable.
Ejemplo:  <IMG src="sailboats.gif" alt="Sailboats in calm water" longdesc="sailboatsdesc.html">
Luego, en el interior de sailboatsdesc.html:

A picture of ten sailboats docked in calm water at the edge of busy street in a small town.

Como algunos usuarios pueden no desear ver incluso una descripción breve del gráfico, manténgalas tan cortas como sea posible. En el futuro, se harán recomendaciones para el uso de hojas de estilo, valores de clase, y XML que permitirán a los usuarios seleccionar los tipos de imágenes que deseen cargar y visualizar.

 

Viñetas

  1. Marque los ítems de lista de forma correcta.
  2. Para listas desordenadas donde las viñetas no proporcionan información adicional utilice "ítem:" como texto alternativo. Evite utilizar hojas de estilo para proporcionar viñetas alternativas hasta que se encuentre una forma de asociar el texto alternativo con la imagen (véase Ejemplo 2).

    Ejemplo 1:
    <STYLE ...><!-- UL { list-style: none }-->
    <UL>
    <LI><IMG src="star.gif" alt="Item:">Audrey</LI>
    <LI><IMG src="star.gif" alt="Item:">Laurie</LI>
    <LI> ... </LI>
    </UL>

    Ejemplo 2: (Evitar)
    <STYLE ...><!-- UL { list-style: url(star.gif) }-->
    <UL>
    <LI> Audrey</LI>
    <LI> Laurie</LI>
    <LI> ... </LI>
    </UL>

  3. Para listas desordenadas donde las viñetas sí proporcionan información adicional, facilite la etiqueta en el texto alternativo.
    Ejemplo:
    <STYLE ...><!-- UL { list-style: none }-->
    <UL>
    <LI><IMG src="red.gif" alt="New:">Roth IRA</LI>
    <LI><IMG src="yellow.gif" alt="Old:">401 K</LI>
    <LI> ... </LI>
    </UL>
  4. Para listas ordenadas, proporcione el número del ítem en el texto alternativo.
    Ejemplo:
    <STYLE ...><!-- OL { list-style: none }-->
    Song titles on our fourth album.
    <OL>
    <LI><IMG src="bullet1.gif" alt="One:">Room</LI>
    <LI><IMG src="bullet2.gif" alt="Two:">Nice Guy</LI>
    <LI> ... </LI>
    </OL>

 

Enlaces y botones

Proporcione la frase de enlace textual en el texto alternativo (esto es, lo que debería decir si el enlace fuese texto en vez de gráfico).
Ejemplo:  <A href="routes.html"><IMG src="topo.html" alt="Current routes at Boulders Climbing Gym"></a>

 

Separadores de sección

Para los gráficos utilizados como separadores de sección (p.e., reglas horizontales) proporcione información sobre lo que representa el gráfico. En otras palabras, proporcione una pista de tipo textual equivalente en relación a lo que percibe el lector de pantalla.
Ejemplo:
<IMG src="redline.gif" alt="End of Chapter 7 - Visual Displays">
<H1>Chapter 8 - Auditory and Tactile Displays</H1>

 

Texto Bitmap

Si la imagen es simplemente un dibujo de texto estilizado o a color, entonces el texto alternativo debe ser el mismo que el texto de la imagen. <P>This is an <IMG src="BigRedExample.gif" alt="Example"> of what we mean.</P>

 

Imágenes invisibles utilizadas como espaciadores

Las imágenes invisibles o transparentes se utilizan a menudo para forzar la maquetación de una página. Proporcione "nada" (alt="") o "espacio en blanco" (alt="   ") como texto alternativo, según lo que se requiera de acuerdo con el contexto.

Ejemplo 1:  Se utiliza una imagen para crear un espacio cuidadosamente definido entre las palabras o los gráficos. "Espacio en blanco" como texto alternativo se utiliza para evitar que las palabras se junten cuando la imagen no se carga.
my poem requires a big space<IMG src="10pttab.gif alt="  ">here

Ejemplo 2: Se usa una imagen para forzar que un gráfico aparezca en una cierta posición
<IMG src="spacer.gif" alt=""><IMG src="colorfulwheel" alt="The wheel of fortune">

 

Notas de futuro

  1. El texto alternativo para las imágenes incluido en el elemento OBJECT es una solución compatible con versiones anteriores pero no es consistente con algunos visualizadores más recientes.
  2. Necesitamos abordar cuestiones relacionadas con el uso de las hojas de estilo para incluir imágenes en listas. .
  3. Como se sugirió anteriormente, las tecnologías futuras, tal como XML permitirán a los autores etiquetar los objetos y las imágenes como decorativos, diagramas, viñetas, etc.
  4. Tipos de clase predefinidos permitirán también a los autores añadir valores literales como tapiz, panel de navegación, etc. a las imágenes y a los objetos. Esto pues permitirá a los usuarios seleccionar qué tipos de aquellos tipos de clase predefinidos desean ver, para cuales desearían descripciones, o cuales desearían ignorar. Esto puede controlarse con hojas de estilo personales.

Lista de comprobación para la creación de páginas HTML
Borrador de Trabajo del W3C    14-Abril-1998


Sistema de valoración

Cada criterio puede ir acompañado de un valor que describe su importantcia:

[Obligado]
Obligado, de lo contrario será imposible que algún grupo de usuarios comprenda la página.
[Recomendado]
Hace que la página sea más fácil de comprender y utilizar.

Estilo y estructura

  1. [Obligado] Todos los elementos se ajustan a la definición del HTML 4.0 y CSS-1.
  2. [Obligado] Las páginas son legibles y funcionales sin hojas de estilo (p.e., cuando el visualizador no las soporta o el usuario las ha desactivado).
  3. [Obligado] Los títulos están anidados de manera correcta y no se utilizan para dar formato.
  4. [Obligado] La estructura de las listas y los ítems de lista se codifican de manera correcta con los propios elementos HTML.
  5. [Obligado] No se utiliza texto en movimiento o parpadeante.
  6. [Recomendado] El texto se formatea a través de las hojas de estilo, no representándolo con un gráfico (que puede ser localizado).
  7. [Recomendado] Las imágnes invisibles o transparentes no se utilizan para forzar la maquetación. Las hojas de estilo se utilizan para controlar ésta.
  8. [Recomendado] Los elementos y atributos al igual que B e I no se utilizan.
  9. [Recomendado] Los elementos estructurales de HTML se utilizan solamente para transmitir significado, no presentación.
  10. [Recomendado] Los elementos de presentación HTML se utilizan solamente para transmitir presentación, no estructura.
  11. [Recomendado] Las reglas horizontales, los acrónimos y las abreviaciones poseen títulos.

Imágenes y mapas interactivos

  1. [Obligado] Todas las imágenes y mapas interactivos poseen texto alternativo.
  2. [Obligado] Los gráficos que presentan información importante (especialmente diagramas, tablas, etc. ) poseen una descripción más larga del gráfico (esto es, mediante un enlace de descripción o el atributo "longdesc"). Además, los autores han incluido texto interno en las imágenes para formatos que lo soportan.
  3. [Obligado] Todos los mapas interactivos son accesibles y navegables a través del teclado. Además:
    • Para cada mapa interactivo de tipo cliente, cada uno de los enlaces del mapa posee una descripción asociada.
    • Para cada mapa interactivo de tipo servidor, se proporciona una lista de enlaces del mapa como enlaces de texto (en la misma página, en una página alternativa que sea accesibles, o en el interior del cuerpo del elemento OBJECT).
  4. [Recomendado] Las imágenes utilizadas como enlaces poseen títulos de enlace descriptivos.
  5. [Recomendado] Los gráficos creados mediante signos o texto en ASCII ha sido sustituidos por imágenes con texto alternativo.

Mini-aplicaciones (applets) y guiones (scripts)

  1. [Obligado] Para las mini-aplicaciones y guiones se proporcionan presentaciones alternativas del contenido que transmitan información.
  2. [Obligado] Se proporcionan mecanismos alternativos para las mini-aplicaciones y guiones que realicen una función importante (otra que la presentación de información).
  3. [Obligado] Las mini-aplicaciones que requieren la interacción del usuario y que no pueden se duplicadas en un formato alternativo son directamente accesibles.
  4. [Obligado] El usuario puede paralizar cualquier texto en movimiento o parpadeante.
  5. [Recomendado] Las mini-aplicaciones poseen texto alternativo ("alt" en APPLET, "title" en OBJECT).
  6. [Recomendado] Los guiones y las mini-aplicaciones son funcionales desde el teclado.

Sonido y vídeo

  1. [Obligado] Toda información de sonido posee una transcripción asociada.
  2. [Obligado] Toda información de vídeo posee una descripción sonora asociada.
  3. [Obligado] Toda información de vídeo posee un guión asociado.
  4. [Obligado] Las transcripciones y las descripciones sonoras se sincronizan con la información sonora o de vídeo, bien directamente o a través de un fichero de sincronización.
  5. [Recomendado] Los sonidos que se reproducen de manera automática poseen un aviso de tipo visual que advierte que el sonido está reproduciéndose.
  6. [Recomendado] Los enlaces a sonidos muy breves poseen títulos.

Tablas

  1. [Obligado] Las celdas de tabla se asocian de manera explícita con las etiquetas de fila y columna.
  2. [Obligado] Las tablas no se utilizan para organizar los documentos de texto en columnas.
  3. [Recomendado] Las tablas no se utilizan solamente para funciones de maquetación de página (utilice las hojas de estilo en su lugar).
  4. [Recomendado] Las tablas de texto y los números están disponibles de manera lineal en una página alternativa.
  5. [Recomendado] Las etiquetas de fila y de columna extensas se abrevian.
  6. [Recomendado] Los resúmenes de tabla se encuentran disponibles.
  7. [Recomendado] Para tablas más complejas, la información se agrupa en categorías.
  8. [Recomendado] El texto alternativo no pasa a la línea siguiente en las tablas utilizadas para posicionar los gráficos.
  9. [Recomendado] Se proporciona un número de teléfono, un número de fax, o una dirección de correo electrónico si las tablas no pueden hacerse accesibles.

Enlaces

  1. [Recomendado] El texto de enlace tiene sentido cuando se lee fuera de contexto, pero no es demasiado denso.
  2. [Recomendado] Las listas de enlaces poseen caracteres no hipertexto, imprimibles (rodeados por espacios) entre ellos.
  3. [Recomendado] Los enlaces poseen accesos a través del teclado.

Marcos

  1. [Obligado] Cada documento del marco (el elemento del FRAMESET) posee una alternativa sin marcos (p.e., el elemento NOFRAME).
  2. [Obligado] Una imagen no aparece directamente en un marco pero forma parte de un documento incluido en un marco.
  3. [Obligado] Todos los marcos poseen un título.
  4. [Recomendado] Se proporcionan enlaces a descripciones sobre la función y la maquetación de los marcos.

Formularios de entrada de datos por parte del usuario

  1. [Obligado] Los mapas interactivos no se utilizan para crear botones gráficos de "enviar".
  2. [Obligado] Cada etiqueta se asocia con su control de formulario.
  3. [Obligado] Las imágenes utilizadas como botones de "enviar" poseen texto alternativo.
  4. [Recomendado] Se especifica un orden de tabulación lógico (con el atributo "tabindex").
  5. [Recomendado] Los controles relacionados se agrupan (con el elemento FIELDSET).
  6. [Recomendado] Los grupos de controles se etiquetan (con el elemento LEGEND).
  7. [Recomendado] Las opciones de menú se agrupan (con el elemento OPTGROUP).
  8. [Recomendado] Los cuadros de edición y las áreas de texto poseen caracteres por defecto y ocupan parte del espacio.
  9. [Recomendado] Se proporciona un número alternativo de teléfono, una dirección de correo electrónico y una dirección postal para el envío de la información.
  10. [Recomendado] Los elementos de formulario poseen accesos mediante teclado (con el atributo "accesskey").

Si todo lo demás falla...

Si después de los mejores esfuerzos, una página todavía se presenta inaccesible, proporcione un enlace a una página alternativa que sea accesible, que posea una información equivalente y que se mantenga con la misma frecuencia que la página inaccesible.

Buenas costumbres para el diseño de sitios Web

  1. Maquete las páginas utilizando un estilo consistente.
  2. Utilice una estructura de navegación clara y consistente, y proporcione acceso a la estructura con barras de navegación.
  3. Proporcione una descripción de la distribución general del sitio, las características de acceso, y cómo utilizarlas.
  4. Ofrezca un mapa del sitio.
  5. Ofrezca diferentes tipos de búsquedas para diferentes niveles de habilidades y preferencias.
  6. Asegúrese que nada dentro del sitio impide el uso del teclado.
  7. Asegúrese que los colores del texto y del fondo o diseños contrastan bien. (Un buen test es imprimir su página con una impresora en blanco y negro).
  8. Utilice una herramienta de diseño que soporte características de acceso (y no elimine el acceso cuando Ud. cierre o vuelva a abrir la página con la herramienta)
  9. Coloque información que destaque al comienzo de los títulos, párrafos, listas, etc., para disminuir la cantidad de filtrado que deben realizar los lectores de pantalla para encontrar información importante.
  10. Cree un único fichero que pueda ser descargado para aquellos documentos que existan como una serie de páginas separadas.
  11. Compruebe la accesibilidad del sitio hojeando las páginas con al menos:
    • un visualizador sólo texto (p.e., Lynx o un emulador Lynx como Lynx Viewer o Lynx-me)
    • varios visualizadores gráficos, con:
      • sonidos y gráficos cargados,
      • gráficos no cargados,
      • sonidos no cargados,
      • sin ratón
  12. Puede ser también útil comprobar un sitio con un visualizador de voz (como PWWebspeak)
  13. Validar las páginas con herramientas como:

Reconocimientos

Co-Presidentes del Grupo de Trabajo sobre Criterios de Marcado WAI :
Chuck Letourneau, Starling Access Services

Gregg Vanderheiden, Trace Research and Development
Contactos de personal:
Judy Brewer and Daniel Dardailler
 
Agradecimientos especiales a las personas siguientes que han realizado contribuciones importantes para dar forma al contenido de este Borrador de Trabajo:
Harvey Bingham, Daniel Dardailler, Al Gilman, Jason White
 
Además nos gustaría dar las gracias a las personas siguientes que han contribuido a través de sus revisiones y comentarios:
Judy Brewer, Kevin Carey, Chetz Colwell, Neal Ewers, Geoff Freed, Larry Goldberg, Jon Gunderson, Phill Jenkins, Leonard Kasday, George Kerscher, Josh Krieger, Scott Luebking, William Loughborough, Murray Maloney, Charles McCathieNevile, MegaZone (Livingston Enterprises), Masafumi Nakane, 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

El borrador original de este documento de trabajo del W3C está basado en The Unified Web Site Accessibility Guidelines confeccionado por el Trace R & D Center, Universidad de Wisconsin bajo la financiación del National Institute on Disability and Rehabilitation Research (NIDRR),  U.S. Dept. of Education.

Para una lista completa de los Contribuyentes a los Unified Guidelines, ésta está disponible en http://trace.wisc.edu/docs/html_guidelines/version7.htm .

Nos gustaría también dar las gracias a las personas enumeradas en la sección de Referencias abajo cuyos trabajos se utilizaron en la confección de los criterios comunes sobre los que se basa este documento.


Referencias

HTML 4.0 Recommendation.

Diseño de páginas Web accesibles -- criterios y documentos generales

  1. Accessible Design for Users with Disabilities. -- Sun Microsystems
  2. The Accessible Web: Web Access Through Adaptive Technology -- Kevin Nguyen, University of Toronto
  3. Accommodating Imperfection -- All Things Web
  4. ALT text recommendations, and notes on viewing situation -- A.J. Flavell, University of Glasgow
  5. Alternative Access to the World Wide Web -- University of Toronto
  6. Any Browser Table Format -- Department of Missions, Abilene Christian University
  7. Best Viewed With Any Browser -- Accessible Site Design
  8. Compatibility & Accessibility -- Towards the creation of an accessible, truly World-wide Web -- All Things Web
  9. Composing Good HTML -- James "Eric" Tilton.
  10. Design Considerations: Readers with Visual Impairments -- Arthur R. Murphy
  11. Designing Access to WWW Pages - Alliance for Technology Access.
  12. Designing HTML Tables to Work with HTML 2.0 Browsers -- Stanton McCandlish
  13. DO-IT HTML Guidelines -- University of Washington
  14. Experiences Implementing Web Accessibility Guidelines in IBM -- Phill Jenkins
  15. For Web Page Designers -- Microsoft
  16. GSA HTML Accessibility Guidelines -- Paul Fontaine
  17. Guide to Writing Accessible HTML -- University of Toronto
  18. Hints for designing accessible Websites -- Royal National Institute for the Blind
  19. IBM Web Design Guidelines  -- IBM Human Computer Interaction (HCI)
  20. IBM Guidelines for Writing Accessible Applications Using 100% Pure Java -- IBM Special Needs Systems
  21. Increasing Access to World Wide Web Sites for Blind and Visually Impaired Computer Users -- Dena Shumila, Jan Richards
  22. InfoUse Web Accessibility Guidelines -- Jane Berliss, Lewis Kraus, Susan Stoddard
  23. LEVELLING THE ROAD AHEAD: GUIDELINES FOR THE CREATION OF WWW PAGES ACCESSIBLE TO BLIND AND VISUALLY HANDICAPPED USERS, Judith M. Dixon, Ph.D., Consumer Relations Officer, National Library Service for the Blind and Physically Handicapped
  24. The Lynx Manifesto -- Dehanced for Lynx
  25. Making Your Site Speech Friendly -- Cathy Anne Murtha, Web Design and Access Specialist, Magical Mist Creations
  26. NCSA Mosaic Access Page
  27. Nimble Document Navigation Using Alternative Access Tools -- Jutta Treviranus, University of Toronto
  28. Starling Access Services Accessible Web Page Design -- Chuck Letourneau
  29. Tables on non-table browsers -- A.J. Flavell, Glasgow University
  30. Unified HTML Accessibility Guidelines -- Previous version of this document
  31. Universal Accessibility -- Government of Canada Internet Guide
  32. Universal Design of WWW Pages -- a DO-IT (University of Washington) Brochure
  33. Universal Information Access on the WWW (COCA)
  34. "Universal Specifications" Accessibility Standards for Web Design -- New South Wales Attorney General's Department
  35. Usability of Information and the WWW -- UCLA Disabilities and Computing Program
  36. IBM Web Accessibility Guidelines -- IBM Special Needs Systems
  37. World Wide Web Access: Disability Discrimination Act Advisory Notes -- Australia

Fin del documento WAI traducido.

[Ir al inicio de la página]


Estudio completo: [Tabla de Contenido] [Sección Anterior] [Sección Siguiente]


Notas sobre la traducción y el copyright

El copyright de de todo el Estudio de Accesibilidad a la Red, incluida la traducción al castellano de los Criterios de accesibilidad WAI pertenece a la Unidad de Investigación Acceso de la Universitat de València E.G.

En esta página se presenta una traducción al castellano del documento Guías de Accesibilidad: Autoría de Páginas (WAI Accessibility Guidelines: Page Authoring) de la W3C-WAI. El documento original completo en inglés en su versión más actualizada está disponible en Internet en http://www.w3.org/TR/WD-WAI-PAGEAUTH.html . La traducción al castellano fue realizada desde la Unidad de Investigación Acceso por Francesc Mancebo i Alemany.

Debe tenerse en cuenta que en el momento de compilación de este estudio (mayo de 1998), el documento aunque muy avanzado, se encontraba aun en fase de borrador (Status: Work in Progress). En caso de duda se recomienda consultar el documento original para ver la versión completa en inglés y estar al tanto de las posibles modificaciones que hayan podido ser introducidas con posterioridad o de errores que hayan podido pasar inadvertidos durante el proceso de traducción.

El copyright del documento original de la W3C-WAI es como sigue:

La traducción de este documento está completamente de acuerdo con la política de Derechos de Propiedad Intelectual del W3C que explícitamente “promueve la más amplia difusión de los trabajos del W3C” siempre que se especifique claramente el origen del documento.

Además el W3C permite explícitamente la traducción a otros idiomas de sus documentos y su publicación en libro u otro formato, incluyendo la publicación online en un sitio web, siempre que se cumplan los requisitos especificados en http://www.w3.org/Consortium/Legal/copyright-documents.html

[Ir al inicio de la página]


Condiciones de reproducción y enlaces a este documento

Desde la Unidad Acceso deseamos promover la diseminación de las pautas de accesibilidad a la Red elaboradas por la WAI y la concienciación sobre la problemática del acceso a la Red de las personas con discapacidad.

Por ello, y dado que todavía existen muy pocas fuentes de información sobre accesibilidad a la red en castellano, se permite crear enlaces a esta página y al Estudio de Accesibilidad a la Red en general a todos aquellos que estén interesados en el tema.

Esto no obsta para que se prohiba la reproducción total o parcial en cualquier medio (escrito o electrónico) sin autorización expresa por escrito, fax o email de la unidad Acceso. Si lo desea, puede crear enlaces desde sus páginas Web a la dirección inicial del estudio de accesibilidad o a la sección correspondiente que le interese.

Si usted desea reproducir en su servidor la presente página de Criterios de accesibilidad WAI traducidos al castellano (versión borrador), puede hacerlo sin coste alguno siempre que cumpla todas las siguientes condiciones:

  1. Avisar por correo electrónico a Rafael.Romero@uv.es explicando el contexto en que se pretende reproducir la página e indicando la URL prevista. Se le contestará autorizando la reproducción.
  2. Incluir un enlace a la dirección original de esta página (http://acceso.uv.es/accesibilidad/estudio/PAGEAUTH.htm) así como a la versión original en inglés de la W3C-WAI en http://www.w3.org/TR/WD-WAI-PAGEAUTH.html. En esta última dirección se encuentra siempre la última versión del documento. Desde la Unidad Acceso, también intentaremos mantener siempre una traducción al castellano actualizada de los Criterios de accesibilidad WAI, conforme vayan saliendo nuevas versiones.
  3. Reproducir la página en su totalidad incluyendo las dos últimas secciones Notas sobre el copyright y la traducción y Condiciones de reproducción y enlaces a este documento.
  4. No incluir modificaciones ni comentarios en la página, para respetar la fidelidad a la versión original. Si se desea se puede incluir únicamente alguna pequeña nota aclaratoria al inicio o final del documento.

Si desea citar todo o parte del presente Estudio de Accesibilidad a la Red en otros estudios o publicaciones, le recomendamos que emplee el siguiente texto, elaborado según la normas actuales de citas bibliográficas:

Romero R. Alcantud F. Ferrer A. (1998): Estudio de Accesibilidad a la Red. [online]. Unidad de Investigación Acceso de la Universitat de València E.G. 05/06/98. ISBN 84-370-3485 [citado en fecha de la cita]. Disponible en Internet en http://acceso.uv.es/accesibilidad/estudio/.

Si tiene alguna duda al respecto, puede contactar con Rafael.Romero@uv.es.

[Ir al inicio de la página]


Estudio de Accesibilidad: [Tabla de Contenido] [Sección Anterior] [Sección Siguiente]


última actualización: 25/06/98   por Rafael.Romero@uv.es | Estad. mayo 2006 | Estadísticas