Accesibilidad web esencial: WCAG en la práctica sin morir en el intento

Una de cada seis personas del mundo vive con alguna discapacidad significativa — y todas ellas navegan webs diseñadas por gente que rara vez las tuvo en mente. La accesibilidad no es una feature para "más adelante" ni un trámite legal: es la diferencia entre que tu producto funcione para todos o excluya silenciosamente a usuarios con discapacidad visual, motriz, auditiva o cognitiva. Lo bueno: el 80% del impacto se consigue con un puñado de hábitos.

HTML semántico: la accesibilidad gratis

El error fundacional es usar <div> y <span> para todo. Cada elemento semántico trae comportamiento accesible incorporado:

<!-- MAL: un div disfrazado de botón no es navegable ni anunciado -->
<div class="btn" onclick="enviar()">Enviar</div>

<!-- BIEN: foco con Tab, Enter/Espacio funcionan, lectores lo anuncian -->
<button type="submit">Enviar</button>

El botón div necesita reimplementar a mano todo lo que <button> regala: rol, tabindex, manejo de teclas, anuncio por lector de pantalla, estados. Estructura equivalente:

• <header>, <nav>, <main>, <footer> delimitan regiones navegables.
• Un único <h1> y jerarquía de headings sin saltos — los usuarios de lectores navegan saltando de heading en heading.
• <label for> vinculado a cada input: clic en la etiqueta enfoca, el lector lee el nombre del campo.
• <table> real con <th> para datos tabulares; listas <ul>/<ol> para listas reales.
• alt descriptivo en imágenes informativas; alt="" vacío en decorativas (que las ignoren es correcto).

Teclado primero

Mucha discapacidad motriz usa solo teclado (o switch devices). El test más rentable del mundo: desconecta el ratón y recorre tu web.

• Todo interactivo alcanzable con Tab en orden lógico (el DOM manda: si el orden visual difiere, rompe algo).
• Indicador de foco visible: jamás outline: none sin sustituto. Si el outline por defecto te parece feo, diseña uno mejor (:focus-visible).
• Modales que atrapan el foco mientras abiertos y lo devuelven al cerrarse.
• Skip link ("Saltar al contenido") como primer elemento enfocable.
• Atajos que no secuestren teclas del navegador.

Si un componente custom (dropdown, tabs, acordeón) no funciona con teclado, o usas el nativo (<select>, <details>) o implementas los patrones WAI-ARIA Authoring Practices — ahí sí toca leerlos.

Contraste: la métrica medible

WCAG exige ratios mínimos de contraste entre texto y fondo:

• 4.5:1 texto normal (< 18pt)
• 3:1 texto grande (≥ 18pt o 14pt bold) y elementos de interfaz (bordes de inputs, iconos)
• 7:1 AAA para texto normal

El gris claro sobre blanco que "queda elegante" suele rondar 2:1 — ilegible para baja visión, difícil para todos bajo luz solar. Convierte tus colores y comprueba el ratio con nuestra herramienta de color antes de aprobar una paleta; si generas combinaciones desde cero, elige paletas armonicas y contrastadas.

Y dos reglas hermanas: nunca transmitas información SOLO con color (el típico "los campos en rojo están mal" falla para daltónicos — añade icono/texto), y mantén objetivos táctiles ≥ 44×44 px en móvil.

ARIA: el condimento, no el plato

ARIA (Accessible Rich Internet Applications) añade semántica donde el HTML nativo no llega:

<div role="alert">Error guardando el formulario</div>
<button aria-expanded="false" aria-controls="menu">Menú</button>
<nav aria-label="Principal">

Pero su primera regla es famosa: la primera regla de ARIA es no usar ARIA si existe elemento nativo equivalente. Un <button role="button"> es redundante; un <div role="button" tabindex="0"> sin manejo de Espacio/Enter está roto. Los atributos que más uso honesto dan:

• aria-label / aria-labelledby: nombrar controles sin texto visible (botones de icono).
• aria-expanded, aria-current, aria-selected: estados dinámicos.
• aria-live="polite": anunciar actualizaciones asíncronas (resultados de búsqueda, notificaciones toast).
• role="alert": mensajes urgentes interrumpen el flujo del lector.

Y cuidado con sobre-etiquetar: cada aria-label incorrecto es peor que ninguno.

Formularios: donde se gana o pierde todo

La mayoría de transacciones mueren en formularios inaccesibles:

1. Labels siempre visibles (los placeholders como única etiqueta desaparecen al escribir — memoria de trabajo castigada).
2. Errores junto al campo, identificados con aria-describedby y anunciados al enviar.
3. autocomplete correcto (email, new-password, postal-code): menos tecleo, gestores de contraseñas felices.
4. Validación tolerante: no borrar lo escrito ante un error; indicar dónde y qué falló.
5. Timeouts avisados y extendibles en flujos largos.

Auditar sin gastar

Stack gratuito suficiente para empezar:

• Lighthouse (DevTools): auditoría automatizada básica con puntos concretos.
• axe DevTools: extensión que detecta violaciones técnicas con precisión notable.
• Navegación por teclado manual: irreemplazable — ninguna herramienta detecta "este modal atrapa el foco mal".
• Lector de pantalla: NVDA (Windows, gratis) o VoiceOver (Mac/iOS integrados). Escuchar tu web 10 minutos cambia tu forma de maquetar para siempre.

Las herramientas automáticas capturan ~30-40% de los problemas; el resto requiere criterio humano. Úsalas como radar, no como veredicto.

Preguntas frecuentes

¿La accesibilidad afecta al SEO? Positivamente: HTML semántico, jerarquía de headings, alt texts y rendimiento son señales compartidas. Google Search Console y los lectores de pantalla premian estructuras parecidas.

¿Es obligatoria legalmente? Depende de jurisdicción y sector: en la UE, el European Accessibility Act (aplicable desde junio 2025) obliga a e-commerce y servicios digitales clave; en EE.UU., ADA ha generado litigios masivos. Para B2C europeo ya no es opcional.

¿Cuánto cuesta hacer accesible un proyecto nuevo? Marginal si se hace desde el diseño (semántica + contraste + labels son casi gratis). Retrospectivamente puede costar rehacer componentes enteros — otra razón para hacerlo desde el minuto uno.

Comprueba los contrastes de tu paleta con nuestro convertidor de colores, gratis y directamente en tu navegador.