- 複雑な JavaScript日付ピッカー の代わりに、シンプルでアクセシビリティの高い入力方法を提案するガイド
- ブラウザ標準の入力要素（date, time, datetime-local）を活用すれば、アクセシビリティ、パフォーマンス、国際化対応を自動的に得られる
- 分離された入力フィールド や マスク入力、ラジオボタングループ などで複雑な UI を簡素化できる
- React などのフレームワーク でも標準の HTML 入力要素をそのまま使え、スタイル指定には制限があるものの、ユーザーにとって馴染みのあるシステム UI を維持できる
- すべての日付ピッカーにはアクセシビリティ上の問題があるため、シンプルな入力構造と実際のユーザーテスト が成功するフォーム設計の鍵
JavaScript日付ピッカーは本当に必要か
- ほとんどの場合、別個の JavaScript日付ピッカー は不要
- 複雑な UI はエラーやフォーム離脱を招く
- カレンダーウィジェットより簡単な日付入力方法がある
- このガイドは ユーザーフレンドリーなインターフェース のための代替案を示すことが目的
ブラウザ標準の日付・時刻入力
- すべての最新ブラウザは 標準の date, time, datetime-local 入力タイプ をサポートしている
date は日付選択、time は時・分入力、datetime-local は両方を組み合わせたもの
- 標準入力は 1 行のコードで実装でき、ブラウザが アクセシビリティ・パフォーマンス・国際化 を処理する
- キーボード入力をサポートし、標準のカレンダー UI を提供
- 完璧ではないが、ほとんどの JavaScript ライブラリより安定している
- ただし、一部の アクセシビリティ上の問題 は依然として存在する
分離された入力と選択要素
- 1 つの日付ピッカーより 年・月・日を分けた入力 のほうが使いやすさを向上できる
- GOV.UK の date input コンポーネントの例を提示
- 有効なデータが限定される場合は select 要素 の使用が適している
- 入力ミスを防ぎ、操作を減らせる
- 月を数字で表記する場合はスクリーンリーダーの誤読に注意
- 旅行予約など固定された時間間隔（例: 15 分単位）では、相対的な日付（今日、明日）の表現が有用
マスク入力とバリデーション
- マスク入力フィールド は、カレンダーなしで日付形式の入力を促す代替手段
- JavaScript でクライアント側の検証と書式設定が可能
- 例: 「2月の有効な日付を入力してください（1〜28）」というエラーメッセージ
Intl API で日付形式を自動フォーマット
- ただし、JavaScript で入力値を更新すると undo/redo 機能が壊れる可能性がある
- CSS を使って複数の入力を視覚的に 1 つのように見せて結合できる
範囲選択と限定された選択肢
- 2 つのカレンダーを使う 範囲選択型の日付ピッカー は操作が難しく、ポインターなしでは使いにくい
- 代わりに 2 つの入力フィールド でシンプルにできる
- 選択可能な日付だけが必要な場合は radio 入力グループ に置き換えられる
- 複雑な UI の代わりに、単純な段階的作業として構成できる
- 多段階フォームを JavaScript で単一ページのインタラクションに拡張できる
自由入力と提案機能
- 正確な日付・時刻が必要ない場合は 標準のテキスト入力 が有用
datalist 要素を使えば入力候補を提示できる
date, time 入力タイプとも一緒に動作する
よくある質問
JavaScriptフレームワークを使う場合
- すべての主要フレームワークで 標準の HTML 要素 を使用できる
- カスタムコンポーネントにする必要はない
value 属性で双方向の状態バインディングが可能
標準の日付ピッカーのスタイリング
input 要素は一部だけスタイル指定でき、残りはできない
- これはユーザーに 馴染みのあるシステム UI を維持するという利点でもある
- デザインは OS・入力方式・ブラウザによって異なる
- 追加でデザインを統一する必要はない
JavaScript日付ピッカーを求める関係者への対応
- 目標は フォーム送信の成功 であり、複雑な UI はエラーを増やす
- すべての日付ピッカーにはアクセシビリティ上の問題がある
- 標準入力の組み合わせのほうがユーザーフレンドリー
- 検証されていない JavaScript UI は 欧州アクセシビリティ法（EAA） などの規制に抵触する可能性がある
- シンプルさが成功の鍵
アクセシビリティテストと保証
- WCAG などのアクセシビリティガイドライン の理解が不可欠
- Web 標準を活用してカスタム UI のエラーを防ぐ
- ブラウザの開発者ツールにあるアクセシビリティ機能でエラーを検出できる
- 完璧なツールはなく、実際のユーザーテスト が唯一の検証方法
- アクセシビリティオーバーレイの使用は強く非推奨 で、かえって問題を悪化させる可能性がある
アクセシビリティ関連の参考資料
- 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
JavaScript日付ピッカーのおすすめを求められたときの答え
- 万能な解決策はない。どの日付ピッカーにも限界がある
- このガイドは要件を自分で評価できるようにすることが目的
- 可能な限り シンプルな方法で目標を達成する ことを推奨
- 日付ピッカーが必須とは限らない
結論
- 実際のユーザーテストとフィードバック収集 が不可欠
- このガイドは継続中であり、フィードバックを歓迎する
1件のコメント
Hacker Newsのコメント
「生年を設定できない」「自分の誕生日まで戻るのに前月の矢印を720回押さなければならなかった」といった声が実際にあった。
当時のiOSとAndroidでは、どちらも年が単なる見出しのように見えて、クリック可能な要素だと認識されていなかった。
美的感覚を優先したFlat DesignがUXを壊していると感じた。Don NormanのようなUX専門家ではなく、デザイナー主導でOSのUIが決まる現実が問題だと思う。
結局、テキストボックス-ドロップダウン-テキストボックス（日-月-年）形式に変えたところ、不満は消えた。
3つのテキストボックス（日、月、年）が最もよい体験を提供するという。
実装のための パターンガイド もある
しかし真夜中近くにフライトを予約するとき、「今日」が自分のタイムゾーン基準なのか、サーバー基準なのか、GMTなのかで混乱する。
タイムゾーン、サマータイム、月末（1月31日 → 翌月?）、深夜0時直後など、例外が多すぎる。
こういう機能を入れる前には本当に慎重になるべきだ
深夜12時を過ぎて働いていると、「明日」という表現が現実感覚とずれてしまう。
実際には「今朝以降」を意味しているのに、システムは翌日として認識する
input type="text"にフォーマットのヒントを付けるのが最善だ。ブラウザ、アクセシビリティ、ロケールの問題で苦しまずに済む。
カスタムコンポーネントはまさに地獄の門だ。格好をつけようとして、10個のウサギ穴にはまり込むだけだ。
日付を視覚的に探索する必要があるから
日付の問題は本当に複雑なので、ユースケースごとのアプローチが必要だ
ネパールの病院システムを作るなら、ネパール暦とグレゴリオ暦の両方をサポートしなければならない。ネパール暦は非常に複雑だ。
エチオピアは13か月のカレンダーを使っていて、最後の月は5〜6日しかない。
まともな国際化対応 date pickerの参考資料があれば知りたい
たとえば夕食の予約では週末の空き状況を見るためにカレンダーが便利だが、誕生日入力なら数字で素早く入力するほうが効率的だ
「月名を選ぶ → ドロップダウン → 年を選ぶ」のような手順はリズムを壊す。
数字だけを入力する方式のほうがずっと自然だ。モバイルではキーボードが何度も開閉してさらに不便になる
標準UIではなくカスタムピッカーを強制するのはおかしい。
特にAndroidでiOS風のホイール回転式時間選択UIをWebで真似したものは最悪だ
月単位、週単位、カスタム期間選択ピッカーも必要だ。ネイティブのフォーム要素は制約が大きすぎる。
<input type="week">や<input type="month">について、Firefoxの対応以外に不足している点があるのか気になる