Fe de erratas de las Pautas de Accesibilidad de Contenido Web del WCAG Samurai [Traducción]

V1.0 de 26 de febrero de 2008

Es posible que prefiera leer antes el documento introductorio. [Original (inglés) - Traducción] Las secciones siguientes se han organizado en consonancia con las secciones listadas en las Pautas de Accesibilidad de Contenido Web 1.0 (inglés), las cuales se han empleado como base.

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. Tanto como le animamos a que escriba su propio texto equivalente, le animamos también a que decida racionalmente si el equivalente realmente es un equivalente.

Correcciones generales a la Pauta 1.1

Proporcionar un texto equivalente «del contenido de un elemento» únicamente se 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 texto «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, alrededor o inmediatamente después del elemento al que se refiere.
«Representaciones gráficas de texto» o «imágenes que representan texto» son imágenes de texto. No se prohibe emplear imágenes de texto si se proporcionan los equivalentes textuales correctos.
- 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.
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 sin marcado, no es posible ni 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, tablas para maquetar, 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 vincule 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 subtítulos abiertos o cerrados¹ (salvo las excepciones listadas abajo).
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 empleadas 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 o 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 breve tras la emisión del podcast. (No vamos a definir lo que significa «plazo breve».)
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. (Si se proporcionan 20 podcasts en un idioma pero la mitad de un episodio está en otro, no tiene que traducir esa parte.) No se puede considerar una traducción como técnica de accesibilidad.
Las emisiones o 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. En concreto, esto significa que los servicios de streaming que repiten emisiones tienen que tratar estas repeticiones como cualquier otra grabación.
La telefonía por Internet, los mensajes de voz o vídeo instantáneos, las conversaciones de viva voz durante partidas a juegos, y otros discursos o lenguaje de signos en directo no son contenido web y 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 subtitulados en abierto o en cerrado². Las películas mudas no deben ser subtituladas, 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 mera banda sonora sea insuficiente necesitan de una audiodescripción³, bien abierta, bien cerrada.⁴ Los vídeos con banda sonora pero sin componente visual (p.ej., una pantalla en negro continua) no necesitan una audiodescripción, 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 dobladas. (Si proporciona 20 vídeos en un idioma pero la mitad de uno está en otro, no necesita tarducir esa parte.)
- Este requisito incluye vídeos de lenguaje de signos, que tampoco necesitan ser traducidos. Sin embargo, si se proporciona una interpretación de voz o hay algún tipo de banda sonora, los requisitos de subtitulado normales se aplican.
- No se puede considerar una traducción como técnica de accesibilidad.
Screencasts (series de diapositivas narradas) son equivalentes a vídeos en cámara lenta con una velocidad normal de sonido, por lo que tienen que ser subtitulados.

Nótese que una transcripción separada en texto plano, HTML, o cualquier otro formato, no es un sustituto para el subtitulado o la audiodescripción. Una transcripción puede proporcionarse adicionalmente.

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

Esta pauta puede que sea la peor comprendida 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. Se proporciona 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. Como con otras pautas de las WCAG 1.0 relacionadas con discapacidades cognitivas, 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.

Colores sujetos a posible confusión son típicamente los que se sitúan en los ejes del rojo y el verde (para los tipos más comunes de las deficiencias de percepción de color, protanopia y deuteranopia) y en los ejes del azul y el verde (para otro tipo, la tritanopia). Los colores sustitutos vistos por los individuos con deficiencia de percepción de color tienden a beis, amarillo pálido y marrón. Todos estos colores, y las sombras similares a ellos, son colores sujetos a posible confusión.

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., un texto verde sobre fondo blanco puede situarse junto a un rectángulo sólido de color rojo).
No emplee el color como único medio para indicar un elemento de una página, independientemente de que sea en su marcado o en su estilo, o como referencia. 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 o iconos visuales, y/o una explicación en palabras de los errores y dónde se localizan.

Para mayor seguridad sobre combinaciones de color para textos y otros contenidos, use la paleta Brewer. [Original (inglés) - Traducción]

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 (los marcos están prohibidos), 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 subtítulos abiertos o cerrados o por medio de una audiodescripción, 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. Eso significa que cualquier comentario condicional —u otra programación o instrucción que se aplique sólo en ciertos casos— debe producir HTML y CSS válido cuando sea ejecutado. La página tal y como sea experimentada por el visitante debe emplear código válido.
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 composición no puede suponer una violación de las WCAG 1.0 o de esta fe de erratas.
- Se debe probar cada sitio con tamaños de fuente significativamente mayores y menores de los que se pretenda emplear por defecto. No deberían surgir barreras de accesibilidad de tales redimensiones. (No vamos a definir «significativamente mayores y menores».)
- Las composiciones líquidas se recomiendan encarecidamente, pero las composiciones fijas, o una mezcla de módulos fijos y elásticos, pueden emplearse si las pruebas no presentan barreras de accesibilidad.
- La diferencia entre unidades relativas y absolutas es inmaterial para esta fe de erratas.
  - El píxel, por especificación (inglés), era y es una unidad relativa. El uso de píxeles como unidad para especificar el tamaño de texto está explícitamente permitido. No obstante, cada unidad tiene su propia semántica implícita que debe seguirse. Los puntos tienen sentido casi exclusivamente para páginas impresas, mientras que los píxeles tienen sentido para textos extremadamente infrecuentes que deban especificarse en un tamaño concreto (p.ej., una advertencia legal obligatoria sobre derechos de copia).
Si para el lenguaje de marcado o de script no existe validador, el requisito de validar el código no se aplica.

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 los 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 formularios.
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 todo contenido es 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.

Pauta 4. Clarifique el idioma natural empleado

Como recordatorio: idiomas naturales son aquellos empleados por seres humanos para comunicarse entre sí. Lenguajes de programación de cualquier clase, incluso aquellos similares a los idiomas naturales o derivados de ellos, no son idiomas naturales. Tampoco lo son los empleados por animales no humanos.

Debe identificar el idioma principal de un documento, preferiblemente en la etiqueta html, que debe incluirse en documentos XHTML (p.ej., html o html xml:lang="en"). Emplee para ello códigos públicos (aunque no limitados a la ISO 639-1).
Si la página es bilingüe o multilingüe, y cada idioma tiene la misma prioridad, no debe especificar idioma principal en la medida en que no hay «idioma principal». Especifique el que se emplee en cada parte de la página. Por ejemplo, añada div o span si es necesario para englobar los textos de sus respectivos idiomas; añada los códigos de idioma a ese marcado <div lang=""> o <span lang="">.
Una página cuyo marcado no funcione más que como contenedor para un vídeo de lenguaje de signos o para un vídeo o grabación de idioma hablado o escrito 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 elementos div o span si es necesario.
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 (p.ej., hreflang="fr" en un vínculo a una página en francés desde una no francesa).
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. Específicamente no hay requisito del atributo summary para cada tabla
- Puede emplear cualquier medio aplicable para introducir y explicar tablas, incluido summary, caption, encabezados de tabla, encabezados ordinarios (del h1 al h6) y texto plano.

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. En particular, esto exige que emplee JavaScript u otro lenguaje de script de manera que sea intrínsecamente accesible. No es obligatorio crear una única página que funcione exactamente igual con y sin scripts, de la misma forma que tampoco es un requisito crear una página con script y otra sin él.
Una página que emplee tecnologías de gestión de derechos digitales o protección de copia de cualquier clase no puede ser declarada como conforme a WCAG+Samurai, en la medida en que su compatibilidad con tecnologías asistivas y con futuras tecnologías no puede ser comprobada independientemente.

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

No cause parpadeos ni destellos. La publicidad, incluso la servida por terceras partes para una página, está sujeta a esta pauta. Ésta tampoco debe parpadear ni destellar.
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 de «iniciar», o por cualquier otro método que sea accesible para los usuarios con discapacidades).
- El visitane del sitio debe poder pausar o detener en contenido en movimiento. Nótese que no hay excepciones.
- El visitante del sitio debe poder cambiar la velocidad del movimiento, a menos que la implementación de los cambios de velocidad sea de una dificultad desproporcionada. (Si por motivos de limitación de medios técnicos se debe escoger, un cambio de velocidad que ralentice el contenido en movimiento es más importante de implementar que uno que lo acelere.)
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 8. Asegure la accesibilidad directa para interfaces de usuario incrustadas

[No se hacen correcciones.]

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 por medio de tabindex. No emplee tabindex.
No cree controles de teclado personalizados por medio de accesskey. No emplee accesskey.

Pauta 10. Emplee soluciones temporales

No abra pop-ups ni ventanas nuevas, y no cambie la ventana actual sin informar al usuario.
- Se recomienda encarecidamente el empleo de un mero texto. El empleo de cualquier otro medio debe reservarse para los casos donde el texto plano sea desproporcionadamente difícil o imposible.
- El atributo title en un hipervínculo puede ser suficiente en el caso único de páginas legadas que sean desproporcionadamente difíciles de actualizar. No es suficiente para páginas recién creadas o en otras circunstancias.
No proporcione alternativas en texto lineal. Emplee un marcado semántico correcto; no emplee tablas para maquetar.
No añada por defecto caracteres de prerrelleno 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 texto se incluya después de procesar datos introducidos por el usuario (p.ej., después de verificar que un identificador de usuario no está disponible, el sitio podría proporcionar uno nuevo),
- que el contenido semántico del documento incluya de forma natural tales caracteres (p.ej., una oferta promocional disponible sólo para residentes de cierto país podría prerrellenar el nombre de ese país), o
- que los caracteres hayan sido previamente introducidos por el usuario (p.ej., en el caso del refinamiento de una búsqueda anterior).
No añada caracteres imprimibles (rodeados de espacios en blanco 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.
Emplee CSS como medio principal de controlar la presentación de documentos XHTML y HTML.
Flash, JavaScript y otras tecnologías «interactivas» se permiten explícitamente, pero deben seguirse las pautas de accesibilidad publicadas para todos sus casos.
Las características depreciadas, incluidos elementos y atributos, pueden emplearse si no existen alternativas razonables.
PDF puede emplearse sólo para ciertos tipos de documentos. [Original (inglés) - Traducción] 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. (Puede emplear iframe.)
No hay obligación de proporcionar 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 del documento sea significativamente más difícil de comprender sin ella. (No vamos a definir «significativamente más difícil».)
No emplee arte ASCII.
La información estructural oculta (p.ej., elementos de encabezados posicionados fuera de pantalla) se permiten siempre y cuando la semántica del documento garantice la información.