Formularios web que la gente sí envía

Un formulario es donde el visitante deja de leer y empieza a actuar: inscribirse en el congreso, renovar la membresía, solicitar una subvención, hacer una pregunta.

Todos esos visitantes ya decidieron actuar. Cuando se van sin enviar, fue el formulario el que los convenció de no hacerlo.

Esta guía cubre las decisiones que marcan la diferencia, en el orden en que el visitante las encuentra. Cada sección tiene un ejemplo que funciona y en el que puede escribir. Los ejemplos se ejecutan en su navegador y no envían nada, y todos los patrones de esta guía funcionan también en los formularios de este sitio.

Por qué ahora es una sola guía. Empezó como una serie de ocho partes. La reunimos en una sola página con ejemplos en vivo, porque se aprende más de un formulario rellenándolo que leyendo sobre él.

Es el primero de nuestros artículos que recibe este tratamiento. Estamos repasando todo lo que hemos publicado para que sea más breve, más fácil de recorrer y más práctico.

¿Quiere ver primero los errores? La página de las versiones rotas tiene formularios en vivo que fallan a propósito.

Cada campo necesita una etiqueta visible

Una etiqueta está fuera del campo y se queda ahí. Un placeholder está dentro del campo y desaparece en cuanto alguien escribe.

Los formularios que usan placeholders como etiquetas se ven tranquilos en una maqueta, que es el único momento en que alguien los ve vacíos. Una vez rellenos, las preguntas han desaparecido:

• Quien revisa sus respuestas antes de enviar no tiene con qué compararlas.
• Quien se interrumpe por una llamada vuelve a unas casillas que ya no dicen qué son.
• El autocompletado rellena todos los campos a la vez, y revisar pasa a ser toda la tarea del visitante. Pruébelo en el ejemplo de abajo: las etiquetas se quedan, así que revisar lleva un vistazo.

Los placeholders siguen teniendo una función: mostrar el formato de una respuesta. La etiqueta pregunta "Teléfono" y el placeholder muestra (555) 012-3456. Cuando el ejemplo desaparece, el visitante ya no lo necesita.

Para quien usa un lector de pantalla, una etiqueta vinculada a su campo en el código se anuncia cuando el campo recibe el foco. El anuncio de un placeholder depende del lector de pantalla, y nunca se pensó como el nombre del campo.

Para los organismos e instituciones públicas, una etiqueta visible es además un requisito de la norma de accesibilidad que deben cumplir, y quienes evalúan las licitaciones lo comprueban.

No espere que un verificador automático detecte esto. Las reglas que ejecutan la mayoría de las herramientas aceptan un placeholder como nombre del campo, así que un formulario solo con placeholders puede aprobar el análisis. Lo comprobamos: la versión rota de este formulario aprueba las mismas reglas automáticas que señalan su menú y su botón de envío.

Etiquetas flotantes, bien construidas

Una etiqueta flotante empieza dentro del campo, donde iría un placeholder. Sube por encima del campo cuando el visitante entra en él o escribe una respuesta.

Ahorra una línea de altura en un formulario largo, y puede hacerse bien. Hacerlo bien significa tres cosas:

• Es una etiqueta real vinculada al campo, así que se anuncia como cualquier otra.
• Se lee bien en las dos posiciones, con contraste completo, nunca atenuada al gris de un placeholder.
• Se aparta antes de que el texto del visitante pueda chocar con ella.

La mayoría de las etiquetas flotantes deciden si flotar con una sola pregunta: ¿el campo está vacío? El truco habitual en CSS comprueba si se ve el placeholder.

Esa pregunta recibe la respuesta equivocada en cuanto hay una máscara de entrada.

Cuando una máscara de entrada llena el campo

Una máscara de entrada da formato a la respuesta mientras se escribe: un teléfono se convierte en (703) 555-0142 y una fecha en 10/11/2026.

Las máscaras ayudan, hasta que sus caracteres se escriben en el campo antes de que nadie teclee. Entonces el campo nunca está vacío, y fallan tres cosas:

• Una etiqueta flotante ve (___) ___-____, decide que hay una respuesta, y salta al cargar la página o se queda encima de la máscara.
• La validación del propio formulario ve texto y puede dejar pasar un teléfono en blanco.
• Un lector de pantalla lee los guiones bajos en voz alta.

Cómo construir una máscara que funcione:

• Cuente dígitos, no caracteres. El campo está vacío hasta que tiene un dígito. La puntuación que añadió la máscara nunca es una respuesta.
• Muestre la plantilla solo mientras el campo tiene el foco, detrás del texto del visitante y fuera del valor. La etiqueta flota primero, así que nada se superpone.
• Acepte cualquier formato. Alguien pega 703.555.0142 o lo escribe con espacios. Quédese con los dígitos y deles formato usted.
• Deje el cursor donde lo puso el visitante. Una máscara que salta al final convierte cada corrección en volver a escribir.
• Deje pasar los números internacionales. Un + al principio debe desactivar la máscara de Estados Unidos. Una máscara estricta es la razón por la que la gente de otros países no puede inscribirse.
• Guarde los dígitos, no el texto con formato. El registro debe contener 7035550142, para que la búsqueda, la eliminación de duplicados y el siguiente sistema coincidan en cuál es el número.

Pida el teclado adecuado

En un teléfono, el tipo del campo decide qué teclado aparece:

• Un campo de correo pone la @ en la primera pantalla.
• Un campo de teléfono abre un teclado numérico.
• Un campo de texto genérico da al visitante el teclado completo para todo, y tiene que buscar entre pantallas de símbolos para escribir una dirección.

<input type="email" autocomplete="email" autocapitalize="off" spellcheck="false">
<input type="tel" autocomplete="tel">
<input inputmode="numeric" autocomplete="postal-code">
<input inputmode="decimal">

Los mismos atributos alimentan el autocompletado. Cuando los campos dicen qué contienen (nombre, correo, organización, código postal), el navegador ofrece rellenarlos, y la parte más lenta de un formulario móvil se convierte en un toque.

Los teclados de teléfono también ponen mayúscula a la primera letra y corrigen palabras que no conocen. Eso ayuda en un mensaje. En una dirección de correo o un número de referencia cambia la respuesta sin avisar, así que desactive las mayúsculas automáticas y el autocorrector en los campos que guardan identificadores.

El tamaño importa tanto como el teclado:

• Haga que los objetivos táctiles midan al menos 44 píxeles de alto.
• Vincule la etiqueta de cada casilla, para que también se pueda tocar el texto.
• Use texto de 16 píxeles o más en los campos. Por debajo de eso, el iPhone amplía el campo y deja la página ampliada cuando el visitante termina de escribir.

Errores que dicen cómo corregir la respuesta

Cuando una comprobación falla, el formulario sabe qué campo falló y qué regla se incumplió. "Entrada no válida" tira ese conocimiento a la basura.

Un mensaje útil nombra el campo, dice qué está mal y muestra cómo es una respuesta correcta: "Escriba un teléfono de 10 dígitos de Estados Unidos con su código de área, como 555-012-3456."

El momento también importa. Un formulario que comprueba con cada tecla llama no válido a un correo durante todo el tiempo que se está escribiendo. Compruebe cuando el visitante sale del campo, que es cuando la respuesta debería estar terminada.

Cuando un campo ya está marcado como incorrecto, compruébelo mientras se escribe, para que el mensaje desaparezca en cuanto la respuesta queda corregida. Además:

• Ponga cada mensaje junto a su campo, donde el visitante ya está mirando.
• Al enviar, liste todos los problemas arriba con un enlace a cada campo, y mueva el foco a esa lista.
• No dependa solo del color. Un borde rojo es invisible para algunas personas con daltonismo y para todos los lectores de pantalla. Las palabras, un icono y un borde más grueso llevan el mensaje.
• Vincule el mensaje al campo en el código, para que se anuncie cuando el campo recibe el foco.
• No vacíe nunca un campo por un error en otro. Una errata en el teléfono no es motivo para borrar el mensaje.

Detectar errores en el correo sin bloquear a nadie

Alguien escribe gamil.com en lugar de gmail.com. La dirección tiene un formato correcto, así que todos los validadores la aceptan.

Su respuesta, su recibo o su confirmación de inscripción no llegan a ninguna parte. Desde el lado del visitante, le escribió y usted nunca contestó.

Un pequeño porcentaje de las direcciones escritas a mano tiene una errata, y las habituales son previsibles. Cuando el visitante sale del campo:

• Compare la dirección con una lista corta de errores conocidos.
• Explique la sugerencia y ofrezca corregirla con un toque.
• Deje que el visitante conserve lo que escribió. Las direcciones poco comunes existen, y la última palabra siempre la tiene el visitante.

Muestre cada estado del botón de envío

Un botón de envío le debe al visitante cuatro estados:

• En reposo invita a pulsar.
• Enviando muestra que la pulsación llegó. El botón cambia su texto y se desactiva, para que un segundo clic nervioso no envíe el formulario dos veces.
• Fallo explica qué salió mal, junto al botón, mientras cada campo conserva lo que el visitante escribió.
• Listo sustituye el formulario por una confirmación que dice qué se recibió y qué pasa después. Esa confirmación se anuncia a los lectores de pantalla además de mostrarse.

Dedique el mayor cuidado al fallo. Si el formulario conserva las palabras del visitante, una conexión caída cuesta un clic más. Si las pierde, muy pocas personas reescriben un mensaje largo de memoria. Active el fallo simulado de arriba y pulse enviar.

Construya un formulario real debajo del script. Si el script no carga en la red estricta de una oficina, el formulario debe enviarse de la forma normal y mostrar una página de confirmación sencilla.

Cuando una solicitud se agota, diga que el resultado es desconocido. Mostrar un éxito que no le consta termina en disculpas por mensajes que nunca llegaron.

Divida los formularios largos en pasos

Una solicitud de subvención o una inscripción a un evento puede llegar a treinta preguntas. En una sola página, la barra de desplazamiento le dice al visitante cuánto trabajo le queda antes de empezar.

Dividido en pasos, el mismo formulario pide unos minutos cada vez. Esto es lo que hace que los pasos funcionen:

• Un solo tema por paso.
• Un indicador de progreso que dice la verdad: "Paso 2 de 3", nunca una barra que salta del 20 al 90 por ciento.
• Compruebe cada paso antes de seguir, para que los problemas salgan mientras las preguntas están frescas.
• Volver no pierde nada. Quien vuelve para corregir una fecha encuentra todas las respuestas posteriores donde las dejó.
• Termine con una pantalla de revisión que muestre cada respuesta con una forma de editarla, antes del envío final.
• Mueva el foco al título del nuevo paso, para que quien usa un lector de pantalla oiga dónde está.
• Intro avanza un paso. Nunca debe enviar un formulario a medias.

Guarde las respuestas para que la gente pueda volver

Pocas personas terminan un formulario largo de una sentada. Necesitan una cifra de presupuesto de finanzas, una carta de referencia, el visto bueno de un colega. Un formulario que lo olvida todo al cerrar la pestaña les obliga a empezar de nuevo, y muchas no lo harán.

Hay dos formas de guardar las respuestas. Use la que use, dígaselo a la gente: "Guardado en este dispositivo" junto al formulario es suficiente.

En un formulario corto o anónimo, guarde las respuestas en el propio navegador del visitante mientras escribe, como hace el ejemplo por pasos de arriba. Recargue esta página y sus respuestas vuelven.

• Nada sale del dispositivo, y no hace falta una cuenta.
• Un botón "Borrar mis respuestas" permite eliminarlas a quien usa un equipo compartido.
• No guarde nunca contraseñas, datos de pago ni nada delicado en el navegador.

En una solicitud larga, guarde borradores en el servidor y envíe al visitante un enlace para continuar. Proteja ese enlace:

• Envíelo solo a la dirección escrita en el formulario.
• Haga que caduque.
• Limite cuántos puede pedir un mismo visitante. Si no, la casilla para continuar se convierte en una forma de enviar su correo a desconocidos.

Fondos oscuros: avise al navegador

Su CSS da estilo a la caja, al borde y al texto de un campo. El navegador y el sistema operativo dibujan el resto: la flecha de un menú, la lista que se abre debajo, el calendario de un campo de fecha, la marca de una casilla.

Dan por hecho que la página es clara salvo que usted diga otra cosa. En un pie de página oscuro con un formulario de boletín, eso puede significar una flecha gris oscura sobre un menú casi negro, que se lee como un simple rectángulo.

Una declaración de CSS lo arregla. Ponga color-scheme en dark en la zona oscura y el navegador vuelve a dibujar su parte de cada control para que coincida.

.site-footer {
  background: #11141a;
  color-scheme: dark;
}

Después revise lo que color-scheme no cubre, a ser posible en un sistema operativo que su equipo no usa, en sus modos claro y oscuro:

• El autocompletado pinta los campos rellenos de amarillo o azul pálido, y el texto blanco se vuelve ilegible.
• El gris de los placeholders se eligió para fondos blancos.
• Un anillo de foco que era evidente sobre blanco puede desaparecer sobre negro.

Frene el spam sin acertijos

Un CAPTCHA convierte su problema de spam en una tarea del visitante. Es más duro con quien tiene baja visión, manos lentas o un lector de pantalla.

Casi todo el spam de formularios es automático y descuidado, así que tres comprobaciones que el visitante nunca ve frenan casi todo:

• Un honeypot: un campo extra oculto para las personas y los lectores de pantalla. Los bots rellenan todos los campos, así que un honeypot relleno marca el envío como spam.
• Un temporizador: nadie contesta un formulario de contacto dos segundos después de cargar la página.
• Un límite de frecuencia: treinta envíos por minuto desde una misma dirección no son treinta personas.

Lo que pasa esas comprobaciones lo escribió una persona. Márquelo para revisión en lugar de bloquearlo, para que un falso positivo nunca pierda un mensaje real.

Muestre a todos la misma confirmación, para que quien maneja un bot no aprenda nada de la respuesta.

Lo que pasa después del botón

Nadie rellena un formulario para ver una pantalla de confirmación. Quiere una respuesta, y todo lo que hay entre enviado y respondido es un segundo sistema que falla más que cualquier botón.

Lo habitual es un formulario que envía un correo a un buzón, y ese correo es la única copia. Si un filtro de spam lo atrapa, o el destinatario cambió de puesto la primavera pasada, la consulta se pierde sin rastro.

Guarde primero y avise después.

Después, asegúrese de que los avisos sigan llegando:

• Envíelos desde su propio dominio autenticado, con la dirección del visitante como respuesta, para que pasen los controles que aplican los proveedores de correo.
• Dé a la ruta del formulario un responsable con nombre, y revísela cada vez que alguien cambia de puesto.
• Vigile el silencio. Un formulario que recibía cinco envíos por semana y lleva tres semanas sin ninguno está roto, aunque todas las páginas carguen.
• Programe un envío de prueba que recorra toda la cadena, del formulario al buzón que lee el personal. Detecta lo que la supervisión de disponibilidad no ve.

Pruebe las versiones rotas

Leer sobre un placeholder que desaparece no es lo mismo que rellenar un formulario y perder la cuenta.

La página de versiones rotas tiene formularios en vivo con los errores de los que avisa esta guía. Cada uno se explica antes de empezar, y cada uno enlaza con su versión corregida aquí.

Por qué es una página aparte. Exigimos a cada página de LFW.com una puntuación perfecta en las comprobaciones automáticas de accesibilidad, y el sitio se analiza cada noche. Unos formularios que fallan a propósito romperían esa regla en la propia guía.

Por eso los fallos viven en una sola página, y cada uno se excusa con precisión: una regla, en un elemento, en esa única página. Cualquier otra cosa que falle allí sigue dando la alarma, y la página conserva su puntuación real, más baja. Además, queda fuera de los resultados de búsqueda.

Si quiere saber cómo están sus propios formularios, la auditoría gratuita revisa los campos de su página de inicio: etiquetas, contraste y las demás reglas automáticas de accesibilidad.

También construimos y corregimos formularios para organizaciones con sitios web en WordPress. Háblenos de sus formularios.