Accesibilidad web: lo mínimo que todo frontend debería saber

La accesibilidad web ya no es un extra, es una obligación legal y, sobre todo, una buena práctica que mejora la experiencia de cualquier usuario. En este artículo repasamos los conceptos básicos que todo frontend debería dominar para crear interfaces inclusivas sin complicarse demasiado.

1. Usa la semántica HTML correcta

Los navegadores y los lectores de pantalla confían en las etiquetas semánticas para interpretar la estructura de la página. En lugar de div genéricos, utiliza header, nav, main, section, article y footer. Los encabezados (h1‑h6) deben seguir una jerarquía lógica, de modo que el usuario pueda saltar de sección en sección con facilidad.

2. ARIA básico, no excesivo

ARIA (Accessible Rich Internet Applications) sirve para describir componentes que el HTML nativo no cubre. Lo esencial es:

• role: indica el tipo de widget (por ejemplo, role="button").
• aria‑label y aria‑-labelledby: proporcionan un texto descriptivo.
• aria‑pressed para botones de alternar estado.

Ejemplo de un botón de cierre accesible:

<button aria-label='Cerrar'>X</button>

Recuerda que ARIA no debe usarse para arreglar una mala estructura HTML; primero asegura la semántica correcta y luego complementa con ARIA cuando sea necesario.

3. Contraste de colores suficiente

El contraste entre texto y fondo debe cumplir al menos una razón de 4.5:1 (AA) y 7:1 (AAA) según WCAG 2.1. Herramientas como Contrast Checker te ayudan a validar rápidamente. Evita depender solo del color para transmitir información; combina con iconografía o texto adicional.

4. Navegación con teclado

Todo usuario debe poder interactuar sin ratón. Los elementos interactivos nativos (a, button, input) ya son enfocables, pero los componentes custom necesitan gestionar el foco manualmente.

Ejemplo de cómo mover el foco a un input tras abrir un modal:

function abrirModal(){
  const modal=document.getElementById('miModal');
  modal.style.display='block';
  const primerInput=modal.querySelector('input');
  if(primerInput) primerInput.focus();
}

Además, respeta el orden lógico del DOM y usa tabindex="0" solo cuando sea estrictamente necesario.

5. Mensajes de error claros y anunciados

Los formularios son el punto crítico donde la accesibilidad se rompe con frecuencia. Cada campo debe tener una etiqueta (label) vinculada mediante for y id. Cuando se produzca un error, muestra el mensaje cerca del campo y anúncialo con aria-live="polite" para que el lector de pantalla lo lea.

<div class="error" aria-live="polite">El email no es válido</div>

Así el usuario recibe feedback inmediato sin necesidad de buscar el mensaje.

6. Prueba con herramientas reales

No basta con revisar el código; prueba tu sitio con un lector de pantalla (NVDA, VoiceOver) y con la navegación solo por teclado. Extensiones como axe‑core o Lighthouse incluyen auditorías de accesibilidad que te alertan de problemas comunes.

En resumen, la accesibilidad no es un checklist infinito. Con una semántica adecuada, un uso mesurado de ARIA, contraste suficiente, foco controlado y errores anunciados, tendrás una base sólida que cubrirá la mayor parte de los requisitos. A partir de aquí, sigue iterando y escuchando a los usuarios para seguir mejorando.