Técnicas › Artículo

Selectores de fecha: el componente más odiado y cómo diseñarlo bien

Cuándo usar tres campos, un calendario o un input nativo para fechas, y cómo cumplir WCAG con formatos claros, mensajes de error útiles y entrada manual.

info Definición Rápida
Un selector de fecha es el control que permite introducir día, mes y año, ya sea como campos separados, como un campo único con formato o como un calendario desplegable. El calendario es solo una de las opciones, y rara vez la mejor para todos los casos.

¿Por qué se considera el componente más odiado?

Porque la frustración es muy común: un calendario que no deja escribir la fecha, que salta al mes equivocado, que no acepta el formato que usamos o que obliga a pulsar decenas de veces para llegar a un año de nacimiento. Son fallos de diseño repetidos en productos muy distintos.

La fecha parece simple, pero hay muchas formas de escribirla, y «10/11/2016» puede ser el 10 de noviembre o el 11 de octubre según la cultura. El componente sencillo se vuelve complicado cuando el usuario no sabe qué formato usar ni qué pasará si se equivoca.

¿Por qué le importa a un diseñador junior?

Porque la fecha aparece en casi todos los formularios: nacimiento, entrega, vencimiento, reservas. Un junior que sabe elegir entre tres campos, un calendario o un input nativo evita decisiones que después cuesta corregir. Y es un buen ejemplo de cómo un componente pequeño puede afectar a la accesibilidad de todo el formulario. En el pago, la fecha de caducidad de la tarjeta es un caso típico, y el artículo sobre UX de checkout muestra qué otras decisiones pesan ahí.

Además, el selector de fecha es un caso donde la regla de «menos clics» choca con la de «menos errores». Entender por qué sirve para discutir las decisiones con el equipo.

¿Cuándo usar cada opción?

GOV.UK, el sistema de diseño del gobierno británico, distingue los casos según cómo conoce el usuario la fecha:

  • Tres campos separados. Para fechas memorables, como la de nacimiento o la de un matrimonio, y para fechas que el usuario toma de un documento o una tarjeta. En el caso de los documentos, conviene que el formato de los campos coincida con el original para copiar la fecha sin errores.
  • Calendario. Solo cuando el usuario debe elegir una fecha en el futuro cercano o el pasado reciente, necesita ver el día de la semana o la semana del mes, o necesita ver las fechas en relación entre sí, como en una reserva.

El artículo de NN/g sobre campos de fecha (Angie Li, 2017) coincide en lo esencial: el calendario conviene para fechas cercanas al presente, de alrededor de un año; para fechas lejanas, como un nacimiento, escribir es más rápido. Además, el usuario debe poder escribir aunque existan otras formas de entrada.

¿Qué pasa con los desplegables?

NN/g desaconseja los menús desplegables separados para mes, día y año, porque añaden clics y desplazamiento. Para públicos internacionales, recomienda campos separados con etiqueta, de modo que cada componente quede claro. Si usas un calendario, también recomienda escribir el mes con letras y etiquetarlo con claridad, para evitar la ambigüedad entre formatos.

El formato también importa. NN/g indica que el usuario no debería tener que escribir caracteres especiales: se deben reconocer los guiones, espacios, barras y puntos, y los ceros a la izquierda no deben cambiar la fecha. Rechazar lo que el usuario escribió de forma razonable es uno de los errores más frustrantes.

¿Cómo se diseña el formato?

  1. Muestra el formato esperado. WCAG 3.3.2 (nivel A) exige etiquetas o instrucciones cuando el contenido pide una entrada del usuario. Uno de los ejemplos oficiales es un campo de fecha con el formato esperado en texto, como «dd/mm/aaaa».
  2. Usa ejemplos sin ambigüedad. GOV.UK recomienda ejemplos con día 13 o más y mes 9 o menos, como «27 3 2007». Según la guía, así el usuario escribe la fecha en el orden correcto y se entiende que no hacen falta ceros a la izquierda.
  3. Agrupa los campos. Si la fecha está en tres campos, WCAG 1.3.1 (nivel A) pide que la relación entre ellos pueda determinarse por software. fieldset con legend es una técnica suficiente (H71), y así el lector de pantalla presenta los tres campos como una sola pregunta.
  4. Evita las opciones ilógicas. NN/g recomienda impedir elecciones sin sentido, como una fecha de vuelta anterior a la de ida o una fecha pasada, y atenuar las opciones no disponibles.
  5. Corrige sin castigar. Si el sistema detecta un error y sabe cómo corregirlo, debe sugerir la corrección (WCAG 3.3.3, nivel AA), salvo que eso ponga en riesgo la seguridad o el propósito del contenido.

Para decidir cuándo avisar del error, el artículo sobre timing de validación de formularios explica cómo no interrumpir al usuario mientras escribe.

¿Qué pasa con el input nativo?

MDN describe el input type="date" con dos datos clave: su valor siempre se normaliza a yyyy-mm-dd, pero la fecha mostrada se formatea según el idioma del navegador, y la apariencia del selector varía según el navegador y el sistema operativo. Eso significa que el mismo campo puede verse distinto en dos dispositivos, y el usuario debe poder entenderlo en ambos. MDN lo marca como una función ampliamente disponible en los navegadores desde abril de 2021, y permite acotar el rango con min y max.

Un input nativo basta cuando las fechas son cercanas y hay pocas opciones válidas, siempre con etiqueta y formato visible. Como el comportamiento de escritura directa varía entre navegadores y sistemas, conviene probarlo en los dispositivos que usa tu público y mantener la validación también en el servidor.

En cuanto al tamaño de los objetivos táctiles, el criterio WCAG 2.5.8 (nivel AA) exceptúa los controles cuyo tamaño determina el agente de usuario y el autor no modifica. Si personalizas el aspecto del selector, esa excepción deja de cubrirte y debes comprobar los 24 píxeles CSS.

¿Cuándo NO usar un selector?

  • Nunca solo con calendario para fechas de nacimiento o de documentos. Usa tres campos con ejemplo.
  • Cuando el usuario puede no conocer la fecha exacta. GOV.UK propone dejar entrar fechas parciales, como «diciembre 2017», y fechas relativas, como «mañana», mostrando el día de la semana si importa.
  • Cuando el rango es muy amplio. Desplazarse por décadas en un calendario es lento. La escritura es más eficiente.

Ejemplo

Ejemplo ilustrativo: un formulario de alta de un seguro de viaje con tres fechas: nacimiento, salida y regreso.

  • Nacimiento: tres campos separados con etiqueta, y el ejemplo «27 3 1990» bajo el campo. Sin calendario, porque es una fecha lejana que el usuario conoce.
  • Salida: un calendario, con la opción de escribir la fecha directamente.
  • Regreso: no permite una fecha anterior a la salida. Si el usuario escribe una anterior, el sistema lo explica y sugiere la corrección.
  • Prueba: el equipo prueba el formulario con un lector de pantalla y con el teclado, y encuentra que el calendario no anuncia el mes al cambiarlo. Ajusta el componente antes de publicar.

El formulario tiene tres comportamientos distintos porque tiene tres tipos de fecha distintos. Esa es la idea central.

Si tu formulario usa autocompletado para otros campos, el artículo sobre patrones de autocompletado explica cómo combinarlo sin confundir al usuario.

Errores comunes

  • Usar solo un calendario para fechas de nacimiento o de documentos.
  • Poner menús desplegables separados para día, mes y año.
  • No mostrar el formato esperado, o dar un ejemplo ambiguo.
  • Rechazar formatos razonables en lugar de interpretarlos.
  • Aceptar fechas imposibles en vez de impedirlas.
  • Cambiar el rango de un segundo campo después de elegir el primero sin avisar.
  • Mostrar errores sin sugerencia de corrección.

Fuentes

Preguntas frecuentes

¿Cuándo usar tres campos separados para una fecha?
Cuando la fecha es memorable, como una fecha de nacimiento, o cuando el usuario la toma de un documento o tarjeta. GOV.UK recomienda tres campos (día, mes y año) en esos casos, y reserva el calendario para fechas cercanas o cuando hace falta ver el día de la semana o comparar fechas.
¿Un calendario puede ser la única forma de introducir una fecha?
No. GOV.UK indica que nunca se debe hacer de un calendario que depende de JavaScript la única opción de entrada. El usuario debe poder escribir la fecha directamente.
¿Qué formato de fecha conviene mostrar?
Uno que no sea ambiguo. GOV.UK recomienda usar como ejemplo una fecha con día 13 o más y mes 9 o menos, como 27 3 2007, para que el orden se entienda sin dudas. WCAG 3.3.2 exige etiquetas o instrucciones en los campos, y uno de sus ejemplos es indicar el formato esperado.
¿Qué hace un input de fecha nativo?
Según MDN, el valor del input type date siempre se guarda como yyyy-mm-dd, pero la fecha mostrada depende del idioma del navegador, y el aspecto del selector varía según el navegador y el sistema operativo. Conviene probarlo en los dispositivos de tu público.
¿Qué exige WCAG sobre los campos de fecha?
WCAG no tiene un criterio solo para fechas. Aplican 1.3.1 (la relación entre los campos debe poder determinarse por software; fieldset y legend es una técnica suficiente), 3.3.2 (etiquetas o instrucciones) y 3.3.3 (sugerir la corrección cuando el sistema detecta un error que sabe corregir).