English
FrançaisSi sospechas que tu web flojea en temas de accesibilidad, no querrás tardar mucho en corregirlo. El año 2025 marcará un punto de inflexión en la accesibilidad web con la inminente entrada en vigor de la Ley Europea de Accesibilidad, programada para junio de 2025. Esta normativa impacta directamente en los productos digitales, exigiendo que sean verdaderamente inclusivos para todas las personas, sin importar sus capacidades o el contexto en el que accedan a la web.
Pero no es solo una cuestión de cumplimiento normativo; desarrolladores y diseñadores están más comprometidos que nunca en mejorar la experiencia del usuario. En nuestro [artículo anterior] (agregar enlace) explicamos los conceptos básicos que todo diseñador de productos digitales debe conocer sobre accesibilidad, pero ¿y los programadores?
A continuación, exploramos las mejores prácticas que pueden implementarse en HTML, CSS y JavaScript para mejorar la inclusión digital:
1. HTML y JavaScript
El uso correcto de HTML es fundamental para mejorar la accesibilidad sin necesidad de soluciones complejas. Una estructura semántica bien definida facilita la navegación de usuarios con discapacidades y optimiza la interpretación del contenido por los lectores de pantalla.
Uso de etiquetas semánticas
Evitar el abuso de <div> y <span> en favor de etiquetas que describan correctamente tanto su contenido (<header>, <main>, <footer>, <nav>…) como su jerarquia (<h1>, <h2>, <h3>, <label>…). De esta forma no solo estamos mejorando el SEO (que nunca viene mal), si no que en el caso de necesitar un lector de pantalla, estamos facilitando mucho la correcta navegación y comprensión de nuestra web.
Del mismo modo, si tenemos links en nuestra web etiquetados con <a>, o call-to-actions envueltos en un <button>, estamos garantizando que un usuario navegando con teclado puede ejecutar estas acciones de forma nativa solo usando foco automático con tabulador y Enter, ya que si tuvieramos un <div> con un onclick, nos obligaría a añadir una linea extra en Javascript para que funcione correctamente.
Roles y estados ARIA
Si por necesidades del proyecto usas etiquetas «no semánticas», puedes recurrir a atributos ARIA (Accessible Rich Internet Applications) (más información), para proporcionar información adicional a lectores de pantalla y otras tecnologías asistivas.
En primer lugar tenemos los Roles (role), que definen el propósito de un elemento , si no lo tiene por defecto. Siguiendo el ejemplo anterior, si usas un <div> con onclick en lugar de un <button>, los lectores de pantalla no reconocerán correctamente el rol de ese elemento. Con role=»button», puedes indicar para qué sirve:
<div role=»button» onclick=»alert(‘Enviado!’)»>Enviar</div> |
Así, un lector de pantalla lo interpretará de esta manera: “Botón, Enviar”
También existen otro tipo de roles más complejos que no tienen un equivalente nativo, pero que se usan con mucha asiduidad, como pueden ser “dialog” (define una ventana modal), “tablist” (defina un sistema de navegación de pestañas), “progressbar” (define una barra de progreso) o “searchbox” (define un input de buscador). Usar los roles para definir este tipo de componentes será de gran ayuda para explicar su funcionamiento.
Y por otra parte tenemos los Estados (aria-*), que informan sobre cambios en la interfaz, ayudando a los usuarios a entender lo que está ocurriendo en sus pantallas. Ejemplo:
<button aria-expanded=»false» aria-controls=»menu» onclick=»toggleMenu()»> Menú</button> |
Si nosotros por programación desplegamos el menú al ejecutar toggleMenu() y cambiamos el estado del aria-expanded de “false” a “true” , le proporcionaremos al lector de pantalla esta información adicional:
«Menú, botón, colapsado» → antes de abrirlo.
«Menú, botón, expandido» → después de abrirlo.
Otros estados útiles que podemos usar son “aria-label” (para definir elementos abstractos, como iconos, y dotarles de una descripción escrita), “aria-checked” (para definir si un checkbox está marcado), “aria-disabled” (para definir si un botón está deshabilitado) o “aria-hidden” (para definir que un elemento es invisible). El estado “aria-live” afecta más a Javascript, y nos podemos apoyar en él a la hora de explicar contenido dinámico:
| <form id=»miFormulario»> <label for=»email»>Correo electrónico:</label> <input type=»email» id=»email» name=»email» required> <button type=»submit»>Enviar</button>
<p id=»errorMessage» aria-live=»assertive» style=»color: red;»></p> </form> <script> document.getElementById(«miFormulario»).addEventListener(«submit», function(event) { event.preventDefault();
let emailInput = document.getElementById(«email»); let errorMessage = document.getElementById(«errorMessage»); if (!emailInput.value.includes(«@»)) { errorMessage.textContent = «Por favor, introduce un correo válido.»; emailInput.setAttribute(«aria-invalid», «true»); } else { errorMessage.textContent = «»; emailInput.removeAttribute(«aria-invalid»); alert(«Formulario enviado correctamente!»); } }); </script> |
En este ejemplo, tenemos un <p> sin contenido inicial, donde solo se pintará un mensaje de error cuando el formato del email sea inadecuado. En el momento en que ese párrafo se actualice con el mensaje de error, el aria-live anunciará de inmediato a un lector de pantalla que su contenido ha cambiado.
Aqui podemos encontrar un listado con todos los roles: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles y estados: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes que se pueden usar actualmente.
Formularios accesibles
Para garantizar formularios accesibles, usa etiquetas <label> correctamente asociadas con los inputs:
| <label for=»nombre»>Nombre:</label> <input type=»text» id=»nombre» name=»nombre» tabindex=»0″ required> |
El atributo for enlaza el <label> con el campo de entrada, facilitando su uso para lectores de pantalla.
El atributo tabindex controla el orden de navegación con Tab. El foco del tabulador irá desplazándose primero por aquellos inputs cuyo tabindex sea mayor. Este atributo, sin embargo, sólo debería usarse en casos muy concretos, cuando los formularios tengan una estructura inusual que no se ciñan a una lectura de arriba-abajo, izquierda-derecha.
Uso accesible de audio y video
Al utilizar etiquetas <video> y <audio>, es esencial garantizar la accesibilidad para usuarios con distintos grados de discapacidad:
- Subtítulos sincronizados para usuarios con discapacidad auditiva.
- Descripciones de audio para personas con discapacidad visual.
- Transcripciones de contenido sonoro (ej. podcasts).
- Evitar la reproducción automática, ya que puede ser disruptiva para usuarios con discapacidades cognitivas o motoras.
2. CSS
CSS puede contribuir significativamente a la accesibilidad al mejorar la visibilidad y usabilidad del contenido. Estas son algunas de las buenas prácticas que deberíamos tener en cuenta:
Uso de prefers- para adaptarse a las necesidades del usuario:
Los media queries prefers-* permiten adaptar el CSS de tu web a las preferencias del usuario en su navegador o sistema operativo.
- prefers-color-scheme, para usuarios que naveguen en modo oscuro:
| @media (prefers-color-scheme: dark) { body { background-color: #121212; color: #ffffff; } } |
- prefers-reduced-motion, para usuarios que quieran deshabilitar el exceso de movimiento en la web que pueda causar mareos o convulsiones:
| @media (prefers-reduced-motion: reduce) { * { animation: none; transition: none; } } |
- prefers-contrast, para usuarios que hayan cambiado los ajustes por defecto de contraste en sus pantallas:
| @media (prefers-contrast: more) { * { border: 2px solid #000; } } |
Foco visible para mejorar la navegación con teclado:
El pseudo-selector :focus-visible muestra el indicador de foco solo cuando se usa el teclado y lo oculta cuando se usa el ratón. Esto evita que los usuarios de ratón vean contornos innecesarios, mientras que quienes usan el teclado tienen un indicador claro. Ejemplo:
| button:focus-visible { outline: 3px solid #49a7dd; } |
Uso de clamp() para fuentes escalables y legibles:
La función clamp() permite definir tamaños de fuente que se ajustan dinámicamente según el tamaño de la pantalla, evitando textos demasiado pequeños o demasiado grandes.
| h1 {font-size: clamp(1.5rem, 5vw, 3rem)} |
El clamp() está ajustando el tamaño de fuente en base a estos criterios:
- Mínimo: 1.5rem
- Óptimo: 5% del ancho de la ventana
- Máximo: 3rem
Conclusión
La accesibilidad web en 2025 no es solo una obligación legal, sino una oportunidad para mejorar la experiencia de todos los usuarios. Aplicando buenas prácticas en HTML, CSS y JavaScript, logramos sitios más usables, eficientes y accesibles para cualquier persona, independientemente de sus capacidades. Incluir accesibilidad desde la base del código no solo amplía la audiencia de un producto digital, sino que también mejora su calidad y usabilidad. Ahora es el momento de implementar estos cambios y construir una web para todos. Si quieres complementar tus conocimientos en accesibilidad web, puedes echar un vistazo a nuestro articulo sobre la accesibilidad en productos digitales.
