<aside> ⚡

UX Hacks · Checklist de Facilitación Express. 5 puntos, 15 minutos, antes de que el formulario llegue a producción. Duplica esta página y úsala en tu próximo QA.

</aside>

Un formulario que no se puede llenar no convierte. Da igual qué tan bonito sea.

La mayoría de los problemas de accesibilidad en formularios se detectan en minutos y se corrigen en horas. En producción se pagan con soporte, abandono y riesgo legal.

Cómo usarla: abre el formulario en staging, recorre los 5 puntos en orden y marca cada casilla solo si pasa la prueba rápida. Cada punto trae el criterio de WCAG 2.1 AA que lo respalda.

01 · Cada campo tiene una etiqueta visible y conectada

• [ ] Cada campo tiene una etiqueta visible que no desaparece al escribir. El placeholder no cuenta como etiqueta.
• [ ] La etiqueta está conectada al campo en código (<label for> + id, o aria-labelledby).
• [ ] Los campos obligatorios se indican con texto, no solo con un asterisco de color.

<aside> 🧪

Prueba rápida: haz clic en la etiqueta. Si el cursor no salta al campo, no están conectados. WCAG 1.3.1 Información y relaciones · 3.3.2 Etiquetas o instrucciones

</aside>

02 · Todo se completa con teclado

• [ ] Con Tab se recorren los campos en el orden en que se leen.
• [ ] El foco siempre se ve: hay un contorno claro en el campo activo.
• [ ] Selects, calendarios y botones personalizados se abren y se cierran con teclado.
• [ ] Nada atrapa el foco: siempre puedes salir con Tab o Esc.

<aside> 🧪

Prueba rápida: suelta el mouse y llena el formulario completo, de principio a fin, hasta enviarlo. WCAG 2.1.1 Teclado · 2.1.2 Sin trampas de foco · 2.4.3 Orden del foco · 2.4.7 Foco visible

</aside>

03 · Los errores se entienden sin depender del color

• [ ] El mensaje de error dice qué pasó y cómo corregirlo ("Escribe un correo con @", no "Campo inválido").
• [ ] El error aparece junto al campo y no solo en rojo: lleva texto o ícono.
• [ ] El error está conectado al campo (aria-describedby) y el campo se marca como inválido (aria-invalid).