Función e importancia
¿Para qué sirve?
Hace tres trabajos a la vez, todos críticos: convierte la intención del visitante en una conversación real (con la menor fricción posible), cumple WCAG 2.2 sin pedir JavaScript adicional, y deja al sitio listo para escalar a backend real con un upgrade limpio (honeypot + Turnstile + consentimiento LFPDPPP) cuando llegue el momento.
Su función primaria es comercial: el formulario es el cuello de botella donde la mayoría de los sitios pierde leads —placeholders en lugar de labels, inputs a 14 px que zoomean iOS, validaciones genéricas que no dicen qué corregir, captchas que toman 30 segundos resolver, formularios de 10 campos para pedir un presupuesto—. El componente actual elimina TODAS esas fricciones: 3 campos, labels asociados, inputs a 16 px, validación HTML5 nativa, cero captcha, envío directo a WhatsApp. Para el visitante: 30 segundos del primer tap al primer mensaje enviado. Para el negocio: el lead llega al canal donde ya responde, sin bandejas que vigilar.
Su función secundaria es de accesibilidad: el formulario es el módulo con MÁS superficie WCAG del sitio (cada input es 6 reglas: label, contraste, foco, touch target, error, focus management). Cumplirlas no es opcional ni es solo para usuarios con discapacidad —son las mismas reglas que mejoran la experiencia en un teléfono al sol, en una conexión 3G, con guantes invierno, o para alguien que escribe en su segunda lengua—. El componente actual cubre las reglas base; el checklist canónico de docs/MODULOS.md §6.3 más las recetas de §5 cubren el AA enhanced. Y la terciaria es de seguridad: el patrón canónico anti-spam (honeypot + consentimiento LFPDPPP + Turnstile + rate-limit) corta el 99% del spam sin pedirle al humano que resuelva un captcha, y deja al sitio listo para escalar a backend real cuando crezca.