Esta traducción corresponde al boceto de la Fe de erratas…, y no a la actual versión. Ver «WCAG Samurai, segundo asalto» para más información.

Boceto de la Fe de erratas de las Pautas de Accesibilidad de Contenido Web del WCAG Samurai [traducción]

Es posible que prefiera leer antes el documento introductorio. [Original (inglés) - Traducción]

Nota especial acerca de las discapacidades cognitivas

Esta fe de erratas no corrige sustancialmente las provisiones de las WCAG 1 en lo referente a discapacidades cognitivas. La conformidad con WCAG+Samurai no puede ser una declaración de accesibilidad total con respecto a las personas con discapacidades cognitivas.

Pauta 1. Proporcione alternativas equivalentes a los contenidos visuales y sonoros

El principal error en muchas de las discusiones sobre los textos equivalentes es la afirmación de que el texto debe «cumplir esencialmente la misma función o propósito» (WCAG 1), o bien «describir» su contenido. Tal terminología confunde a los desarrolladores al hacerles creer que deben escribir un tratado acerca de una simple imagen: «Ésta es una imagen de una flecha que es un vínculo a la página inicial del sitio».

Adicionalmente, los textos equivalentes sólo pueden ser juzgados por un ser humano. La escritura y la valoración de los mismos es subjetiva. El WCAG Samurai no va a intentar dictar el estilo de escritura de cada cual.

El WCAG Samurai redefine los textos equivalentes como reemplazos para una imagen u otro objeto.

Se debe ser capaz de sustituir el objeto original por el texto equivalente. Al hacerlo, la página debe seguir siendo funcional, y los lectores no deben perder contenido significativo.
Puede ser que no pueda evitar la pérdida de significado al escribir equivalentes de texto para algunos trabajos, como fotografías o pinturas. No tendría sentido definir «contenido significativo» para tales casos; simplemente le animamos a que escriba su propio texto equivalente, y le animamos a que decida racionalmente si el equivalente realmente es un equivalente.

Correcciones a la Pauta 1.1

Proporcionar un texto equivalente «del contenido de un elemento» únicamente de aplicaría a un hipotético iframe y, donde sean apropiados, a SVG y Flash. Las páginas en HTML ordinario no cuentan con medio de proporcionar un equivalente de texo «del contenido de un elemento». Posicionar fuera de la pantalla un duplicado del texto presentado en una imagen con contenido textual puede ser considerado comparable y se permite.
Se puede dejar vacío un equivalente de texto (p.ej., un alt nulo, alt="") si existe un texto que cumpla la función del texto equivalente inmediatamente antes o inmediatamente después del elemento al que se refiere.
«Representaciones gráficas de texto» son imágenes de texto. En HTML ordinario, emplee un alt cuyo texto sea exactamente el mismo —incluso si éste está escrito en más de un idioma—. Ejemplos de tipografía u otras ilustraciones de textos sin significado no necesitan incluir todo el texto de la imagen, y se pueden emplear equivalentes similares a alt="Ejemplo de la fuente Verdana que muestra letras y números". Para imágenes de textos en los que las propiedades de los tipos son de interés (p.ej., el uso de ciertas fuentes en negrita o cursiva en el interior de una palabra), o en las imágenes de bloques de texto extensos donde el diseño gráfico o la edición son de interés, no se necesita incluir el texto, sino que el texto alternativo debe explicar los puntos de interés.
Los símbolos no son «representaciones gráficas de texto» a menos que sean representaciones directas de texto. Se deben emplear sólo si Unicode, u otra codificación de caracteres declarada, no puede representar los caracteres. Por ejemplo, no se deben emplear imágenes de flechas en texto corrido o valores de atributos; se debe emplear el caracter de flecha de Unicode.
No hay prohibición en contra de emplear imágenes de texto («imágenes para representar texto») si se proporcionan equivalentes de texto correctos.
Los «Applets» y los «scripts» deben ser intrínsecamente accesibles, por medio de las técnicas de accesibilidad propias de, por ejemplo, JavaScript o Flash. No emplee textos equivalentes para tales applets intrínsecamente accesibles. Ignore la referencia a los «objetos de programación».
Si las imágenes se van a usar como viñetas de listas, emplee sólo CSS, como en ul { list-style: url("flecha.gif") disc }.
Los archivos PDF publicados por los medios comunes (p.ej., un hipervínculo al propio PDF) no son información no textual, y por tanto no requieren de textos equivalentes.
Cuando se vincule directamente a una imagen de manera que la imagen sea vista como un documento independiente, no es necesario ningún texto equivalente. Por ejemplo, vincular a http://wcagsamurai.org/image.jpg no requiere que se escriba un texto equivalente.

Qué no hacer

No emplee GIF animados, arte ASCII, marcos, imágenes espaciadoras ni mapas de imagen del lado del servidor.

Gráficas y diagramas

El texto equivalente ordinario para una gráfica o un diagrama (p.ej., alt) debe explicar los puntos de la gráfica o diagrama que sean relevantes para el documento en el caso de que éste se pueda malinterpretar si se omiten.
Las gráficas o diagramas extensamente detallados deben ser descritos por medio de longdesc o por medio de texto ordinario; este último puede ser posicionado fuera de la pantalla si se desea.
No publique (o víncule al) conjunto de datos original como pretendido texto equivalente. Si se proporcionan textos equivalentes apropiados, entonces, adicionalmente, se pueden publicar (o vincular a) los datos originales.

Sonidos y archivos de audio

Los sonidos no deben reproducirse sin que el usuario los active. La página o sitio no debe reproducir sonidos automáticamente una vez cargados.
Los sonidos y el diálogo en juegos, bien pregrabados o bien generados por la máquina, deben aparecer en transcripciones abiertas o cerradas¹.
Podcasts y otras grabaciones que consistan principalmente en diálogo, discursos o entrevistas deben ser transcritas.
- Para los sitios grandes con presupuestos y recursos significativos, la publicación de la transcripción debe coincidir con la emisión del podcast. No hay tal obligación para los sitios pequeños con presupuestos limitados (lo que incluye los blogs personales), pero no puede haber un retraso no razonable. (No vamos a definir «grandes» ni «pequeños», ni qué sea o no «razonable».)
- Las grabaciones usadas como ejemplos de lenguaje hablado (en las que es el idioma mismo o su uso el propósito de la grabación, no el significado de las palabras empleadas), incluidas sesiones de aprendizaje de un idioma y grabaciones del campo de la lingüística, no necesitan ser transcritas.
Los podcasts y otras grabaciones que sean principalmente musicales, incluidas sesiones de DJ y música programada para emisiones web, no necesitan ser transcritas. No obstante, se deben proporcionar listas de los temas con títulos e intérpretes, y se deben publicar en un plazo máximo de veinticuatro horas desde la emisión del podcast.
Los podcasts y otras grabaciones en idiomas distintos del idioma de la página en la que están incluidos no necesitan ser traducidas ni dobladas. No se puede considerar una traducción como técnica de accesibilidad.
Las emisiones web en directo no grabadas ni archivadas no tienen que ser transcritas. Una vez grabadas o archivadas es cuando las provisiones de arriba se aplican.
La telefonía por Internet, los mensajes de voz instantáneos, las conversaciones de viva voz durante partidas a juegos, y otros discursos en directo no tienen que ser transcritos.

Vídeos

Los vídeos no deben reproducirse sin que el usuario los active. La página o sitio no debe reproducir vídeos automáticamente una vez cargados.
Todos los vídeos que contengan banda sonora deben ser transcritos en abierto o en cerrado. (El término correcto es «transcripción», no «subtitulado»; el subtítulo es una traducción. En inglés, emplee «transcripción».) Las películas mudas no deben ser transcritas, pero el hecho de que carecen de banda sonora debe explicarse, bien en la página que las vincula o bien en la página en la que están incrustadas.
Los vídeos para cuya comprensión la sola banda sonora sea insuficiente necesitan de una descripción sonora, bien abierta, bien cerrada. (El término correcto es «descripción sonora», no «descripción audible» tal como aparece en las WCAG 1, ni tampoco «vídeo descriptivo» o «videodescripción». En inglés, emplee «descripción sonora».)² Los vídeos con banda sonora pero sin componente visual (p.ej., una pantalla en negro continua) no necesitan de descripción sonora, pero el hecho de que no hay componente visual debe explicarse, bien en la página que los vincula o bien en la página en la que están incrustados.
Los vídeos que se proporcionan como ejemplos de idioma escrito, hablado o por signos (en las que es el idioma mismo o su uso el propósito de la grabación, no el significado de las palabras empleadas), incluidas sesiones de aprendizaje de un idioma y grabaciones del campo de la lingüística, no necesitan ser transcritas ni descritas.
Los vídeos en idiomas distintos del idioma de la página en la que están incluidos no necesitan ser traducidos, transcritos ni doblados. No se puede considerar una traducción como técnica de accesibilidad.

Nótese que las excepciones indicadas arriba son las únicas excepciones.

Pauta 2. No confíe sólo en el color

Esta pauta puede que sea la peor comprendia de las WCAG 1, en parte porque confunde las discapacidades humanas con el equipamiento tecnológico (y además no comprende correctamente la discapacidad).

Los propósitos de esta pauta son:

Prevenir el uso de colores sujetos a posible confusión, de formas sujetas a posible confusión (proporcionando así accesibilidad para personas que padezcan las principales deficiencias relacionadas con la percepción del color: protanopia, deuteranopia, y tritanopia).
Evitar referencias a elementos de una página por medio exclusivo de su color (proporcionando así accesibilidad al pequeño grupo de personas afectadas de acromatopsia —quienes tienen muy poca o ninguna capacidad para percibir color—, y a las personas totalmente ciegas).

La pauta original de las WCAG no proporciona las combinaciones de color preferidas por las personas que padecen ciertas deficiencias de aprendizaje. Esta fe de erratas no va a rectificar tal omisión.

Ignore todas las referencias a «dispositivos no visuales» o «dispositivos monocromáticos». La accesibilidad web se refiere a personas con discapacidades, no a sus equipos. Un «dispositivo» no es una persona, por lo que no precisa accesibilidad.

Para contenido propiamente dicho, no sitúe un color sujeto a posible confusión sobre otro de las mismas características. Por ejemplo, no sitúe texto rojo sobre un fondo verde o negro. No hay limitación a la hora de usar colores potencialmente confusos como elementos de diseño, ni tampoco a la hora de situar colores potencialmente confusos en campos adyacentes (p.ej., texto verde sobre fondo blanco junto a un rectángulo sólido de color rojo).
No emplee el color como único medio para indicar un objeto de una página, independientemente de que sea en su marcado o en su estilo. Por ejemplo, no devuelva un formulario con los errores indicados en rojo exclusivamente; emplee marcado adicional como strong, y/o emplee texto adicional como asteriscos, y/o una explicación en palabras de los errores y dónde se localizan.

Pauta 3. Emplee marcado y hojas de estilo, y hágalo de manera apropiada

El HTML y las CSS de todas las páginas web conformes a las WCAG+Samurai deben ser válidas.

Se puede emplear cualquier declaración de tipo de documento HTML excepto Frameset, cualquier declaración de tipo de documento XHTML excepto Frameset, cualquier revisión de HTML publicada (incluso HTML 5 o un boceto de HTML 5), o cualquier declaración de tipo de documento XML, incluida su propia DTD personalizada para XHTML.
Si la única causa de invalidez del código HTML o XHTML es el empleo de la etiqueta embed para vídeo, la página se considerará como conforme si el vídeo se ha hecho accesible por medio de su transcripción abierta o cerrada o por medio de una descripción sonora, según lo requiera su contenido. Se permite emplear una DTD de XHTML personalizada que incluya embed (ejemplo, en inglés).
Todo HTML o CSS insertado en una página por medio de un script u otro medio cualquiera debe dar como resultado una página igualmente válida cuando se interprete para el usuario.
Se puede emplear cualquier versión de CSS.
La página se considerará conforme incluso si un validador encuentra un error en el documento, si se conoce que tal validador comete por sí mismo un error al validar un tópico específico.
Se puede emplear cualquier unidad definida para designar tamaños de texto, composición y demás propósitos. La diferencia entre unidades relativas y absolutas es inmaterial para esta fe de erratas. (Los píxeles, por definición, eran y son una unidad relativa.) El uso de píxeles como unidad para especificar el tamaño de texto está explícitamente permitido.
Si para el lenguaje de marcado no existe validador, esta pauta debe ser ignorada.

Mantener las páginas en conformidad

Como recordatorio: no todas las páginas de un sitio necesitan ser conformes con las WCAG+Samurai.

En el momento en que se sea consciente de que una página que se intenta hacer conforme con las WCAG+Samurai es inválida, se debe reparar el contenido inválido en un plazo razonable. Si la reparación no es posible, no se puede declarar la conformidad de esa página.
Las páginas que no puedan ser mantenidas en su estado de validez —incluidos foros de discusión en el que los miembros del público pueden añadir sus propios textos y/o marcado, y algunas aplicaciones web— no pueden portar una declaración de conformidad con las WCAG+Samurai.

Obligación de emplear HTML semántico

No sólo se debe emplear HTML válido en los documentos, sino que se debe emplear HTML válido y semántico.
Debe emplear los elementos y atributos más apropiados para el contenido, incluidos encabezados, listas y bloques de cita.
En los casos ambiguos, debe emplear los elementos y atributos que de manera aproximada mejor se ajusten al contenido, incluso si algunos autores no están de acuerdo. Por ejemplo, puede marcar elementos ambiguos como una lista de definición incluso en caso de que otros autores empleen una lista ordenada, o puede emplear elementos de presentación como b o i cuando se trate del marcado de un contenido que sea más «presentacional» que estructural (p.ej., cuando se representa el aspecto de un documento impreso para hacer referencia a ese aspecto).
- El desacuerdo de otros autores con las elecciones que tome no es relevante para esta fe de erratas.
- Esta excepción se aplica exclusivamente a aquellos casos ambiguos, y no a elementos claramente diferenciados de una página típica. En ningún caso es una licencia para marcar cada elemento de una página como un párrafo si no hay nada que sea un párrafo, ni para utilizar negrita o cursiva para dar formato a líneas en lugar de emplear los elementos correctos para encabezados, ni para emplear párrafos como elementos de lista, ni para usar b o i indiscriminadamente.
No es obligatorio emplear el elemento q; debe indicar las citas en línea, pero basta con el empleo de comillas.
No debe emplear el elemento blockquote para aplicar márgenes a un bloque de texto.

Clarificar el idioma empleado

Debe identificar el idioma principal de un documento (en la etiqueta html, que debe incluirse en documentos tanto XHTML como HTML). Debe emplear para ello códigos públicos (aunque no limitados a la ISO 639-1).
Si la página es bilingüe o multilingüe, no debe especificar idioma principal. Debe especificar el que se emplea en cada parte de la página, añadiendo div o span si es necesario como elementos contenedores de las partes en cada idioma.
Una página cuyo marcado no funciona más que como contenedor para un vídeo de lenguaje de signos o para un vídeo o grabación de idioma hablado debe emplear el código identificativo correcto para ese idioma. Una página escrita en un idioma que incluya un vídeo o grabación de idioma hablado debe identificar correctamente ese segundo idioma, añadiendo div o span si es necesario como elementos contenedores del objeto multimedia.
Cuando el autor sepa que un hipervínculo dirige al usuario a una página, vídeo o grabación en otro idioma, debe emplear hreflang con el código de idioma del documento de destino.
Cuando una página disponga de traducción, debe emplear link rel="alternate translation" con el href apropiado apuntando a la traducción.
No intente marcar cambios del idioma para los valores de un atributo.
Ignore las referencias de las WCAG con respecto a los motores de búsqueda.

Pauta 5. Cree tablas que se transformen elegantemente

No emplee tablas para maquetar.
El empleo de summary, caption y las abreviaturas para los encabezados de tabla está cubierto en la Pauta 3. Estos elementos y atributos deben emplearse si el contenido los justifica.

Pauta 6. Asegúrese de que las páginas que requieren nuevas tecnologías se transforman elegantemente

No proporcione presentaciones o páginas alternativas (Pauta 6.5). Haga la página original accesible.

Pauta 7. Asegure el control del usuario de los cambios de contenido que dependan del tiempo

No cause parpadeos. La publicidad servida por terceras partes para una página está sujeta en esta pauta, y tampoco debe parpadear.
El «contenido móvil», que se desplace verticalmente, que se arrastre, o que sea animado, no puede iniciarse automáticamente, ni siquiera en los elementos publicitarios. El usuario debe elegir si quiere permitir tal movimiento (bien habilitando preferencias para el sitio, bien haciendo clic explícitamente, bien pulsando un botón, o por cualquier otro método que sea accesible para los usuarios con discapacidades).
Cuando una redirección del lado del servidor sea imposible (p.ej., porque el responsable del sitio no pueda modificar el archivo .htaccess o su equivalente), se permite un meta con un refresh de 0.
blink y marquee no se permiten, ni siquiera en una DTD de XHTML personalizada.

Pauta 9. Diseñe con independencia del dispositivo

No emplee mapas de imágenes del lado del servidor.
No cree un orden personalizado de navegación para la tecla Tab. No emplee tabindex.

Pauta 10. Emplee soluciones temporales

No abra pop-ups ni ventanas nuevas, y no cambie la ventana actual sin informar al usuario. (El método preferido para informar al usuario es el texto plano. El atributo title en un hipervínculo puede ser suficiente.)
No proporcione alternativas en texto lineal. Emplee un marcado semántico correcto; no emplee tablas para maquetar.
No añada por defecto caracteres ancla en cajas de formulario editables ni áreas de texto, incluso si los caracteres se eliminan por medio de un script cuando el campo recibe el foco, a menos que el contenido semántico del documento incluya de forma natural tales caracteres.
No añada caracteres imprimibles (rodeados de espacios o no) entre vínculos adyacentes que no pertenezcan a estos, a menos que el contenido semántico del documento incluya de forma natural tales caracteres.

Pauta 11. Aplique tecnologías y pautas del W3C

Emplee XHTML o HTML para los documentos que consistan principalmente en texto y/o imágenes. No existe obligación de emplear las últimas versiones de HTML o XHTML. Las variaciones de HTML desarrolladas fuera del W3C se permiten si están definidas adecuadamente. Se permiten las DTD personalizadas para XHTML.
Las características depreciadas, incluidos elementos y atributos, pueden emplearse si no existen alternativas razonables.
Emplee PDF sólamente para documentos de estos tipos:
1. Notas de texto, notas a pie de página o notas al margen, dado que no hay forma de marcar estas estructuras en HTML.
2. Un formulario interactivo, dado que la interactividad de PDF es más flexible y potente que la de HTML. (Empléelo con precaución y sólo si HTML es realmente insuficiente.)
3. Versiones combinadas de contenidos accesibles e innaccesibles. Un caso típico es el escaneado de un histórico que incluya texto activo³. Otro ejemplo —uno que es legal en Canadá bajo una excepción de copyright (inglés)— es la traducción en lenguaje de signos dentro de un texto o una grabación sonora.
4. Los creados específica y exclusivamente para impresión. Y nos referimos a eso, no a documentos tan mal diseñados que los usuarios no tengan más remedio que imprimirlos porque su lectura en pantalla sea demasiado tediosa. Los documentos burocráficos oficiales, si están en Internet, pueden permanecer en PDF.
5. Los diseñados para anotaciones y devolución: si se está publicando algo que pretenda obtener comentarios que deban ser enviados de vuelta al autor, PDF proporciona unas estructuras valiosas de las que HTML no dispone.
6. Un especímen de tipo que sea imposible de crear en HTML (inglés), a menos que el especímen sea una tipografía como Arial.
7. Una muestra de un formato que un navegador no sea capaz de renderizar (p.ej., documentos de Illustrator o Photoshop) o que sólo pueda renderizar de forma insatisfactoria (CAD donde GIF o JPEG no tengan resolución suficiente). Este caso incluye también archivos PDF cuyo fin es ser muestras de archivos PDF.
8. El archivo del estado de un documento en un momento específico. En este contexto, PDF es un método de preservación de un formato adecuado incluso para páginas HTML.
9. Un documento en un idioma cuyo alfabeto no tenga un soporte satisfactorio en los navegadores. Éste puede ser un subapartado del caso de ejemplo de tipo si el PDF se considera como ilustración o documentación del sistema de escritura empleado por un idioma.
10. Fórmulas matemáticas, si HTML es insuficiente para codificar y/o representar tales fórmulas.
11. Documentos con un formato restringido legalmente.
12. Documentos con control de derechos digitales.
13. Uno huérfano, cuando el software original no puede localizarse o no puede usarse en un sistema actual.
Todos los PDF deben etiquetarse, empleando para ello los elementos semánticos apropiados para el contenido. (En otras palabras, un documento en el que todo el texto sea etiquetado como Para no es conforme a estas normas si el texto no está íntegramente compuesto por párrafos.)
No cree páginas alternativas. Haga la página original accesible.

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

No emplee marcos.
No proporcione un mapa del sitio ni una tabla de contenidos a menos que el sitio no pueda ser entendido o navegado sin ellos.
No sitúe información distintiva al principio de encabezados, párrafos, listas, etc., a menos que el contenido semántico del documento lo requiera.
No emplee arte ASCII.