Codelab de prácticas recomendadas para el formulario de dirección

Sam Dutton

Para seguir este codelab, abre esta falla en una segunda pestaña.

¿Cómo puedes diseñar un formulario que funcione bien para una variedad de nombres y formatos de dirección? Los errores de formulario menores molestan a los usuarios y pueden hacer que abandonen tu sitio o se renuncien a completar una compra o registrarse.

En este codelab, se muestra cómo compilar un formulario fácil de usar y accesible que funcione bien para la mayoría de los usuarios.

Paso 1: Aprovecha al máximo los elementos y atributos HTML

Comenzarás esta parte del codelab con un formulario vacío, solo un encabezado y un botón. Luego, comenzarás a agregar entradas. (ya se incluyen CSS y algo de JavaScript).

• Haz clic en Remix to Edit para que el proyecto sea editable.

• Agrega un campo de nombre a tu elemento <form> con el siguiente código:

<section>
  <label for="name">Name</label>
  <input id="name" name="name">
</section>

Esto puede parecer complicado y repetitivo para un solo campo de nombre, pero ya es bastante.

Asociaste el label con el input haciendo coincidir el atributo for de label con el name o el id de input. Cuando presionas o haces clic en una etiqueta, el enfoque se mueve a la entrada, lo que genera un objetivo mucho más grande que la entrada por sí sola, lo que es bueno para los clics con los dedos, los pulgares y el mouse. Los lectores de pantalla anuncian el texto de la etiqueta cuando esta o la entrada de esta se enfocan.

¿Y name="name"? Este es el nombre (que es "name") asociado con los datos de esta entrada, que se envía al servidor cuando se envía el formulario. La inclusión de un atributo name también significa que la API de FormData también podrá acceder a los datos de este elemento.

Paso 2: Agrega atributos para ayudar a los usuarios a ingresar datos

¿Qué sucede cuando presionas o haces clic en la entrada Nombre en Chrome? Deberías ver las sugerencias de autocompletado que el navegador almacenó y las suposiciones que son adecuadas para esta entrada, dada sus valores de name y id.

Ahora, agrega autocomplete="name" a tu código de entrada para que se vea de la siguiente manera:

<section>
  <label for="name">Name</label>
  <input id="name" name="name" autocomplete="name">
</section>

Vuelve a cargar la página en Chrome y presiona o haz clic en la entrada Nombre. ¿Qué diferencias ves?

Nota: ¿Alguna vez te preguntaste cómo borrar las sugerencias de Autocompletar en Chrome? * En Windows: Shift + delete * Mac: Shift + fn + delete

Deberías notar un cambio sutil: con autocomplete="name", las sugerencias ahora son valores específicos que se usaron antes en entradas de formularios que también tenían autocomplete="name". El navegador no solo está adivinando qué podría ser apropiado: tú tienes el control. También verás la opción Administrar... para ver y editar los nombres y las direcciones almacenados por tu navegador.

IU para autocompletar con valores adivinados en comparación con autocompletar.

Nota: Si hay disponible un valor de autocompletado apropiado para una input, select o textarea, debes usarlo.

Ahora agrega atributos de validación de restricciones maxlength, pattern y required para que tu código de entrada se vea de la siguiente manera:

<section>
  <label for="name">Name</label>
  <input id="name" name="name" autocomplete="name"
    maxlength="100" pattern="[\p{L} \-\.]+" required>
</section>

• maxlength="100" significa que el navegador no permitirá ninguna entrada de más de 100 caracteres.

• pattern="[\p{L} \-\.]+" usa una expresión regular que permite caracteres de letras Unicode, guiones y puntos (puntos completos). Eso significa que los nombres como Françoise o Jörg no se clasifican como "no válidos". Ese no es el caso si usas el valor \w, que [solo permite caracteres del leto latino.

• required significa... obligatorio. El navegador no permitirá que se envíe el formulario sin datos en este campo, y advertirá y destacará la entrada si intentas enviarla. No se requiere ningún código adicional.

Precaución: Este codelab no aborda la localización ni la internacionalización (Bloque). Según el lugar en el que se encuentren los usuarios, deberás considerar los formatos de las direcciones, así como los diferentes nombres que se usan para los componentes de las direcciones, incluso si están dentro del mismo idioma (código postal, Eircode o PIN). Tal vez sea necesario que tu sitio se personalice para varias configuraciones regionales, pero el formulario de dirección de este codelab está diseñado para ofrecer flexibilidad y debería funcionar "lo suficientemente bien" para un rango de direcciones.

Para probar el funcionamiento del formulario con y sin estos atributos, prueba ingresar datos:

• Intenta ingresar valores que no se ajusten al atributo pattern.
• Intenta enviar el formulario con una entrada vacía. Verás una advertencia de funcionalidad del navegador integrada de campo obligatorio vacío y la configuración de enfoque en él.

Paso 3: Agrega un campo de dirección flexible al formulario

Para agregar un campo de dirección, agrega el siguiente código a tu formulario:

<section>
  <label for="address">Address</label>
  <textarea id="address" name="address" autocomplete="address"
    maxlength="300" required></textarea>
</section>

Un textarea es la forma más flexible que tiene los usuarios de ingresar su dirección y es excelente para cortar y pegar.

Evita dividir tu formulario de dirección en componentes como el nombre de la calle y el número, a menos que sea necesario. No fuerces a los usuarios a tratar de incluir su dirección en campos que no tengan sentido.

Nota: Considera la forma en que se usan los datos de tu formulario. ¿Para qué sirve? Asegúrate de comprender los requisitos de los datos y quién los establece.

Ahora, agrega campos para Código postal y País o región. Para simplificar, aquí solo se incluyen los primeros cinco países. En el formulario de dirección completo, se incluye una lista completa.

<section>
  <label for="postal-code">ZIP or postal code (optional)</label>
  <input id="postal-code" name="postal-code"
    autocomplete="postal-code" maxlength="20">
</section>

<section id="country-region">
  <label for="">Country or region</label>
  <select id="country" name="country" autocomplete="country"
    required>
      <option selected value="SPACER"> </option>
      <option value="AF">Afghanistan</option>
      <option value="AX">Åland Islands</option>
      <option value="AL">Albania</option>
      <option value="DZ">Algeria</option>
      <option value="AS">American Samoa</option>
  </select>
</section>

Verás que el código postal es opcional, ya que muchos países no utilizan códigos postales. (Global Sourcebook proporciona información sobre los formatos de dirección para 194 países diferentes, incluidas direcciones de muestra). Se usa la etiqueta País o región en lugar de País, ya que algunas opciones de la lista completa (como el Reino Unido) no son países únicos (a pesar del valor autocomplete).

Paso 4: Permite que los clientes ingresen fácilmente direcciones de envío y facturación

Creaste un formulario de dirección altamente funcional, pero ¿qué pasa si tu sitio requiere más de una dirección, por ejemplo, para envío y facturación? Intenta actualizar el formulario para permitir que los clientes ingresen direcciones de envío y facturación. ¿Cómo puedes hacer que el ingreso de datos sea lo más rápido y fácil posible, en especial si las dos direcciones son iguales? En el artículo que se incluye en este codelab, se explican las técnicas para manejar varias direcciones. Hagas lo que hagas, asegúrate de usar los valores de autocomplete correctos.

Paso 5: Agrega un campo de número de teléfono

Para agregar una entrada de número de teléfono, agrega el siguiente código al formulario:

<section>
  <label for="tel">Telephone</label>
  <input id="tel" name="tel" autocomplete="tel" type="tel"
    maxlength="30" pattern="[\d \-\+]+" enterkeyhint="done"
    required>
</section>

En el caso de los números de teléfono, usa una sola entrada; no dividas el número en partes. Eso facilita que los usuarios ingresen datos o copien y peguen, y simplifica la validación y permite que los navegadores completen el autocompletado.

Existen dos atributos que pueden mejorar la experiencia del usuario cuando ingresa un número de teléfono:

• type="tel" garantiza que los usuarios de dispositivos móviles puedan utilizar el teclado correcto.
• enterkeyhint="done" establece la etiqueta de la tecla Intro del teclado del dispositivo móvil para mostrar que este es el último campo y que el formulario ahora se puede enviar (el valor predeterminado es next).

Usa el atributo enterkeyhint para configurar la etiqueta del botón Intro: "next" y "done".

Si usas type="number", se agrega una flecha hacia arriba o hacia abajo para aumentar la cantidad de números, lo que no tiene sentido para datos como números de teléfono, tarjetas de pago o números de cuenta. En cambio, debes usar type="tel" para los números de teléfono. Para otros números, usa type="text" (o no incluyas el atributo, ya que text es el valor predeterminado) y agrega inputmode="numeric" para obtener un teclado numérico en dispositivos móviles.

Nota: ¿Crees que tienes problemas para usar una sola entrada para el número de teléfono? ¿Guardas las partes de los números de teléfono (código de país y de área) por separado? Si es así, ¿por qué?

Tu formulario de dirección completo debería verse de la siguiente manera:

• Prueba el formulario en diferentes dispositivos. ¿A qué dispositivos y navegadores orientas? ¿Cómo se podría mejorar el formulario?

Existen varias formas de probar un formulario en diferentes dispositivos:

• Usa Device Mode de las Herramientas para desarrolladores de Chrome para simular dispositivos móviles.
• Envía la URL de tu computadora a tu teléfono.
• Usa un servicio como BrowserStack para realizar pruebas en una variedad de dispositivos y navegadores.

Nota: Antes de comenzar a crear formularios, asegúrate de comprender qué datos se necesitan y si son estrictamente necesarios. ¡No pidas datos que no necesitas! La forma más sencilla de reducir la complejidad de los formularios y mejorar la privacidad es quitar los campos innecesarios. Almacenar menos datos también reduce el costo y la responsabilidad de los datos de backend.

Un paso más allá

• Analytics y supervisión de usuarios reales: Permite probar y supervisar el rendimiento y la usabilidad del diseño de formulario para usuarios reales, y verificar si los cambios se realizaron correctamente. Debes supervisar el rendimiento de la carga y otras Métricas web, además de las estadísticas de la página (¿qué porcentaje de usuarios rebota en el formulario de dirección sin completarlo? ¿Cuánto tiempo pasan los usuarios en las páginas de tu formulario de dirección?) y las estadísticas de interacción (con qué componentes de la página interactúan los usuarios o no).

• ¿Dónde se encuentran tus usuarios? ¿Qué formato deben tener las direcciones? ¿Qué nombres usan para los componentes de las direcciones, como el código postal? En la Guía compulsiva de Francisco sobre direcciones postales, encontrarás vínculos útiles y una amplia orientación en la que se detallan los formatos de dirección en más de 200 países.

• Los selectores de país tienen mala fama por su usabilidad deficiente. Es mejor evitar seleccionar elementos para una larga lista de elementos, y el estándar de código de país ISO 3166 actualmente enumera 249 países. En lugar de <select>, te recomendamos que consideres una alternativa, como el selector de país de Baymard Institute.

  ¿Puedes diseñar un mejor selector para listas con muchos elementos? ¿Cómo garantizarías que tu diseño sea accesible en una variedad de dispositivos y plataformas? (El elemento <select> no funciona bien en una gran cantidad de elementos, pero al menos se puede usar en casi todos los navegadores y dispositivos de asistencia).

  En la entrada de blog <input type="country" />, se analiza la complejidad de estandarizar un selector de país. La localización de nombres de países también puede ser un problema. Listas de países tiene una herramienta para descargar códigos y nombres de países en varios idiomas y formatos.