Las caras ocultas de la accesibilidad
Estos días fueron motivos para crear entradas en las bitácoras sobre las nuevas páginas institucionales, como la página del Palacio de la Moncloa, Gencat y la página oficial de la gripe aviar. Todas ellas deberían cumplir las normativas mínimas de accesibilidad, estándares, etcétera. En efecto, de las tres mencionadas solo una se acerca a dicho estado. La página de Generalitat de Catalunya está hecha «por seres de otro planeta», como cuando se dice que uno ve la tecnología que está delante de nuestro nivel de comprensión. Así es, una página bastante equilibrada por donde la mire, tanto gráficamente como de código. Es estándar, no valida de momento por un error tonto, pero eso no es motivo de desaprobación.
Cuando me topo con artículos de accesibilidad o estándares suelo leer de forma remarcada que «la página no valida» o «no es accesible AA». Cabe destacar la cantidad de veces que he dicho que el validator del W3C no es un sello de calidad. Cualquier test automático no es sello de calidad, no asegura el sano juicio del diseñador, programador, escritor. Es sólo una referencia, una ayuda para dar un resultado positivo cuando se quiere alcanzar la accesibilidad. Por eso, cuando escriban sobre estos temas, y protesten porque se han molestado en darle una mirada al TAW, siempre procuren realizar análisis más profundos sobre el tema. Como cuento en esta nota, la accesibilidad no pasa por correr un test automático. Prueba de ello, visiten la página de la gripe aviar y la página de la Generalitat de Catalunya. Pásenle un test de accesibilidad web y comparen (aunque sea inútil):
- Ambas páginas pasan el nivel A de accesibilidad.
- La página de la gripe aviar tiene 8 errores automáticos en la prueba AA y la página de la Gencat tiene 11.
- De los 8 errores automáticos que tiene la página. Todos son obvios, y se pueden solventar poniendo apenas dos etiquetas:
<h1>,<p>y con ayuda de CSS quitarle todos los atributos de presentación de las etiquetas que contienen el Flash. Esto daría una página válida AA. - La Gencat tiene 11 errores. La mayoría son comunes como por ejemplo el uso de
<b>, que puede ser reemplazado por<strong>. Solucionando estos descuidos la página sería válida en un nivel de conformancia AA.
Ahora, lo más gracioso de todo esto –que demuestra que tengo razón y que muchos que trabajan de esto también– es que, haciendo la prueba básica de accesibilidad, la página de la gripe aviar es muda. Sí, muda. No se oye más que el título de la ventana activa. Mientras que la página de la Gencat tiene un grado mínimo de audibilidad asegurado. ¿Se dan cuenta que los tests automáticos no siempre te ofrecen la seguridad de que algo es accesible?
La accesibilidad no es un tema de pasar un chequeo automático y listo. Esto se trata de estar incansablemente en todos los detalles. Disponer de un grupo de mínimo de personas especializadas trabajando en el mantenimiento o desarrollo de estos aspectos. Conocer todas las deficiencias existentes y cómo afecta al uso del ordenador. Conocer las herramientas, conocer los lenguajes, conocer los dispositivos físicos de usuario, conocer todas las convenciones y más. Existen muchos puntos a comentar sobre el tema. Uno de ellos es, la utopía de la accesibilidad perfecta, un tema del que me gustaría debatir más adelante. No, no existe tal perfección. No existe un sitio que sea perfecto al ciento por ciento. Podrá validar, podrá pasar los tests de accesibilidad TAW pero quizás no podrá afrontar otros problemas que si tienen que ver con la accesibilidad. La accesibilidad, en mi punto de vista, es un conjunto de trabas que están impuestas con o sin voluntad. En el 99% de los casos estas trabas están puestas sin conciencia de la gravedad. Este conjunto de trabas las he catalogado en cinco puntos:
- Accesibilidad comunicativa.
- Accesibilidad Económica.
- Accesibilidad motriz.
- Accesibilidad intelectual.
- Accesibilidad tecnológica.
Estos cinco puntos engloban en mi opinión las trabas más importantes que afectan al status quo en lo que respecta la accesibilidad en la web.
Accesibilidad comunicativa (cómo las personas podrían ver, oír, hablar, escribir)
La accesibilidad comunicativa, la que nos permite intercambiar información (hablar, escribir, escuchar, ver) es la primera de todas. Ésta, sin duda alguna, está cubierta apenas hoy en día en la web. Una persona ciega (total y parcialmente) tiene muy pocas posibilidades de disfrutar de internet con deficiencias visuales, por ejemplo. Ésta deficiencia está impuesta por una variedad de problemas. Algunas de estas deficiencias están relacionadas a las deficiencias de visualización como el daltonismo, la dislexia y otras, que impiden ver la información en el espectro de colores correspondiente. Para estos casos existen una gran variedad de opciones, desde lectores de pantalla para los que tienen problemas visuales, hasta navegadores que soportan un medio braile para los invidentes y sordos.
Accesibilidad Económica
No está exento de todos estos problemas la economía de un ser. Sin acceso monetario, éste se ve imposibilitado para disfrutar del acceso al conocimiento. Sea cual sea su situación, tenga o no deficiencias físicas, mentales, éste siempre tiene dificultades –incluso de una gravedad notable– si van acompañadas de alguna deficiencia física. Un ejemplo de accesibilidad –y bastante irónica– son los lectores de pantalla, o como la gente erróneamente denomina: navegadores para ciegos. En el mercado existen varias opciones para utilizar un lector de pantalla y de ésta forma poder leer páginas e interactuar con ellas. Contrariamente a las personas que no tienen problemas económicos, ni físicos, ni mentales, los que deben utilizar lectores de pantalla deben abonar un precio. Éste precio es elevadísimo, comparado con lo gratuito y amplio que ofrece el mundo tecnológico para los que no padecemos esto. Para que os deis una idea de lo que hablo, un lector de pantalla JAWS cuesta hoy en día unos 900 dólares (744 euros) cuando un navegador decente se puede obtener de forma gratuita. El IBM Hompage Reader cuesta alrededor de 142 dólares (y éste se limita casi a leer páginas no a controlar el SO). Window-Eyes es un lector popular y bastante completo, incluso diría que mejor que JAWS en muchos aspectos y cuesta 795 dólares (658 euros). ¿Es irónico no? Para saltar este paso, los sistemas operativos deben centrarse en este punto y poner más esfuerzo. En Macintosh, existe una tecnología que permite aumentar el grado de accesibilidad pero no está muy popularizada. Además se ha de disponer de un equipo, de un precio relativamente elevado para el que no tiene un buen sueldo y tener la última versión de Mac OS X para disfrutarlo en plenitud. Pero vamos, hablamos de un sector reducido de gente usuaria de Mac. En Windows nos quedamos en pañales si buscamos soluciones eficaces para estos temas. Hay que pagar sí o sí.
Accesibilidad motriz
La accesibilidad motriz afecta de varias formas en el uso del ordenador. Imposibilitando parcialmente al usuario de utilizar dispositivos de control como, el ratón o un teclado normal, trackpads y otros. Para ello, se han de disponer herramientas especiales, como el reconocimiento de voz (experimental y cara), teclados especiales, ratones especiales (Stephen Hawking ha escrito varios libros con un dispositivo parecido a un ratón con dos botones) que ayudan a las personas a introducir determinados comandos. Estos comandos ayudan a moverse entre objetos de interacción en la página. Es por eso, que si ponemos una película en Flash como la de la página oficial de la gripe aviar, será imposible navegarla ya que no incluye la interacción necesaria para realizar scroll entre las noticias y otros comandos. Ése fue un ejemplo entre los cientos que puedes anotar.
Accesibilidad intelectual
Sin dinero, sin comunicación no podremos estudiar, ni siquiera auto-formarnos en los mejores casos, seremos meros analfabetos, acibernetos o simples discapacitados intelectuales. Existen muchas personas que no saben leer y escribir en el mundo. Es triste que no puedan acceder a una educación. Ya sea, por motivos económicos, porque deben pasar un nivel de aprendizaje malo, burocrático y competitivo. Pero existen otro tipo de trabas que fomentan a este tipo de accesibilidad. Son trabas culturales, como el idioma o las costumbres religiosas. Me enfocaré de forma resumida en la primera. Los idiomas son la base de nuestra comunicación. Ésta no siempre está a la mano de todos. Es probable que una persona que no sepa inglés no sepa entender ciertas palabras para desarrollar una tarea simple como un empty cache o un paste in place. Toda esta terminología en general produce dudas y dificulta la accesibilidad en un sitio.
Accesibilidad tecnológica
Esta accesibilidad como contaba en unos párrafos más arriba de esta nota, afecta de forma directa a los elementos, dispositivos y programas que están relación con la tecnología. Esta tecnología es sin dudas inaccesible aún en el siglo 21. Para acceder a tecnología hace falta economía. También hace falta desarrollo: navegadores potentes, inteligentes, lectores de pantalla gratuitos y fáciles de usar. En este tipo de accesibilidad es la que de alguna forma u otra ignoramos casi por completo. Ya sea porque no han aceptado pagarte ese «agregado» en tu presupuesto, lo que invita a tachar los puntos de accesibilidad en los desarrollos que haces, como también, cosas curiosas del mundo tecnológico: el targeting. Siempre se desarrolla en base a un target (destino), una masa en concreto de la gente. Esto elimina de entrada una gran porción de población. Se desarrollan sitios para gente que tenga instalados versiones de sistemas operativos comerciales y actualizados. Que corran sobre pantallas de buena resolución y además que dispongan de ciertas características como: memoria, espacio en disco, versiones de navegadores, etc. Se sobreentiende de entrada que la gente debe disponer de una línea de acceso a internet de alta velocidad, lo que induce a hacer páginas cada vez más complejas, pesadas. La misma informática está condicionada por un mercado selecto: gente con dinero, con cierto conocimiento tecnológico, cultural y además sin discapacidades físicas. Existen detalles y curiosidades que he ido anotando desde que trabajo en Cataluña: no existe o al menos nunca he encontrado librerías con voces sintetizadas para usarlas en los lectores habituales de pantalla. ¿Se imaginan entrar a la web de la Generalitat de Catalunya con un lector de pantalla y no comprender una palabra en catalán? Pues es la realidad amigos. Por eso, hacer una página correctamente en HTML o XHTML no garantiza que cualquier discapacitado visual disfrute o se informe en idioma que no sea castellano de la península o latinoamericano. En esta parte queda mucho por hacer.
Otra curiosidad para agregar al tema. Tanto que habla la gente de lectores de pantalla, ¿se han puesto a usar uno? ¿Saben lo que toma aprender a usar un JAWS u otro similar? Usar JAWS requiere de más de 90 horas de capacitación. JAWS tiene más de 100 tipos de accesos de teclado, y no es algo tan simple como usar el navegador (que incluso poca gente sabe tenga o no una discapacidad). En mi caso, por citarme, tuve que estar varios días acostumbrándome a usar el lector de pantalla para comprender cómo funciona todo. Navegar y usar el sistema operativo es complejo, lento y engorroso. Incluso más cuando se navega una página que no cubre esta posibilidad de que una persona pueda entrar a curiosear con un lector de pantalla. Llevo más de 5 años usando lectores de pantalla y me conozco todas las paridas. Créanme no es fácil, imaginen lo que le cuesta a una persona que apenas tiene conocimiento aprenderlo todo. Imaginen lo que cuesta si tiene una deficiencia. Es todo un proceso.
Conclusiones
Todas estas condiciones ayudan a que una simple página tenga más posibilidades de fallecer ante la subida al trono de la accesibilidad. Existen soluciones a medias para solventar todo este tipo de trabas pero si nadie toma conciencia el camino a la accesibilidad será el mismo: se hace si se necesita, si cabe o si no cuesta dinero.
¿Qué se debe hacer en estos casos? Primero poner los pies en la tierra. Mirar al alrededor y comprobar que no es fácil hacer algo accesible, universal sin tener en cuenta estos aspectos y el conocimiento necesario. Segundo, conocer las tecnologías y aplicarlas debidamente. De nada sirve programar una sopa de etiquetas que validan en un test de código o de accesibilidad cuando uno abriendo un lector de pantalla tarda más de 10 minutos en terminar de oírla. Programar con un código limpio no arruina el nivel de accesibilidad pero tampoco ayuda como todos imaginan. Tener en cuenta cómo navega la gente con discapacidad, conocer cada impedimento, conocer cada lector de pantalla. Desarrollar pensando en las trabas y no en como conformar a nuestros egos, aunque ello cueste quitar esa introducción bonita y hollywoodense en Flash tan cineasta.
En los días que vendrán, publicaré más datos sobre accesibilidad. Cada nota dedicada a un tema específico y no tan general como del hoy. Todo producto de los trabajos que he realizado y que estoy realizando ahora.
17 Respuestas a la entrada “Las caras ocultas de la accesibilidad”
Escrito por XAR
Octubre 31st, 2005 at 6:49 pm
¡¡Cuánta razón tienes!!
Escrito por are
Octubre 31st, 2005 at 7:37 pm
Creo que en el artículo no queda claro la diferencia enorme que hay entre una validación automática de código y una de accesibilidad.
La validación de código es muy fiable en cuanto a sintáxis (x)html. Eso es innegable.
Escrito por Gez
Octubre 31st, 2005 at 7:54 pm
Exceleeeeente post.
No lo tomes a mal, pero se extrañaban este tipo de artículos, más “cerebrales” si se le puede llamar de alguna manera que los meros artículos sobre gadgets.
En cuanto al post en sí mismo, me pareció excelente. Una verdadera reflexión sobre los aspectos que no siempre se mencionan cuando se habla del tema y sólo se deja lugar para detalles técnicos.
Como dice Are, la validación de código es una muy buena herramienta para controlar la sintaxis, pero creo que eso en ningún momento se puso en duda. Está claro que la accesibilidad es otra cosa, y que la validación de accesibilidad no es lo mismo que la validación de código.
En lo que a mi respecta, puedo decir que utilizo la validación de código a diario, pero trato de tomarme más personalmente los aspectos de accesibilidad (y tratar por mis propios medios de analizar los posibles problemas), ya que todos los tests automáticos que vi me parece que son sólo eso… tests automáticos, y como los hace una máquina no se tienen en cuenta varios factores.
Es extremadamente difícil, como vos mencionás, cubrir todos los frentes, y evidentemente será imposible hacer el sitio 100% accesible. Pero se puede hacer un esfuerzo: conocer y utilizar los recursos técnicos, tener en cuenta los perfiles de audiencia y los contenidos del sitio.
Evidentemente no podemos pretender que un sitio de bajada de mp3 sea accesible para un sordo, o un sitio de una empresa que se dedica a motion graphics sea accesible para un ciego. No es discriminación, pero intentarlo sería perder el foco de lo que uno busca, porque utilizando recursos para algo de lo que ni el emisor ni el receptor sacarían provecho.
Aunque tal vez en las páginas de inicio de los sitios podría existir algún aviso, que a la manera de los requisitos de hardware avisen al visitante el tipo de material que hay dentro de ese sitio para que éste compruebe si el contenido se ajusta o no a sus posibilidades (no lo digo en broma, ojo).
Así, si un ciego ingresa a un sitio cuyo contenido es principalmente gráfico, podría existir un aviso al principio que le evite el tener que tratar de recorrer con su lector de braille información de la que no puede sacar provecho.
Bueno, eso… mis dos centavos
Escrito por mini-d
Octubre 31st, 2005 at 8:12 pm
Todas las validaciones sirven para guiarnos en el proceso de creación. Para verificar los errores puntuales. Pero ningún validador te ayudará a maquetar semánticamente, o mejor dicho, no te avisará si estás usando más divs de las recomendadas u otras prácticas.
Gez. En la nota, como bien podrás leer, no me limito hablar de «discapacidad visual» aunque es la más frecuente y variada en la población. La accesibilidad no sólo le toca a esta porción de la gente. Como bien explicas, no se pueden cubrir todos los frentes de golpe, pero se pueden ir preparando los andamios para construir nuevas soluciones. Tal es el tema que, fíjate, no hace falta hablar de invidencia cuando hablamos de accesibilidad. Puede ser algo simple, que nos puede pasar a todos nosotros en cualquier situación.
Un ejemplo, un castellano-parlante entra a un restaurante Vasco y pide la carta. La carta está escrita en Euskera, lo que le impide realizar una orden. Aquí hablamos de un problema de accesibilidad cultural. Esto se soluciona de dos formas. La primera y más lógica es: escribir un menú en euskara-castellano, si el lugar es frecuentado por castellano-parlantes (vamos, como en las ramblas de catalunya donde puedes pedir el menú hasta en alemán). La segunda: obligar al usuario aprender vasco (lo tienen chungo pero le enriquecerá culturalmente).
Todo bien con los vascos eh.
Escrito por Rodolfo
Octubre 31st, 2005 at 9:30 pm
Pues la verdad es que el texto está muy bueno y tienes razón en tus argumentos. Solo que: La tipografía de éste blog es muy pequeña (sobre todo para quienes navegamos a más de 800×600 que cada vez somos más).El color de la fuente tiene poco contraste para el blanco que usas de fondo. La tipografía es palo seco, lo que dificulta un poco más la legibilidad (que si tuviera una romana, por ejemplo) y además de ser palo seco tiene poco interletrado.
Pero tu lista es un buen check list para tomar en cuenta.
Saludos
Escrito por mini-d
Octubre 31st, 2005 at 10:14 pm
Gracias por el comentario, pero tengo mis serias dudas sobre lo que has escrito. Creo que, el control de esto lo sigues teniendo. Puedes:
Escrito por Francisco Vargas
Octubre 31st, 2005 at 11:10 pm
mini-d, la verdad que se agradece que gente como tú hagas estos comentarios sobre los buenos trabajos realizados. Y hablo por la experiencia que he tenido trabajando, con la gente de gencat.net, nosotros hicimos la parte del lector RSS y la verdad que dentro de las administraciones publicas, aquí hay gente muy competente.
Si supierais como estaba montado la página antigua de gencat.net y la que ahora se esta creando, fliparias!! y eso que ahora estan en fase BETA.
Es una labor de 150 personas trabajando durante mucho tiempo. Yo cuando entre la primera vez y me di cuenta del proyecto, dije a las personas que lo llevaban, si lo conseguis yo me quito el sombrero. Pues ahí va mi sombrero…
Enhorabuena Cristina y Oriol !!
Escrito por mini-d
Octubre 31st, 2005 at 11:18 pm
¿Gracias porqué? Los que debemos agradecer somos nosotros por fin una página hecha con conciencia. Esto, aunque no sea la nirvana de las webs, demuestra el poder de varias cosas hechas pensando un poco en todo el mundo. Cabe destacar que ahora cualquier cosa es mejorable sin tener que hacer re-ingeniería de las cosas.
Envidiable.
Escrito por are
Noviembre 1st, 2005 at 2:40 am
Evidentemente…un validador de sintáxis sirve para validar eso y no semántica. Són cosas bastante distintas que hay que diferenciar bien.
El validador del W3C nunca ha dicho (ni creo que haga) que valide nada de semántica.
En mi comentario lo único que queria puntualizar es este hecho: Si una web tiene la sintáxi mal, no puede aspirar a nada de semántica pues esta se basa en que dicha sintáxi sea la que tiene que ser.
Són términos diferentes pero ligados.
Escrito por mini-d
Noviembre 1st, 2005 at 1:44 pm
Ya, pero lo que intento explicar que, no todas las páginas que validan serían semánticamente correctas. A eso me refiero. Es bueno usar el validador (palabro). Es bueno usarlo si realmente estás diseñando con la semántica en mente, para evitar errores de sintáxis y demás.
Escrito por atroz
Noviembre 1st, 2005 at 5:09 pm
A ONCE le han concedido el premio Dia de Internet a la web privada con mejor accesibilidad. El TAW indica 1 error en proridad 1, 179 errores para priridad 2 y 12 para el nivel 3 en la página index de once.es. ¿Como es posible esto?
Escrito por xavi
Noviembre 1st, 2005 at 9:04 pm
Genial! He disfrutado leyendo este post… el minid de “estándares web” es el que más me gusta.
Muy interesante el analisis a partir de los 5 ítems de accesibidad web…
Escrito por mini-d
Noviembre 1st, 2005 at 9:54 pm
La página aunque no pase un control WAI de puntos puede ser aceptablemente accesible. Esos puntos no garantizan la perfecta audición. Ya lo dije, incluso, siendo el más estándard puede que no sea el más aceptable. Hay que verificar colores, etc. etc. Accesibilidad no es un test de TAW.
Escrito por atroz
Noviembre 2nd, 2005 at 7:25 am
OK, puede ser accesible aunque no valide en el TAW pero, creo que no es el caso. No soy un experto pero veo maquetación por tablas, etiquetas desaconsejadas, faltan atributos alt o estan vacios, etc. Esto me parece especialmente grave en la web de una organización de ciegos.
Escrito por mini-d
Noviembre 2nd, 2005 at 10:08 am
Sí, lo es. Debería ser al revés, esta web ser la primera y luego el resto dar el ejemplo. Pero ya ves. Recién este año y el que viene se verán cambios radicales. Estas organizaciones y empresas comenzarán a contratar gente que les ayude en el proceso de normalización, a menos que, pongan a trabajar gente que apenas conoce sobre el tema y todo termine siendo igual.
Escrito por Gonzalo
Noviembre 2nd, 2005 at 12:22 pm
Diego, es un buen artículo. Felicidades. Me sumo a la opinión de los que demandan más artículos de este tipo, respetando la libertad del autor para elegir, por supueso.
Algunas opiniones sobre los validadores:
Son muy útiles, y por supuesto no infalibes.
Aunque no sean perfectos, detectan errores, ofrecen soluciones para arreglarlo, y nos dirigen por el “buen camino”
Con los validadores web no se aprende accesibilidad y estándares, es un segundo paso en la formación de buenos creadores web. El primer paso, evidentemente, es conocer las especificaciones oficiales. Aunque todos los sabéis, no está de mal recordar que Sidar cuenta con una excelente recopilación de traducciones de documentos del W3C.
En el artículo y los comentarios se ha hablado con merecida insistencia del Test de Accesibilidad Web: La última versión ha mejorado muchísimo las anteriores y es una herramienta muy útil. Pero no nos olvidemos del validador de accesibilidad HERA. La forma de trabajar es una sabia mezcla entre validación automática y revisión manual, está disponible en ocho idiomas: para mí ha sido una de las mejores noticias de este año en el mundo de la accesibilidad web. Otro simpático validador, es examinator, que como ellos mismos dicen:
Poco más que añadir, saludos.
Escrito por Carlos
Marzo 19th, 2006 at 1:25 pm
Hola,
muchas gracias por esos enlaces a los validadores, me han resultado de gran utilidad para comprobar que mis sitios web no pasan ningún nivel de accesibilidad. Me gustaría saber si existe/conocéis alguna herramienta que te ayude a resolver todos esos problemas de forma rápida y sencilla. El problema de esos validadores que citáis es que típicamente te indican unos errores que raramente alcanzo a comprender. Conóceis algo más intuitivo.
Un saludo