MasterClassAccesibilidad — !Input type number eres muy maligno!
La accesibilidad web es la asignatura pendiente que habrá que aprobar en los próximos años (Siempre nos quedará Septiembre para los rezagados xD).
Cada vez se vuelve más importante, anteriormente era opcional añadirla en la matricula, pero estos últimos años se esta volviendo una asignatura obligatoria para pasar de curso. Los alumnos deberán aprenderla cómo si fuese el aprendizaje de un nuevo framework.
Te dejo una web interesante que te habla sobre la accesibilidad Web, concepto, beneficios, leyes aplicadas… para entrar un poco en calor por si no conoces o conoces poco de este mundo.
Disfruto de la accesibilidad web, tengo la oportunidad de trabajarlo todos los días en el cliente aplicando distintas soluciones en los componentes web contrastándolas con la WCAG2.1 y con los equipos de auditoría. Me encanta este mundo y poco a poco voy especializándome en este terreno.
Como sabrás o no, se tiene que dar todas las herramientas y facilidades posibles para que nuestra Web pueda ser usada por cualquier persona, independientemente de su diversidad funcional. En este link te explican de forma más detallada todos los beneficios que puede tener nuestra Web si aplicamos accesibilidad.
Una de las aplicaciones que mas uso en mi trabajo es el lector de pantalla. Un lector de pantalla es un sintetizador de voz que “lee y explica” lo que se visualiza en la pantalla, lo que supone de gran ayuda para personas ciegas o con problemas de visión.
Si tenemos un marcado html y una funcionalidad javascript correcta, para una persona que use un lector de pantalla le vamos a facilitar mucho la vida para que pueda usar nuestra Web o aplicación sin ningún problema.
Los lectores de pantalla más usados en ámbito móvil son: VoiceOver y TalkBack.
Estos dos lectores de pantalla se usan en Android y en IOS y dependiendo de cómo construyas tus componentes Web, en un lector de pantalla te funcionará bien y en el otro regular o incluso que no te funcione en ninguno. Normalmente lo que se intenta hacer es que en ambos lectores de pantalla funcionen exactamente igual dependiendo de las circunstancias del componente, widget, template…
Pero como he mencionado anteriormente, los lectores de pantalla son distintos como son los navegadores Web, cada uno es de su índole. Como todo en esta vida no es un camino de rosas, siempre hay caminos complicados que hay que tomar e intentar solucionar de la mejor manera posible.
Te expongo un caso que me encontré hace poco.
¿Sabes que el lector de pantalla talkback no lee el value de un input type number?¿Como te quedas?
Desde Marzo del 2020 el input number por alguna razón ha dejado de funcionar para el lector de pantalla Talkback en la version 7 de Android. Cuando añades un número en el campo y después vuelves a leerlo con el lector de pantalla talkback, no te lee el valor introducido anteriormente.
He hecho varias pruebas en versiones posteriores como la 8 y la 10 y no funciona.
Aquí os dejo el vídeo del fallo encontrado:
El lector de pantalla Voiceover funciona correctamente pero TalkBack no lee el value al hacerle foco:
Y ahora es cuando te preguntas… si me toca a mi esta incidencia en mi proyecto… ¿Cómo lo soluciono?
Tienes dos opciones:
- Esperar a que los de Android solucionen este bug o los que llevan el lector de pantalla Talkback saquen una nueva actualización (Esto puede conllevar mucho tiempo)
- Jugar con las posibilidades que nos da HTML y WAI-ARIA
Elegimos la segunda 😇😇😇
He realizado varios tests donde soluciono este bug.
PD: No valgo para ser youtuber xD
La primera posible solución:
Cambiamos el input type number a input type text, añadiendo el inputmode=”number” para simular el teclado numérico. No os recomiendo mucho esta solución ya que en otros sistemas operativos te puede dejar incluir letras, así que se podría usar pero con alguna solución al introducir caracteres que no se permitan añadir letras.
La segunda posible solución (La que más me gusta):
Añadimos al input number un aria-label dinámico, cada vez que el usuario escriba en el input añadimos ese valor dentro del aria-label, con esto lo que conseguimos es que si volvemos a hacer foco al input, el texto introducido se leerá a través del aria-label. En Voiceover no se produce repetición.
La tercera posible solución:
En esta solución ocultamos un <span> con un id que va a estar apuntado a través de un aria-labelledby del input type number. Cuando se introduzca un valor, ese valor habrá que setearlo dentro de ese span para que cuando salgas y hagas foco al input, este span sea leído. (Se produce repetición del valor)
En accesibilidad como en la programación, hay muchas posibles soluciones dadas a un caso en concreto, siempre hay que tirar de la mas fácil, liviana, compatible y que no produzca mucho problema de integración.
De vez en cuando encuentro este tipo de bugs y los disfruto más que cuando veo incidencias donde no se aplica un label correcto o que la semántica de un componente no es la apropiada.
El código de estas pruebas las tienes aquí: https://codepen.io/francisco1990Web/pen/Jjbggjz
Cualquier duda, otra posible solución que hayas podido encontrar, si quieres preguntarme alguna cosa o si quieres sugerirme que haga algún video de algo me puedes localizar en estas redes sociales:
Youtube: https://www.youtube.com/channel/UCPTKqt3lKhm9NhX7phBvrKA/featured
Twitter: https://twitter.com/FranWeb1990
Linkedin: https://www.linkedin.com/in/francisco-marquez-duro-3b1b0969/
Agradecimientos a mi colega Jorge López Verdú y a los compañeros de trabajo.
Muchas gracias por llegar hasta aquí. Un saludo!
