Introducción a la accesibilidad web: lo esencial para un sitio más inclusivo.
¡Hola Devs!, haré varias publicaciones cortas sobre este tema, inspiradas de lo aprendido del curso ‘Accesibilidad Web’ impartido por Udacity.
Comenzaré definiendo que entiendo por accesibilidad y por qué debería de importarnos como devs.
Pero, sin antes citar esta frase que me encanta 😍:
“El poder de la web está en su universalidad. El acceso por cualquier persona, independientemente de la discapacidad que presente es un aspecto esencial”. — Tim Berners-Lee.
Todas las personas deberíamos tener derecho a la información y por ende la web tendría que ser accesible para todos y todas, considerando que aproximadamente entre el 15 y el 20% de la población mundial tiene alguna discapacidad ya sea visual, auditiva, motriz o cognitiva, incluso existen otros casos como, personas de la tercera edad, alguna discapacidad temporal, si queremos acceder desde un smart watch, pantallas muy grandes o pequeñas, etc., la accesibilidad no solo debería pensarse para personas con discapacidad si no para toda la población.
Este tema ha sido tomado tan enserio que en el año 1973 Estados Unidos promulgó una ley de rehabilitación en la sección 508 donde exige a instituciones con financiamiento federal que toda la tecnología electrónica o informática que adquieran sea accesible a personas con discapacidades, y gracias a la W3C podemos tener ciertas pautas de accesibilidad en nuestra web, las cuales se basan en cuatro principios: perceptible, operable, entendible y robusta.
- Perceptible: La gente puede ver y escuchar el contenido de la web;
- Operable: La gente puede usar la computadora ya sea escribiendo o por voz;
- Entendible: La web es clara y con un lenguaje simple;
- Robusta: La gente puede usar diferentes tecnologías de apoyo sin afectar el funcionamiento de nuestra web.
Para ir terminando con esta sesión de definición, me gustaría compartirles algunos mitos sobre la accesibilidad web:
- Las personas con discapacidad no utilizan la web;
- Las páginas web con solo texto son accesibles;
- Es cara y costosa;
- Es solo para ciegos;
- Es solo para personas con discapacidades.
Agregar accesibilidad a una página web puede parecer costoso, incluso pensar que su lanzamiento puede demorar más de lo ‘normal’, sin embargo, si ponemos eso en una balanza con los beneficios que podremos brindarles a nuestros usuarios, creo que vale mucho la pena y deberíamos considerar la accesibilidad como parte de nuestro desarrollo y no un ‘nice to have’, y si vas comenzado como yo en este tema, sé que parece un mundo inmenso pero podemos empezar por pequeños pasos, así que aquí escribiré algunas consideraciones al momento de desarrollar web 🚀.
Links.
Simple 😌, con utilizar la etiqueta correcta <a href=""> </a> con eso estaremos mejorando la accesibilidad en nuestra web, ¿por qué? 🤔, si tu decides utilizar otras etiquetas como <span /> y después personalizarla para que parezca un link, esto ocasionará que el voice over no funcione correctamente ya que no la reconocerá como tal y además esta no es semántica. Usando la etiqueta correcta podremos acceder por keyboard y puede ser bookmark. Algo a considerar es que los links deberían de tener una descripción clara de lo que van a mostrar o hacer según el contexto, por ejemplo, en esta imagen se muestra como en vez de solo decir ‘Leer más’ , dice ‘Leer más sobre resposive layouts’, con el objetivo de que los usuarios que naveguen con la ayuda del voice over tengan claro a donde los llevará ese link.
Por último, nos dice que si una imagen será un link, esta debería ser envuelta por la etiqueta<a> y no al revés, la etiqueta <img/> debe de contener su atributo alt="descripción_breve" el cual nos permite dar una descripción breve sobre esta imagen para lectores con discapacidad visual.
Checkboxes
Ahora hablemos sobre nuestros hermosos checkboxes, esas cajitas lindas que personalizar es todo una tema 😒, y en muchas ocasiones nos preocupamos más por sus estilos que por su accesibilidad, olvidando su atributo aria-checked el cual indica su estado actual, ocasionando que el voice over no lo pueda leer y que nuestro usuario no sepa si lo activó o no 😨. En la siguiente imagen se aprecia que nuestro checkbox es creado con un <div /> y al darle clic se le agrega una clase llamada checked la cual le pone los estilos correspondientes para identificar que fue activado, pero si tenemos dificultad de visión esto no es suficiente 😞.
Pero no todo esta perdido, si podemos crear o personalizar un checkbox correctamente 🙌, usando sus atributos role y aria-checkeddonde en la primera se le indica el tipo de componente (en este caso un checkbox) y en la segunda se debe especificar su status, es decir, si está en true o false (ver la imagen 3), de modo que cuando se use el voice over nuestro usuario sabrá el status que tiene el checkbox 😊.
Nota: El atributo
aria-checkedsolo modifica el árbol de accesibilidad sin agregar unfocus, por ende, deberíamos agregarlo. Aquí una imagen de lo que modifica este atributo:
Y que hay sobre nuestras famosas listas y acordeones 😬, para agregar accesibilidad a estas etiquetas debemos hacer uso correcto de su role , en este caso es tree el cual identifica al elemento <ul> y debido a que el movimiento de enfoque en la lista se gestiona con un roving tabindex, éste elemento no necesita un atributo tabindex. Para identificar a sus elementos hijos (li o a) usamos el siguiente atributo role="treeitem” y por último, para indicarle a nuestros usuarios si un acordeón(collapse element) esta abierto o cerrado utilizamos el atributo aria-expanded='booleano' el cual recibe true o false según su estado. En la imagen 5 te muestro un ejemplo y aquí te dejo un link para que obtengas más información sobre listas y acordeones 🤓.
Por ahora, lo dejaré aquí, pero si te interesa seguir aprendiendo junto conmigo sobre accesibilidad, no te pierdas las demás publicaciones 😎. Gracias por leerme 🫂.
