Lighthouse 100 en accessibility le da al equipo una confianza que el sitio no merece. La herramienta valida contraste y alt text, pero se pasa de largo ante un orden de foco confuso, un div clickeable sin label y un modal que atrapa el teclado. La accesibilidad de verdad combina patrones WCAG aplicados en el código con pruebas manuales de lector de pantalla; los ejemplos siguientes muestran ambos.

¿Por qué el HTML semántico va antes que ARIA?

Un <button> entrega foco visible, soporte de teclado y anuncio para lectores de pantalla gratis. La misma interacción con <div onclick> exige tabindex, handler de Enter y role reconstruidos a mano, cada uno con chance de bug. La primera regla de ARIA manda usar HTML nativo donde existe; reserva ARIA para widgets customizados.

¿Cómo gestionar el foco en rutas, modales y skip links?

  • El cambio de ruta envía el foco al heading del nuevo contenido
  • El modal atrapa Tab dentro del diálogo y restaura el foco al elemento original al cerrar
  • El skip link salta la navegación repetida y lleva directo al contenido principal
  • El estilo de foco visible se rediseña cuando la marca lo pide; quitarlo con outline: none rompe la navegación por teclado

¿Cómo construir formularios accesibles?

Asocia cada label vía for/id y conecta los mensajes de error con aria-describedby dentro de una región aria-live. El campo obligatorio se marca en texto, además del color. Atributos autocomplete correctos (cc-csc, email) ayudan a personas con limitaciones cognitivas y motoras, y el navegador completa mejor.

¿Cuándo usar live regions?

Un toast de éxito usa aria-live="polite"; un fallo crítico de pago pide "assertive". Las regiones live en exceso ahogan al usuario en anuncios y transforman NVDA en ruido. Una región por contexto alcanza.

¿Cómo probar con lectores de pantalla?

NVDA en Windows y VoiceOver en macOS cubren la mayor parte de la base de usuarios. Aprende dos comandos antes de confiar en cualquier walkthrough: la lista de headings (navega con H) y forms mode en NVDA. Cinco minutos de navegación keyboard-only por release revelan problemas que ningún score muestra.

¿Basta contraste 4.5:1?

El mínimo WCAG AA pasa los checks automáticos y falla en la calle, con el sol pegando en la pantalla del celular. Para texto corrido, apunta a 7:1 (nivel AAA) y valida con el brillo máximo del aparato.

¿Qué prácticas caben en el proceso del equipo?

axe-core en CI captura regresiones en cada pull request, el barrido manual keyboard-only entra en el checklist de release y los criterios de accesibilidad aparecen escritos en el ticket de la feature. El checklist sirve de piso; el código correcto y la prueba con lector de pantalla construyen el resto.