Um guia amigável para seletores de data no frontend

• Um guia que propõe formas de entrada simples e acessíveis em vez de seletores de data em JavaScript complexos
• Ao usar os elementos de entrada nativos do navegador (date, time, datetime-local), você obtém automaticamente acessibilidade, desempenho e suporte à internacionalização
• É possível simplificar UIs complexas com campos de entrada separados, entrada com máscara e grupos de botões de opção
• Mesmo em frameworks como React, é possível usar diretamente os elementos de entrada HTML nativos; a estilização é limitada, mas mantém uma UI do sistema familiar ao usuário
• Como todos os seletores de data têm problemas de acessibilidade, uma estrutura de entrada simples e testes com usuários reais são a chave para projetar formulários bem-sucedidos

---

O seletor de data em JavaScript é realmente necessário?

• Na maioria dos casos, um seletor de data em JavaScript separado é desnecessário
  • UIs complexas provocam erros e abandono de formulários
  • Existem formas de inserir datas mais fáceis do que um widget de calendário
• Este guia tem como objetivo apresentar alternativas para uma interface amigável ao usuário

Entradas nativas de data e hora do navegador

• Todos os navegadores modernos oferecem suporte aos tipos de entrada nativos date, time e datetime-local
  • date serve para escolher a data, time para inserir hora e minutos, e datetime-local combina os dois
• As entradas nativas podem ser implementadas com uma única linha de código, e o navegador cuida de acessibilidade, desempenho e internacionalização
  • Suporte à digitação por teclado e UI de calendário básica
  • Não são perfeitas, mas tendem a ser mais estáveis do que a maioria das bibliotecas JavaScript
• Ainda assim, alguns problemas de acessibilidade continuam existindo

Entradas separadas e elementos de seleção

• Em vez de um único seletor de data, separar ano, mês e dia em campos distintos pode melhorar a usabilidade
  • É apresentado o exemplo do componente de entrada de data do GOV.UK
• Quando os dados válidos são limitados, o uso do elemento select é apropriado
  • Evita erros de entrada e reduz a interação necessária
  • Ao exibir o mês em formato numérico, é preciso atenção a leituras incorretas por leitores de tela
• Em reservas de viagem e outros casos com intervalos de tempo fixos (por exemplo, a cada 15 minutos), expressões de data relativa como hoje e amanhã podem ser úteis

Entrada com máscara e validação

• Campos com máscara de entrada são uma alternativa que orienta o formato da data sem usar calendário
  • É possível fazer validação e formatação no lado do cliente com JavaScript
  • Ex.: “Insira um dia válido de fevereiro (1 a 28)”
  • A API Intl pode formatar datas automaticamente
• No entanto, ao atualizar o valor do campo com JavaScript, a funcionalidade de desfazer/refazer pode ser quebrada
• Também é possível usar CSS para combinar vários campos visualmente, fazendo-os parecer um único campo

Seleção de intervalo e opções limitadas

• Seletores de intervalo com dois calendários são difíceis de operar e pouco práticos sem ponteiro
  • Em vez disso, podem ser simplificados com dois campos de entrada
• Quando só é necessário escolher entre datas disponíveis, isso pode ser substituído por um grupo de entradas radio
  • Em vez de uma UI complexa, a tarefa pode ser organizada em etapas simples
  • Um formulário em várias etapas pode ser expandido com JavaScript para uma interação de página única

Entrada livre e recursos de sugestão

• Quando não é necessário informar data e hora exatas, uma entrada de texto básica pode ser útil
• O elemento datalist permite oferecer sugestões de preenchimento
  • Ele também funciona com os tipos de entrada date e time

Perguntas frequentes

Ao usar frameworks JavaScript

• Todos os principais frameworks permitem usar elementos HTML nativos
  • Não há necessidade de criar componentes personalizados
  • É possível fazer binding bidirecional de estado com o atributo value

Estilização do seletor de data nativo

• Apenas parte do elemento input pode ser estilizada; o restante não
  • Isso tem a vantagem de manter uma UI do sistema familiar para o usuário
  • O design varia conforme o sistema operacional, método de entrada e navegador
  • Não é necessário forçar uma uniformidade adicional de design

Como responder a partes interessadas que exigem um seletor de data em JavaScript

• O objetivo é o envio bem-sucedido do formulário, e UIs complexas aumentam os erros
  • Todos os seletores de data têm problemas de acessibilidade
  • Combinações de entradas nativas são mais amigáveis ao usuário
  • UIs JavaScript não validadas podem entrar em conflito com regulamentações como a Lei Europeia de Acessibilidade (EAA)
  • A simplicidade é a chave do sucesso

Testes e garantia de acessibilidade

• É essencial entender diretrizes de acessibilidade como a WCAG
  • Usar padrões web ajuda a evitar erros de UIs personalizadas
• É possível detectar erros com os recursos de acessibilidade das ferramentas de desenvolvedor do navegador
  • Não existe ferramenta perfeita, e testes com usuários reais são a única forma de validação
• O uso de overlays de acessibilidade é fortemente desaconselhado, pois pode piorar os problemas

Materiais de referência sobre acessibilidade

• 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

Resposta a pedidos de recomendação de seletor de data em JavaScript

• Não existe solução universal; todos os seletores de data têm limitações
• Este guia busca ajudar você a avaliar os requisitos por conta própria
• A recomendação é atingir o objetivo da forma mais simples possível
• Um seletor de data não é necessariamente obrigatório

Conclusão

• Testes com usuários reais e coleta de feedback são indispensáveis
• Este guia está em andamento, e feedback é bem-vindo

[GN⁺]

Comentário do Hacker News

• Há alguns anos, criei um app móvel para pacientes de um hospital regional. Muitos usuários eram idosos, e choveram reclamações de que o seletor de data padrão do sistema era inconveniente demais
  Havia relatos reais como “não consigo definir meu ano de nascimento” e “precisei apertar a seta do mês anterior 720 vezes para chegar à minha data de nascimento”
  Tanto no iOS quanto no Android, na época o ano aparecia como se fosse apenas um título, então não era percebido como um elemento clicável
  Tive a impressão de que o Flat Design, focado na estética, estava destruindo a UX. Acho problemático que a UI do sistema operacional seja decidida por designers, e não por especialistas em UX como Don Norman
  No fim, quando mudamos para o formato caixa de texto–dropdown–caixa de texto (dia–mês–ano), as reclamações desapareceram
  • A pesquisa da equipe de design do Gov.uk do governo britânico chegou à mesma conclusão.
    Dizem que três caixas de texto (dia, mês, ano) oferecem a melhor experiência.
    Também existe um guia de padrões para implementação
  • Também lembro que, na primeira vez que usei aquele campo, toquei mais de 100 vezes antes de pensar “isso está estranho” e ir pesquisar. Foi realmente um pesadelo de UX
  • Era tão pouco intuitivo que a reação natural era: “o ano é clicável??”
  • Eu também já fiquei perdido por um bom tempo naquele calendário por não saber como mudar o ano
  • Mas fico me perguntando por que usaram um calendar picker para inserir data de nascimento
• Quando a data é definida, como numa reserva de viagem, expressões de data relativa como “hoje” e “amanhã” podem ser convenientes
  Mas, ao reservar um voo perto da meia-noite, fica confuso se “hoje” é com base no meu fuso, no servidor ou em GMT
  • Datas relativas como “hoje” e “amanhã” parecem uma boa ideia, mas a implementação é um inferno.
    Há exceções demais: fuso horário, horário de verão, fim do mês (31 de janeiro → mês seguinte?), logo após a meia-noite etc.
    É preciso pensar muito bem antes de colocar esse tipo de recurso
  • O transporte público de Montreal usava antigamente um relógio de 28 horas. Depois da meia-noite, os ônibus apareciam com horários como 27:30, o que era muito confuso
  • Não gosto que o computador defina “hoje” com base na meia-noite.
    Quando você está trabalhando depois da meia-noite, a expressão “amanhã” entra em conflito com a percepção da realidade.
    Na prática, você quer dizer “depois desta manhã”, mas o sistema entende como o dia seguinte
  • Mas, seja “hoje” ou “12 de novembro”, se o fuso horário for diferente, o mesmo problema acontece
• Pela minha experiência de mais de 20 anos lidando com datepicker, o melhor é simplesmente usar input type="text" com uma dica de formato
  Assim você evita sofrer com navegador, acessibilidade e problemas de locale
  Componente customizado é realmente a porta do inferno. Você tenta inventar moda e cai em 10 tocas de coelho
  • Para datas já conhecidas, como aniversário, tudo bem, mas para algo como buscar um voo “ali por uma sexta no começo de abril”, é preciso um calendário.
    Você precisa explorar visualmente as datas
  • Não importa a dica de formato que você coloque, não dá para confiar se “3-9-1980” significa 9 de março ou 3 de setembro para o usuário
  • Isso é um conselho ruim. ISO 8601 serve para momentos no passado, mas não é adequado para reservas futuras ou agendamentos entre países.
    Problemas com datas são realmente complexos, então é preciso uma abordagem por caso de uso
  • Ainda assim, acho muito melhor do que um calendário em que não dá para selecionar o ano no celular
• É engraçado falar de internacionalização e, ao mesmo tempo, só dar suporte a formatos de data ocidentais
  Se você estiver criando um sistema hospitalar no Nepal, precisa suportar tanto o calendário nepalês quanto o gregoriano. O calendário nepalês é muito complexo
  A Etiópia usa um calendário de 13 meses, em que o último mês tem 5 ou 6 dias
  Se alguém tiver uma boa referência de date picker internacionalizado, eu gostaria de conhecer
• O contexto da entrada de data deve determinar qual picker usar
  Por exemplo, para uma reserva de jantar, um calendário é útil para ver a disponibilidade nos fins de semana, mas para inserir data de nascimento é mais eficiente digitar rapidamente os números
• Quando o fluxo de digitação numérica é importante, como ao inserir dados de cartão de crédito,
  um processo como selecionar o nome do mês → dropdown → selecionar o ano quebra o ritmo
  Simplesmente inserir números é muito mais natural. No celular é ainda pior porque o teclado fica abrindo e fechando toda hora
• Achei interessante ver um date picker em que dá para digitar direto pelo teclado
  Forçar um picker customizado em vez da UI padrão é estranho.
  Especialmente no Android, imitar na web o seletor de hora em roda no estilo iOS é o pior dos mundos
• Como dinamarquês, acho engraçado o nome “Pikaday”. “pik” é uma gíria para pênis em dinamarquês
  • A ponto de surgir a piada: “então Pokémon também faz sucesso na Dinamarca?”
• Só Date, Time e DateTime pickers não bastam
  Também são necessários seletores por mês, por semana e por intervalo personalizado. Os elementos nativos de formulário são limitados demais
  • Fico curioso se falta algo em <input type="week"> ou <input type="month">, além do suporte do Firefox
  • Eu gostaria que existisse um seletor de tempo com IA alimentado pelo poder de Cronos, deus grego
• Só para contexto, esta discussão vem de um post sobre o Pikaday
  • Lembro que já usei uma biblioteca de datepicker chamada Pikaday no passado