Ayer os contaba por twitter que las tablas con scroll infinito eran un infierno para los lectores de pantalla. Para explicaros el porqué, pensaba hacer un hilo, pero me ha salido tan largo que al final os lo pongo en un post 😉
Los lectores de pantalla interceptan casi todas las teclas cuando estamos en un navegador, para proporcionarnos numerosos atajos de teclado que nos permiten la navegación de forma cómoda por un sitio web.
Por ejemplo: si pulsamos la e nos moveremos entre cuadros de edición, b entre botones, t entre tablas, h entre encabezados, y así con casi todos los tipos de controles que nos ofrece html.
Por tanto, si añadís eventos de teclado a vuestra web, a priori no van a funcionar, porque el lector no pasa las teclas al navegador y los eventos no se ejecutan.
Existen varios roles de “ARIA” que aplicados a un control, indican al lector de pantallas que dicho control es un control interactivo, y que dentro de él, las teclas deben pasar sin ser interceptadas. Alguno de estos roles son:
Imaginad entonces. Podéis poner el rol grid a una tabla con scroll infinito y así las flechas ya serán manejadas por el navegador. Sí, pero…
Para empezar, deberéis crear un completo mecanismo de manejo de esa tabla por teclado, utilizando flechas para que el usuario pueda moverse por todas las celdas de la tabla, programar teclas para ir al inicio y fin de la misma, ETC. Y siempre, marcando las celdas como focalizables y aplicando el foco a cada una cuando se produzca el movimiento.
Y ahora pensad en el usuario, que está acostumbrado a moverse por una tabla utilizando su lector de pantallas y las teclas rápidas que éste le proporciona, y de repente no puede hacerlo.
Con un lector de pantallas, dentro de una tabla, podemos usar las flechas para leer carácter a carácter una palabra, pulsar control + flechas para ir a la siguiente palabra… Con un grid que se maneja con flechas, no podríamos ni siquiera analizar el contenido de la celda.
Y por si esto fuera poco, comentaros que el soporte de “ARIA” y de manejo de foco durante una sesión dentro de un widget no es igual de buena en todos los navegadores ni con todos los lectores de pantalla, por lo que la experiencia puede variar de buena a pésima en función de qué combinación de lector y navegador se utilice. Por ejemplo, en las hojas de cálculo de google, con JAWS e IE va lentísima la navegación y con NVDA y Firefox funciona súper bien.
¿Alternativas sencillas? Podéis dejar el scroll infinito si poner el rol de application, pero colocar un botón (incluso ocultándolo visualmente para que solo sea legible por lectores de pantalla), que cargue más resultados… O un sistema de paginación oculto visualmente.
Ocurre lo mismo con controles no nativos como presentaciones en árbol y presentaciones en lista. Hay implementaciones de estos controles que funcionan perfectamente con Firefox y JAWS, y no funcionan en absoluto con Internet Explorer o Edge, y JAWS o NVDA…
En la actualidad, la única forma de asegurarnos que algo complejo hecho con “ARIA” funcionará con todas las combinaciones es no hacerlo, pues casi siempre habrá un lector, un navegador, o la combinación de ambos, que hará que vuestro invento no funcione. Es por eso Por lo que digo que el soporte de “ARIA” es muy inestable y da unos dolores de cabeza que no os imagináis.
Y ahora viene la parte en la que cruzo la línea y me sitúo en la perspectiva de un desarrollador, que para algo juego a dos bandas 😉
El problema de todo esto es que hoy en día creo que tampoco tiene sentido decirle a un desarrollador que no puede utilizar una presentación en árbol en un formulario para elegir una opción dentro de un árbol jerárquico, por ejemplo, máxime cuando en teoría esto debería estar soportado usando ARIA de forma correcta.
Así que en mi opinión, sí que hay momentos en los que usar “ARIA” es la única solución viable en el mundo real, pero hay que luchar porque el soporte de la especificación sea completo tanto para lectores de pantalla como para los navegadores actuales, y sobre todo, utilizarla de forma correcta.
A más compleja la web, más compleja la accesibilidad, sobre todo si se quiere hacer una experiencia cercana al mundo desktop, ya que normalmente, para conseguir esto hay que utilizar controles no nativos. No hay más que ver, por ejemplo, webs como la del portal de Azure, que a pesar de que intentan (me consta de primera mano) hacerla lo más accesible posible, hay sitios en los que han usado tanto “ARIA” y con mecanismos tan complejos que es una locura.
¿Conclusión? Siempre y cuando podáis usar controles nativos, hacedlo. Nos facilitaréis la vida una barbaridad, ya que estos controles ofrecen soporte nativo de accesibilidad. De hecho, la primera de las cinco reglas del uso de “ARIA” dice:
Si puede utilizar un elemento HTML nativo o un atributo con la semántica y el comportamiento que necesita ya incorporado, en lugar de redefinir el propósito de un elemento y añadir un rol, estado o propiedad ARIA para hacerlo accesible, hágalo.
Sin embargo, Si veis que vuestra funcionalidad requiere de controles no nativos y no queda más remedio, utilizad ARIA, con cuidado, mimo, y sobre todo, haciendo tests con la mayor cantidad de navegadores, sistemas operativos y lectores de pantalla posibles.
Y si tenéis dudas, ¡preguntad! Podéis encontrarme en Twitter como @kastwey.
Entrada visitada 306 veces
