Tipografía para formularios y campos de entrada

Hay un fallo de formularios tan común que se ha convertido en un antipatrón con nombre propio: el formulario con el marcador de posición como etiqueta. Cada campo es una caja vacía y limpia con texto gris pálido dentro —«Correo electrónico», «IBAN», «Número de IVA»— y en el momento en que el usuario hace clic y escribe, la etiqueta desaparece. Rellena seis campos, sufre una interrupción, vuelve, y el formulario es un muro de cajas anónimas: comprobar lo que escribiste frente a lo que se pedía es imposible sin vaciar los campos para volver a ver sus etiquetas. En un pago o en una transferencia bancaria, eso no es fricción: son carritos abandonados y dinero enviado por error.

La tipografía de formularios se compone para escanear y verificar, no para la lectura continua: texto de entrada con un mínimo de 16px, etiquetas encima del campo en tamaño de cuerpo o un paso menor con un peso medio, texto de ayuda y de error pequeño pero no por debajo de unos 13px, errores señalados con más que color, y monoespaciada para todo lo que se comprueba carácter a carácter. Cada regla de esa lista existe porque los errores de formulario, a diferencia de una mala lectura de prosa, cuestan dinero y tiempo de verdad. Este artículo forma parte de nuestra guía de tipografía.

¿Por qué los formularios necesitan una tipografía distinta a la del texto corrido?

La prosa se lee en flujo: el ojo cabalga sobre el contexto y predice las palabras que vienen. Los formularios se leen en un modo completamente distinto: escanear hasta el siguiente campo, leer una etiqueta corta, producir texto propio y luego verificar lo que produjiste. El paso de verificación es el inusual. Leer tus propios caracteres recién escritos es más difícil que leer prosa compuesta, porque no hay contexto de frase desde el que predecir: nada en un IBAN sugiere si el siguiente dígito debería ser un 4 o un 9, así que cada carácter debe decodificarse por separado —trabajo de legibilidad más que de lecturabilidad.

Eso convierte a los formularios en el hábitat de mayor riesgo de la tipografía. Un párrafo un poco demasiado gris cuesta comodidad; un número de cuenta mal verificado cuesta un ticket de soporte, un pago fallido o algo peor. Las reglas de abajo son ideas tipográficas ordinarias llevadas más al límite porque el precio del fallo es más alto.

¿Qué tamaño de fuente deben usar los campos de un formulario?

Dieciséis píxeles, como mínimo, para el texto dentro del campo. Dos razones: una mecánica y otra perceptiva.

La mecánica es la trampa del zoom de iOS: cuando el tamaño de fuente de un campo enfocado está por debajo de 16px, Safari en el iPhone amplía toda la página para compensar. El diseño da un salto, el campo se descoloca del centro y el usuario tiene que volver a alejar la vista con los dedos después de cada campo. Es un comportamiento de larga data, y fijar el texto de entrada en 16px o más es la solución directa: el navegador está imponiendo, en la práctica, un mínimo para el texto que se supone que vas a escribir.

La razón perceptiva es la lectura de verificación. La prosa de cuerpo sobrevive a 14px porque el contexto hace parte del trabajo; tu propio IBAN escrito a 14px no recibe esa ayuda, y la comprobación carácter a carácter necesita el tamaño extra. Los equipos que crean herramientas internas solo para escritorio a veces bajan los campos a 14px y les sale bien —pero en cualquier sitio donde un teléfono pueda llegar a la página, 16px es el mínimo.

¿Dónde deben ir las etiquetas: encima, al lado o dentro del campo?

Encima del campo, alineadas a la izquierda con él. Las recomendaciones de usabilidad basadas en cómo recorren los ojos los formularios —reflejadas en el tutorial de etiquetado de formularios del W3C— prefieren las etiquetas superiores: el ojo baja por una sola columna y cada par etiqueta–campo se capta como una unidad. Las etiquetas al lado del campo obligan a un escaneo en zigzag y a un espacio variable e incómodo entre la etiqueta y la caja; además, son las primeras en romperse en pantallas estrechas.

Las etiquetas dentro del campo —el patrón del marcador de posición del principio— fallan de forma estructural, no estilística: la etiqueta queda destruida por el acto mismo de responderla. Los marcadores de posición siguen teniendo un trabajo legítimo como pistas de formato complementarias («[email protected]»), pero nunca como el único nombre que tiene un campo.

¿Cómo se deben estilizar las etiquetas, el texto de ayuda y los errores?

• Etiquetas: tamaño de cuerpo o un paso menor, peso medio. En una escala de 16px eso significa 16px o 14px con peso 500: lo bastante presentes para escanearlas, lo bastante discretas para no competir con lo que el usuario escribe. La pertenencia se logra con espaciado, no con estilo: una etiqueta debe estar visiblemente más cerca de su propio campo que del campo de arriba (el principio de proximidad de la percepción: las cosas más cercanas entre sí se leen como si fueran juntas). Si de etiqueta a campo hay 8px, de campo a la siguiente etiqueta deberían ser 20px o más.
• Texto de ayuda: pequeño, pero no por debajo de ~13px. Un paso por debajo del cuerpo es natural; por debajo de unos 13px, el texto que explica formatos y casos límite se convierte en el texto que nadie puede leer.
• Texto de error: el mismo mínimo, y nunca solo el tono. Texto rojo más un icono más un mensaje: los usuarios con daltonismo pierden las señales de tono puro, así que el error también debe poder localizarse por forma y posición (nunca solo con color, con ropa de formulario). Un peso medio ayuda a que se registre.
• El propio texto de entrada: tinta de contraste pleno. Un número sorprendente de formularios en producción estilizan el texto escrito por el usuario con el mismo gris pálido que los marcadores de posición: las palabras del propio usuario se leen entonces como una sugerencia y no como una respuesta, y la verificación se vuelve más difícil sin motivo. El texto escrito es contenido, no una pista.

¿Qué aspecto tiene un campo de formulario en una escala de 16px?

A partir de una escala base de 16px (ratio 1,333, dos notas por intervalo → 12, 14, 16, 18, 21…), la anatomía completa de un campo:

El espaciado procede del mismo sistema: 8px de la etiqueta al campo, 20–24px entre campos, y cada interlineado un múltiplo de la unidad de línea base de 8px, de modo que un formulario largo se apila sobre un único ritmo vertical en lugar de acumular deriva campo a campo.

Puedes inspeccionar estos niveles como tipografía en vivo: abre los tres niveles de texto del formulario en Scale Composer —etiqueta, entrada y ayuda extraídos de una sola escala de 16px, cada uno con su propio peso e interletrado— y escribe tus propias etiquetas en el espécimen para juzgarlas a tamaños reales.

¿Cuándo debe un campo ser monoespaciado?

Siempre que el modo de lectura sea carácter a carácter: códigos de confirmación, IBAN, claves de licencia, tokens de API, números de tarjeta. La razón es el paso fijo: cada carácter ocupa el mismo ancho, así que el quinto carácter queda en el mismo lugar en cada cadena, los dígitos pueden compararse columna contra columna, y un carácter que falta cambia de forma visible la longitud de la cadena. Los tipos proporcionales están optimizados para las formas de las palabras; la verificación no lee palabras. Combina la monoespaciada con agrupación (SE35 5000 0000 …) y le habrás dado al ojo del usuario la misma estructura que usa el validador del banco.

Construye la variante densa

Los formularios de back-office cambian aire por filas en pantalla, y la compresión es una buena prueba de qué reglas ceden: las etiquetas pueden bajar a 12px medio con el interletrado ligeramente abierto, los interlineados se aprietan un paso de línea base, los espacios entre campos se encogen de 24px hacia 16px —mientras que el texto de ayuda se mantiene en 14px (el siguiente paso hacia abajo de la escala, 12px, cruza el mínimo de ~13px) y el texto de entrada se queda en 16px, porque al comportamiento del zoom y a la lectura de verificación no les importa lo denso que sea tu panel. Para ver qué reglas se comprimieron y cuáles se negaron, carga la variante densa de la misma anatomía de campo.