Archivo de la etiqueta: accesibilidad

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

¡Desde el MVP Summit 2018!

Cuando Microsoft me premió con el MVP Award, no os podéis ni imaginar lo que significó. Ya no solo por el honor que supone para mí y todo lo que este premio conlleva, sino por sentir que había conseguido llegar donde nunca creí que llegaría.

Integrarse laboralmente en un mundo de personas que ven es difícil, en muchas ocasiones. La sociedad no está preparada para que una persona con discapacidad disfrute de las mismas oportunidades que los demás. Y el desarrollo de software no es la excepción.
Cuidado, ¡no quiero decir que llegar hasta aquí haya sido una carrera de obstáculos, una serie de peripecias y un constante trabajo de autosuperación! ¡Nada más lejos de la realidad! Lo que quiero decir es que siempre te encuentras obstáculos (en mi caso en forma de multitud de herramientas inaccesibles), pero nunca he sentido que me haya tenido que esforzar muchísimo más que el resto de mis compañeros para conseguir mis metas. Quizá ha sido suerte, en gran parte, y que he sabido buscarme los trucos para hacer accesible lo que no lo era, o al menos para ser capaz de buscar el atajo que me permitiera soslayar (que no romper ) una determinada barrera. La cuestión es que he sido capaz de tirar adelante y seguir trabajando de lo que me apasiona, aunque soy consciente de que las cosas serían más fáciles si todo fuera más accesible.

Allá por el 2000, cuando aún picaba en el block de notas, conocí Visual Basic 6.0. Y curiosamente, resultó que aquel entorno de programación era muy accesible para mi lector de pantallas. Tanto era así, que incluso nos permitía diseñar interfaces gráficas conociendo en todo momento si algún control se solapaba con otro, y en qué zonas de los mismos.
Conforme han ido evolucionando las versiones y pasamos a Visual Studio, han sido distintos los problemas y mejoras de accesibilidad que ha sufrido este entorno; pero hoy por hoy, puedo decir que es, sin duda alguna, la mejor herramienta de desarrollo con la que he trabajado nunca en términos de accesibilidad.
Gracias a ella he podido programar junto con mis compañeros, y he podido utilizar las mismas herramientas que ellos, con casi todas sus ventajas.

En fin, que me voy por las ramas.

La cosa es que gracias al MVP, he tenido la oportunidad de asistir al “MVP Summit” que se celebró la semana pasada en Seattle, en la sede de Microsoft en Redmon. Microsoft nos paga la estancia en un hotel chulísimo, y en mi caso, Pasiona me pagó el viaje (y los días que he estado fuera, claro); así que, ¡mil gracias para ellos! 🙂

Hace más o menos un mes y medio me contactaron desde Microsoft, y me ofrecieron la oportunidad de presentar una charla en el evento previo al “Summit”, el Pre-day, sobre la creación de presentaciones accesibles para todos… Así que pese a que sentía que todo aquello me quedaba grande, creí que era una oportunidad que no debía dejar pasar, y acepté.

Han sido un par de meses de trabajo intenso, porque quería montarles algo interesante que enseñar.
He desarrollado un visor de diapositivas accesible (la idea primigenia de esto me la dio Ramón Corominas cuando hace más de cuatro años nos presentó unas charlas de accesibilidad con un visor estático en HTML y javascript), y le he añadido algunas funcionalidades:

  • Traducción en tiempo real a sesenta y dos idiomas (gracias al translator de Azure Cognitive services).
  • Compartir las diapositivas desde una web donde la diapositiva en proyección se mostrará a todos los dispositivos conectados (Signal R power!) 😉
  • Proyección de subtítulos en tiempo real con lo que el presentador está contando (también traducibles en tiempo real al idioma seleccionado en la diapositiva para cada usuario conectado) (Speak to text, de Azure Cognitives services, again)
  • Interactuar con los asistentes a la charla, pudiendo crear encuestas durante la presentación, que todos los participantes podrán contestar desde sus dispositivos, y cuyos resultados el presentador podrá ver durante la proyección.

Un visor que en definitiva, intenta resolver las distintas barreras que una persona con discapacidad puede encontrarse a la hora de acceder a la proyección de una presentación, o las barreras que un presentador con discapacidad puede encontrarse a la hora de exponer en una charla.

Parece que a los asistentes a la charla les gustó el invento… y he de decir que gran parte del atractivo de la aplicación es gracias a mi amigo Jorge, un diseñador genial que convirtió un adefesio visual (lo mío es el back xD) en un diseño chulísimo 🙂 ¡Gracias tío!

Ahora mismo es solo una prueba de concepto, pero quiero publicar todo el código en github, para que no solo podáis usar la herramienta en vuestras presentaciones, sino para que también podáis colaborar en el desarrollo del proyecto si os apetece hacerlo.

¡En un próximo post os contaré más sobre el proyecto y sobre cómo podéis colaborar!

Son muchas las cosas que he aprendido, y muchas las personas interesantes a las que he conocido.
He tenido el inmenso placer de desvirtualizar a muchos MVP’s a los que solo conocía por Twitter, y que en persona resultaron ser un encanto. ¡Gracias a todos por hacerme sentir tan acogido!
He podido pasar más tiempo con mi compi de curro Carmen Checa (@cmcheca) (¡seguidla por Twitter, que le encanta! 😉 ), y la verdad es que me lo he pasado genial. ¡Gracias por echarme una mano con todo lo que he necesitado!

También conocí por fin en persona al crack de Carlos Mendible (@cmendibl3) (él me conocía del summit de Madrid, pero yo nunca le había visto 😛 ¡Vale, es un chiste muy malo, no me matéis, es viernes!. Fue mi compañero de habitación, y me ha soportado durante cuatro días ;). ¡Gracias por todo, compi! Además, ya hemos estado pensando en alguna que otra cosa que perpetrar juntos, así que os mantendremos informados 😉

Carmen, Carlos y yo.
Carmen, Carlos y yo.

Ha sido genial conocer a MVP’s de todo el mundo con los que he podido conversar (a pesar de mi deplorable inglés), y que también han sido super cercanos y pacientes con mis whats, mis “can yu ripit?” y mis “eeeh… ai zink aim not anderstanding yu! 😉 ¡Y cuál fue mi sorpresa cuando me encontré con Alexandre Costa, ¡otro MVP ciego que además tiene el honor de haber sido el primer MVP ciego del mundo! ¡No sabéis lo que mola poder hablar con alguien que se encuentra todos los días con tus mismos problemas usando las mismas tecnologías! 🙂

También he conocido a grandes estrellas (Miguel de Icaza (a quien abordé cual gruppie para contarle que gracias a Xamarin pude empezar en el mundo del desarrollo móvil de manera accesible), Scott Hanselman (que se acercó para pedirme un mail al que enviarme las slides de su presentación), a Julie Lerma (que tuvo una pequeña confusión con mi colega Alexandre Costa, pero que gracias a la cuál, acabamos teniendo una conversación más que interesante sobre vídeos de formación accesibles :), y también conocí a responsables de producto, como Jenny Lay-Flurrie (- Chief Accessibility Officer en Microsoft), a Leon Welicki (Principal Group Program Manager de Microsoft Azure)… Todos me han impresionado por su cercanía y por su buena disposición a abordar y resolver los problemas de accesibilidad de los mismos. Durante estos días he comprobado de primera mano que Microsoft está realmente comprometida con la accesibilidad, (y está poniendo mucho de su parte para mejorar los productos que desarrolla (aunque aún les quede mucho camino por recorrer en muchas cosas). Tengo el camino libre para reportar, ayudar y meterles caña, ¡así que es lo que voy a hacer, ahora que puedo estar más cerca de ellos!

Han sido tres días de sesiones intensas donde nos han enseñado muchas cosas que ya están o que estarán por venir, y algunas de ellas realmente me han encantado… ¡pero por ahora no puedo hablar de eso!

En definitiva, más de cuatro días donde he disfrutado como un niño con todo lo que nos tenían preparado los chicos de Microsoft. ¡Y de verdad que Whost y yo estuvimos allí! Tenemos una foto (no trucada) que lo demuestra!

También me gustaría agradecer a Cristina González, (nuestra MVP Lead), quien me acompañó en todo momento, se preocupó por que todo estuviera perfecto, y aguantó mis agobios cuando se acercaba la hora de mi charla el domingo, y a Molly Warner, quien se puso en contacto conmigo para darme la oportunidad de dar una charla en el pre-day, me brindó toda la ayuda que necesité para prepararla, e hizo que todo estuviera tal y como le pedí para que si algo fallara, fuera solo cosa mía 😉 ¡Mil gracias a las dos!

Y por último, aunque perfectamente podría haberlo puesto lo primero, agradecer a mi mujer, Núria (@amaterasu_n), pues gracias a que estuvo con el peque durante mis fines de semana de reclusión preparando la charla, y a que se encargó de todo por casa y cuidó al vikingo en solitario durante todo este tiempo, pude disfrutar de esta pedazo de experiencia. ¡Lo sé, los family points están en mínimos históricos, a ver cómo me lo monto para remontar! xDDD. ¡Gracias, amor!

Entrada visitada 492 veces

¿Puedes vivir sin tu ratón?

Inténtalo. Desconecta el ratón, o apártalo de tu mano.
Ahora, continúa con lo que estabas haciendo: abre el correo, responde un mail, entra a tu web favorita y examina tus finanzas en el banco. ¡Eh! ¡Que te he visto mirándolo de reojo! ¡No! ¡Concéntrate! ¡no caigas en la tentación!

¿Qué tal? ¿Cuánto has durado antes de volver a conectar el ratón?

En muchas interfaces el ratón es prescindible. Existen muchísimos atajos de teclado que el usuario medio no conoce, aunque de conocerlos y utilizarlos, le agilizarían el día a día de una manera notable.

Sin embargo, otras muchas interfaces son dependientes del ratón: iconos que no se alcanzan con las flechas o el tabulador, menúes que se despliegan al pasar el ratón por encima… Cosas muy monas, pero que excluyen a las personas que como yo, no podemos usar el ratón.

Esta tarde, intentando seleccionar una fila completa en el editor de tablas de SQL server, me di cuenta de que no había (o yo no encontré), ningún atajo de teclado para realizar esa operación. Si hacéis click con el ratón en el encabezado de la fila, se selecciona… y yo tuve que meterme en el navegador de la capa de accesibilidad del sistema operativo, buscar la fila 201, entrar dentro del control y buscar el encabezado. Por suerte, el objeto de accesibilidad permitía ser pinchado , así que pude simular el click de ratón.
Una operación que vosotros hacéis en medio segundo, tardé en hacerla más de 30 segundos (y porque lo mío con el navegador de objetos de UIA es puro vicio)
El siguiente paso podría ser automatizarlo con un script para que mi lector de pantallas, al pulsar una tecla, hiciera ese trabajo por mí y me seleccionara la fila… ¡Fijaros la de tiempo que tendría que perder, cuando lo único que debería haber hecho el desarrollador era poner un dichoso ítem más en el menú contextual!

Y para no alargarme innecesariamente, solo pedirte, amigo desarrollador, que cuando desarrolles alguna interfaz, te pares un momento, la manejes con teclado, y si no eres capaz de llegar a todos los rinconcitos, sabrás que yo tampoco podré hacerlo.

¡Gracias por tenerlo en cuenta a partir de ahora! ¡Si no lo haces, te remorderá la conciencia! 😉

¡A descansar!

Entrada visitada 308 veces

ValidationSummary accesible en MVC 5

¡Hola!

Hoy os vengo con un truquillo que, en caso de estar desarrollando webs accesibles en MVC, os puede venir bien.

Una de las cosas que considero muy importantes a la hora de mostrar una lista de errores de cumplimentación de formularios, es encabezar la misma con una cabecera, de modo que el usuario de lector de pantallas, al navegar por la lista de encabezados, dé con el resumen de los errores de formulario de forma fácil. Si obviamos esta cabecera, es posible que esa lista pase desapercibida, o al menos es lo que me dice la experiencia 🙂

En MVC 4, hasta donde recuerdo, no existía la sobrecarga de ValidationSummaryFor que os muestro a continuación, y que sí está disponible en MVC 5:

@Html.ValidationSummary("Revisa los siguientes errores", new { @class = "text-danger" }, "h3")

Esta extensión de HtmlHelper pinta una lista de errores, añadiéndole la clase text-danger (estoy usando bootstrap), y encabezando la lista con una etiqueta “h3” que encerrará el mensaje pasado en el primer parámetro.

¿La única pega de todo esto? Que el encabezado con el mensaje se ve siempre aunque no haya errores 🙁 .
Sin embargo, este método pinta una clase por defecto cuando el formulario es válido: “validation-summary-valid”; así que con un poco de magia CSS, podemos añadir lo siguiente a nuestra hoja de estilos:

/* para ocultar los encabezados de los validation summary si son válidos */
.validation-summary-valid {
	display: none;
}

¿Más fácil? ¡Imposible!

Y ahora ya, como truquillo de nota, podríamos hacer una pequeña mejora a la experiencia del usuario, añadiendo, mediante jquery, una función que ponga el foco en la lista de errores cuando esta esté visible. Así, un usuario de lector de pantallas, escuchará el encabezado con el mensaje que hayamos puesto, y será consciente al instante de que algo pasa con ese formulario.
Añadamos este script a nuestro sitio (recordad que necesitaréis jquery):

$(function () {
	var encabezado = $(".validation-summary-errors:last :header");
	if (encabezado.length) {
		encabezado.attr("tabindex", "-1");
		encabezado.focus();
	}
});

¡

Et Voilà!

¿Qué estamos haciendo aquí?

  1. Adjuntándonos al evento onDocumentReady, para que esto se ejecute cuando la página esté cargada.
  2. Buscando el último elemento con la clase validation-summary-error, y dentro de él, cualquier encabezado, sea del nivel que sea.
  3. Si lo encuentra, le pone tabIndex a -1 para poder focalizar en él de forma programática.
  4. Y por último, fuerza el foco a ese encabezado.

A mí personalmente me gusta crear un bundle de scripts de accesibilidad, y meter en él pequeños ficheros, cada uno de los cuales realiza una acción concreta. Así tengo la sensación de que mi código es más fácil de mantener.

¡Espero que os sirva!

¡A disfrutar picando! 😉

Entrada visitada 722 veces

Evitar interacciones no deseadas al ocultar elementos con animación en jQuery

¡Hola!

Esta mini entrada surge por un problema que estaba teniendo con unas animaciones en jQuery.

Resulta que estoy mostrando y ocultando una lista de enlaces usando fadeIn, fadeOut, slideDown y slideUp, dándole un tiempo de animación tanto en mostrar como en ocultar. ¡Estas cosas que a los que veis os molan tanto, que eso de que aparezcan y desaparezcan elementos de la pantalla así de golpe como que no os mola! 😉
Pues resulta que me di cuenta de algo obvio pero que no se me había ocurrido: Durante una animación de desaparición (por deslizamiento o por transparencia), el usuario de lector de pantallas puede seguir interactuando con los elementos, sin darse cuenta de que esos elementos están desapareciendo.
Y como a mí me la traen al fresco las animaciones y las desapariciones progresivas, se me ocurrió usar, durante las desapariciones, un atributo que oculta elementos para lectores de pantalla. Este atributo, dentro de las recomendaciones ARIA de la w3c, es “aria-hidden“, que ajustado a true, oculta la etiqueta en la que se aplique a lectores de pantalla.

Así que, podríamos usar el siguiente código para ocultar un ul durante 400 milisegundos, pero que desde el primer momento ya no se muestre a lectores de pantalla aunque tarde un rato en desaparecer:

lista.attr("aria-hidden", "true").slideUp(200, function () { $(this).removeAttr("aria-hidden"); });

¿Qué estamos haciendo?

  1. Ocultamos el elemento a lectores de pantalla.
  2. Lanzamos la animación de desaparición.
  3. Cuando se completa la animación, volvemos a mostrar el elemento a lectores de pantalla, pues como ya está oculto con display:none, no será visible para nadie. Vuelvo a quitar el aria-hidden, ya que si luego queremos volver a mostrar el elemento, los lectores no lo verán si esa propiedad se ha quedado a true :).

¡Mucho cuidado con aria-hidden y display:none! Si un elemento tiene display:none pero aria-hidden está a false explícitamente (no que no esté el atributo, sino puesto a false), el elemento será mostrado a lectores de pantalla pese al display:none. ¡Flipante!

¡Espero que este truquillo os pueda servir!

¡Buena semana!

Entrada visitada 520 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 2353 veces