Accesibilidad web práctica: lo mínimo que todo dev debe cumplir

La accesibilidad web se siente como un tema “extra” hasta que entendés que, según la OMS, el 16% de la población mundial vive con alguna discapacidad significativa. No es un subgrupo: es uno de cada seis usuarios. Y la mayoría de los sitios que visitás a diario tienen errores básicos que se arreglan en un par de horas.

El 80% de la accesibilidad vive en HTML semántico

<!-- Mal: div para todo -->
<div class="button" onclick="guardar()">Guardar</div>
<div class="heading">Mi perfil</div>

<!-- Bien: elementos nativos -->
<button type="button" onclick="guardar()">Guardar</button>
<h1>Mi perfil</h1>

Si usás <button> en vez de <div onclick>, ya tenés foco, soporte de teclado, lectores de pantalla y eventos listos. HTML semántico es accesible por default. El primer paso de cualquier auditoría es mirar si los divs podrían ser elementos nativos.

Los cinco elementos que más se rompen

1. Inputs sin label

<!-- Mal -->
<input type="email" placeholder="Email" />

<!-- Bien -->
<label for="email">Email</label>
<input id="email" type="email" />

El placeholder no es label. Cuando el usuario empieza a escribir, el label desaparece. Los lectores de pantalla no anuncian placeholders consistentemente.

2. Contraste insuficiente

Texto sobre fondo necesita 4.5:1 de contraste para texto normal, 3:1 para texto grande. Eso es WCAG AA. Si usás Tailwind, text-gray-400 sobre bg-white no llega. Herramientas para chequear: WebAIM Contrast Checker, axe DevTools.

3. Foco invisible

/* Nunca esto */
button:focus { outline: none; }

/* Mínimo aceptable */
button:focus-visible {
  outline: 2px solid hsl(220 90% 50%);
  outline-offset: 2px;
}

:focus-visible muestra el outline solo cuando el foco viene del teclado, no del mouse. Es la solución moderna al eterno debate de “feo outline”.

4. Imágenes sin alt

<!-- Imagen decorativa -->
<img src="decoracion.jpg" alt="" />

<!-- Imagen informativa -->
<img src="grafico.png" alt="Ventas del Q3: 1.2M de pesos" />

<!-- Imagen link -->
<a href="/producto">
  <img src="zapato.jpg" alt="Ver producto Zapatilla Urbana" />
</a>

alt="" (vacío, no ausente) le dice al lector de pantalla “esto es decorativo, ignoralo”. alt ausente es un error.

5. Formularios sin mensajes de error accesibles

<label for="email">Email</label>
<input
  id="email"
  type="email"
  aria-invalid="true"
  aria-describedby="email-error"
/>
<p id="email-error" role="alert">
  El email no es válido
</p>

aria-invalid indica el estado al screen reader. aria-describedby conecta el input con su mensaje de error. role="alert" hace que el mensaje se anuncie cuando aparece.

Navegación por teclado

Probá esto con tu sitio: navegá solo con teclado, sin tocar el mouse. ¿Podés llegar a todos los botones y links? ¿El orden del tab es lógico? ¿Los modales atrapan el foco hasta cerrarse?

Si la respuesta es no, tenés trabajo de accesibilidad por hacer. La mayoría de los usuarios con movilidad reducida usan exclusivamente teclado.

ARIA: el último recurso, no el primero

ARIA fue pensado para llenar los huecos que HTML no cubre. Si podés resolver algo con HTML semántico, hacelo con HTML. Las cinco reglas de oro de ARIA, según la documentación de W3C:

1. Si podés usar un elemento HTML nativo con el comportamiento y semántica que necesitás, hacelo.
2. No cambies la semántica nativa con ARIA a menos que realmente lo necesites.
3. Todos los controles interactivos deben ser operables por teclado.
4. No uses aria-hidden="true" en contenido visible y focusable.
5. Todos los elementos interactivos deben tener un nombre accesible.

Herramientas para auditar

• axe DevTools (extensión de browser): detecta automáticamente los issues mecánicos — labels faltantes, contraste, ARIA inválida. Lo que no encuentra ningún scanner: los problemas de UX que exigen juicio humano (¿este flujo tiene sentido con un lector de pantalla?).
• Lighthouse (en Chrome DevTools): incluye un audit de accesibilidad con score 0-100.
• Lectores de pantalla: VoiceOver (macOS, gratis), NVDA (Windows, gratis). Aprendé los básicos en 30 minutos.

Un sitio accesible es, casi siempre, un sitio más rápido, más limpio y mejor estructurado para todos. La accesibilidad no es una feature: es calidad básica.

Lo mínimo que tenés que cumplir antes de mergear a producción: semántica correcta, labels en formularios, contraste mínimo y foco visible. Si cumplís esas cuatro cosas, ya estás en mejor lugar que la mayoría de la web.