Introducción a 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.

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

Está disponible desde el 26 de febrero de 2008 [Original (inglés) - Traducción]. También lo están dos documentos adicionales: uno sobre la paleta Brewer para la deficiencia de color [Original (inglés) - Traducción] y otro sobre PDF [Original (inglés) - Traducción].

¿Y con respecto a las WCAG 2?

Esta 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?

Probablemente. En este momento la Fe de erratas de de las Pautas de Accesibilidad de Contenido Web del WCAG Samurai queda 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. En casos concretos corregiremos errores menores, o incluso algunos mayores. Una diferencia de opinión no es un error en este contexto, en la medida en que el objetivo de esta fe de erratas es articular la opinión de un grupo.

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.)

Como en el mundo real, asumimos que está empleando HTML y CSS la mayor parte del tiempo y JavaScript parte del tiempo. No asumimos un futuro no realizado en el que Flash, Silverlight o cualquier otra tecnología se convierta en el principal medio de distribución de páginas web.
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», «no es obligatoria», «no tiene que usar» 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. 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 artefactos innecesarios 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 audiodescripción.

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

Lo primero que hay que comprender es que no hay que cumplir con esta fe de erratas. La Fe de erratas de las Pautas de Accesibilidad de Contenido Web del WCAG Samurai es una adición opcional 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 estas 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 se tiene que 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 estatus de experto invitado ha sido rechazado o revocado; el Grupo de Trabajo puede declarar que se ha alcanzado consenso incluso chocando de frente con disputas internas irresolubles; 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 pronunciación.
- 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.
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 algunas 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.
Se deben marcar de manera apropiada los formularios, lo que incluye añadir un label a todos los elementos que lo requieran.

Pautas de Prioridad 3 a ignorar

Todas ellas. En concreto:

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, tal 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 exige 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 de relleno previo 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 «de relleno previo». 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 «de relleno previo».)
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). No es obligatoria.
Pauta 13.5: No todos los sitios ni todas las páginas requieren barras de navegación. Esta pauta se aplica sólo a los sitios que la necesitan. Si su sitio emplea barras de navegación, que lo haga de forma consistente (p.ej., no cambie arbitráriamente de barras de navegación horizontales a verticales dentro de una misma sección del sitio) y emplee el marcado correcto (por lo general una lista no ordenada, ul). Si su sitio no necesita una barra de navegación no está obligado a incluir una.
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). El empleo de link dentro de head no es oblogatorio.
Pauta 13.7: No es necesario proporcionar distintos métodos de búsqueda (no es una cuestión de accesibilidad). No es obligatoria.
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». No es necesaria. No obstante, algunas clases de páginas web, como glosarios, podrían cumplir con este punto emplazando palabras clave antes o a comienzo de un párrafo.
Pauta 13.9: No es obligatoria.
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 las ilustraciones requerirían textos equivalentes.
Pauta 14.3: Se puede emplear cualquier «estilo» accesible que se desee, incluso estilos que no sean «consistentes».
Pauta 1.5: No es obligatoria.
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. Aún así, podría ser el método adecuado para algunas tablas.
Pauta 5.6: No es necesaria. La técnica casi nunca es necesaria y está pobremente soportada; 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.

Corrección por pares

Enviamos una primera versión de esta fe de erratas para una corrección por pares independiente y confidencial a dos personas, Gian Sampson-Wild y Alastair Campbell. Puede leer la revisión de Gian (inglés) y la revisión de Alastair (inglés). El WCAG Samurai no tuvo control ni conocimiento previo de los contenidos de estas revisiones.

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».