Respuesta corta: Un buen formulario de contacto pide solo lo necesario: por lo general un nombre, el correo o el teléfono por el que vas a responder y un mensaje corto. Dale a cada campo una etiqueta visible y marca cuáles son obligatorios. Usa el tipo de campo correcto para que el teléfono muestre el teclado adecuado y el navegador pueda rellenarlo, y confirma con claridad cuando el formulario se envía.
Qué debe pedir un formulario de contacto
La forma más sencilla de hacer un formulario más fácil es quitar los campos que no necesitas. web.dev agrega que menos campos son mejores para la privacidad y pueden reducir el costo y la responsabilidad de los datos que guardas.
Para el nombre, web.dev recomienda un solo campo, salvo que tengas una buena razón para guardar sus partes por separado. Para el correo y el teléfono, usa type="email" y type="tel": el teléfono muestra el teclado que corresponde y el navegador hace comprobaciones básicas. No uses type="number" para el teléfono: web.dev señala que agrega flechas para subir y bajar el número, que ahí no tienen sentido.
Cómo hacer cada campo
| Campo | Cómo hacerlo | Nuestro formulario |
|---|---|---|
| Nombre | Un campo con etiqueta visible y autocomplete="name" | Un campo «Nombre completo», obligatorio |
| Correo | type="email" y autocomplete="email" | Obligatorio, con el teclado de correo en el teléfono |
| Teléfono | type="tel" y autocomplete="tel" | Obligatorio, con el teclado numérico en el teléfono |
| Mensaje | Un área de texto para la solicitud | «¿Qué necesitas?», opcional |
| Botón de envío | Desactivado al hacer clic, porque mucha gente hace clic más de una vez | Desactivado hasta que responde nuestro servidor |
| Control de bots | Un campo oculto o una prueba de trabajo, no un acertijo | Un campo oculto y una prueba de trabajo |
De web.dev, «Payment and address form best practices», y del tutorial de formularios de la W3C, en inglés, consultados el 3 de noviembre de 2026. La última columna es nuestro formulario ese día.
Cómo hacer un formulario de contacto que la gente complete
- Haz una lista de lo que necesitas para responder una solicitud y quita los demás campos.
- Dale a cada campo una etiqueta visible, no solo un texto de ejemplo dentro del cuadro.
- Marca qué campos son obligatorios y cuáles opcionales, y dilo antes del formulario.
- Usa type="email" y type="tel", con sus valores de autocomplete, para que el navegador pueda rellenar los campos.
- Revisa cada campo mientras la gente lo llena y explica cada error junto a su campo, con palabras sencillas.
- Muestra un mensaje claro cuando el formulario se envía, para que la gente sepa que funcionó.
- Envía una prueba desde tu teléfono y comprueba que el mensaje te llega.
Las comprobaciones del navegador ayudan a corregir errores, pero la W3C señala que se pueden saltar, así que los datos se deben revisar también en el servidor.
Si tu formulario pide permiso para enviar mensajes de texto, nuestra guía de la TCPA explica las reglas del consentimiento. Nuestra guía de accesibilidad web y ADA explica el resto de un sitio accesible.
El formulario de nuestra web
Revisamos nuestro formulario de solicitud de auditoría el 3 de noviembre de 2026, en inglés y en español. Cada campo tiene una etiqueta visible, y los obligatorios llevan un asterisco y el atributo required. El nombre va en un solo campo, «Nombre completo».
El campo de teléfono usa type="tel" y el de correo type="email", cada uno con su valor de autocomplete. Una casilla obligatoria pide permiso para contactar a la persona sobre su solicitud, y otra aparte, opcional, cubre los mensajes de texto de marketing. Al enviarlo, el botón queda desactivado y marcado como ocupado hasta que responde nuestro servidor, así que un segundo clic no lo envía dos veces.
Para frenar a los bots, el formulario lleva un campo que la gente nunca ve y una prueba de trabajo. El navegador del visitante la resuelve en segundo plano en más o menos un segundo en un teléfono, y no le pide nada al visitante.
Antes de publicar el formulario
- Cada campo es uno que necesitas para responder.
- Cada campo tiene una etiqueta visible.
- Los campos obligatorios están marcados, y la gente lo sabe antes de empezar.
- Los campos de correo y teléfono usan su propio tipo y autocomplete.
- Los errores dicen qué falló y cómo corregirlo.
- Una prueba enviada desde tu teléfono llegó a tu bandeja.
RecuerdaPide menos, ponle etiqueta a todo y confirma con claridad que el mensaje llegó.
Si quieres una web cuyos formularios te traigan contactos, mira nuestro servicio de diseño web.
Respuestas rápidas sobre los formularios de contacto
¿Qué campos debe tener un formulario de contacto?
Solo los que necesitas para responder: por lo general un nombre, el correo o el teléfono por el que vas a responder y un mensaje corto. web.dev señala que quitar campos también ayuda a la privacidad y puede reducir el costo y la responsabilidad de los datos que guardas.
¿El nombre va en un campo o en dos?
En uno, salvo que tengas una buena razón para guardar el nombre y el apellido por separado. web.dev recomienda un solo campo de nombre, que simplifica el formulario y sirve para nombres que no se dividen en dos partes.
¿El texto de ejemplo puede reemplazar a la etiqueta?
No. web.dev advierte que el texto de ejemplo desaparece en cuanto alguien empieza a escribir, así que es fácil olvidar para qué es el campo. La W3C agrega que la mayoría de la gente prefiere, o necesita, etiquetas visibles para entender un formulario.
¿Debo poner un CAPTCHA en mi formulario de contacto?
Prueba antes otras opciones. Una nota de la W3C dice que la tarea que pide un CAPTCHA excluye a muchas personas con discapacidad. También dice que las técnicas de CAPTCHA más populares ya no son especialmente eficaces. Describe otras opciones, como campos ocultos que solo llenan los robots y las pruebas de trabajo.
¿Qué debe pasar después de enviar el formulario?
Dile a la persona con claridad si funcionó. La W3C pide una respuesta breve al enviar un formulario: mensajes de error que expliquen cómo corregir el problema, y un mensaje de éxito que confirme que la tarea está hecha.
Fuentes
Consultadas el 3 de noviembre de 2026, en inglés. W3C Web Accessibility Initiative: Labeling Controls, Form Instructions, Validating Input y User Notification. También de la W3C: Understanding Success Criterion 1.3.5: Identify Input Purpose e Inaccessibility of CAPTCHA. web.dev: Payment and address form best practices. Nuestro caso: nuestro formulario de solicitud de auditoría, leído como visitante el 3 de noviembre de 2026.