Archivo de la etiqueta: diversidad

Controles HTML no nativos. ¿Son accesibles?

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 186 veces

Los captchas y el concepto de discapacidad

  • ¿Qué es una persona con discapacidad? – le pregunté.
  • Pues… una persona que tenga una discapacidad, ¿no? es decir: un sordo, un ciego, un tetrapléjico.
  • ¿Y tú?
  • ¿Yo qué?
  • ¿Tú eres discapacitado?
  • No no, claro, yo no, yo no tengo ninguna discapacidad, gracias a dios.
  • ¿Y yo?
  • ¿Tú? ¿Esta pregunta tiene trampa?
  • No hombre, no.
  • Pues… pues claro, ostias, eres ciego.
  • Ajam…

    Imagina que aquí tienes un formulario. Pongamos que el formulario es largo, de cuarenta campos. Te has pasado más de cinco minutos rellenando el dichoso formulario, pero no te importa, porque en cuanto le des a enviar, te habrás registrado en una página maravillosa a la que tenías muchas ganas de acceder.

    Ahora imagína que, antes de enviar el formulario, tienes que resolver un captcha. Pero ¡vaya! no es un captcha en el que tienes que descifrar una imagen, sino que se trata de un captcha musical.

    Pulsa en el botón “Reproducir”, escucha las notas, y escríbelas en el cuadro de edición. El 1 es el do, el 2 el re, y así hasta el siete, que es el si. Así, si las notas son re, mi, fa, sol, la si, tendrás que pulsar en el teclado: 234567.


Pulsa las notas usando los botones, si lo prefieres:

Notas que has pulsado:


    Vista no, pero buen oído tengo, afortunadamente; y gracias a mis años de conservatorio, muy entrenado para detectar las notas musicales. Te puedo resolver este captcha con un 95% de aciertos.
    ¿Que no? En esta demo te lo demuestro:< ¿Y tú? ¿Eres capaz?... ¿no?... ¡vaya! ¡Y luego dicen que yo soy el discapacitado! 😉 Y ahora, pregúntate: ¿es justo que alguien ponga este captcha en una página web?
    ¿No? ¿Por qué?
    Pues evidentemente, porque no todas las personas tienen formación musical y buen oído. Así que tampoco es justo que me pongas un captcha con imagen, porque no puedo verla. Al menos tú puedes entrenar la oreja 😉

    Así que cuando tengas que desarrollar tu próximo sitio, piensa en cuántas personas con capacidades diferentes podrán entrar a tu web: personas que ven bien, personas que usan gafas, personas que no ven, personas que no escuchan, personas que no pueden usar el teclado o personas que no pueden usar el ratón, personas expertas en informática, personas menos expertas… ¡el abanico es amplísimo!

    ¿Que es imposible tener en cuenta a todo el mundo? ¡Claro! Pero hay que intentarlo, ¿no? las propias siglas de la www te lo están pidiendo: world wide web: la web a lo ancho del mundo… Y mira que hay personas distintas en el mundo!

    Entrada visitada 2204 veces