30 aniversario de Egokituz, ponencia en torno a la accesibilidad

El pasado 16 de diciembre EGOKITUZ, Laboratorio de Interacción Persona-Computador para Necesidades Especiales (UPV-EHU), organizó una jornada sobre accesibilidad para celebrar su 30 aniversario en la que participaron investigadores, colaboradores, empresas y organizaciones con las que ha trabajado. Bixente Monreal, diseñador de Lotura, tomó parte en la mesa redonda de empresas y centros técnológicos, presentado su visión sobre la accesibilidad en el desarrollo web.

"La accesibilidad web: de la fe a los hechos" por Bixente Monreal

16 Diciembre 2015 · 15:00h · Carlos Santamaria Zentroa Hasta ahora hemos conocido dos versiones de pautas para definir contenido accesible en las web, la WCAG 1.0 y la WCAG 2.0. La primera versión de las pautas de contenido web accesible de la WAI, la comparo con la Biblia. Es decir, describía las reglas mediante figuras retóricas, que daban pie a múltiples interpretaciones. Por ejemplo, “10.2 Hasta que las aplicaciones de usuario soporten explícitamente la asociación entre control de formulario y etiqueta, para todos los controles de formularios con etiquetas asociadas implícitamente, asegúrese de que la etiqueta está colocada adecuadamente.” En aquellos casos en que cada campo está formado únicamente por una etiqueta y un control de formulario no cabía la menor duda, rodeabamos el control con las etiquetas correspondientes. Pero cuando además había un texto adicional de ayuda, de poco nos servía la regla. Como solución los desarrolladores, como buenos “feligreses” nos inventábamos soluciones estrafalarias, no por imaginativas menos erróneas, como separar los campos mediante una lista. El siguiente precepto es otro ejemplo, “13.1 Identifique claramente el objetivo de cada vínculo.“. Supuestamente esa era la labor del atributo <title>, pero resulta que había lectores de pantalla que no lo interpretaban. Había que hacer malabarismos con etiquetas <span> que aportaban la explicación pertinente, pero que se escondían porque afeaban el diseño. O este otro, “9.5 Provea atajos de teclado a los enlaces importantes”. Es decir, la consideración de enlace importante recaía exclusivamente en los desarrolladores. Y en el colmo de la ambigüedad, “14.1 Utilice el lenguaje apropiado más claro y simple para el contenido de un sitio. “. ¿Cómo se mide ésto? Para complicar las cosas, en aquel momento existían dos “evangelios”, el HML4 y el XHTML, y ambos prometían un desarrollo coherente para toda la eternidad. Esta ambigüedad de la WCAG 1.0 tenía como consecuencia que la accesibilidad fuera una cuestión de fe. Me acuerdo de las amargas “discusiones teológicas” con los “sacerdotes auditores” (para los que no conozcáis esta figura aclararos que es muy similar a un inquisidor de la edad media) y cómo buscábamos la “absolución” de nuestras técnicas y no nos “excomulgaran” la subvención. En uno de los proyectos, uno de los auditores me obligó a incluir los atributos “placeholder” en los formularios y después nos llamó el cliente diciéndonos que lo quitáramos porque los lectores de pantalla leían dos veces la misma información, el <label> y el “placeholder”. Todos estos problemas provocaban paradojas como la que nos contó una persona invidente, que accedía mejor a una página de turismo estructurada mediante tablas, que a otra que supuestamente cumplía con los preceptos de la accesibilidad. A pesar de todo, esta primera versión tuvo la virtud de obligarnos a estructurar las páginas de una manera correcta, mediante capas y encabezados, dotando de cierta lógica semántica a las mismas. En aquellos tiempos las etiquetas que aportaban valor semántico a la página eran unas pocas, e incluían a los encabezados <h1>, <h2>, <h3>..., las listas, y las tablas de datos. En el “concilio” de diciembre de 2008 publicaron la segunda versión, la que, en un alarde de imaginación, definieron como WCAG 2.0. El susto fue mayúsculo. Ahora dividían los preceptos en cuatro principios: perceptible, operable, comprensible y robusto. Lo primero que pensé fue que eran los cuatro jinetes del Apocalipsis. Por aquella época, se publicó el “nuevo evangelio”, el HTML5, que sustituía a los dos precedentes. Nuevos protagonistas, como las etiquetas <section>, <article>, <nav>, <aside>, <header> y <footer>, hacían su aparición, que usándolos junto con los WAI-ARIA roles facilitaban el acceso a los lectores de pantalla, mejorando la accesibilidad notablemente. Además se eliminaban etiquetas redundantes como las <abbr> y <acronym> o las <caption> y <summary>. Pero la principal virtud de las nuevas pautas era que eliminaban la ambigüedad de la primera versión. Además, definían claramente las técnicas que se podían utilizar para implementar la accesibilidad. Por fin, la accesibilidad no era una cuestión de fe.

Proyecto con Egokituz

Cuando ya se había publicado la segunda versión de las pautas, nos propusieron desarrollar junto con Egokituz uno de los proyectos más interesantes. El proyecto GureMintza necesitaba algo más que cumplir con las pautas de accesibilidad, ya que estaba dirigido a discapacitados cognitivos. Además de los habituales retos que la accesibilidad presenta, debimos resolver otros específicos del colectivo al que la web iba dirigido. Los discapacitados intelectuales tienen problemas para recordar las claves, no comprenden el scroll, de modo que lo que no ven en la pantalla no existe, tienen problemas para entender los submenús y necesitan que los enlaces dispongan de iconos que refuercen el texto.

Futuro de la accesibilidad

Espero equivocarme, pero creo que la accesibilidad se va a implementar solo en aquellas webs que estén obligadas a cumplirla. Cuando Google decidió dar un empujón al lenguaje javascript y en concreto al ajax, marcó un camino que la mayoría de los desarrolladores hemos adoptado como modelo. Si bien existe la posibilidad de construir de forma accesible una aplicación web que haga uso de la tecnología ajax, para que el contenido dinámico sea accesible, la aplicación debe alertar al usuario cuando ocurra un cambio y permitir el acceso directo al nuevo contenido, de modo que la aplicación web funcione de manera continua. Pero lograr este objetivo es complicado, especialmente para usuarios de lectores de pantalla, y, aunque se consiga, la aplicación resulta más cara. Un coste que la empresa privada no está dispuesta a asumir, sobre todo ahora que se han eliminado casi todas las subvenciones a la accesibilidad. Como consecuencia, en Lotura hemos notado que la empresa privada prescinde de la accesibilidad y exige un diseño más dinámico y visual. Los estándares web están definidos por una entidad, la W3C, que está al margen del mercado y no tiene el poder de influencia que sí tienen las grandes empresas como Google, Microsoft y Apple, que son las que, al fin y al cabo, definen las técnicas que se van a utilizar en la construcción de Internet. Así, la accesibilidad siempre va por detrás, a la espera de que estas empresas se dignen a implementarla.