29 de Agosto
Sistemas de navegación accesibles
Para saber cómo crear un sistema de navegación accesible primero hay que saber cómo navegan los usuarios con algún tipo de discapacidad. Luego hay que implementar la solución.
Los problemas más comunes afectan a:
- Usuarios invidentes o con graves problemas de visión.
- Usuarios que no pueden usar el ratón u otro dispositivo apuntador.
- Usuarios con problemas de concentración o con algún tipo de discapacidad intelectual.
¿Cómo navegan éstos usuarios?
Las personas ciegas usan los lectores de pantalla para navegar. Son programas que se ejecutan a la vez que el navegador y verbalizan la información que éste muestra, siempre y cuando esté correctamente codificada. El lector lee la información según las preferencias del usuario: puede leer el contenido automáticamente según lo encuentra, moverse línea a línea, palabra a palabra, navegar entre encabezados o tablas, etc. El orden de lectura por defecto es de arriba a abajo: primero se lee el título de la página, luego el número de enlaces (dependiendo del lector), y a continuación lo que vaya apareciendo en el código en el orden en el que esté.
Explicar en profundidad las opciones de lectura y el funcionamiento interno de los lectores daría para escribir un libro, pero lo importante es que permiten obtener una lista de los encabezados y enlaces de la página y moverse a y entre ellos.
El listado de enlaces es importante porque los enlaces son los que permiten navegar entre páginas (a todos los usuarios, discapacitados o no), esto es algo obvio, pero el listado de encabezados tiene una función menos obvia. Sirve para que las personas ciegas se puedan mover por dentro de la propia página. ¿Por qué es importante esto? Porque no tienen el contexto que tenemos las personas sin problemas visuales. Nosotros sabemos lo que hay alrededor de lo que estamos mirando, podemos ojear una página y ver las partes en las que está dividida, dónde está el logo, el buscador, etc. Ellos, en cambio, necesitan que codifiquemos correctamente los elementos para poder obtener este contexto. Cuando entran a una página normalmente esperan a que el lector les lea el título y enseguida obtienen el listado de encabezados para ver la estructura general de la página, luego la de enlaces, las de tablas y formularios para ver si los hay, etc. Es la forma que tienen de situarse y saber dónde pueden ir y qué elementos hay, por eso es tan importante crear una estructura de encabezados sólida y con sentido.
La falta de contexto es el problema fundamental de este tipo de usuarios y del que se derivan casi todos los demás. Tenerla en cuenta es básico.
Las personas con graves problemas de visión generalmente navegan a través de un magnificador de pantalla, con una versión gráfica de alto contraste de la web o usando un determinado juego de colores que les pueda venir mejor.
Las personas con problemas de manejo de ratón o dispositivos similares suelen utilizar el tabulador para navegar entre enlaces y/o elementos de formulario. Con la palabra tabulador me refiero no sólo al tabulador del teclado que todos conocemos, sino a otro tipo de formas de navegar que funcionan de manera similar, como por ejemplo los licornios o los punzones para los casos de discapacidad física severa.
Las personas con problemas de concentración o algún otro tipo de problema cognitivo forman un grupo extraordinariamente heterogéneo y complejo, plantean los problemas con diferencia más difíciles de afrontar para un desarrollo web accesible. Generalmente se simplifica mucho la cuestión y se suele considerar de forma generalista que una buena práctica para estos usuarios es crear interfaces sencillas y consistentes. Los elementos deben aparecer siempre en los mismos sitios, se deben reducir en la medida de lo posible los efectos que distraigan, etc. Se pueden hacer efectos, pero no convertir la navegación en un circo donde todo se mueva, salte, cambie de color, etc.
Implementar la solución
Para los usuarios de lectores de pantalla lo más importante es estructurar bien la información, maquetar de forma correcta. Es vital usar encabezados y usarlos bien para estructurar la información de la página en bloques lógicos, dar jerarquía y permitir la navegación entre ellos, y asegurarse de que el texto de los enlaces es descriptivo. Por ejemplo, un enlace que dirige al sitio web del Sidar debe ser algo como:
<a href="http://www.sidar.org">Sidar</a>
En vez de:
Para ir al sitio web del Sidar <a href="http://www.sidar.org">haz clic aquí</a>
Que es una práctica todavía muy usada pero muy poco recomendable. Como se ha explicado al principio del artículo, cuando el usuario del lector obtenga la lista de enlaces de la página le va a salir el texto “haz clic aquí”, que no dice nada, el usuario no sabe a dónde dirige el enlace. En algunos casos el “clic aquí” puede tener sentido, por ejemplo en páginas con un listado de productos para comprar. En estos casos, el texto significativo hay que ponerlo en el atributo title del enlace, que también se mostraría en el listado de enlaces del lector de pantalla:
<a href="http://www.sidar.org" title="Sidar">haz clic aquí</a>
Vamos a verlo con un ejemplo práctico. ¿Podrías decir a dónde dirige el enlace “Haz clic aquí” que aparece en la siguiente imagen?
Y no hay mucho más. Estos usuarios accederán a la página, leerán el título de esta y obtendrán la lista de encabezados para situarse. Si la página está bien pensada, con un encabezado por zona importante, podrán moverse entre las zonas bastante rápido: pulsan un encabezado y el lector les lee desde ahí. ¿Qué no les interesa? Pues nada, se mueven al siguiente encabezado u obtienen la lista de enlaces y se mueven por estos.
Dos cosas más. Algunas personas prefieren situar en el código primero el menú y luego el contenido, mientras que otros prefieren hacerlo al revés. A nivel de accesibilidad en mi opinión las dos son válidas si se estructura bien la página con encabezados. Normalmente siempre he puesto primero el logo, buscador y demás, luego el menú y luego el contenido, por dar acceso rápido a la navegación a los usuarios de lectores, pero últimamente opto por la segunda forma añadiendo un detalle. Primero pongo un enlace para ir al contenido y otro de ir al menú de navegación, luego el logo y buscador, luego el contenido y por último el menú y el pie. Los dos enlaces iniciales los pongo para ayudar a la navegación de los usuarios que no usan el ratón, el logo y la caja de búsqueda para dar acceso rápido a dos elementos importantes, luego pongo el contenido para que esté lo más arriba posible por SEO, el menú precedido por un encabezado para poder acceder a él, y finalmente el pie.
Por último, algo obvio: si los elementos de navegación son imágenes hay que ponerles los alts.
Para los usuarios con problemas de manejo de ratón hay que permitir la navegación independiente de dispositivo y tener cuidado si usamos Javascript.
Lo primero a tener en cuenta es el orden de tabulación. Por defecto, este es el mismo que el orden de aparición del elemento en el HTML: lo primero que aparece en el código es lo primero a lo que se accede, así que iremos tabulando elemento a elemento empezando por el que más arriba aparezca.
Se puede cambiar poniéndole la propiedad tabindex a los elementos. Si por ejemplo tenemos 4 elementos y ninguno tiene tabindex, se leen en el orden en que aparecen en el HTML, pero si al cuarto le ponemos tabindex=”1”, se leería el primero y luego los demás.
De todas formas, es muy raro tener que usar tabindex ya que una maquetación bien planteada que siga un orden lógico ya debería tener el orden de tabulación correcto.
También hay que tener en cuenta que los únicos elementos que pueden ganar el foco (ser tabulados) son los enlaces y los elementos de formulario. Con JavaScript se puede poner el foco a más elementos poniéndoles un tabindex negativo, pero ese es otro tema que trataré en otro artículo, ya que es una técnica usada para hacer que los lectores de pantalla detecten cambios hechos con Javascript. Esto se usa para validar formularios y en aplicaciones Ajax, aunque plantea un montón de problemas que no se resolverán hasta que se extienda la especificación WAI-ARIA.
A nivel de usabilidad hay que tener en cuenta que las páginas web suelen tener muchísimos enlaces, así que tabulando puede ser muy costoso llegar a un enlace que esté muy abajo. La solución a esto se explica en el apartado “atajos de navegación” ya que este problema afecta tanto a usuarios que tabulan como a usuarios de lectores de pantalla, y la solución es común.
Y por último, es importante también que cuando un elemento gana el foco el usuario pueda notarlo. A veces es difícil saber qué elemento lo tiene. Para esto simplemente se añade una regla CSS:
a:focus, input:focus{outline:2px red solid;}
Ésto hará que los elementos se recuadren con un borde de 2px. Por cierto, en IE 6 y 7 no funciona el pseudoestado focus. Para que los usuarios de estos navegadores obtengan una funcionalidad similar se puede añadir el pseudoestado :hover.
En la siguiente imagen se puede ver cómo el foco está en el enlace a Aaron Rester.
También hay que tener en cuenta que el cambio de estado que hagamos no debe basarse solo en el color. Por ejemplo, si tenemos una caja de texto con un borde negro de un pixel, no debemos cambiarlo a borde rojo de 1 pixel porque los usuarios con problemas para ver el rojo no detectarán el cambio. Deberíamos ampliar el borde, poner una imagencita de fondo o algún cambio similar que se note claramente.
Además de la tabulación, hay que tener cuidado con Javascript. Se puede usar sin problema para añadir mejoras a la navegación o crear efectos pero no se debe depender exclusivamente de él. Los enlaces deben ser enlaces, con su href para que el usuario pueda navegar aunque no tenga habilitado Javascript. Si luego quieres añadirle mejoras a la experiencia de usuario con Javascript, pues perfecto, pero siempre respetando el esquema básico. Siguiendo esta línea no veo problema en añadir algún efecto con eventos Javascript, sean o no dependientes del ratón (por ejemplo, ondblclick)
Para los usuarios con problemas cognitivos lo dicho, consistencia en el diseño y sencillez en la medida de lo posible. Es importante definir una arquitectura de información que refleje el lenguaje de los usuarios, para lo que se puede recurrir a sesiones de card sorting, o como solución mas artesanal para presupuestos bajos, investigando las palabras más comunes de búsqueda en Google respecto a la temática de nuestro sitio web, echando una ojeada a Google Trends sobre los términos más buscados y con técnicas similares.
También es importante reducir el ruido en el diseño, eliminar elementos superfluos que distraen la atención, tener cuidado con las zonas donde se coloca la publicidad, etc. En resumen, simplificar el diseño mostrando los elementos realmente importantes.
Atajos de navegación
Como comentaba anteriormente, para los usuarios con problemas de visión y/o movilidad tan importante como navegar entre páginas es navegar dentro de ellas. Para un invidente es crítico poder moverse entre encabezados para acceder a las distintas secciones de la página, enlaces, formularios, tablas, etc.
Esto también es importante para los usuarios que, aún viendo bien, tienen problemas de movilidad, no pueden usar el ratón por ejemplo. Pueden ojear la web, ver de un vistazo sus secciones, las partes importantes, dónde están los enlaces y los formularios, pero se mueven entre los elementos tabulando, así que ¿qué pasa si tienen que tabular a través de un montón de enlaces de un menú para acceder al enlace que les interesa?, ¿y si quieren rellenar un formulario que está en el contenido de la página pero antes tienen que pasar tabulando de nuevo por un montón de enlaces? En el sentido estricto, estos elementos son accesibles porque poder se puede acceder a ellos, pero el proceso es muy engorroso.
Para ayudar a solucionar estos problemas hay dos técnicas: los atajos de navegación y las accesskeys.
Atajos de navegación
La idea consiste en crear unos pocos enlaces en la parte superior de la página que apunten a las secciones importantes de esta. Son útiles especialmente para los usuarios con problemas de movilidad. Para los invidentes es más bien una ayuda a la navegación.
En el fondo consiste en dar a los usuarios con problemas de movilidad una funcionalidad similar (aunque más limitada) a la navegación entre encabezados que los lectores de pantalla ofrecen a los invidentes.
Yo normalmente pongo sólo dos enlaces para agilizar la navegación y dar acceso a las partes realmente importantes: uno para acceder al contenido y otro para acceder al menú. Más o menos así:
<ul class=“saltar”>
<li><a href=“#contenido” accesskey=“2″>Contenido</a></li>
<li><a href=“#menu” accesskey=“3″>Menú</a></li>
</ul>
Colocado en la parte superior de la página para que sea lo primero en recibir el foco al tabular.
Estos enlaces solo son visibles al recibir el foco, lo que no es ningún inconveniente para los invidentes ya que ellos sabrán que están casi desde que el lector empieza a leer la página o al obtener la lista de enlaces, ni tampoco para los que tengan problemas de movilidad porque en cuanto tabulen sabrán que están ahí. Para facilitar un poco más el acceso a ellos le suelo poner un accesskey a cada uno.
El css que los muestra y oculta podría ser así:
.saltar{position:absolute;}
.saltar a{position:absolute;left:-1000px;top:0px;}
.saltar a:hover,.saltar a:active,.saltar a:focus{position:absolute;top:0px;left:0px;z-index:1000;}
Oculto los enlaces de esta forma porque display:none oculta los elementos a muchos lectores de pantalla.
Por último, hay que tener en cuenta los problemas con el HasLayout de IE6. Es una propiedad creada por Microsoft para definir el comportamiento de los elementos de una página web e influye en un porcentaje altísimo de los problemas con este navegador. Esta propiedad puede tener un valor true o false. Algunos elementos la tienen por defecto a true y otros a false y hay propiedades css que la modifican. ¿Por qué es importante esto al crear enlaces internos? Porque normalmente el objetivo de estos enlaces (al menos los que yo creo) son divs contenedores de zonas importantes, y la propiedad HasLayout de los div es false por defecto. Y un elemento con HasLayout con valor false no puede ser objetivo de un enlace interno: si por ejemplo tras pulsar un enlace de ir al contenido pulsamos luego uno de “subir”, no funcionará.
¿Cómo se arregla? Con una regla CSS aplicada a través de un hack para IE6 para aplicarle una propiedad al elemento objetivo que ponga su HasLayout a true. Por ejemplo:
* html #contenedor {height:1%;}
No tendrá consecuencias de cara a la maquetación y todo funcionará correctamente en todos los navegadores.
Accesskeys
Otra ayuda para estos usuarios pueden ser las accesskeys, atajos de teclado que permiten acceder rápidamente a un elemento. Son muy útiles para acciones que se hacen muy a menudo o muy importantes, pero hay que crear poquitas para que sean fáciles de recordar. Yo normalmente creo cuatro o cinco, por ejemplo:
- 1: Página de inicio
- 2: Buscar
- 3: Contenido
- 4: Menú
- 5: Subir
Aunque depende de la página y cómo la utilicen los usuarios. Por ejemplo, en un site en el que los usuarios usaran mucho un formulario de contacto podría tener sentido poder acceder a él con un accesskey.
Pero tienen varios problemas, así que hay que tener cuidado. Primero, no se ha conseguido consensuar entre los desarrolladores un grupo de teclas, así que en cada sitio los usuarios tienen que aprender una nuevas. Segundo, hay conflictos con los atajos de teclado de varios tipos de agentes de usuarios. No se deben usar letras como accesskeys porque casi seguro entrarán en conflicto. Lo más seguro es usar números, aunque no es seguro al 100% que no vaya a haber problemas. Y tercero, los usuarios tienen que ir a la página de accesibilidad o mirar en el código fuente para aprender los atajos, lo que es un problema. Esto tal vez debiera correr a cargo de los desarrolladores de navegadores creando una opción de menú que te resaltara los atajos del site.
En resumen, se deben usar siempre que merezca la pena de verdad y con sentido común y criterio.
En un par de añitos, WAI-ARIA al rescate
Todos estos problemas muy posiblemente se solucionarán con la implantación de WAI-ARIA. Es una especificación que está en proceso para crear aplicaciones dinámicas accesibles: actualizaciones del DOM, Ajax, etc. Todavía le queda un tiempo para ver la luz pero todos los navegadores, librerías Javascript y lectores de pantalla la están implementando. Hoy en día, Firefox permite acceder a características implementadas con WAI-ARIA mediante la extensión Firefox Accessibility Extension.
Otra novedad son los role landmarks, que permiten definir zonas de la página. Así:
<div role=”navigation”>
Añadiendo semántica al código, algo bueno para casi todos: los robots de los buscadores lo tendrán más fácil y podrán acceder a una información sobre la información más rica, y los navegadores y lectores de pantalla podrán acceder a estos elementos y ofrecer una navegación más cómoda. Un usuario de un navegador podrá obtener un listado de secciones de la página y moverse a ellas.
Esto añadido al uso de encabezados facilitará mucho las cosas a los invidentes y ayudará muchísimo a los usuarios con problemas de movilidad.
Referencias
- Videos on computer accessibility
- Técnicas de agrupación de tarjetas (Card Sorting)
- Ayuda técnica: licornios
- Atajos de teclado en documentos web
- Use of XHTML role landmarks to improve document navigation
- “HasLayout” Overview
- Invisible Content Just for Screen Reader Users
1 de Julio
Ejemplos de buen diseño para móvil
La semana pasada Nokia publicó un documento con algunos de los mejores desarrollos para móvil de los últimos tiempos. Aparte de muy bien presentado, me han gustado mucho los tres criterios que usan para definir un buen diseño: facilidad de uso, diseño de interacción y atractivo visual. Son los tres pilares de una buena experiencia de usuario.
Aunque todos los […] Continuar leyendo…
24 de Junio
Generación de comunidades online
En las últimas semanas he participado en una charla y un curso de Eduardo Manchón sobre creación de comunidades online. La charla fue en las conferencias Foro de Internet 2008 y el curso en el User Interface Workshop de Evolucy.
Eduardo es uno de los creadores de Panoramio, una comunidad online para mostrar fotos de lugares que fue comprada por […] Continuar leyendo…
21 de Junio
Infografía de The New York Times sobre los fondos soberanos
El diseño de información es el área del diseño que más me interesa tras el diseño de interacción aunque de momento no le he podido dedicar mucho tiempo porque uno no puede abarcar la cantidad de disciplinas que hay que seguir si trabajas en temas relacionados con Internet.
Es una disciplina fundamental en el diseño para medios interactivos de la […] Continuar leyendo…
4 de Junio
La web multidispositivo
LLevo tiempo dándole vueltas a la web multidipositivo. Hace unos día escribía sobre ello y seguirá siendo uno de los temas centrales de este blog y de mi carrera futura. Esta entrada en Digital Living me ha animado a escribir más sobre el tema. Creo que esta vez va en serio, tanto a nivel técnico y de infraestructura tecnológica, […] Continuar leyendo…
22 de Mayo
La nueva hornada de ’start-ups’ españolas
Una gozada leer el artículo de hoy de El País sobre Startup 2.0 y las 3 nominaciones españolas. He estado echando una ojeada a las 10 finalistas y hay ideas muy buenas. Creo que ha ganado Zilok, una web para alquilar cosas que no uses. No me acaba de convencer demasiado. No sé cómo encajará esa idea en España, […] Continuar leyendo…
22 de Mayo
Webs populares en el internet móvil
Comentan en alt1040 el último estudio de Opera sobre las tendencias de navegación de los usuarios de Opera Mini, su navegador móvil. Me ha parecido curioso que un servicio muy usado sean las redes sociales, no esperaba que se empezaran a extender tan pronto a otros dispositivos.
Llevo un tiempo dándole vueltas a la web móvil y los desarrollos multidispositivo […] Continuar leyendo…
14 de Mayo
Foro de Internet 2008: Javier Castilla (SEO)
La otra charla que me gustó fue la que dió Javier Castilla. Se titulaba “La estrategia de posicionamiento SEO” y a los que estamos empezando a darle al SEO nos vino de perlas porque explicó las cosas muy bien, con ejemplos y de forma muy amena. Javier es el CEO de Hydra Networks, el organizador del congreso.
La idea principal […] Continuar leyendo…
12 de Mayo
Comparativa de accesibilidad de las WCAG 1.0 y la norma UNE 139803/2004
Excelente comparativa creada por Olga Revilla de Itákora entre las WCAG 1.0 y la norma UNE 139803/2004. Las leyes españolas se basan en esta norma en vez de en las WCAG para legislar y aunque son casi idénticas hay que tener claras sus pequeñas diferencias. En su post las explica y en el excell que adjunta viene una tabla […] Continuar leyendo…
11 de Mayo
Foro de Internet 2008: Enrique Dans
Bueno, pues ya estoy de vuelta. Han sido dos días bastante intensos, sobre todo el primero ya que fuí a todas las ponencias menos una. En el segundo día he sido más selectivo porque son 12 horas al día y si vas a todo acabas agotado.
Ha habido ponencias de todo tipo, pero el congreso estaba muy centrado en la […] Continuar leyendo…
Tags
- accesibilidad (4)
- arte (2)
- diseño (3)
- Diseño de información (7)
- Diseño de interacción (7)
- experiencia de usuario (9)
- front-end (4)
- general (6)
- Redes sociales (4)
- SEO (1)
- Web móvil (4)
- Web semántica (3)
Archivo
- Agosto 2008 (1)
- Julio 2008 (1)
- Junio 2008 (3)
- Mayo 2008 (10)
- Abril 2008 (16)
Areia.info y todo su contenido están creados bajo la licencia de Reconocimiento de Creative Commons