Address Form

El lookup automático de direcciones (autocomplete contra un proveedor de datos como Google Places o un servicio postal) es la intervención más efectiva para reducir errores de captura: sin él los usuarios cometen erratas incluso al escribir su propia dirección, y la tasa de error sube en mobile por los teclados pequeños. El patrón correcto es un campo único "Empieza a escribir tu dirección" que ofrece sugerencias en tiempo real y, al elegir una, rellena el resto del formulario. Pero el lookup falla a menudo (direcciones nuevas, rurales o mal indexadas), así que un enlace "Ingresar manualmente" debe quedar siempre visible como salida, nunca esconder los campos convencionales detrás de la dependencia de un servicio externo.

Mostrar "Address Line 2" como campo permanente interrumpe el flujo aunque la mayoría de usuarios no lo necesite: por el eye-tracking el campo atrae atención desproporcionada, los usuarios se detienen, dudan de lo que ya escribieron y a veces meten datos en el campo equivocado. Baymard documenta que solo el 20% de los sitios ocultan Address Line 2, el resto lo deja siempre visible. La solución es esconderlo tras un enlace "+ Agregar departamento, suite, piso" que lo revele bajo demanda y lo marque explícitamente como opcional. Casi ningún sitio del benchmark combina ambas cosas a la vez (ocultarlo y marcarlo opcional), que es justo lo que se debe hacer.

El atributo autocomplete permite al navegador rellenar los campos y a las tecnologías asistivas identificar el propósito de cada uno (WCAG 2.1 SC 1.3.5 Identify Input Purpose, nivel AA). Los tokens deben corresponder exactamente a la semántica del campo y respetar las reglas del spec WHATWG: street-address y address-line1/2/3 son mutuamente excluyentes, las líneas solo deben estar presentes si street-address no lo está. address-level1 es el nivel administrativo más amplio (estado/provincia), address-level2 la ciudad, y country espera un código ISO 3166-1 alpha-2. En formularios con bloques de facturación y envío, prefija cada bloque con billing o shipping para que el autofill no mezcle datos.

<input autocomplete="name">
<input autocomplete="address-line1">
<input autocomplete="address-line2">
<input autocomplete="address-level2"> // ciudad
<input autocomplete="address-level1"> // estado
<input autocomplete="postal-code">
<select autocomplete="country">

<input autocomplete="off">
<input autocomplete="street-address">
<input autocomplete="address-line1">
// street-address + line1 a la vez: prohibido
<input autocomplete="name"> // en campo ciudad
<input autocomplete="zip"> // token inexistente

Existen más de 130 formatos de dirección en el mundo. Términos fijos como "ZIP code", "State" o "Address Line 1" son señales de exclusión para usuarios fuera de EE.UU.: un campo "ZIP code" inmóvil le comunica a un usuario canadiense que el servicio quizá no lo contempla. Cuando el usuario selecciona un país, el formulario debe actualizar etiquetas, orden de campos y qué campos son opcionales o requeridos, preservando siempre los datos ya ingresados. En Asia Oriental las direcciones suelen ir del área administrativa más grande (país) a la más pequeña (departamento), lo opuesto al orden occidental, y eso también debe respetarse.

El país determina la estructura completa del address form: etiquetas, número de campos, formato del código postal, presencia de estado/provincia y orden de presentación. Por eso debe ubicarse al principio, o pre-seleccionarse por geolocalización conservadora, para renderizar la estructura correcta desde el primer render. La regla de oro de la geolocalización es "menos es más": pre-rellenar solo el país evita parecer invasivo. Si el usuario cambia el país después de haber escrito, los campos deben re-adaptarse sin borrar los datos previos; nada frustra más que ver desaparecer lo que uno ya tecleó. Ubicar el país al final del formulario obliga a rehacer todo cuando no coincide.

Autocompletar ciudad y estado a partir del código postal elimina erratas y reduce el formulario percibido. La detección debe dispararse en tiempo real al completar el número de dígitos requerido (por ejemplo 5 en EE.UU. o México), no al salir del campo (blur): esperar al blur hace que el autocompletado se sienta tardío y desconectado de la acción del usuario. Los campos de ciudad y estado deben ir debajo del código postal, no encima, para que el usuario vea cómo se rellenan justo después de teclear el CP. Y siempre permitir override manual: la detección falla en CPs compartidos por varias localidades, así que los campos deben quedar editables con el valor pre-poblado.

Los códigos postales varían radicalmente: alfanuméricos (Canadá: A1A 1A1), solo numéricos (México: 5 dígitos), con o sin espacios y de distintas longitudes. Nunca apliques una máscara universal ni rechaces entradas con espacios o minúsculas, la GOV.UK recomienda aceptar postcodes en mayúsculas y minúsculas, con o sin espacios, y dejar que el backend normalice. Conviene recordar varias falsedades comunes sobre direcciones: los ZIP de EE.UU. sí pueden empezar con cero (01001), un código postal no corresponde a una sola ciudad, y no toda dirección tiene postcode. Para países sin código postal, el campo debe ser opcional o eliminarse, nunca un bloqueo.

Dividir nombre y apellido asume un modelo occidental de dos componentes que no aplica globalmente: hay personas con un solo nombre (Indonesia, Islandia), nombres compuestos, apellidos dobles y órdenes invertidos (en Asia Oriental el apellido va primero). Patrick McKenzie lo resume en sus falsedades sobre nombres: nadie tiene exactamente N nombres para ningún N, los nombres no siempre tienen un orden fijo, no todos comparten apellido con sus parientes y no todos se escriben en ASCII. Un campo único "Nombre completo" de ancho generoso captura cualquier variación sin imponer estructura. Solo separa nombre y apellido cuando el backend lo exija de forma estricta y el mercado sea homogéneo.