form-design

Diseño de formularios

Un formulario es una conversación en la que la organización pide algo y la persona paga en tiempo, esfuerzo y riesgo. Funciona cuando cada pregunta se gana su lugar, cada respuesta se puede dar en los términos de la persona y cada error se detecta a tiempo, se explica en su lugar y se puede corregir sin perder el trabajo realizado. El fallo de modelo más común es un formulario que parece terminado y no lo está: etiquetas como marcadores de posición, campos obligatorios inventados, type="number" para números de tarjeta, sin autocomplete, errores solo como burbujas del navegador o bordes rojos, un botón de envío que dice "Enviar" y un camino de éxito que fue el único probado.

Aplica los principios jerarquizados de interface-guidelines (todo el mundo puede usarlo > dice la verdad > dice lo que significa > la respuesta es lo primero > los errores son recuperables > permanece en su lugar > lo posible es visible > convención > refinamiento). Si ese skill está instalado, lee su SKILL.md primero. Su references/human-interface.md sección 3 contiene las reglas básicas de formularios (etiquetas visibles, marcado de opcionales, pegado, temporización de validación, botón de envío deshabilitado, comportamiento de guardado); este skill va más allá y no las repite.

Resumen

Responde estas preguntas antes de dibujar un campo. Escríbelas si el formulario tiene más de cinco preguntas.

• ¿Para qué sirve cada respuesta? Nombra la decisión o acción que la utiliza. Un campo sin uso nombrado se elimina.
• ¿Quién responde, con qué frecuencia, en qué dispositivo? Un solicitante único en un teléfono, o un empleado que introduce 200 registros al día en un escritorio. Esto decide una cosa por página frente a una página densa.
• ¿De quién son los datos? De la propia persona (aplica autocompletado, WCAG 1.3.5 aplica) o de otra persona (un destinatario, un paciente, un cliente introducido por el personal).
• ¿Tienen la respuesta a mano? Número de pasaporte, ID de póliza, ingresos del año pasado. Si no, díselo de antemano qué reunir y permite guardar.
• ¿Qué cuesta una respuesta incorrecta y qué es irreversible una vez enviado (pago, declaración legal, publicación pública)?
• ¿Dónde están los encuestados? Países, escrituras, formatos de dirección, formatos de teléfono, estructuras de nombre.
• ¿Qué puede saber ya el sistema? Nunca lo preguntes (WCAG 3.3.7).
• Lector agente: ¿un agente rellenará esto para alguien (extensiones de autocompletado, agentes de navegador, asistentes)? Asume que sí para cualquier cosa pública.

Reglas

Pregunta menos

• Elimina campos antes de diseñarlos. Cada campo debe tener un uso nombrado ahora, no "podría ser útil". Baymard encuentra que el proceso de pago medio tiene 11,3 campos donde 8 bastan; el número de campos duele más que el número de pasos. [P: Baymard 2024]
• Recoge el nombre completo en un solo campo a menos que las partes impulsen un comportamiento específico (ordenación, dirección formal). Muchos nombres no se dividen en nombre y apellido. Nunca exijas un apellido. [S: W3C i18n; P: Baymard]
• Oculta los campos poco usados detrás de un enlace, no como entrada obligatoria: línea 2 de dirección, empresa, código de cupón. [P: Baymard]
• Establece la dirección de facturación por defecto como la de envío con una casilla marcada que oculta los campos de facturación. [P: Baymard]
• Ofrece la creación de cuenta después de la transacción, no como una barrera antes. [P: Baymard]
• Permite "No sé" donde sea una respuesta válida, en lugar de forzar una suposición. [S: páginas de preguntas de GOV.UK]
• Deriva lo que puedas: ciudad y región a partir del código postal donde sea fiable, tipo de tarjeta a partir del número, país a partir de la búsqueda de dirección. Mantén los valores derivados visibles y editables. [P: Baymard]

Estructura y flujo

• Elige la forma según el resumen, no por costumbre. Tareas raras, estresantes o desconocidas: una pregunta por página, con la pregunta como h1/legend. Entrada frecuente de expertos: una página, agrupada, rápida con teclado. GOV.UK comienza cada servicio con una cosa por página y fusiona solo cuando la investigación lo dice. [S: estructura de formularios de GOV.UK]
• Ordena las preguntas como la persona piensa en ellas, primero las más fáciles y seguras, y ramifica para que nadie vea una pregunta que no pueda aplicarse. [S: GOV.UK; J]
• Di lo que la persona necesitará antes de empezar (documentos, tiempo, costo) y qué sucede después. [S: páginas de inicio de GOV.UK]
• Los formularios largos de varias sesiones tienen una lista de tareas con estados claros y guardar y volver. Úsala solo cuando las personas no puedan terminar en una sola sesión o deban elegir su propio orden. [S: lista de tareas de GOV.UK]
• Atrás funciona. Incluye un enlace Atrás en las páginas de preguntas y nunca rompas el botón Atrás del navegador; al volver, las respuestas anteriores se muestran ya rellenadas. [S: GOV.UK]
• Termina los flujos con consecuencias con una página de revisión de respuestas: cada respuesta con un enlace Cambiar cuyo nombre accesible nombre el campo ("Cambiar fecha de nacimiento"), que vuelva al resumen después de la edición. [S: GOV.UK revisar respuestas; WCAG 3.3.4]
• Los diseños de varias columnas rompen el orden de lectura para personas y agentes. Una columna, excepto campos cortos naturalmente emparejados (mes y año de caducidad, ciudad y código postal). [P: Baymard, Wroblewski; J]

Etiquetas, sugerencias y agrupación

• Etiqueta encima del campo. La ventaja de velocidad reportada por Penzo 2006 proviene de una prueba pequeña e informal de seguimiento ocular y fue contradicha por Das 2008; elige etiquetas superiores porque sobreviven a pantallas estrechas, traducciones largas y zoom, no porque sean las más rápidas probadas. [E, débil: Penzo 2006, Das 2008]
• Las sugerencias van entre la etiqueta y el campo y están vinculadas con aria-describedby. Los ejemplos de formato ("Por ejemplo, 27 3 2007") pertenecen a la sugerencia, nunca al marcador de posición. [S: GOV.UK]
• Agrupa controles relacionados con fieldset y legend: cada conjunto de radios, casillas y respuesta de varias partes (fecha, caducidad de tarjeta). La leyenda es la pregunta. [S: WCAG 1.3.1; GOV.UK]
• En una página de una pregunta, la etiqueta o leyenda es el encabezado de la página para que los lectores de pantalla lo escuchen una vez. [S: páginas de preguntas de GOV.UK]
• Marca los campos opcionales con "(opcional)" y no uses asteriscos para los obligatorios. Si la mayoría de los campos son opcionales, pregúntate si pertenecen. [S: GOV.UK]

Tipos de entrada y autocompletado

• Establece autocomplete en cada campo sobre la persona, con el token exacto de WHATWG (given-name, email, postal-code, cc-number, one-time-code, new-password). Permite el autocompletado del navegador, los gestores de contraseñas y el rellenado de agentes, y es un requisito WCAG 1.3.5. autocomplete="off" en datos personales es un defecto. [S: autocompletado WHATWG; WCAG 1.3.5]
• Usa type para el significado e inputmode para el teclado. type="email", type="tel", type="url" donde apliquen. Los identificadores compuestos de dígitos (tarjeta, código postal, cuenta, código) son type="text" inputmode="numeric", nunca type="number", que elimina ceros iniciales, cambia al desplazarse, redondea valores largos y confunde el software de dictado. [S: GOV.UK 2020; MDN]
• Controles nativos primero. select para una lista cerrada de aproximadamente una docena de opciones, radios para unas pocas opciones que la gente debe comparar, un combobox con autocompletado para listas largas como países. Los menús desplegables personalizados ocultan sus opciones a los agentes. [S: APG; P: prueba en interface-guidelines]
• Las fechas memorables son tres campos de texto (día, mes, año) con tokens bday-* para fechas de nacimiento, que aceptan nombres de mes. Los selectores de fecha son adecuados solo para fechas que las personas eligen en relación con un calendario. [S: entrada de fecha de GOV.UK]
• Dimensiona el campo al tamaño esperado de la respuesta. Una caja de código postal tan ancha como una caja de calle da una pista equivocada. [S: GOV.UK; J]
• Acepta respuestas en el formato de la persona: espacios y guiones en números de tarjeta y teléfono, cualquier mayúscula/minúscula en códigos postales, nombres de mes, espacios al principio o final. Normaliza en el servidor. [S: GOV.UK]
• Los patrones campo por campo (nombres, direcciones por país, teléfono, dinero, tarjetas, archivos) están en references/fields.md.

Validación y errores

• Valida al enviar por defecto; en línea solo después de que la persona haya dejado un campo que haya terminado, y elimina un error tan pronto como se corrija. Nunca marques en la primera pulsación de tecla. La evidencia entra en conflicto: Bargas-Avila 2007 encontró que los errores listados después de la finalización superaban a los errores inmediatos; Wroblewski 2009 encontró que la validación en línea al perder el foco ayudaba (n=22). GOV.UK valida al enviar; Baymard recomienda al perder el foco y eliminar errores a la corrección. Decide según la longitud del formulario y lo comprobable que sea el campo por sí solo. [E: Bargas-Avila 2007; E, débil: Wroblewski 2009; S: GOV.UK; P: Baymard]
• En un envío fallido: conserva cada respuesta, pon un resumen de errores en la parte superior con un enlace por problema a su campo, mueve el foco al resumen, antepone al título de la página "Error: " y muestra la misma redacción junto a cada campo. [S: resumen de errores de GOV.UK; WCAG 3.3.1]
• Vincula cada mensaje a su campo con aria-describedby (añade aria-errormessage si quieres; su soporte en lectores de pantalla aún es desigual) y establece aria-invalid="true". El mensaje debe ser texto visible: los serializadores de agentes descartan aria-invalid pero conservan el texto adyacente. [S: WCAG 3.3.1; P: Roselli 2023; P: prueba en interface-guidelines]
• Desactiva las burbujas de validación del navegador (novalidate) y renderiza los mensajes en la página. Las burbujas desaparecen, no se pueden enlazar desde un resumen y no son texto de página. La validación del servidor sigue siendo autoritaria. [S: validación de GOV.UK]
• Escribe errores que digan cómo solucionarlo, específicos de la causa: "Introduce una fecha de nacimiento en el pasado", no "Fecha inválida". Un mensaje por causa (vacío, formato incorrecto, fuera de rango), en las palabras del formulario. [S: mensaje de error de GOV.UK; WCAG 3.3.3]
• Una condición que la persona no puede solucionar editando (no elegible, cuenta bloqueada, servicio inactivo) es una página con el motivo y el siguiente paso, no un error de campo. [S: GOV.UK]

Inicio de sesión, contraseñas, passkeys

• Permite que los gestores de contraseñas y el pegado funcionen. autocomplete="username" y current-password o new-password; nunca bloquees el pegado; no maxlength por debajo de 64; ofrece Mostrar contraseña; elimina el campo de confirmación de contraseña cuando se ofrece Mostrar. [S: NIST SP 800-63B-4 3.1.1.2; entrada de contraseña de GOV.UK; WCAG 3.3.8]
• Sin reglas de composición, sin caducidad periódica, sin pistas. Verifica las nuevas contraseñas contra listas de filtraciones conocidas y explica por qué se rechazó una. [S: NIST SP 800-63B-4]
• Ofrece passkeys sin forzar una elección desde el principio: mantén el campo de nombre de usuario, añade autocomplete="username webauthn" y una solicitud condicional de WebAuthn, luego ofrece la creación de passkey después de un inicio de sesión con contraseña. [S: autocompletado WHATWG; P: web.dev passkey autofill]
• Códigos de un solo uso: un campo, autocomplete="one-time-code", inputmode="numeric", se acepta pegar. Las cajas divididas de un solo dígito que rechazan un código pegado fallan WCAG 3.3.8. [S: WCAG 3.3.8]
• No digas cuál de usuario o contraseña era incorrecto. [S: contraseñas de GOV.UK]
• No bloquees el inicio de sesión con un CAPTCHA de acertijo. Los acertijos de texto y lógica fallan WCAG 3.3.8 sin una alternativa no cognitiva. [S: WCAG 3.3.8]

Envío

• El botón de envío nombra el resultado: "Crear cuenta", "Pagar 42,00 €", "Enviar solicitud". "Continuar" entre pasos; "Guardar y continuar" solo si se guardó. [S: botón de GOV.UK; base]
• Los envíos legales, financieros y de eliminación de datos son reversibles, verificados o confirmados con un paso de revisión (WCAG 3.3.4). La revisión muestra exactamente lo que se enviará y lo que cuesta. [S: WCAG 3.3.4]
• El envío es idempotente: deshabilita la nueva entrada mientras está en curso, muestra progreso en el botón y protege en el servidor con una clave de idempotencia. Un reintento después de un tiempo de espera no debe cobrar dos veces. [S: botón de GOV.UK; P: idempotencia de Stripe]
• La página de confirmación indica qué sucedió, un número de referencia y qué sucede a continuación, y sobrevive a una recarga. Un toast no es un recibo. [S: páginas de confirmación de GOV.UK; base]

Para el lector agente

• Cada control tiene un nombre programático que coincide con su etiqueta visible, y sus opciones son enumerables (select nativo, radios visibles). [J]
• Las restricciones son texto visible antes del envío (formato, longitud, valores permitidos), no solo en un atributo pattern. [J]
• Los errores son texto junto al campo y en un resumen, estables hasta que se corrigen. [J]
• La URL o encabezado de cada paso indica dónde está el agente en el flujo; existen caminos Atrás y Cambiar. [J]
• El texto escrito por terceros (prellenado desde un correo electrónico, una nota de referencia) se muestra como datos citados, nunca como etiqueta o instrucción. [J]
• Los envíos con consecuencias mantienen la autoridad en el servidor: una página de revisión ayuda a las personas; no detiene a un agente que haga clic a través de ella. [J]

Orden de construcción

1. Enumera las preguntas con el uso de cada respuesta; elimina aquellas sin uso.
2. Elige la forma: una página, una cosa por página o lista de tareas. Esboza la ramificación.
3. Escribe el texto: preguntas, sugerencias, cada mensaje de error por causa, etiquetas de botones, confirmación.
4. Construye con elementos nativos: label for, fieldset/legend, type correcto, inputmode, autocomplete, novalidate.
5. Validación del servidor y envío idempotente, luego validación del cliente con los mismos mensajes.
6. Estado de error: resumen, foco, prefijo de título, mensajes en línea, entrada conservada.
7. Páginas de revisión de respuestas y confirmación; guardar y volver si es de varias sesiones.
8. Estilo al final; la marca es dueña del aspecto (brand-identity).

Verificar

• node <form-design>/scripts/form-check.mjs <url|file|dist> --try-submit contra una compilación local o de prueba. Comprueba nombres y etiquetas visibles, validez y propósito de autocompletado, tipos de entrada, pegado, radios nativos ocultos, leyendas de grupo, cableado de errores, foco después de un envío fallido y redacción de envío. Los errores salen con código 1. --try-submit realmente envía: nunca lo apuntes a producción.
• node <interface-guidelines>/scripts/audit.mjs <url|dist> para la auditoría renderizada general (contraste, objetivos, teclado, reflujo, estabilidad del agente).
• Rellénalo con un gestor de contraseñas y autocompletado del navegador en un perfil real: cada campo personal se rellena y nada termina en la caja equivocada.
• Rellénalo solo con teclado y a 320 px con texto al 200 %.
• Rellénalo como un agente solo desde la instantánea de accesibilidad: encuentra cada campo por nombre, lee cada opción, envía incorrectamente, lee los errores, corrígelos, termina.
• Datos incorrectos: un nombre de una palabra, un nombre de 60 caracteres con apóstrofe y acentos, una dirección en Japón y otra en Irlanda sin código postal, un número de tarjeta pegado con espacios, un doble clic en enviar, un tiempo de espera de sesión en medio del flujo.

Trampas

• Marcador de posición como etiqueta, o una etiqueta flotante que se encoge dentro del borde y falla el contraste.
• type="number" para tarjeta, teléfono, código postal o códigos.
• autocomplete="off" en campos que piden los datos de la persona.
• Un botón de envío deshabilitado sin explicación visible de por qué.
• Validación solo en el servidor, o solo en el cliente.
• Varias columnas en un flujo de una cosa por página.
• Una lista de tareas para un formulario de una sola sesión.
• Un enlace "Atrás" que borra las respuestas o retrocede más de un paso.
• Una página de revisión que no muestra lo que se va a enviar.
• Errores que dicen "Campo inválido" sin decir qué está mal ni cómo arreglarlo.