Date & Time Picker

Cuando el usuario ya conoce la fecha (cumpleaños, fecha de nacimiento, vencimiento de un documento), forzarle un calendario lo obliga a navegar mes a mes con decenas de clics innecesarios. Un input de tres campos día / mes / año, con label visible encima de cada campo, se alinea con el modelo mental de quien recuerda una fecha como una cadena de dígitos. GOV.UK reserva su componente de date input para fechas que el usuario "ya sabe o puede buscar sin usar un calendario", y desaconseja el calendario cuando es improbable que el usuario conozca la fecha exacta. El calendario aporta valor solo cuando la fecha importa en relación a otras: disponibilidad, temporadas, día de la semana.

Los pickers nativos de iOS y Android están optimizados para cada plataforma: haptics, scroll de inercia, accesibilidad del sistema y entrada manual de texto sin abrir el selector. Reimplementar uno custom duplica el esfuerzo y casi siempre degrada la experiencia. Material 3 recomienda que en móvil el usuario pueda ingresar fechas tecleando, sin obligarlo al picker. WCAG 2.5.8 (AA) exime explícitamente a los inputs de calendario dimensionados por el navegador, salvo que el autor modifique sus dimensiones por defecto. Si la marca exige colores o tipografía propios, envuelve el trigger nativo en un botón custom, pero nunca reemplaces la lógica interna de selección.

El patrón oficial WAI-ARIA APG define un conjunto exacto de teclas para el grid del calendario; omitir cualquiera lo hace inaccesible para teclado y lectores de pantalla. Las flechas mueven día y semana, Home/End van al inicio/fin de la semana, Page Up/Down cambian de mes y con Shift de año, y Escape cierra devolviendo el foco al trigger. El grid usa role="grid" con roving tabindex (0 en la celda activa, -1 en el resto) y aria-selected; el heading mes/año usa aria-live="polite" para anunciar los cambios. Al abrir sin valor previo, el foco cae en la fecha actual del sistema; si hay un valor válido, cae en esa fecha.

El doble panel de calendario es el patrón estándar en desktop para seleccionar rangos porque permite ver inicio y fin sin cambiar de mes; en móvil un solo panel con navegación de flechas es preferible al panel doble comprimido. Mientras el usuario mueve el cursor tras elegir el inicio, muestra un preview del rango potencial para confirmar visualmente antes del clic. Previene selecciones de fin-antes-de-inicio automáticamente: reasigna el inicio o muestra error inmediato, nunca esperando al submit. Las celdas de día en un picker custom deben respetar un objetivo táctil adecuado (WCAG 2.5.8 exige ≥ 24×24 CSS px en AA; WCAG 2.5.5 eleva a ≥ 44×44 px en AAA).

Los selectores de hora tipo "drum roll" son lentos e imprecisos; el input directo de teclado con validación en tiempo real es más rápido para horas conocidas. Material 3 ofrece dos variantes oficiales, Dial (reloj analógico interactivo) e Input (campos de texto directo), y recomienda permitir ambas. Detecta el locale para mostrar 12h (AM/PM) o 24h por defecto, y ofrece un toggle visible para cambiar entre modos. En los inputs, acepta entradas abreviadas como "9" (9:00), "930" (9:30) o "1430" (14:30) para reducir fricción, y al hacer clic en el campo de horas o minutos selecciona todo el contenido para reemplazo inmediato sin borrar primero. El paso de minutos debe ajustarse al dominio (citas, reservas, timers).

En analítica y reportes los usuarios razonan en rangos relativos ("últimos 7 días", "este mes"), no en fechas absolutas; ofrecer estos atajos junto al picker elimina el paso de calcular fechas a mano. Los atajos deben estar visibles sin abrir el calendario, en una lista lateral o un row de chips, nunca escondidos dentro del grid. Al seleccionar uno, muestra la fecha absoluta resultante en el campo o en un tooltip para confirmar el rango exacto, y distingue visualmente el atajo activo (color de acento, peso) para que el usuario sepa qué modo está aplicado. En móvil los atajos funcionan bien como chips horizontales scrolleables sobre el picker.

La validación prematura mientras el usuario escribe interrumpe el flujo y genera errores falsos; valida al blur de cada campo. El formato esperado debe ser texto permanente bajo el campo, nunca solo placeholder, porque los placeholders desaparecen al escribir y dejan al usuario sin referencia. GOV.UK acepta nombres de mes completos o abreviados ("january" o "jan") porque sus datos mostraron que muchos usuarios escriben el mes como nombre, y tras aceptar ambos formatos las tasas de error bajaron; además nunca aplica auto-tab entre campos. Los mensajes deben ser específicos ("El mes debe estar entre 1 y 12", "Febrero no tiene 31 días") y referenciar el campo exacto. Los campos de fecha de nacimiento deben declarar bday-day, bday-month, bday-year para cumplir WCAG 2.2 SC 1.3.5 (Identify Input Purpose).

El orden de la fecha varía por región y mostrar el incorrecto provoca errores críticos (confundir el día 03 con el mes 03). Usa Intl.DateTimeFormat o el equivalente del framework para formatear según el locale detectado (navigator.language o preferencia de cuenta); nunca hardcodees el formato. El primer día de semana también cambia: lunes en Europa, Asia y según ISO 8601; domingo en Estados Unidos y Canadá; sábado en partes de Medio Oriente y Norte de África. ISO 8601 define YYYY-MM-DD como formato de intercambio para APIs y bases de datos, con lunes = 1 y domingo = 7. Muestra el hint de formato en la locale local ("DD/MM/YYYY" en México, "MM/DD/YYYY" en EE. UU., "YYYY年MM月DD日" en Japón) y acompaña siempre la hora de su zona horaria cuando el evento cruza zonas.