Un dificultad para los diseñadores web tradicionales es el simple hecho de crear un estricto documento XHTML y aplicarle una estructura semántica; de este modo los buscadores, navegadores y otros dispositivos automáticos pueden “entender” mejor el documento y tratarlo con corrección y eficiencia (mejor posición en buscadores, evitar comportamientos extraños en navegadores…).
Otras formas de acceder a páginas web.
Hay que saber qué sucede a nivel de código, y por supuesto prever otro uso o circunstancia más allá de la pantalla de un Internet Explorer. Muchas webs oficiales están pagando ahora el precio al pasar a la Web 2.0. Excluyendo con ello a colectivos de personas de muchos tipos, empezando por los que no utilizan windows como sistema operativo hasta los usuarios con discapacidades, así que empiezan a ponerse al día y tomarse esto más en serio.
Estos usuarios con discapacidad utilizan software especial que les permite acceder a la información y navegar, sin ver la página o usar el ratón. Así que una página debe estar preparada para que estos programas de ayuda, permitan la navegación de forma fluida.
¿Qué medidas se toman?
Actualmente, las recomendaciones WCAG 2.0 del W3C-WAI son las que deberíamos seguir para hacer una web accesible con este software, sin embargo, es la versión WCAG 1.0 de 1999 la que todavía se requiere en la práctica.
En ellas, se establecen tres niveles de prioridad que podríamos definir a groso modo como:
- A o Prioridad 1: La página cumple los requisitos para ser accesible
- AA o Prioridad 2: La pagina es muy accesible, incluso para más público.
- AAA o Prioridad 3: La accesibilidad de la página debería ser casi perfecta (todos sabemos que esa palabra debe usarse con cuidado)
Siempre llega el momento de medir nuestros esfuerzos en crear una web accesible, y pulir lo mejorable, de modo que utilizamos diferentes aplicaciones que analicen el código, en busca de problemas de accesibilidad, y que eventualmente nos informen de consideraciones y otorguen una validez a nuestro trabajo en éste campo.
Herramientas como WAVE o TAW Online (test de accesibilidad web) que financia el Ministerio de Industria, Turismo y Comercio, son una magnífica ayuda, desglosan los auténticos problemas (automáticos) y las consideraciones (manuales) de una página web especificando cual es el problema y la recomendación. Pero, desafortunadamente, se quejan de más problemas de los que hay realmente a día de hoy con software 10 años más avanzado.
Validación problemática
Algunos de dichos tests, como HERA, ven un error AA al usar Google Analytics porque inserta un manejador de evento sólo al hacer click. Ésto, hoy día, es algo que, ni mucho menos impide la accesibilidad, porque posicionarse con el teclado usando el tabulador e intro genera igualmente un evento click en el navegador. Igual ocurre usando software de accesibilidad, de modo que en la práctica, ya no es necesario duplicar esa función para otros eventos. Sin embargo, con otros eventos como Mouse Over (dependiente del dispositivo ratón) sí se debe proporcionar una funcionalidad duplicada para otro evento como Focus (evento lógico o independiente del dispositivo).
Otro error AA si usamos los necesarios hacks (arreglos específicos) en hojas de estilo CSS es que la hoja deja de validar, por tanto, los desarrolladores podíamos separar la hoja de estilos principal y validable, e importar los hacks desde dentro, de modo que nos permitiera validar nuestra hoja de estilos general, y posteriormente añadir los arreglos específicos o funcionalidad extra para navegadores específicos de forma controlada. Pero de un tiempo a esta parte, el validador CSS del W3C incluye en la validación las hojas importadas desde otra hoja, y los test de accesibilidad que hacen uso de esta herramienta muestran el error.
También se pretende que usemos medidas relativas para toda la página en lugar de medidas absolutas, y esto es ideal, pero en la práctica no es posible, ya que las imágenes utilizadas en la maquetación son mapas de píxeles y su tamaño no es variable, así que cualquier tamaño relativo provocaría la deformación y pérdida de calidad de imagen, lo cual es inaceptable. No obstante seguimos con interés, la implantación de imágenes vectoriales SVG del W3C que sí podrían especificarse con medidas relativas sin que afecte a la calidad de la imagen, pero por desgracia no es factible a día de hoy ya que el navegador mayoritario, Internet Explorer, queda atrás incluso en su versión 8, siendo el único navegador que no soporta de algún modo los gráficos SVG.
En cuanto a los formularios, se estipula que los campos y controles, no deben estar vacíos porque algún software de accesibilidad podría no ubicarse en ese control (hoy en día todos pueden). También me parece absurdo rellenar campos para datos personales con ejemplos de nombres y apellidos, pero bueno, pasaremos por el aro e invertiremos tiempo en scripts que controlen el comportamiento de estos campos al entrar y salir de ellos (si no hay script, el usuario tendrá que eliminar el ejemplo manualmente), y la validación total del formulario para que no sea enviado con los valores por defecto. Además, no es necesario para los lectores de pantalla que el campo contenga texto, ya que hay una etiqueta Label vinculada a cada campo, con la información que el lector necesita para ese campo.
Lo mismo se aplica para los atajos de teclado en páginas web que resultan inservibles, porque el usuario no los conoce, y además podrían bloquear atajos de teclas en su software de accesibilidad, suponiendo más un impedimento que una ayuda. Otra cosa es en el caso de las RIA, que tienen su propia especificación de accesibilidad WAI-ARIA.
Conclusiones en accesibilidad.
En fin, no es la primera vez que se dice que es mala idea tomar al pie de la letra todas las indicaciones de estos tests, no obstante es necesario revisar sus recomendaciones, y el sentido común nos dirá si realmente es un problema. En cualquier caso, muchos de los test empleados para nuestra página de Webmancers® nos acreditan para la mejor accesibilidad AAA, y así lo creemos.
Y por favor, si alguien tiene algún problema con la accesibilidad del sitio, no dude en contactarnos, y estudiaremos el incidente.
