Resumen

Este documento explica cómo diseñar aplicaciones accesibles usando XML, el Lenguaje de Marcado Extensible. Comparado con los lenguajes HTML o MathML, XML está un nivel arriba: es una meta sintaxis usada para describir estos lenguajes, así como otros lenguajes nuevos. Como meta sintaxis, XML proporciona una garantía no instrínseca de independencia del tipo de dispositivo o de ayudas alternativas textuales. Es esencial, sin embargo, que los diseñadores de formatos y herramientas XML cuenten con directrices que expliquen cómo incluir funciones de accesibiliad básicas - tales como las que hay en HTML, SMIL, y SVG - en todos sus nuevos desarrollos.

Estatus de este documento

Este documento es un Borrador de Trabajo disponible gracias al Grupo de Trabajo sobre Protocolos y Formatos del WAI (PFWG), para que sea revisado por los miembros del W3C y otras partes interesadas. El grupo PF funciona como parte de la Actividad Técnica del WAI.

Dependiendo de las reacciones recibidas, este documento puede llegar a convertirse en una Nota del W3C, integrándose en la serie de Directrices de Accesibilidad para el Contenido Web, por ejemplo como técnicas para XML, o seguir su propio proceso hasta llegar a ser una Recomendación.

Por favor, envíe los comentarios sobre el contenido de este documento y sobre cómo le gustaría que evolucionara, a los archivos públicos de las listas de correo electrónico: wai-tech-comments@w3.org. Se recibirán los comentarios hasta el 30 de septiembre de 2001. Puede enviar comentarios menores sobre la edición directamente a los editores.

La publicación de este documento no implica el respaldo del W3C, sus miembros o su dirección. Este es un borrador y puede,en cualquier momento, ser actualizado, reemplazado o quedar obsoleto por otros documentos. No es apropiado utilizar los borradores de trabajo del W3C como material de referencia o citarlos de manera que no sea como "trabajo en progreso". Puede encontrarse una lista de informes técnicos y publicaciones del W3C actuales, incluyendo borradores de trabajo y notas, en http://www.w3.org/TR/.

Tabla de Contenidos

Introducción

XML (Extensible Markup Language) es una meta-sintaxis, utilizada para crear nuevos lenguajes.

Ello puede verse como una simplificación de SGML (Standard Generalized Markup Language), diseñado para promover una amplia aceptación en los mercados Web, pero sirviendo a la misma funcionalidad de extensibilidad y de diseño de nuevos lenguajes.

HTML (HyperText Markup Language), de otro lado, es una aplicación particular de SGML, que cubre una serie de necesidades (documentos hypertexto "simples") y una serie de elementos y atributos.

Por ejemplo, en HTML, los autores pueden escribir elementos como:

 <title>XML and Accessibility</title>
 <address lang=fr>Daniel Dardailler</address>
 <h1>Background</h1>

y sólo pueden usar elementos (title, h1, etc.) definidos por la especificación HTML (que define cerca de cien) y sus atributos.

En SGML y XML, los autores pueden definir su propia serie de elementos, para acabar teniendo documentos como:

 <menu>New England Restaurant</menu>
 <appetizer>Clam Chowder
   <photo url="clam.jpg">A large creamy bowl of clam showder, with
       bread crumbs on top</photo>
 </appetizer>

lo que puede satisfacer mejor las necesidades de su sistema de información.

Dentro del W3C, el lenguaje HTML está siendo ahora refundido como XML - esto es lo que se llama XHTML - incluyendo una modularización de HTML para satisfacer las necesidades de una amplia comunidad (usuarios de móviles, Web TV, etc.).

Por tanto, no debe verse al XML como un reemplazo de HTML, sino como un nuevo piso del edificio sobre el que se pondrá al HTML, junto a otros lenguajes diseñados por el W3C, tales como MathML (para representar fórmulas matemáticas), SMIL (para sincronizar multimedia), SVG (para gráficos escalables), etc.; y otros nuevos lenguajes diseñados por otras organizaciones (tales como OpenEBook, XML-EDI, etc.).

Además, es importante comprender que XML es no sólo una tecnología de Interfaz de Usuario (como HTML), sino que puede y a menudo se usa en protocolos de comunicación, para serializar y codificar datos para ser enviados desde una máquina a otra.

Gramáticas XML, y el Alcance de XMLGL

Las gramáticas XML (se llaman schemata - pero vea la advertencia sobre el uso que damos al término "esquema" en la sección de definiciones) pueden clasificarse en dos ejes diferentes:

orientada a datos:

Juegos de etiquetas para: Interfaz de Usuario (UI)--orientada a la interpretación estructural textual, tal como Docbook, HTML, MenuML, OEB, etc.; interpretación especializada - por ejemplo MahtML, Scalable Vector Graphics (SVG), MusicML, Synchronized Multimedia Integration Language (SMIL); o cualquier formato de almacenamiento de datos genéricos. Una definición informal es 'cualquier cosa para la que tenga sentido la pregunta ¿Hay un equivalente textual para todos los componentes de datos de medios enriquecidos?'. La schemata centrada en datos (Data-centric) incluye los aspectos tanto de interacción como de comportamiento de una aplicación XML.

Orientada a Metadatos (Metadata-oriented):

Cuando el contenido marcado es un metadato. Exemplos: Para expresar datos que se procesan (por ejemplo XSL - Extensible Style Language), RDF (Resource Description Framework), lenguajes de Esquema, etc.

Según esta taxonomía, estas directrices se dirigen sólo a schemata orientada a datos. Lo cual no implica que no haya problemas o características de accesibilidad en la schemata Orientada a Metadatos - vea, por ejemplo, cómo XSLT, un componente de XSL, puede ayudar a crear un formato para Braille - puesto que ellas no incluyen datos orientados al usuario final, sin embargo, la schemata orientada a Metadatos queda fuera del alcance de estas directrices.

Declaración de problemas

El WAI (Web Accessibility Initiative) ha hecho una gran cantidad de trabajo en el área de HTML, produciendo muchas nuevas funcionalidades que se añden a la versión 4.0 del lenguaje (vea el HTML4 Accessibility Improvements paper).

Estas funcionalidades incluyen:

• Estructura mejorada (tales como "fieldset", "optgroup" en formularios)
• Soporte para Hojas de Estilo separadas
• Mejor contenido alternativo (se requiere "alt", "longdesc", "caption", etc.)
• navegación simplificada ("tabindex", "link", etc.)

Un tema que preocupa con la llegada de XML es la libertad de diseño que tiene y que puede resultar en una pérdida de características de accesibilidad, presentes hoy debido a la amplia disponibilidad y penetración de la especificación de HTML.

Por ejemplo, uno podría diseñar un nuevo lenguaje XML que prevendría la creación de documentos accesibles, mediante la no inclusión en el elemento o atributo de una manera establecida para adjuntar una descripción alternativa textual para una fotografía:

 <menu>New England Restaurant</menu>
 <appetizer>Clam Chowder
   <photo url="clam.jpg"/> <!-- aquí
    no existe el atributo alt ni un modelo de contenido textual -->
 </appetizer>

En este ejemplo, el problema no es que el autor de este documento no haya puesto un atributo alt o añdido al elemento fotográfico un equivalente textual, el problema es que el diseñador del lenguaje no ha puesto el atributo o el soporte apropiado en el lenguaje en sí mismo (esto es, en el esquema o la DTD).

Pero comencemos por definir qué queremos decir por un esquema y documento accesible (al final de este documento se detallan estas definiciones):

• Un esquema XML es accesible si posibilita, y de hecho promueve activamente, la creación de documentos accesibles.

• Un documento es accesible si puede ser igualemente entendido por su público objeto independientemente del dispositivo que use para acceder a él.

  Un documento accesible también se define como aquel que conforma las Directrices de Accesibilidad para el Contenido Web.

Tal como se explica en la introducción, aquí sólo vamos a considerar lenguajes orientados a datos, y para ellos el mensaje es simple: sea independiente del tipo de dispositivo y exporte sus semánticas tanto como pueda.

Aunque la prioridad es fundamental en el primer aspecto (multi-modalidad), ambos aspectos son importantes, tanto como que sin el conocimiento del significado de los elementos y atributos XML, queda una pequeñísima posibilidad de que las aplicaciones alternativas del usuario puedan hacer algo inteligente con apenas trozos del documento.

Por supuesto que estos conocimientos semánticos pueden proporcionarse mediante documentación leíble por el humano, pero teniendo aserciones de semánticas leíbles por la máquina, que pueden entonces usarse para presentar el documento por varios medios, es lo máximo para el acceso extensivo (esto es, usted no necesita un programador, sólo necesita un programa). Permitiendo a otros mapear desde su lenguaje a otros existentes o viceversa, es una útil característica de accesibilidad.

ICADD (International Committee on Accessible Document Design) fue pionero en el tema de la accesibilidad para SGML y en maneras de transmitir semánticas de esquema arbitrarias (usando mecanismos obligatorios específicos de SGML). Unos pocos años después, ICADD no ha sido adoptado realmente (de hecho, la DTD de ICADD fue reemplazada por HTML y sus bien conocidas semánticas), y la gente sigue intentando resolver el mismo problema, aunque con más experiencia en el campo de la accesibilidad de HTML y esta vez aplicándola a XML.

Directrices para diseñadores de Tagsets XML orientados a Datos

Esta sección proporciona una lista de cuatro directrices, que son principios generales del diseño accesible. Las directrices incluyen su razonamiento y puntos de control. Cada punto de control expresa un requerimiento, incluye algún texto informativo sobre el punto de control y una o más Técnicas, en las que se discuten la aplicación y ejemplos de los puntos de control. Advierta que los puntos de control no han sido clasificados por prioridad, todavía.

• Pauta 1. Garantice que los autores puedan asociar como alternativa múltiples objetos de medios.

  Los proveedores de contenidos Web deben ser capaces de ofrecer versiones alternativas de sus contenidos si desean hacerlo (Tal como las Directrices de Accesibilidad para el Contenido Web les dicen que deben hacer). Las alternativas en formato texto, por ejemplo, pueden ser reformateadas para muchos dispositivos de salida, mientras que el contenido que no es texto a menudo queda confinado a una cierta serie de dispositivos. Así, permitiendo y alentando la inclusión de alternativas en formato texto sincronizadas, usted permite que sus tagset sean más inter-operables y por tanto accesibles.

  1.1 Proporcione un mecanismo para asociar explícitamente equivalentes alternativos para el contenido o fragmentos de contenido.

  Los autores que utilicen los elementos/atributos en su lenguaje deben tener la capacidad de proporcionar alternativas para cualquier contenido, sean imágenes, películas, sonidos, texto corrido, cualquier cosa.

  Técnicas para 1.1

  Por ejemplo, los elementos summary y caption en el XHTML table module pueden usarse para proporcionar una rica descripción en formato texto de un medio audivisual. WCAG 1.0 checkpoint 1.1.

  <table border="1"
         summary="Esta tabla recoge algunas
  	   estadísticas sobre la mosca de la fruta: 
  	   promedio en altura y peso, y porcentaje 
  	   con ojos rojos (tanto en machos como en hembras).">
    <caption><em>Estadísticas</em> sobre moscas de la fruta</caption>
    <tr><th rowspan="2"><th colspan="2">promedio
        <th rowspan="2">ojos<br>rojos
    <tr><th>altura<th>peso
    <tr><th>machos<td>1.9<td>0.003<td>40%
    <tr><th>hembras<td>1.7<td>0.002<td>43%
  </table>

  1.2 Defina asociaciones flexibles, donde una clase dada de relaciones puede enlazar con o desde objetos de varios tipos.

  Por flexible queremos decir que, no esté constreñido por el lenguaje en sí mismo. Por ejemplo, HTML le permite agregar "alt" a las imágenes, pero no le permite a usted agregar imágenes a una serie de texto/marcado, de manera que la gente tiene que ponerlas con el mecanismo menos adecuado, quizás añadiendo "ver figura 1" al final de un párrafo. Si el contenido de <img> no estuviera vacío, esto resolvería el problema hasta cierto punto. Otra manera podría ser añadir un atributo "appliesto" para el elemento <img> permitiéndole a usted poner la imagen asociada en cualquier lugar en el documento. Satisfacer este punto de control exige pensar mucho debido a su naturaleza subjetiva, pero es muy importante. Por ejemplo, si <img> fuera no-vacío, o si tuviera un atributo appliesto, es probable que mucha más gente asociaría imágenes con series de texto/marcado.

  Técnicas para 1.2

  En SVG, puede usarse el elemento desc para describir completamente un gráfico, por ejemplo utilizando texto estructurado desde un tagset diferente y, en el gráfico en sí mismo, el texto de la descripción puede reutilizarse.

  <svg xmlns="http://www.w3.org/2000/svg" xml:lang="en">
     <g>
         <desc xmlns:mydoc="http://example.org/mydoc">
            <mydoc:title id="title1">The sales bar
  		  chart by region</mydoc:title>
            <mydoc:para>This description uses markup from the
            <mydoc:emph>mydoc</mydoc:emph> namespace.</mydoc:para>
         </desc>
            <!-- ahora la imagen que incluye el texto que
  		  hace referencia a la descripción -->
          <rect x="10" y="20" ...>
          <text x="100" y="200" font-size="15" fill="red" >
             <tref xlink:href="#title1"/>
          </text>
     </g>
  </svg>

  1.3 Reutilice módulos accesibles existentes para indicar asociaciones de equivalentes-alternativas.

  Reutilizar módulos accesibles tiene la ventaja de garantizar que sus "clientes" pueden confiar en que los materiales producidos al usar su lenguaje serán accesibles para los suyos. No necesita crear "nuevos" elementos/atributos o re inventar la rueda solo para satisfacer alguna fantasía creativa. Aprender nuevos conceptos significa un costo no despreciable para sus autores (la gente que utiliza su lenguaje).

  Técnicas para 1.3

  Este ejemplo muestra cómo usar un módulo DTD existente: el objeto desde el tagset XHTML

  <!DOCTYPE document SYSTEM "myDTD.dtd" [
      <!ENTITY % qnames 
           PUBLIC "-//W3C//ENTITIES XHTML Qualified Names 1.0//EN" 
                  "xhtml-qname-1.mod" >
      <!ENTITY % object 
           PUBLIC "-//W3C//ELEMENTS XHTML Embedded Object 1.0//EN" 
                  "xhtml-object-1.mod" >
      %qnames;
      %object;
      ]>
   <i:inventory xmlns:i="http://www.my.org/xmlns/inventory">
   <i:stockitem>
      etc.
    <xhtml:object...>  
      to include a picture or movie of the part.

• Pauta 2. Cree lenguajes semánticamente-ricos

  El XML orientado a datos debe contener métodos precisos de codificar los datos para su alcance particular. Incrementando la semántica de su tagset y estableciendo dispositivos enlazados a presentaciones externas o semánticas ulteriores, usted permite que sus datos sean "Webized" y a partir de ahí funcionen en muchos entornos.

  2.1 Asegúrese de que todas las semánticas están capturadas en marcado de manera reutilizable.

  En general, los lenguajes deben diseñarse de manera que puedan ser presentados de manera independiente del tipo de dispositivo. Los lenguajes utilizados sólo para la presentación a un cierto grupo de usuarios (esto es, tagsets de forma final) deben tener en cuenta las siguientes advertencias:

  • No deben promoverse como un método generalmente conveniente para almacenar contenido que pueda usarse a través de varios dispositivos.
  • El servidor debe asegurarse de que el cliente quiere esa forma en particular antes de servirla.
  • Deben permitir a los autores asociar la forma final con el nivel más alto de las semánticas de la fuente, siempre que sea aplicable.

  Técnicas para 2.1

  Vea el último párrafo de la XSL 1.1.1 section para ver un ejemplo de tales términos.

  2.2 Separe las propiedades de presentación utilizando los mecanismos de la tecnología/estilo de las hojas de estilo.

  Los autores deben ser capaces de marcar los documentos con los elementos estructurales propios y controlar la presentación con hojas de estilo en vez de con elementos y atributos de presentación. Esta separación del contenido de la presentación facilita la adaptación a los usuarios con diferentes necesidades de presentación (tipografía grande, mayor contraste, etc.) y también facilita el mantenimiento de las páginas.

  Técnicas para 2.2

  Ejemplo: Errado

  No incluya elementos y atributos de presentación en su lenguaje.

   <p align="center" font="arial" weight="bold">News items 1</p>
   <p align="center" font="arial" weight="bold">News items 2</p>
   <p align="center" font="arial" weight="bold">News items 3</p>

  Ejemplo: Correcto

  Apoye la inclusión y procesado de hojas de estilo externas.

  mystyle.css: .news { text-align: center; font: bold arial }

  <?xml-stylesheet href="mystyle.css" type="text/css"?>
  <p class="news">News items 1</p>
  <p class="news">News items 2</p>
  <p class="news">News items 3</p>

  2.3 Utilice los mecanismos de enlace y apuntamiento estándares de XML (XLink y XPointer).

  XLink y XPointer han sido revisados para la accesibilidad y proporcionan mecanismos conocidos de enlace y apuntamiento.

  Técnicas para 2.3

  Ejemplo. Errado

  Las aplicaciones de usuario no tienen manera de saber que esto es un enlace.

   <mylink 
    linkend="http://mysite/myfile.xml">
      Current list of references
   </mylink>

  Ejemplo: Correcto

  Los enlaces pueden ser reconocidos de manera segura por las aplicaciones XLink.

  <crossref	xmlns:xlink="http://www.w3.org/1999/xlink"
   	xlink:href="http://mysite/myfile.xml">
     	Current list of references
  </crossref>

  2.4 Defina los tipos de elementos que permiten la clasificación y agrupamiento (títulos, sección, listas, etc).

  Haga uso de los mecanismos existentes (advierta el punto de control 1.2), o creélos cuando sea necesario, siguiendo estas directrices. Asegúrese de que los elementos que esteén presentes puedan ser utilizados para la clasificación y agrupamiento.

  Técnicas para 2.4

  Cuando diseñe un tagset piense en la totalidad de la estructura de sus documentos.

   <-- menu - highest level block element
       appetizer - first child of section, major block element
       entree - second child of section, major block element
       entity meal-sequence - common paragraph level blocks -->
   <!ELEMENT menu (title , ((%meal-sequence;)|  appetizer)+)>
   <!ELEMENT appetizer (title? , ((%meal-sequence;) | entree)+)>

  2.5 Proporcione un modelo de contención completo con trozos de tamaño razonable.

  Si una instancia de un documento está plenamente contenida, es decir, hay elementos que envuelven adecuadamente a los PCDATA, entonces pueden usarse tanto CSS como XSLT para dar estilo al contenido para la presentación en formatos alternativos. Si el contenido se encuentra en contenedores de tamaño razonable, esto permite que el documento sea hojeado rápidamente por los lectores no visuales. Si se utiliza una jerarquía lógica de elementos, entonces puede generarse una tabla de contenidos o resumen proporcionando un acceso lógico al contenido del documento.

  Técnicas para 2.5

  En este ejemplo de Esquema XML, se parte un documento en un número de secciones, y una secuencia de secciones anidadas con una estructura consistente puede ser usada tanto para la navegación como para la generación automátizada de una tabla de contenidos para cualquiera que sea el nivel.

  <xsd:schema xmlns="http://www.publishing.org"
  	 xmlns:xsd="http://www.w3.org/2000/10/XMLSchema">
   	<xsd:element name="document">
  	  	<xsd:complexType>
  	  		<xsd:sequence>
  	  			<xsd:element ref="head"/>
  	  			<xsd:element ref="section"/>
  	  		</xsd:sequence>
  	  	</xsd:complexType>
  	 </xsd:element>
  	 <xsd:element name="head" type="xsd:string">
  	  <xsd:annotation>
  	 	 <xsd:documentation>Section title</xsd:documentation>
  	  </xsd:annotation>
  	 </xsd:element>
  	 <xsd:element name="section">
  	  	<xsd:complexType>
  	  		<xsd:sequence>
  	  			<xsd:element ref="head"/>
  	  			<xsd:element ref="section"/>
  	  			<xsd:element ref="paragraph" maxOccurs="unbounded"/>
  	  		</xsd:sequence>
  	  	</xsd:complexType>
    </xsd:element>
  	 <xsd:element name="paragraph" type="xsd:string"/>
  </xsd:schema>

  2.6 Defina tipos de elementos que identifiquen texto importante del contenido.

  En la mayoría de los documentos, ciertos elementos son clave para su comprensión. Si estos son tanto claros, como identificados para el acceso de máquinas, su contenido puede ser presentado a los usuarios para ganar un entendimiento rápido de las semátnicas del elemento, sección, e incluso del documento completo. Ejemplos de tales elementos importantes son los números, fechas, títulos y enlaces.

  Técnicas para 2.6

  Marque su texto con más semántica, como diciendo "esto es una fecha", o "esto es un acrónimo".
  Código ejemplo: Utilizando el esquema del lenguaje XML para identificar tipos de datos, en vez de dejarlos simplemente como cadenas: un número ISBN totalmante obligado:

  <xsd:simpleType name="ISBN-Type">
      <xsd:restriction base="xsd:string">
          <xsd:pattern value="\d{5}-\d{5}-\d{5}"/>
          <xsd:pattern value="\d{1}-\d{3}-\d{5}-\d{1}"/>
          <xsd:pattern value="\d{1}-\d{2}-\d{6}-\d{1}"/>
      </xsd:restriction>
  </xsd:simpleType>

  2.7 Proporcione un mecanismo para identificar síntesis / resumen/ título.

  El conocimiento de cómo extraer esa información le permite a las Aplicaciones de Usuario presentarla al usuario final, facilitando así la navegación por el contenido (es decir, decidiendo si el documento es de interés o no).

  Técnicas parar 2.7

  Ejemplo: XML utilizando RDF y Dublin Core, semánticas bien conocidas.

    <someElement xmlns="http://xmlns.com/example">
     <rdf:RDF
      xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
      xmlns:dc="http://purl.org/dc/elements/1.1/">
      <rdf:Description about="http://www.dlib.org/">
        <dc:Title>
            D-Lib Program - Research in Digital Libraries
        </dc:Title>
        <dc:Description>The D-Lib program supports the community of 
         people with research interests in digital libraries and 
         electronic publishing.</dc:Description>
        <dc:Publisher>
            Corporation For National Research Initiatives
        </dc:Publisher>
        <dc:Date>1995-01-07</dc:Date>
        <dc:Type>World Wide Web Home Page</dc:Type>
        <dc:Format>text/html</dc:Format>
        <dc:Language>en</dc:Language>
      </rdf:Description>
    </rdf:RDF>
  <!-- .....other xml.... -->
  </someElement>

  2.8 No cargue excesivamente la semántica con elementos individuales.

  Si un nombre de elemento puede ser confundido, dentro del contexto del documento caso, entonces se dice que puede ser sobrecargado. Si cada nombre de elemento es único dentro del contexto es fácil acceder a las semánticas del documento. Advierta la relación con el punto de control 4.9.

  Técnicas para 2.8

  Ejemplo: Errado

   <report>
     <invoice>
      <amount>25 dollars</amount>
      ....
      </invoice>
    <description>
     <item>Widgets</item>
     <amount>25</amount>
    </description>
   </report>

  En el ejemplo de arriba, el diseñador del esquema ha utilizado la primera ocurrencia del elemento "amount" (cantidad en inglés) para significar el 'precio' de los productos comprados y la segunda vez para significar la 'cantidad' de productos comprados.

  Ejemplo: Correcto

   <report>
     <invoice>
      <price>25</price>
      <currency>Dollar</currency>
  	....
     </invoice>
    <description>
     <item>Widgets</item>
     <quantity>25</quantity>
    </description>
   </report>

  En el ejemplo de arriba, el significado de todos los elementos es claro y ninguno de los elementos individuales puede sobrecargarse.

  2.9 Reutilice módulos accesibles desde schemata tal como fueron especificados / proyectados originalmente.

  Al usar módulos desde otra schemata, utilícelos con la misma semántica que fue proyectada originalmente para ellos.

  Técnicas para 2.9

  Ejemplo: reutilizando switch de SMIL

    ...
    <par>
      <video src="anchor.mpg" ... />
      <switch>
        <audio src="HiQuality.wav" systemBitrate="56000" ... />
        <audio src="MedQuality.wav" systemBitrate="28800" ... />
        <audio src="LowQuality.wav" ... />
      </switch>
    </par>

  2.10 Permita la asociación de metadatos con elementos distintos y con grupos de elementos.

  Esto permite a los autores hacer incluso más asociaciones semánticas que las que fueron originalmente proyectadas por el diseñador del lenguaje.

  Técnicas para 2.10

  En SVG por ejemplo, hay un elemento metadata en el que pueden ser declaradas instrucciones RDF, apuntando a elementos gráficos y añadiendo más relaciones semánticas (un objeto enlazado con otro, o encima de otro) que las que proporciona SVG en sí. Para obtener ejemplos, vea la SVG Accessibility note.

• Pauta 3. Diseñe una interfaz de usuario accesible.

  El contenido Web está cambiando rápidamente desde páginas estáticas a páginas dinámicas, llamadas aplicaciones Web. A menudo esto se hace utilizando un lenguaje de guión (scrpting languaje) basado en eventos callback. El diseñador del lenguaje debe asegurarse de que el modelo que elija permite al usuario el control de la presentación. Siempre asegúrese de que nada en los aspectos de presentación del documento intenta restringir el control del usuario sobre cómo se accede a la instancia del documento.

  3.1 Proporcione múltiples hojas de estilo en cascada para múltiples modalidades de salida donde sea posible.

  El esfuerzo adicional, desde el punto de vista del diseñador del lenguaje, de proporcionar hojas de estilo que puedan representar un documento XML en modos alternativos, es mínimo y tendrá un beneficio multiplicador para todos los autores que utilicen el lenguaje y esas hojas de estilo. Los lectores de su documento pueden preferir el acceso auditivo, de manera que, proporcionando con su esquema una hoja de estilos, apropiada, permitirá a esos lectores utilizar habla sintética para producir una clara representación del contenido.

  Técnicas para 3.1

  Ejemplo: Vea el sample style sheet for HTML 4.0 provisto con la especificación de CSS2,

  3.2 Defina estructuras navegables que permitan funcionalidades distintas, secuenciales, estructuradas, y navegación por búsqueda.

  Las estructuras navegables son los elementos clave utilizados para la navegación al rededor de una aplicación XML. Defina elementos tipo que permitan la clasificación y agrupamiento, o reutilice modulos existentes accesibles de clasificación y agrupamiento.

  Techniques for 3.2

  Ejemplo: Vea cómo la Digital Talking Book DTD proporciona elementos para estructuras navegables.

  3.3 Utilice CSS o XSLT para describir una vista de presentación básica.
  

  El diseñador del lenguaje es el más apropiado para proporcionar una correspondencia de los constructos del nuevo lenguaje para un formato básico de salida, lo que facilitará el desarrollo de contenido haciéndolo entendible para toda clase de usuarios.

  Técnicas para 3.3

  <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                  version="1.0">
  <xsl:output method="html"/>
  <xsl:template match="/">
  <html>
  <head>
  <title>Outline of x</title>
  <body>
   <-- This provides the link back to the full source document -->
   <a href="source.xml">full source of document</a>
   <h3>Outline view</h3>
   <p>  <xsl:for-each select="//section">
        <xsl:number level="multiple" count="section" format="1.1.1"/>
  	  <xsl:value-of select="title"/> 
        <br />
     </xsl:for-each>
   </p>
   <xsl:apply-templates/>
  </body>
  </html>
  </xsl:template>
  <xsl:template match="*"/>
  </xsl:stylesheet>

  3.4 Utilice una interacción dispositivo-independiente y eventos modelo / módulo.

  Cualquier aplicación XML que contenga interacción por parte del usuario puede excluir a un número de lectores si se hacen presunciones sobre la tecnología que se usará para acceder a ella. ¿Qué pasa cuando la aplicación sólo soporta la interacción mediante el ratón y el usuario no puede utilizarlo? El resultado puede ser la pérdida de ventas, se perderá el interés y se buscarán alternativas.

  Técnicas para 3.4

  Utilizando eventos DOM2, la manera correcta en SVG.

  <script> function DoOnActivate(evt) { .. } </script>
  
  <g onactivate="DoOnActivate(evt)">
    <rect id="button" x="500" y="500" width="250" height="40"/> 
  </g>

  3.5 Permita que los usuarios tengan el control o la posibilidad de cambiar el promedio de tiempo necesario para las interacciones, eventos externos que activan cambios en el documento, etc.

  Si una aplicación XML presume que todos los usuarios leerán el contenido en un período determinado de tiempo, a una determinada velocidad promedio, o accederá a cada página en un determinado momento, entonces los usuarios y lectores de esa aplicación se perderán. Cada uno de nosotros hace las cosas en su propio momento y nos disgusta ser mandados.

  Técnicas para 3.5

  Garantice y promueva el trabajo que los agentes de usuario tienen para hacer sobre el control - en nombre del usuario final - del ritmo de cambio en la presentación del contenido, tal vez utilizando atributos de elementos para facilitar la frecuencia de pausa o reinicio para permitir al usuario el control de todas las interacciones. Las terminaciones intencionadas en períodos de tiempo fijo, no son populares. Vea la especificación de SMIL-Animation para obtener ejemplos de este tipo de diseño.

• Pauta 4. Documente y exporte las semátnicas

  Asegúrese de que todas las personas pueden entender su diseño y mapear hacia y desde sus elementos y hacer fácilmente aserciones sobre ellos. Además, asegúrese de proporcionar sus propias primeras aserciones sobre sus lenguajes: por ejemplo, no haga que los usuarios tengan que suponer el propósito de un elemento.

  4.1 Garantice que la documentación legible por un humano conforma el nivel Doble A de las Directrices de Accesibilidad para el Contenido Web.

  Todo el mundo debe poder leer y entender una especificación técnica, incluso una que esté dirigida a un determinado tipo de usuario en particular.

  Técnicas para 4.1

  Por ejemplo, los usuarios ciegos pueden ser autores de contenidos Web dirigidos a usuarios que ven, y pueden hacerlo debido a que las especificaciones de HTML y CSS son accesibles (bien estructuradas, con descripción de las imágenes, etc.).

  4.2 Proporcione un medio/mecanismo inteligible por una máquina para obtener el esquema de un documento.

  Esto permite a los programas recuperar automáticamente la documentación en un idioma determinado.

  Técnicas para 4.2

  Ejemplo: Utilice como esquema el lenguaje Esquema XML del W3C, haciendo referencia a él a través del atributo xsi:schemaLocation.

  <?xml version="1.0" encoding="utf-8"?>
  <my:doc 
      xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
     	xsi:schemaLocation="http://www.example.org/schemas/doc.xsd"
     	xmlns:my="http://www.jenitennison.com/"
      xmlns="http://www.w3.org/1999/xhtml">

  4.3 Proporcione definiciones explícitas legibles por un humano para el marcado semántico.

  Cualquier esquema que es diseñado por una única persona, durante un período razonable, sólo será entendido por esa persona que lo ha diseñado. Cuando se expone a los autores de documentos, las interpretaciones variarán. Si el diseñador del esquema desea que los autores de documentos utilicen las mismas semánticas, entonces esas semánticas requieren documentación. La mejor cualidad de esa documentación será la mayor comprensión compartida.

  Técnicas para 4.3

  Ejemplo: TREX

  <element name="paragraph">
      <xsd:annotation>the lowest level block container.</xsd:annotation>
      <empty/>
  </element>

  4.4 Utilice el esquema (preferiblemente una DTD) para proprocionar documentación/anotación explícita de las semánticas de los elementos/atributos/etc.

  El Esquema permite a los diseñadores de lenguajes añadir explícita documentación para los elementos y atributos, y de esta manera se hace más entendible el lenguaje.

  Técnicas para 4.4

  Ejemplo: Describe claramente la necesidad de usar los elementos de encabezado.

  <xsd:element name="head" type="xsd:string">
   <xsd:annotation>
  	<xsd:documentation xml:lang="en-US">Title of the section.
      	Required for table of contents generation.
  	</xsd:documentation>
   </xsd:annotation>
  </xsd:element>

  4.5 Proporcione relaciones semánticas con otras schemata, cuando sea apropiado y posible.

  Esto permite a los autores que utilizan el lenguaje, reutilizar sus conocimientos previos y las herramientas que ya tenían.

  Técnicas para 4.5

  Esto puede hacerse implícitamente a través de la derivacíón/subclasificación de tipos existentes, por medio de la aserción de equivalencia de los tipos (Ej. el título en SVG o el título en SMIL) o trazando correspondencias con semánticas bien conocidas.

  Ejemplo: Creando una correspondencia entre el ejemplo de Menú proporcionado en la introducción a XHTML, utilizando XSLT:

  <html xsl:version="1.0"
        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
        xmlns="http://www.w3.org/1999/xhtml> 
  <head>
    <title>Mapping of language MenuML to html</title>
  <body>    
      <h1>Menu of: <xsl:value-of select="menu/"/></h1>   
      <h2>Appetizer: <xsl:value-of select="menu/appetizer/"/></h2>
     etc...
  </body>
  </html>

  4.6 Documente las características de accesibilidad de la aplicación.
  

  Esto es útil para fomentar el desarrollo del "estado del arte" de las ayudas técnicas para identificar todas las características de un nuevo lenguaje que lo hacen más accesible.

  Técnicas para 4.6

  SVG ha proporcionado un buen ejemplo de esto constituyendo una parte de la recomendación. Para los Borradores de Trabajo del W3C, incluya y documente esas características específicas que ayudan positivamente a la accesibilidad.

  4.7 Incluya requisitos de accesibilidad entre los requerimientos de conformidad.

  Esto promueve el desarrollo de contenido accesible en la comunidad que se preocupa por la conformidad.

  Técnicas para 4.7

  SVG tiene requisitos de accesibilidad específicos como una parte de la totalidad de los requerimientos del documento. Cuando se trazan los requerimientos, es necesario incluir claúsulas específicas con declaraciones claras de requerimientos de accesibilidad

  4.8 Documente las técnicas para WCAG, ATAG, y UAAG respecto a la aplicación XML.

  La serie de directrices de accesibilidad del WAI (WCAG, ATAG, y UAAG) contienen descripciones detalladas sobre cómo satisfacer cada uno de los requerimientos individuales de los documentos. Por consiguiente, es importante revisar su aplicación XML para asegurarse de que ha aplicado una técnica relevante para cada punto de verificación de la serie de directrices de accesibilidad del WAI. Por ejemplo, usted podría mostra cómo una instancia (hipotética) de su aplicación conforma las WCAG, cómo una herramienta de autoría que integra su aplicación podría habilitar a un autor para crear contenido accesible, cómo un navegador capaz de soportar su aplicación debe conformar las UAAG, etc.

  Técnicas para 4.8

  Continúe utilizando el lenguaje MenuML, aquí hay ejemplos de las técnicas de las WCAG:

  • WCAG, punto de control 1.1: Proporcione un texto equivalente para cada elemento en formato no-texto

    técnica MenuML: use el contenido del elemento photo para indicar el equivalente textual de una foto.

  • WCAG, punto de control 3.5: Utilice elementos de encabezado para transmitir la estructura del documento y úselos de acuerdo con la especificación.

    técnica MenuML: utilice el elemento appetizer para introducir un nuevo "aperitivo", no lo utilice para conseguir un efecto de fuente mayor

  4.9 No asuma que los nombres de elemento o atributo proporcionan ninguna información sobre la semántica del elemento.

  Un elemento nombrado puede tener un significado completamente contextualizado para el autor del esquema, pero es improbable que signifique algo para una persona que no habla inglés. Igualmente, sacado de contexto, sin explicación semántica, a menudo los nombres de elemento pierden su significado. Nombrar un elemento simplemente, no es suficiente para garantizar que los autores de documentos utilizarán ese elemento en conformidad semántica con la intención del autor del esquema. Es probable que se produzca confusión y mala interpretación si los nombres de elemento o atributo dependen de documentar un esquema.

  Técnicas para 4.9

  Por ejemplo, utilizando TREX, se evitan nombres de elemento coloquiales.

  Ejemplo: Errado

  <element name="paragraph">
      <xsd:annotation>
      <xsd:documentation>paragraph</xsd:documentation>
      </xsd:annotation>
      <empty/>
    </element>

  Aquí el nombre de elemento ha sido descrito utilizando sólo el nombre del elemento, lo que no añade valor semántico.

  Ejemplo: Correcto

  <element name="paragraph">
      <xsd:annotation>
      <xsd:documentation>The lowest level block container.
      </xsd:documentation>
      </xsd:annotation>
      <empty/>
    </element>

  Aquí el nombre de elemento ha sido descrito de manera alternativa para aclarar el significado semántico en vez de solo reforzar el nombre, repitiéndolo.

  4.10 Documente las estructuras navegables. Describa cómo deben trabajar los mecanismos de dispositivos, secuenciales, estructurados, y los de navegación de búsqueda

  Para navegar al rededor de un documento significativo, es útil para el lector saber qué elementos están disponibles para dicha navegación.

  Técnicas para 4.10

  Acceso aleatorio a cualquier parte del documento vía una tabla de contenidos detallada, títulos numerados que pueden ser buscados, una vista jerárquica habilitando el acceso rápido a las partes buscadas, y ayudas para la búsqueda.

Apéndices

Apéndice A: Razón de las Técnicas

En la presentación de las directrices de accesibilidad para XML, nosotros tratamos de separar las directrices abstractas de las técnicas de aplicación. Esto nos permite hablar sobre principios generales de las directrices sin gastar tiempo en intentar resolver los problemas de aplicación.

De hecho, hay varias técnicas para obtener los mismos resultados y la decisión de las personas estará en función del tiempo y de los productos disponibles y de su propio compromiso con la accesibilidad.

Por ejemplo, si un diseñador de XML quiere crear algún tipo de elemento de "lista" en un marcado dado, puede hacerlo aplicando varias técnicas:

• utilizando XHTML namespace y sus elementos (xhtml:ul, xhtml:li)
• inventando nuevos constructos pero proporcionando una XSLT obligatoria (para un par de elementos UL/LI en HTML)
• utilizando XML/RDF schemata (si hay una lista primaria disponible o a través de un nuevo esquema si no hay disponible una lista primaria)
• utilizando formas Arquitectónicas con soporte para listas de semátnicas
• etc.

Apéndice B: Definiciones de Accesibilidad en XML

• Esquema: A pesar de que utilizamos el término "esquema", no queremos que la gente asuma que estamos hablando sólo sobre un esquema tal como está definido en XML Schema sino, sobre algún documento o colección de documentos que contengan todas las referencias para la interpretación de un documento que está codificado de acuerdo con el uso de alguna aplicación o comunidad de discurso. "Perfil" podría ser una palabra mejor para el uso que nosotros le damos.

• Un esquema XML es accesible si posibilita y promueve activamente la creación de documentos accesibles.

• Un documento es accesible si puede ser entendido igualmente por su público objetivo independientemente del dispositivo usado para acceder a él.

  Un documento accesible también se define como uno que conforma las Web Content Accessibility Guidelines.

• La palabra "promueve" es importante ya que la palabra "posibilita" por sí sola no cubre el caso de que un esquema pudiera incluir una representación engañosa abierta en alguna parte y alegar la accesibilidad mínima.

  Por ejemplo, supongamos que HTML no tuviera un atributo ALT en IMG, en teoría seguiría "posibilitando" la creación de documentos accesibles, ya que los archivos HTML llevan contenido en formato texto y uno podría poner siempre la descripción de las imágenes en él, como en: <IMG SRC="Tasas.gif"> Cómo pagar sus tasas pero esto no "promueve" la accesibilidad ya que la mayoría de los autores no querrían repetir "Cómo pagar sus tasas" si el logo ya dice "Cómo pagar sus tasas" (asumiendo que no se usen CSS para esto en vez de un bitmap). Teniendo el atributo ALT se "promueve" la accesibilidad ya que ello permite a las imágenes ser descritas sin pérdidas de presentación - tales como la duplicación - para los visualizadores de imágen.

  En cualquier caso, la accesibilidad no consiste sólo en el contenido alternativo, tal como mostrará la siguiente sección.

• La palabra "dispositivo" también es importante ya que abarca más que sólo la independencia de los medios: se refiere tanto a dispositivos de salida (gráfica, por voz, braille, sólo texto) como de entrada (ratón, teclado, por voz, pantalla tactíl, teclado comprimido).

  Este término también conlleva potencialmente los problemas relativos a la disponibilidad de contar con banda ancha (o la carencia de ella), en los casos en que el acceso a los datos, debido a su volúmen, llega a ser imposible con conexiones lentas.

• Los términos "entendido igualmente" son críticos cuando se permite alguna forma de transformación airosa cuando se presentan los documentos en algún medio diseñado en principio para contener otro tipo de medios.

  Transformación airosa es un concepto clave en el área de la accesibilidad. Definámoslo.

  Definición:

  Transformación airosa es una propiedad de un sistema que puede seguir funcionando relativamente libre de errores cuando el sistema se daña o cuando los estímulos de entrada están incompletos. En tales sistemas, la eliminación de un único símbolo de la señal da como resultado la pérdida de la información almacenada en esa señal, sin una caída abrupta de todo el proceso.

  Por ejemplo, supongamos que yo necesito revisar el horario de trenes de la línea amarilla en Internet y no tengo acceso visual a la Web. El sitio Web de los ferrocarriles utiliza un icono animado de un vagón amarillo para llevarme al horario, y no proporciona una etiqueta en alguna parte diciendo que es para la línea amarilla, sólo confía en mi capacidad de ver el color, de repente yo no puedo entender este sitio: no se transforma airosamente.

  Si el diseñador del esquema no ha proporcionado una manera de añadir contenido alternativo para algunos elementos enriquecidos, como un vagón amarillo animado, el provedor de contenidos no alcanzará, con esta información, a toda su audiencia.

  Supongamos ahora que en una página diferente este sitio Web proporciona un bonito mapa "clicable" en 2D con todas las paradas, y me pide que seleccione mi punto de partida y de destino. Si se proporciona en formato texto una simple lista de las paradas de la línea, esto se transformará airosamente: no es tan rápido como un par de pulsaciones del ratón, de manera que hay una cierta "degradación" en el sistema, pero un usuario que depende del texto puede obtener la información.

• Otro aspecto del término "entendible" es que para que tenga sentido y pueda transformar airosamente el contenido de un documento basado en un esquema arbitrario, una Aplicación de Usuario tiene que encontrar alguna semántica. Esto puede lograrse reutilizando o ligando a priori elementos/atributos desconocidos a otros bien conocidos (en XML nuclear o HTML).

Apéndice C: Agradecimientos

Además de los editores, los siguientes participantes del Grupo de Trabajo de Protocolos y Formatos del WAI (PF) han contribuido directamente al contenido de este documento:

Kynn Bartlett , Geoff Freed, Al Gilman, Vijay Gummadi, Ian Jacobs, Chris Lilley, William Loughborough, Charles McCathieNevile, Dave Pawson, Gregory J. Rosmaita, Aaron Swartz y Carlos A. Velasco.

Apéndice D: Referencias

• W3C WAI Home page
• WAI PF Home page
• W3C XML Home Page