Libro blanco de eXaminator

Problemas con la accesibilidad

Esta sección contiene una larga perorata sobre lo que considero son los principales inconvenientes que enfrentamos al intentar lograr una web accesible. Está divida en bloques para facilitar su lectura pero fue escrita sin un orden estricto y no tiene la pretensión de ser un análisis exhaustivo sino de servir como base para proponer luego algunas soluciones posibles. Entiendo que quienes se tomen el trabajo de leer todo esto serán personas con conocimientos sobre accesibilidad y no me sentiré en la obligación de explicar todas y cada una de las referencias sobre cuestiones técnicas.

El diseño web

El principal obstáculo que existe para llegar a una web accesible es la falta de conocimientos técnicos de quienes crean, desarrollan y mantienen los sitios. Creo que en algún momento tuvimos la esperanza de que la accesibilidad siguiera el mismo camino de HTML -que pasó de unos escasos creadores a miles de desarrolladores en muy poco tiempo- y lograr que los evangelizados se volcaran masiva y espontáneamente a aplicar los principios de accesibilidad para llegar a tener, al cabo de algunos años, una web libre de barreras.

Pero a diferencia del HTML que no exige casi ningún conocimiento (sin duda una de las claves de su arrollador éxito), la accesibilidad no se puede conseguir sin el dominio de las pautas, sin saber cómo utilizan la web los usuarios y, fundamentalmente, sin un manejo de los lenguajes y estándares que hacen funcionar la web.

Pero, además, no bastan sólo los conocimientos teóricos porque la accesibilidad, tal como la caracteriza Tim Berners-Lee en su conocida definición [1], es un arte y exige mucha práctica llegar a dominarlo. Pero, claro, el diseño web nació con HTML, heredó su falta de disciplina y es una profesión de exigencias mínimas. No existe, incluso, un perfil profesional definido para el diseñador web y es un puesto ocupado por cualquiera que se atreva a hacer páginas con HTML, CSS, Javascript y un poco de audacia.

En ese contexto, la accesibilidad se percibe como un añadido molesto que intenta imponer reglas donde no existen normas y que sólo sirve para limitar la creatividad. Generalmente tratamos de combatir esa actitud diciendo que la accesibilidad es en beneficio de las personas con discapacidad y agregamos -casi en un intento de soborno- que el esfuerzo tiene muchas otras compensaciones, cuando lo cierto es que la accesibilidad debería considerarse -lisa y llanamente- una parte esencial e inseparable del diseño web.

Soy un antiguo diseñador gráfico que comenzó recortando y pegando papeles con minuciosa prolijidad para armar los originales de impresión, luego pasó a usar la computadora a fines de los 80 y finalmente se convirtió en diseñador web eventual. Como testigo viviente de la transición entre la impresión tipográfica y la información digital, considero que la accesibilidad es esencialmente un ajuste en los parámetros técnicos que siempre delimitaron nuestra labor de diseñadores.

Algunos de esos parámetros están determinados por el soporte físico de los mensajes. En la industria gráfica, uno debe proceder de distintas maneras según el tipo y calidad del material, el sistema de impresión, la cantidad de tintas y aún el tamaño de la pieza de comunicación. El diseño web, en cambio, está libre de todos esos problemas relacionados con elementos tangibles porque la información digital está liberada de su soporte físico y son sólo datos binarios que no pueden ser consultados directamente por los humanos sino a través de algún intermediario -que genéricamente denominamos agentes de usuario- y que permiten leer una página, escucharla o incluso tocarla, por ejemplo, a través de una línea braille. Esta característica, que hace tan dúctil a la información digital, es la que plantea nuevas exigencias para los diseñadores.

Al pasar del diseño gráfico a la web, el trabajo se hizo más aliviado en algunos aspectos pero se dotó de nuevas dificultades. Y el desafío mayor está representado por la variedad de contextos en los que se presentarán nuestros mensajes y la diversidad de formas que usan las personas para interactuar con la web. El diseñador debe lograr que la información pueda ser percibida, entendida y usada por la mayor cantidad de usuarios posibles, aplicando correctamente las tecnologías apropiadas.

Aquí es donde se hacen imprescindibles las pautas de accesibilidad porque sería imposible para cualquiera de nosotros conocer todas las formas en que las personas usan la web. Las WCAG son, antes que nada, una amplia recopilación de información para identificar los problemas que pueden encontrar los distintos grupos de usuarios y las recomendaciones necesarias para solucionarlos.

Tanto las WCAG como los otros estándares usados en la web son establecidos por la comunidad del W3C, que pone mucho cuidado en asegurar que las tecnologías operen coordinadamente. Por eso existe una estrecha relación entre accesibilidad y diseño web y, en general, sólo es necesario conocer y aplicar correctamente los estándares para hacer un sitio web aceptablemente accesible.

Un verdadero profesional del diseño no tiene excusas para no trabajar de manera accesible pero, como dije, el problema es que el diseño web está en manos poco competentes. Sabemos que existen muchos diseñadores capacitados pero hablo de proporciones: en una web inmensa, esa gran cantidad de expertos significa apenas un grupo marginal de personas trabajando con eficiencia, insuficientes para lograr el salto cualitativo que hoy necesita dar el diseño web.

Los sitios web

Incluso para un experto en accesibilidad y en los estándares resulta cada vez más difícil lidiar con las dimensiones que ha alcanzado la web. Ya no se trabaja en pequeños sitios donde uno puede elaborar artesanalmente cada una de las páginas, corregirlas y modificarlas cuantas veces sea necesario. Hoy los sitios web son enormes.

Por supuesto siempre existirán los pequeños sitios personales pero cuando hablamos de accesibilidad nos preocupa principalmente la información generada por las instituciones del sector público, las que están sostenidas con el dinero de todos los ciudadanos y no pueden, ni ética ni legalmente, dificultar el acceso de ninguna persona.

Los sitios importantes contienen gran cantidad de material, muchas secciones y también errores acumulados durante años. Los gestores de contenido no ayudan en nada y las tareas en los sitios se reparten entre equipos multidisciplinarios con muy distinto grado de capacidad. Esa división del trabajo es un obstáculo para la accesibilidad porque se requieren esfuerzos coordinados y homogéneos para lograr buenos resultados. Si la accesibilidad es un tema complejo para una persona, imaginen cuando se trata de un equipo.

No es justo cargar todas las tintas contra los responsables de los sitios web porque a veces existen problemas que dificultan o impiden su buen desempeño. En ocasiones, una parte de su trabajo depende de terceros; a veces están forzados a usar sistemas no accesibles; en algunos casos existen problemas de organización o simplemente no tienen posibilidades prácticas de hacer correctamente su trabajo. De todos modos, aunque puedan existir circunstancias atenuantes, la responsabilidad de un sitio inaccesible le corresponde a quien está a cargo de su diseño y mantenimiento.

Las leyes de accesibilidad

En muchos países los sitios del sector público están obligados a cumplir con leyes sobre accesibilidad web, la mayoría de ellas basadas en las Pautas de Accesibilidad para el Contenido Web (WCAG). En algunos casos ni siquiera existe una norma específica sino que la ley simplemente indica que se deben cumplir las recomendaciones de las pautas de accesibilidad. Y aquí tenemos otro pequeño problema.

Las WCAG son recomendaciones, no un reglamento, y no se puede hacer una norma de cumplimiento obligatorio basada en sugerencias. Por ejemplo, en las WCAG 1.0 [2] dice no use tablas para maquetar, a menos que el contenido de la tabla tenga sentido cuando se represente en forma lineal. El problema es que según la página, el número de tablas y el nivel de anidamiento que tengan esas tablas, el contenido podría tener mayor o menor sentido cuando se represente en forma lineal. Quizás algunos usuarios puedan percibir la información, otros podrán deducirla y otros, posiblemente, no entiendan nada. ¿De qué sirve una norma legal de verificación ambigua?

Algo que deberían tener más en claro los legisladores y quienes redactan las normas es que no se trata de repetir las sugerencias que ya se encuentran en las WCAG sino definir las condiciones que deben cumplir los sitios de la administración pública de sus países. Por ejemplo, sería perfectamente lógico -y recomendable- que la norma simplemente diga "en los sitios oficiales no se usarán marcos" (porque todos conocemos sus desventajas y sabemos que tienen pocas justificaciones técnicas) en lugar de embrollar el tema con instructivos para solventar los problemas que acarrean esos benditos marcos.

No es una excusa válida decir que no se hace así porque podría existir algún sitio -entre los miles de sitios que normalmente contiene una administración pública- que necesite usar marcos, porque ninguna ordenanza general puede contemplar cada caso en particular. Alguna que otra posible excepción no justifica el uso de fórmulas complejas y difusas que sólo crean confusiones. El caso es que sin normas estrictas y de verificación efectiva, no hay posibilidades de hacerlas respetar.

Incluso creo que no se produce una avalancha de querellas contra sitios que violan de manera evidente las leyes porque existe una aceptación tácita de que las normas sobre accesibilidad son más un acto de corrección política que un serio intento de establecer obligaciones estrictas. Esos juicios tan sonados en los que se penalizaron a empresas e instituciones por no cumplir con las disposiciones sobre accesibilidad son casos aislados, extravagancias de países con abogados que, así como te enjuician por una falta de accesibilidad, te querellan por una taza de café derramada [3].

También, toda la cuestión sobre accesibilidad está exageradamente ligada a las personas con discapacidad. Es indudable que resulta el grupo de usuarios más perjudicados, pero no son los únicos que sufren la falta de accesibilidad. Poniendo el foco del problema casi exclusivamente en esas personas sólo logramos confundir los términos y que en muchos casos se piense que la accesibilidad es un problema de sensibilidad social y no un problema técnico.

Así tenemos a muchos desarrolladores bienintencionados que usan FrontPage y nunca vieron el código HTML de una página, pero que están ilusionados con hacer su sitio doble A de acuerdo con las WCAG, creyendo que es más importante la actitud que el conocimiento de los estándares. Lo peor es descubrir sitios solidarios con las luchas de las personas con discapacidad, donde se explica la importancia del diseño universal o -el colmo- se promocionan cursos sobre diseño inclusivo que no son en absoluto accesibles.

Las WCAG 2.0

Las Pautas de Accesibilidad para el Contenido Web 2.0 [4] son un nuevo problema. Esperamos con impaciencia casi 10 años las nuevas pautas, esperanzados con la promesa de que serían más precisas y se podrían verificar con más exactitud. La buena noticia es que realmente son mucho más precisas; la mala noticia es que para dar todas esas precisiones se necesita mucho -muchísimo- texto. Y no, no son más fáciles de verificar.

Los criterios de conformidad, en el documento normativo de las WCAG 2.0, están escritos como enunciados verificables. Esto facilitará, sin duda, migrar las disposiciones legales de los distintos países a las nuevas recomendaciones pero, asociados a ese documento base, existen muchos otros cuya extensión y complejidad desalientan a cualquiera.

Comprender las WCAG 2.0 [5] consta de una larga serie de documentos donde se explican detalladamente los criterios de conformidad y proporcionan un listado de técnicas y fallos para cada uno de esos criterios. Entre técnicas suficientes, técnicas adicionales y fallos comunes, hay alrededor de cuatrocientos documentos más para consultar y, si no se habla inglés, para traducir.

Las traducciones no avanzan. En español, por ejemplo, todavía no llegamos a ponernos de acuerdo en la traducción oficial del documento normativo pero también son imprescindibles los documentos no normativos, que permiten entender lo que dicen en WCAG 2.0 en un lenguaje tan técnico como críptico. Y el WAI, en los últimos años, ya hizo tres actualizaciones a los documentos de técnicas sin que hayamos comenzado a traducir sus primeras versiones.

Las WCAG 2.0 nos han puesto frente al hecho de que la accesibilidad es un tema muy complejo y difícil de abarcar. Por supuesto que ya lo sabíamos pero evitábamos decirlo abiertamente porque no era cuestión de ponerse a pregonar sus dificultades y correr el riesgo de espantar a los aún no evangelizados.

Ahora, después de decirle a alguien que en el nivel A debe comprobar que para todos los componentes de la interfaz de usuario, el nombre y la función pueden ser determinados por software; los estados, propiedades y valores que pueden ser asignados por el usuario pueden ser especificados por software; y los cambios en estos elementos se encuentran disponibles para su consulta por las aplicaciones de usuario, incluyendo las ayudas técnicas [6] ¿cómo hacemos para convencerlo de que eso es fácil de hacer?

Al contrario de algunas opiniones que he leído en la web, no creo que el problema sea que los técnicos se estén aislando en sus conocimientos y alejándose del común de las personas. El problema es que no se puede explicar en palabras sencillas un tema complejo y las WCAG 2.0 (y todos los estándares de la web) están dirigidos a quienes deberían tener los conocimientos suficientes para entenderlos.

Pero sí creo que en las WCAG 2.0 se exagera un poco al tratar de incluir la mayor cantidad de técnicas posibles. Por caso, hay una técnica para reemplazar la etiqueta de un control de formulario por el atributo title del control [7]. De acuerdo, a veces el texto resulta difícil de acomodar y con title se podría solucionar el problema. Pero, además, se incluye otra técnica para usar el texto del botón adyacente como etiqueta de un control [8] y se aclara que se debe considerar como "último recurso" y sólo se utilizará cuando las otras técnicas no se puedan aplicar a la página.

¿Último recurso? ¿En qué caso sería imposible usar label y/o el title del control? ¿Es tanta la molestia que provocaría la repetición de title y el texto de un simple botón? Creo que sería mucho mejor indicar el uso de la etiqueta en todos los casos y dejar como "último recurso" el uso de title, especialmente para no relajar al extremo una regla básica como es el uso de etiquetas para identificar los controles de formularios.

Entiendo que haya una intención de no limitar las posibilidades de los diseñadores pero también se debería tener en cuenta que luego es necesario evaluar el cumplimiento de los criterios de conformidad y resulta imposible lidiar con esa maraña de técnicas y fallos. El resultado es que volvemos al mismo problema que teníamos con las WCAG 1.0 y no podemos lograr que ni siquiera los resultados de las revisiones hechas por expertos sean unánimes y concluyentes.

La evaluación de la accesibilidad

La revisión heurística realizada por expertos es el único método que permite evaluar el nivel de conformidad de las páginas web con las WCAG. Digo páginas y no sitios web porque este método es tan costoso que sólo se puede aplicar a un reducido grupo de páginas de cada sitio. Las evaluaciones heurísticas llevan mucho tiempo porque deben ser completas y exhaustivas para que tengan validez. Se debe considerar que no se trata sólo de hacer una revisión sino que, luego de la primera evaluación, se debe repetir el trabajo cuando se consideran corregidos los errores detectados previamente. Además, las revisiones deberían repetirse con cierta frecuencia para verificar que las páginas no pierden su accesibilidad cuando son actualizadas.

Debido a estas dificultades, se prefiere usar métodos automáticos porque son más rápidos y menos costosos, aunque también mucho más limitados porque sólo pueden revisar una pequeña cantidad de técnicas, muy lejos del número necesario para evaluar la conformidad de las páginas. Otro problema reconocido de las herramientas automáticas es que pueden generar falsos positivos o falsos negativos, es decir, indicar que no existen errores donde los hay o detectar problemas inexistentes.

Pero hay una cierta cantidad de técnicas que pueden ser revisadas con mucha seguridad por las herramientas automáticas y algunas otras técnicas que pueden ser evaluadas con un aceptable grado de certeza. Lo más importante es que se pueden obtener resultados de grandes cantidades de páginas -incluso de sitios completos- con mínimo esfuerzo. Creo que esa capacidad de las herramientas automáticas no está bien aprovechada porque generalmente se usan para hacer revisiones individuales y sin seguir una metodología programada. Entonces es común que el hábito de revisar las páginas -si alguna vez existió- se vaya perdiendo con el tiempo y se convierta en una práctica eventual y desordenada.

Un agregado a favor de las herramientas automáticas es que pueden generar la información -valga la redundancia- de forma automática. No es una ventaja menor ya que así los resultados pueden ponerse a disposición de muchas personas inmediatamente y actualizar esa información de manera constante. De este modo no sería tan sencillo simular sitios accesibles colocando logos de conformidad en las páginas, una técnica usada con mucha ligereza y, en ocasiones, de muy mala fe.

Existen sitios inaccesibles que parecen usar esos logos no como una declaración sino como una promesa a futuro (“nuestra intención es tener un sitio Doble A”, sería su significado). Y están también los logos que pone el diseñador porque sabe que es muy difícil que alguien se tome el trabajo de verificar lo que afirma. Incluso se dan situaciones ridículas cuando se enlazan los logos con las herramientas automáticas y los resultados demuestran que la página tiene errores. Los propios responsables del sitio ponen a un clic de distancia la prueba de su hipocresía.

Muchos sitios incluyen páginas especiales donde se dan a conocer las acciones que se tomaron para mejorar la accesibilidad y muestran, por ejemplo, un listado de todos los accesskey que deberían memorizar los usuarios pero no hay detalles esenciales como cuáles fueron las páginas evaluadas, en qué fecha se revisaron y qué sistema se usó en cada caso. No conozco ningún sitio que presente una declaración de conformidad exhaustiva y precisa, incluyendo la publicación de toda la información pertinente.

Es difícil pensar que, si alguien hizo un trabajo realmente prolijo, desaproveche la oportunidad de mostrar sus logros al mundo. Más bien debemos sospechar que la enorme inversión de tiempo y dinero que se requiere para evaluar, corregir y controlar la evolución de la accesibilidad de cualquier sitio web de mediana o grandes dimensiones es el motivo de que no logremos tener un solo sitio importante que justifique, con pruebas, sus alardes en materia de accesibilidad.

Referencias

  1. Accesibilidad es el arte de garantizar que, tan amplia y extensamente como sea posible, los medios (como por ejemplo el acceso a la Web) estén disponibles para las personas, tengan o no deficiencias de un tipo u otro. Tim Berners-Lee
  2. Pautas de Accesibilidad al Contenido en la Web 1.0
  3. Wikipedia Premios Stella (ridículas y escandalosas demandas judiciales)
  4. WCAG 2.0 Traducción Candidata a ser la Oficial al Español
  5. WCAG 2.0 Comprender las WCAG 2.0 (borrador)
  6. WCAG 2.0 4.1.2 Nombre, función, valor
  7. WCAG 2.0 H65: Using the title attribute to identify form controls when the label element cannot be used (en inglés)
  8. WCAG 2.0 G167: Using an adjacent button to label the purpose of a field (en inglés)

Siguiente: Revisiones automáticas

Anterior: Presentación

Fecha de publicación: 01/06/2012