Guía amigable de selectores de fecha para frontend

• Una guía que propone métodos de entrada simples y accesibles en lugar de selectores de fecha en JavaScript complejos
• Al aprovechar los elementos de entrada nativos del navegador (date, time, datetime-local), se obtiene automáticamente accesibilidad, rendimiento y soporte de internacionalización
• Es posible simplificar interfaces complejas con campos de entrada separados, entrada con máscara o grupos de botones de opción
• Incluso en frameworks como React, se pueden usar directamente los elementos de entrada HTML nativos; el estilo es limitado, pero se conserva una UI del sistema familiar para el usuario
• Como todos los selectores de fecha tienen problemas de accesibilidad, la clave para diseñar formularios exitosos está en una estructura de entrada simple y pruebas con usuarios reales

---

¿Realmente se necesita un selector de fecha en JavaScript?

• En la mayoría de los casos, un selector de fecha en JavaScript independiente no es necesario
  • Una UI compleja provoca errores y abandono del formulario
  • Existen formas más fáciles de introducir fechas que un widget de calendario
• El objetivo de esta guía es presentar alternativas para una interfaz fácil de usar

Entradas nativas de fecha y hora del navegador

• Todos los navegadores modernos admiten los tipos de entrada nativos date, time y datetime-local
  • date permite seleccionar una fecha, time introducir hora y minutos, y datetime-local combina ambos
• Las entradas nativas pueden implementarse con una sola línea de código, y el navegador se encarga de la accesibilidad, el rendimiento y la internacionalización
  • Admiten entrada por teclado y ofrecen una UI de calendario predeterminada
  • No son perfectas, pero suelen ser más estables que la mayoría de las bibliotecas de JavaScript
• Aun así, todavía existen algunos problemas de accesibilidad

Entradas separadas y elementos de selección

• Separar año, mes y día en lugar de usar un solo selector de fecha mejora la usabilidad
  • Se presenta como ejemplo el componente de entrada de fecha de GOV.UK
• Cuando los datos válidos son limitados, conviene usar un elemento select
  • Ayuda a evitar errores de entrada y reduce la interacción
  • Hay que tener cuidado con la lectura incorrecta por parte de lectores de pantalla cuando el mes se muestra como número
• En reservas de viaje y otros casos con intervalos de tiempo fijos (por ejemplo, cada 15 minutos), resulta útil expresar fechas relativas como hoy o mañana

Entrada con máscara y validación

• Los campos de entrada con máscara son una alternativa para guiar el formato de fecha sin usar calendario
  • Es posible validar y dar formato en el cliente con JavaScript
  • Ejemplo: “Ingrese un día válido de febrero (1~28)” como mensaje de error
  • La API Intl permite dar formato automático a fechas
• Sin embargo, si JavaScript actualiza el valor introducido, la función de deshacer/rehacer puede romperse
• También es posible combinar visualmente varias entradas para que parezcan una sola mediante CSS

Selección de rangos y opciones limitadas

• Los selectores de rango de fechas que usan dos calendarios son difíciles de manipular e incómodos de usar sin puntero
  • En su lugar, pueden simplificarse con dos campos de entrada
• Cuando solo se necesitan fechas seleccionables concretas, pueden sustituirse por un grupo de entradas radio
  • En lugar de una UI compleja, se organiza como una tarea simple por pasos
  • Un formulario de varios pasos puede ampliarse con JavaScript hasta convertirse en una interacción de una sola página

Entrada libre y funciones de sugerencia

• Cuando no se necesita una fecha u hora exacta, una entrada de texto básica puede ser útil
• El elemento datalist permite ofrecer sugerencias de entrada
  • También funciona junto con los tipos de entrada date y time

Preguntas frecuentes

Al usar frameworks de JavaScript

• Todos los frameworks principales permiten usar elementos HTML nativos
  • No hace falta convertirlos en componentes personalizados
  • Es posible enlazar el estado en ambos sentidos mediante la propiedad value

Estilizar selectores de fecha nativos

• Solo algunas partes del elemento input pueden estilizarse; el resto no
  • Esto tiene la ventaja de mantener una UI del sistema familiar para el usuario
  • El diseño cambia según el sistema operativo, el método de entrada y el navegador
  • No hace falta forzar una uniformidad visual adicional

Cómo responder a interesados que exigen un selector de fecha en JavaScript

• El objetivo es enviar formularios con éxito, y una UI compleja aumenta los errores
  • Todos los selectores de fecha presentan problemas de accesibilidad
  • Las combinaciones de entradas nativas son más amigables para el usuario
  • Una UI de JavaScript no verificada podría entrar en conflicto con normativas como la Ley Europea de Accesibilidad (EAA)
  • La simplicidad es la clave del éxito

Pruebas y garantía de accesibilidad

• Es indispensable comprender las guías de accesibilidad como WCAG
  • Aprovechar los estándares web ayuda a evitar errores de UI personalizada
• Es posible detectar errores con las funciones de accesibilidad de las herramientas de desarrollo del navegador
  • No existe una herramienta perfecta, y las pruebas con usuarios reales son el único método de verificación
• Se desaconseja firmemente usar overlays de accesibilidad, ya que pueden empeorar los problemas

Materiales de referencia sobre accesibilidad

• Collecting dates in an accessible way — Graham Armfield
• What makes an accessible date picker? — Russ Weakley
• Maybe You Don’t Need a Date Picker — Adrian Roselli
• Date Picker Dialog Example — ARIA Authoring Practices Guide
• Designing The Perfect Date And Time Picker — Vitaly Friedman

Respuesta a solicitudes de recomendación de selectores de fecha en JavaScript

• No existe una solución universal; todos los selectores de fecha tienen limitaciones
• El propósito de esta guía es ayudar a evaluar los requisitos por cuenta propia
• Se recomienda alcanzar el objetivo con el método más simple posible
• Un selector de fecha no es necesariamente imprescindible

Conclusión

• Es indispensable probar con usuarios reales y recopilar retroalimentación
• Esta guía sigue en desarrollo y recibe con gusto comentarios

[GN⁺]

Opiniones en Hacker News

• Hace unos años hice una app móvil para pacientes de un hospital regional. Entre los usuarios había muchos adultos mayores, y llovían las quejas de que el selector de fecha nativo del sistema operativo era demasiado incómodo
  Había comentarios reales como: “no puedo poner mi año de nacimiento” o “tuve que presionar la flecha del mes anterior 720 veces para llegar a mi cumpleaños”
  Tanto en iOS como en Android, en ese momento el año se veía solo como un título, así que no se percibía como un elemento clicable
  Me daba la impresión de que el Flat Design, centrado en lo estético, estaba arruinando la UX. Creo que el problema es que la UI de los sistemas operativos la terminan definiendo diseñadores, y no expertos en UX como Don Norman
  Al final, cuando lo cambiamos a un formato de caja de texto-desplegable-caja de texto (día-mes-año), desaparecieron las quejas
  • El equipo de diseño de Gov.uk llegó a la misma conclusión en su investigación.
    Dicen que tres cajas de texto (día, mes, año) ofrecen la mejor experiencia.
    También hay una guía de patrones para implementarlo
  • Yo también recuerdo haber usado ese campo por primera vez, tocar más de 100 veces y pensar “esto está raro”, así que terminé buscándolo. De verdad fue una pesadilla de UX
  • Era tan poco intuitivo que la reacción natural era: “¿¿se puede hacer clic en el año??”
  • A mí también me pasó que no sabía cómo moverme entre años en ese calendario y estuve perdido un buen rato
  • Igual me pregunto por qué insistieron en usar un selector de calendario para ingresar una fecha de nacimiento
• Cuando el itinerario ya está definido, como en una reserva de viaje, expresiones de fecha relativas como “hoy” o “mañana” pueden resultar cómodas
  Pero al reservar un vuelo cerca de la medianoche, no queda claro si “hoy” se refiere a mi zona horaria, a la del servidor o a GMT
  • Fechas relativas como “hoy” o “mañana” suenan bien como idea, pero implementarlas es un infierno.
    Hay demasiados casos límite: zonas horarias, horario de verano, fin de mes (31 de enero → ¿mes siguiente?), justo después de la medianoche, etc.
    Hay que pensarlo muy bien antes de meter algo así
  • El transporte público de Montreal usaba antes un reloj de 28 horas. Después de medianoche, los buses aparecían con horarios como 27:30, y era muy confuso
  • No me gusta que la computadora defina “hoy” tomando como corte la medianoche.
    Cuando uno trabaja después de las 12 de la noche, la palabra “mañana” deja de coincidir con la sensación real del tiempo.
    En la práctica significa “después de esta mañana”, pero el sistema ya lo interpreta como el día siguiente
  • Pero ya sea “hoy” o “12 de noviembre”, si cambias de zona horaria aparece el mismo problema
• Después de más de 20 años lidiando con datepicker, mi experiencia es que lo mejor es simplemente usar input type="text" con una pista del formato
  Así te ahorras dolores de cabeza con navegadores, accesibilidad y problemas de locale
  Los componentes personalizados sí que son la puerta al infierno. Por querer hacer algo bonito, terminas cayendo en diez madrigueras de conejo
  • Para una fecha que ya conoces, como un cumpleaños, está bien; pero para algo como buscar un vuelo “más o menos un viernes de principios de abril”, sí hace falta un calendario.
    Porque ahí necesitas explorar visualmente la fecha
  • Pongas el formato que pongas como pista, no puedes confiar en que “3-9-1980” signifique para el usuario 9 de marzo o 3 de septiembre
  • Este es un mal consejo. ISO 8601 puede servir para fechas pasadas, pero no encaja bien con reservas futuras ni con itinerarios entre países.
    Las fechas son realmente complejas, así que hace falta un enfoque según el caso de uso
  • Aun así, me sigue pareciendo mucho mejor que un calendario móvil donde no puedes elegir el año
• Hablar de internacionalización mientras solo se soportan formatos de fecha occidentales da risa
  Si estuvieras creando un sistema hospitalario en Nepal, tendrías que soportar tanto el calendario nepalí como el gregoriano. El calendario nepalí es muy complejo
  Etiopía usa un calendario de 13 meses, donde el último mes tiene 5 o 6 días
  Si alguien conoce buen material de referencia sobre un date picker internacionalizado de verdad, me gustaría saberlo
• El contexto de la entrada de fecha debería determinar qué selector usar
  Por ejemplo, para una reserva de cena el calendario es útil porque permite ver la disponibilidad del fin de semana, pero para ingresar una fecha de nacimiento es más eficiente escribir números directamente
• Cuando es importante mantener el flujo de entrada numérica, como al capturar datos de una tarjeta de crédito,
  un proceso tipo “elegir nombre del mes → desplegable → elegir año” rompe el ritmo
  Es mucho más natural simplemente escribir números. En móvil es peor todavía porque el teclado se abre y se cierra todo el tiempo
• Me pareció interesante ver un date picker en el que puedes escribir directamente con el teclado
  Es raro que te obliguen a usar un selector personalizado en vez de la UI nativa.
  Sobre todo en Android, imitar en la web el selector de hora tipo rueda de iOS fue de lo peor
• Como danés, el nombre “Pikaday” me da risa. “pik” en danés es una forma vulgar de decir pene
  • Tanto así que salía el chiste de “entonces, ¿Pokémon también es popular en Dinamarca?”
• No basta con selectores de Date, Time y DateTime
  También hacen falta selectores por mes, por semana y de rangos personalizados. Los elementos de formulario nativos son demasiado limitados
  • Me pregunto si a <input type="week"> o <input type="month"> les falta algo aparte del soporte en Firefox
  • Ojalá existiera un selector de tiempo con IA impulsado por el poder de Cronos, dios griego
• Como referencia, el contexto de esta discusión está en este artículo sobre Pikaday
  • Recuerdo haber usado antes una librería de datepicker llamada Pikaday