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.

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

Ésta es una introducción a la fe de erratas (correcciones) de las Pautas de Accesibilidad de Contenido Web 1.0 (WCAG 1). La fe de erratas ha sido publicada por y puede atribuirse al WCAG Samurai, un grupo independiente de desarrolladores reunido en 2006. Publicamos esta fe de erratas el 7 de junio de 2007.

¿Dónde puedo encontrar el documento de erratas completo?

Está disponible desde junio de 2007. [Original (inglés) - Traducción]

¿Y con respecto a las WCAG 2?

Ésta fe de erratas no contempla las WCAG 2.0 bajo ningún aspecto. La fe de erratas del WCAG Samurai ha sido publicada como una alternativa a las WCAG 2. Se puede cumplir con las WCAG 2, o con esta fe de erratas, o con ninguna, pero no con ambas a la vez.

¿Es ésta la versión final?

No. Éste es un único borrador. Una versión final saldrá a la luz en tres semanas, después de que la revisión por pares haya sido tenida en cuenta. También se tendrán en cuenta los correos electrónicos recibidos y puede que se incorporen cambios sugeridos en estos.

Tras ese punto, la Fe de erratas de de las Pautas de Accesibilidad de Contenido Web del WCAG Samurai quedará fija en su versión 1.0 para un futuro inmediato. (No tenemos intención de declarar explícitamente si publicaremos revisiones o no. Vamos a ver qué tal va.)

Resumen rápido

He aquí un resumen rápido de los cambios que hemos hecho sobre las WCAG 1. (Si quiere cumplir con las WCAG+Samurai, tiene que aplicar las secciones apropiadas en toda su extensión, no este resumen, recogido aquí por motivos de conveniencia.)

Prohibimos y exigimos: No nos enzarzamos con términos imprecisos como «evite» o «hasta que los agentes de usuario», cuyas definiciones públicas son malinterpretadas o ignoradas. En su lugar, se indicará si se debe aplicar o no una pauta. Utilizamos términos como «borre», «ignore» y «no use» por un lado, y «debe» por el otro.
No a la Prioridad 3: No sólo no tiene que cumplir con las pautas de Prioridad 3, muchas de las cuáles son inaplicables, sino que no debe cumplirlas.
Sí a las Prioridades 1 y 2: Debe cumplir con las pautas de las Prioridades 1 y 2, tal y como han sido corregidas por el WCAG Samurai. Entre otras cosas, esto significa que debe crear un código válido en prácticamente cada caso.
No hay pautas nuevas para las discapacidades cognitivas: Las WCAG 1 y 2 no son adecuadas para tratar las necesidades de las personas con discapacidades cognitivas como la dislexia (aunque ésta es sólo una de tales discapacidades, muchas de las cuales a veces presentan necesidades en conflicto entre sí). No podíamos permitirnos eliminar la única pauta bajo la Prioridad 3 que intenta tratar las discapacidades cognitivas («Emplee el lenguaje más claro y sencillo»), pero tampoco hemos sido capaces de idear un repertorio de nuevas pautas. Tampoco lo ha hecho nadie más; ello requeriría considerablemente más investigación y, más importante aún, pruebas por parte de usuarios. No confiamos en lo que hemos leído por parte de los presuntos expertos en este campo. Dejamos en este aspecto las WCAG 1 prácticamente como están y, separadamente, exigimos que el cumplimiento de las WCAG+Samurai no se considere una declaración de accesibilidad completa con respecto a las personas con discapacidades cognitivas.
Las tablas destinadas a maquetación y los marcos están prohibidos:Todas las pautas que se refieren a tablas destinadas a maquetación y a marcos han sido borradas. Sí se puede emplear todavía iframe.
Adiós, noscript: Scripts y applets (por lo que ahora entendemos, la mayor parte de las veces, Ajax y Flash) deben ser directamente accesibles. No sólo no se puede seguir incluyendo el texto estándar en el elemento noscript, sino que el elemento no debe emplearse.
Prohibimos la mayor parte de los PDF: Los PDF que deberían ser HTML están prohibidos a menos que vayan acompañados de un HTML. Todos los demás PDF deben estar marcados con sus correspondientes etiquetas.
Adiós, reliquias del siglo XX: En lugar de preocuparnos por cómo hacer accesibles residuos de finales del siglo XX, simplemente excluimos absurdos como el arte ASCII.
Somos más estrictos con respecto al contenido multimedia que nadie: Todos los vídeos con pista de sonido deben ser transcritos, la mayor parte de los vídeos deben tener una descripción sonora (dependiendo del contenido), se deben transcribir los podcast con alto contenido en diálogos (aunque no en el caso de los podcast musicales), y no pueden emplearse archivos de texto o HTML como sustitutos para la transcripción o la descripción sonora.

¿Cómo puedo cumplir con la fe de erratas?

La Fe de erratas de las Pautas de Accesibilidad de Contenido Web del WCAG Samurai es un adjunto a las WCAG 1, que deben emplearse como base. Se debe empezar por leer y comprender las WCAG 1, y después leer esta fe de erratas como correcciones a las mismas.

La fe de erratas indica qué partes de las WCAG 1 deben ignorarse y qué partes son incorrectas. Indica también cuáles son los métodos modernos con los que cumplir con las mismas. Así, la fe de erratas selecciona parte del contenido total de las WCAG 1. Sin embargo, no se puede escoger algunas de las correcciones. Se debe cumplir con todas y cada una de ellas, en la medida en que un documento incluya algún contenido sometido a una pauta sobre el que puedan aplicarse.

No es obligatorio declarar la conformidad con la Fe de erratas de las Pautas de Accesibilidad de Contenido Web del WCAG Samurai, ni siquiera en el caso de que de hecho sea así. Pero si se desea hacer la declaración, se debe hacer claramente. No vamos a dictar los términos concretos que se deben emplear, pero algunos ejemplos son:

Este sitio cumple con las WCAG 1.0, tal y como son corregidas en la Fe de erratas de las Pautas de Accesibilidad de Contenido Web del WCAG Samurai.
Este sitio ha sido creado en cumplimiento de las WCAG+Samurai.
Cumplimos con las pautas de accesibilidad y la Fe de erratas de las Pautas de Accesibilidad de Contenido Web del WCAG Samurai.

Si solamente algunas de las páginas del sitio son conformes, se debe limitar las declaraciones a tales páginas. Si sólo algunas de las páginas del sitio no son conformes, se debe declarar que tales páginas no son conformes.

Algunos ejemplos de terminología que no se puede emplear:

Cumplimos con la mayoría de las WCAG (tal como han sido corregidas). [No se ha especificado el nombre del WCAG Samurai.]
La mayoría de las páginas de este sitio cumplen los requisitos de las WCAG 1.0 y del WCAG Samurai. [Se debe especificar qué páginas no los cumplen.]

Por qué desarrollamos el Samurai en un proceso cerrado

Porque el proceso abierto manifestado ostensiblemente por el W3C en realidad no es abierto: está dominado por las multinacionales; las opiniones de aquellos que no sean expertos invitados pueden ser y son ignoradas; el Grupo de Trabajo puede declarar que se ha alcanzado consenso incluso chocando de frente con disputas internas irresolubles; el estatus de experto invitado ha sido rechazado o revocado; el proceso en sí mismo es innaccesible para gente con discapacidades, como por ejemplo para personas sordas; los presidentes del Grupo de Trabajo de las WCAG han actuado como matones.

El proceso «abierto» del W3C simplemente no funciona. Hemos intentado otra cosa.

Implicación de un HTML semántico

Para cumplir con las WCAG+Samurai, se deben satisfacer todas las Prioridades 1 y 2 de las Pautas, tal y como han sido corregidas. Eso incluye la pauta 3.2, que requiere de un código válido («documentos válidos con respecto a gramáticas formales públicas»). Sabemos por experiencia que un documento puede ser un HTML estrictamente válido y aun así ser innaccesible. El clásico ejemplo son las tablas empleadas para maquetación. Un ejemplo más relevante es el de una página con un HTML válido pero pobre desde el punto de vista semántico (p.ej., que cada bloque de texto haya sido marcado como un párrafo con p, incluso listas y encabezados). No podemos criticar al W3C por omitir la semanticidad del documento cuando se redactaron las WCAG 1.0 a finales de los 90, pero podemos corregir ahora tal omisión.

Bajo WCAG+Samurai, no sólo se debe escribir documentos HTML válidos (con CSS válidas), sino que se debe emplear el marcado semánticamente correcto para el documento. Sabemos que algún contenido es ambiguo y que a veces el marcado es aproximado (¿lista de definición?, ¿lista no ordenada?, ¿strong?, ¿sólo negrita?). Casos límite como estos no son suficientes para descalificar la declaración de conformidad con WCAG+Samurai porque, en la Web, el marcado semántico correcto para la mayoría del contenido no se discute.

En la medida en que estamos exigiendo código válido, muchas de las pautas de las WCAG 1 se vuelven redundantes o demasiado restrictivas. En concreto, en el curso de la eliminación de requisitos para cumplir con la Prioridad 3, alguna de sus pautas quedaron subsumidas bajo el requisito de emplear HTML válido y semántico.

Se debe emplear abbr o acronym cuando el contenido lo requiera, pero se dan algunas condiciones.
- Sólo se debe emplear este marcado en caso de que un lector humano o una tecnología adaptativa pueda ser inducido a error (p.ej., no hay que marcar emisora de TV como emisora de <abbr>TV</abbr>).
- Los acrónimos y abreviaturas sin expansión en su uso cotidiano (p.ej., DVD) no necesitan ser marcados.
- No hay solución inmediata a la disputa acerca del significado de «abreviatura», «acrónimo» y «siglas», y esta fe de erratas deliberadamete no se va a unir a esa discusión.
- La frase «en un documento donde [la abreviatura o el acrónimo] aparezca por primera vez» de las WCAG no tiene un significado claro, porque los visitantes pueden comenzar a leer un documento por cualquier punto. Ignore esta provisión.
- Lo que intentamos es clarificar el problema actual de incluir la expansión de las abreviaturas en el HTML; no estamos interesados en perpetuar una pauta que permite a cualquier intruso declarar que toda una página es inaccesible sólo porque su autor hizo una elección inteligente acerca de las abreviaturas y los acrónimos con la que el intruso no está de acuerdo. No sólo le animamos a que haga elecciones inteligentes, sino que debe hacerlas.
- Tampoco estamos interesados en perpetuar un terreno de juego desigual, en el que los autores deben marcar partes extensas de sus documentos y en el que sin embargo los creadores de tecnología adaptativa nunca tienen que actualizar sus propios diccionarios de excepciones.
- Tampoco creemos que la expectativa de un lector por encontrar el significado de una abreviatura o acrónimo cree una barrera de accesibilidad para mucha gente con discapacidades; en ese contexto, tales lectores están en la mismas condiciones que los lectores no discapacitados.
En resumen, el debate sobre abreviaturas/acrónimos consume demasiado tiempo para el daño tan minúsculo que causa incluso en el documento más innaccesible y peor marcado.
Mantenemos la exigencia de indicar un cambio en el idioma del documento, pero eso implica, obviamente, que el idioma original del mismo haya sido también indicado. No creemos que eso sea una exigencia exagerada.
Existe más de un medio para explicar el propósito de una tabla de datos (incluido el uso de un texto plano), por lo que no hay motivo para exigir el uso del atributo summary, el cual, por su propia especificación, permanece oculto para cualquiera que sea capaz de ver, incluidas las personas con discapacidades.
No hay que satisfacer las pautas que requieren un elemento HTML semántico que no existe, como agrupar secciones relacionadas de un documento, para lo que la única opción disponible, div, no tiene significado real.

Pautas de Prioridad 3 a ignorar

No intente cumplir con las pautas de Prioridad 3. Entre otras cuestiones, ya está obligado a emplear el HTML de acuerdo con la semántica de su documento, y hay más de un medio para marcar el contenido de un documento. No vemos beneficio alguno en la obligación de exigir un marcado concreto entre las múltiples posibilidades viables.

Pauta 4.2: No es necesario ofrecer la expansión de una abreviatura o acrónimo a menos que una persona con una discapacidad no pueda comprender el documento sin tal expansión, como se ha explicado antes.
Pauta 4.1: Se debe especificar el idioma de un documento en orden a indicar un cambio en el mismo. Esta pauta es un prerrequisito para la pauta 4.3, que requiere el marcado de un cambio de idioma. El marcado correcto del idioma se requiere en todo momento, tanto para el idioma de base como para un idioma distinto. No hay, sin embargo, forma de marcar los cambios de idioma en los atributos, lo que incluye los textos alt, así que no intente hacerlo.
Pauta 9.4: No intente crear su propio orden de tabulación. Eso es competencia del navegador y de la tecnología adaptativa.
Pauta 9.5: No proporcione atajos de teclado. Eso es competencia del navegador y de la tecnología adaptativa.
Pautas 10.4 y 10.5: No sitúe texto como anclas en los formularios. Eso es competencia del navegador y de la tecnología adaptativa. (Los campos de formulario pueden contener texto como resultado de un proceso en el servidor —p.ej., después de verificar que un nombre de usuario deseado no está disponible, el sitio puede proponer uno nuevo— pero en ese caso no se trata de un texto «ancla». Un sitio puede también almacenar una cookie con información de usuario y con ella rellenar el campo de un formulario en sucesivas consultas. Eso tampoco es un texto ancla.)
Pauta 11.3: No hay un medio práctico de cumplir con esta pauta, puesto que implícitamente requeriría que el autor proporcionase traducciones (lo que no es una cuestión de accesibilidad) o diferentes «tipos de contenido» (p.ej., duplicar un sitio web completo en SVG, algo que tampoco es una cuestión de accesibilidad). Ignórela.
Pauta 13.5: No todos los sitios ni todas las páginas requieren barras de navegación. Ignórela.
Pauta 13.6: No todos los sitios ni todas las páginas tienen «vínculos relacionados», y los únicos elementos HTML semánticos relacionados se aplican sólamente a formularios (p.ej., optgroup).
Pauta 13.7: No es necesario proporcionar distintos métodos de búsqueda (no es una cuestión de accesibilidad). Ignórela.
Pauta 13.8: Los encabezados son «información distintiva», y no conocemos idioma alguno que exija que cada párrafo comience con «información distintiva». Ignórela.
Pauta 13.9: Ignórela.
Pauta 13.10: No emplee arte ASCII.
Pauta 14.2: Emplee el contenido que desee. No es obligatorio ilustar documentos (además, si usted es una persona ciega, no podría hacerlo), pero en tal caso requeriría textos equivalentes.
Pauta 14.3: Se puede emplear cualquier «estilo» accesible que se desee, incluso estilos que no sean «consistentes».
Pauta 1.5: Ignórela.
Pauta 5.5: El atributo summary, por especificación, permanece oculto visualmente. El HTML proporciona numerosos medios para clarificar el propósito de las tablas (caption, summary, encabezados), y los mismos datos informativos se pueden proporcionar por medio de texto plano. Cuando decimos que se ignore esta guía, queremos decir que se ignore la obligación de emplear el atributo summary.
Pauta 5.6: Ignórela. Casi nunca es necesario y está pobremente soportado; tal y como está redactada, la pauta requiere la abreviatura de todos los encabezados de tabla.
Pauta 10.3: CSS es un medio para maquetar soportado más que adecuadamente, y no se deben emplear tablas para maquetar.

Excepción general para documentos educativos

Los documentos cuyo objetivo es educar en cuestiones de accesibilidad web, incluidos aquellos documentos en los que se incluyen deliberadamente errores de marcado o características que los lectores o estudiantes deben corregir, están exentos de las WCAG+Samurai siempre que su intención didáctica sea indicada.

Copyright

Esta fe de erratas está basada en el documento siguiente, original del W3C, con el cual no está afiliado de ninguna forma:

Documento original: Pautas de Accesibilidad de Contenido Web 1.0 (inglés)
Su estatus: Este documento ha sido revisado por miembros del W3C y otras partes interesadas y ha sido corroborado por el Director como una Recomendación del W3C. Éste es un documento estable y debe usarse como material de referencia o citado como normativa de referencia desde otros documentos. El papel del W3C al redactar la Recomendación es llamar la atención sobre la especificación y promocionar su amplia implementación. Ésta mejora la funcionalidad y la universalidad de la Web.

Proporcionamos estas referencias de arriba para cumplir con las exigencias del actual copyright del W3C. Las referencias presentes a continuación se aplican al documento que se está leyendo.

Esta fe de erratas ha sido desarrollada de manera independiente del W3C y no establece juicios o impresiones sobre las posiciones, juicios o acciones del W3C. Francamente, no queremos establecer tales juicios, de la misma manera que no queremos que el W3C establezca juicios acerca de nosotros.

W3C™ es marca registrada del World Wide Web Consortium. De la misma forma lo es HTML™, a pesar de que «WCAG» no lo sea.

Adicionalmente, esta fe de erratas ha sido publicada como revisión y crítica de las WCAG 1.0 bajo las provisiones de imparcialidad de la ley de copyright canadiense. No son un trabajo derivado ni tampoco son una «integración de erratas».