Frontend tarih seçiciler için kullanıcı dostu bir rehber

• Karmaşık JavaScript tarih seçiciler yerine daha basit ve erişilebilir giriş yöntemleri öneren bir rehber
• Tarayıcının yerleşik giriş öğeleri (date, time, datetime-local) kullanıldığında erişilebilirlik, performans ve uluslararasılaştırma desteği otomatik olarak sağlanabilir
• Ayrı giriş alanları, maskeli giriş veya radyo düğmesi grupları ile karmaşık arayüzler sadeleştirilebilir
• React gibi framework'lerde de yerleşik HTML giriş öğeleri aynen kullanılabilir; stil seçenekleri sınırlı olsa da kullanıcıların aşina olduğu sistem arayüzü korunur
• Tüm tarih seçicilerde erişilebilirlik sorunları bulunduğundan, basit giriş yapısı ve gerçek kullanıcı testleri başarılı form tasarımının anahtarıdır

---

JavaScript tarih seçici gerçekten gerekli mi?

• Çoğu durumda ayrı bir JavaScript tarih seçici gereksizdir
  • Karmaşık arayüzler hata ve formun yarıda bırakılmasına yol açar
  • Takvim widget'larından daha kolay tarih giriş yöntemleri vardır
• Bu rehberin amacı, kullanıcı dostu arayüzler için alternatifler sunmaktır

Tarayıcının yerleşik tarih ve saat girişleri

• Tüm modern tarayıcılar yerleşik date, time ve datetime-local giriş tiplerini destekler
  • date tarih seçer, time saat ve dakika girişi sağlar, datetime-local ise ikisini birleştirir
• Yerleşik girişler tek satırlık kodla uygulanabilir ve tarayıcı erişilebilirlik, performans ve uluslararasılaştırmayı kendisi ele alır
  • Klavye girişini destekler, varsayılan takvim arayüzü sunar
  • Kusursuz değildir ama çoğu JavaScript kütüphanesinden daha kararlıdır
• Yine de bazı erişilebilirlik sorunları devam eder

Ayrı girişler ve seçim öğeleri

• Tek bir tarih seçici yerine yıl, ay ve günü ayrı alanlara bölmek kullanılabilirliği artırır
  • GOV.UK'un date input bileşeni buna örnek olarak gösterilir
• Geçerli veri aralığı sınırlıysa select öğesi kullanmak uygundur
  • Giriş hatalarını önler, etkileşimi azaltır
  • Sayısal ay gösterimlerinde ekran okuyucuların yanlış okumasına dikkat edilmelidir
• Seyahat rezervasyonu gibi sabit zaman aralıklarında (ör. 15 dakikalık dilimler) göreli tarih ifadeleri (bugün, yarın) faydalıdır

Maskeli giriş ve doğrulama

• Maskeli giriş alanları, takvim olmadan tarih biçimini yönlendiren bir alternatiftir
  • JavaScript ile istemci tarafında doğrulama ve biçimlendirme yapılabilir
  • Örnek: “Şubat için geçerli bir gün girin (1~28)” hata mesajı
  • Tarih biçimi Intl API ile otomatik olarak biçimlendirilebilir
• Ancak JavaScript ile giriş değerini güncellemek geri al/yinele işlevini bozabilir
• CSS ile birden çok girişi görsel olarak tek alan gibi birleştirmek mümkündür

Aralık seçimi ve sınırlı seçenekler

• İki takvim kullanan aralık seçmeli tarih seçiciler kullanımı zor yapılar olup işaretçi olmadan kullanılması güçtür
  • Bunun yerine iki giriş alanı ile sadeleştirilebilir
• Yalnızca seçilebilir tarihler gerekiyorsa radio giriş grubu ile değiştirilebilir
  • Karmaşık arayüz yerine basit ve adım adım ilerleyen bir yapı kurulabilir
  • Çok adımlı formlar JavaScript ile tek sayfalık etkileşime genişletilebilir

Serbest giriş ve öneri özelliği

• Kesin tarih veya saat gerekmediğinde standart metin girişi kullanışlıdır
• datalist öğesi kullanılarak giriş önerileri sunulabilir
  • date ve time giriş tipleriyle de birlikte çalışır

Sık sorulan sorular

JavaScript framework kullanıldığında

• Tüm büyük framework'lerde yerleşik HTML öğeleri kullanılabilir
  • Özel bir bileşen oluşturmaya gerek yoktur
  • value özelliğiyle iki yönlü durum bağlama yapılabilir

Yerleşik tarih seçiciyi stillendirme

• input öğesinin yalnızca bazı kısımları stillendirilebilir, geri kalanı stillendirilemez
  • Bu, kullanıcıların aşina olduğu sistem arayüzünü koruma açısından avantajdır
  • Tasarım, işletim sistemi, giriş yöntemi ve tarayıcıya göre değişir
  • Ek tasarım birliği sağlamak gereksizdir

JavaScript tarih seçici isteyen paydaşlara yanıt

• Amaç formun başarıyla gönderilmesidir; karmaşık arayüzler hataları artırır
  • Tüm tarih seçicilerde erişilebilirlik sorunları vardır
  • Yerleşik girişlerin kombinasyonu daha kullanıcı dostudur
  • Doğrulanmamış JavaScript arayüzleri Avrupa Erişilebilirlik Yasası (EAA) gibi düzenlemelerle çelişebilir
  • Başarının anahtarı sadeliktir

Erişilebilirlik testi ve güvence

• WCAG gibi erişilebilirlik yönergelerini anlamak şarttır
  • Web standartlarından yararlanarak özel arayüz hataları önlenebilir
• Tarayıcı geliştirici araçlarının erişilebilirlik özellikleriyle hatalar tespit edilebilir
  • Kusursuz bir araç yoktur; tek doğrulama yöntemi gerçek kullanıcı testidir
• Erişilebilirlik overlay'lerinin kullanımı kesinlikle önerilmez; aksine sorunları kötüleştirebilir

Erişilebilirlikle ilgili başvuru kaynakları

• 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 tarih seçici önerisi talebine yanıt

• Evrensel bir çözüm yoktur; tüm tarih seçicilerin sınırları vardır
• Bu rehberin amacı, gereksinimleri kendi başınıza değerlendirebilmenize yardımcı olmaktır
• Mümkün olduğunca en basit yöntemle hedefe ulaşmanız önerilir
• Tarih seçici mutlaka gerekli değildir

Sonuç

• Gerçek kullanıcı testleri yapmak ve geri bildirim toplamak şarttır
• Bu rehber hâlâ geliştirilme aşamasındadır ve geri bildirimlere açıktır

[GN⁺]

Hacker News yorumu

• Birkaç yıl önce yerel bir hastanenin hastalarına yönelik bir mobil uygulama yaptım. Kullanıcıların arasında ileri yaş grubu çoktu ve işletim sisteminin varsayılan tarih seçicisinin fazla kullanışsız olduğuna dair şikayet yağıyordu
  “Doğum yılımı ayarlayamıyorum”, “Doğum günüme gitmek için önceki ay okuna 720 kez basmam gerekti” gibi şeyler gerçekten yaşandı
  O dönemde hem iOS hem Android'de yıl, basit bir başlık gibi göründüğü için tıklanabilir bir öğe olarak algılanmıyordu
  Estetik odaklı Flat Design yaklaşımının UX'i mahvettiğini düşünüyordum. Don Norman gibi UX uzmanları yerine tasarımcı merkezli şekilde OS arayüzünün belirlenmesi bence asıl sorundu
  Sonunda bunu metin kutusu-açılır menü-metin kutusu (gün-ay-yıl) biçimine çevirince şikayetler kayboldu
  • Birleşik Krallık hükümetinin Gov.uk tasarım ekibi araştırması da aynı sonuca varmıştı.
    Gün, ay ve yıl için üç ayrı metin kutusunun en iyi deneyimi sunduğu söyleniyor.
    Uygulama için bir pattern guide da var
  • Ben de o giriş alanını ilk kullandığımda 100'den fazla kez dokunduktan sonra “Bu işte bir tuhaflık var” deyip arama yaptığımı hatırlıyorum. Gerçekten tam bir UX kâbusuydu
  • “Yıla tıklanabiliyor muymuş??” tepkisini verdirecek kadar sezgisel olmaktan uzaktı
  • Ben de o takvimde yıl değiştirme yöntemini bilmediğim için epey afallamıştım
  • Ama doğum tarihi girişi için neden özellikle takvim seçici kullanıldığını merak ediyorum
• Seyahat rezervasyonu gibi takvimi belli durumlarda “bugün”, “yarın” gibi göreli tarih ifadeleri kullanışlı olabilir
  Ama gece yarısına yakın bir saatte uçuş rezervasyonu yaparken “bugün” benim saat dilimime göre mi, sunucuya göre mi, GMT'ye göre mi, kafa karıştırıyor
  • “Bugün”, “yarın” gibi göreli tarihler fikir olarak güzel görünür ama uygulaması cehennemdir.
    Saat dilimi, yaz saati uygulaması, ay sonu (31 Ocak → sonraki ay?), gece yarısından hemen sonrası gibi istisna çok fazla.
    Böyle bir özelliği eklemeden önce gerçekten çok dikkatli olmak gerekir
  • Montreal toplu taşıması eskiden 28 saatlik saat sistemi kullanıyordu. Gece yarısından sonraki otobüsler 27:30 gibi gösteriliyordu ve bu çok kafa karıştırıcıydı
  • Bilgisayarın “bugün”ü gece yarısını temel alarak tanımlamasından hoşlanmıyorum.
    Gece 12'yi geçtikten sonra çalışırken “yarın” ifadesi gerçeklik hissiyle uyuşmuyor.
    Aslında kastedilen “bu sabah sonrasıdır” ama sistem bunu ertesi gün olarak algılıyor
  • Ama ister “bugün” deyin ister “12 Kasım”, saat dilimi farklıysa aynı sorun yine ortaya çıkar
• datepicker ile 20 yıldan uzun süredir uğraşmış biri olarak, en iyisi sadece input type="text" kullanıp bir biçim ipucu vermek
  Böylece tarayıcı, erişilebilirlik ve locale sorunlarıyla boğuşmazsınız
  Özel bileşenler gerçekten cehennemin kapısı gibi. Gösteriş yapayım derken kendinizi 10 ayrı tavşan deliğinde buluyorsunuz
  • Doğum günü gibi zaten bilinen tarihler için sorun değil ama uçak ararken “Nisan başında bir cuma civarı” gibi bir şey aranıyorsa takvim gerekir.
    Çünkü tarihi görsel olarak keşfetmek gerekir
  • Hangi biçim ipucunu verirseniz verin, “3-9-1980” ifadesinin kullanıcının gözünde 9 Mart mı yoksa 3 Eylül mü olduğu güvenilir değildir
  • Bu kötü bir tavsiye. ISO 8601 geçmiş tarihler için uygun olabilir ama gelecek rezervasyonları veya sınır ötesi planlamalar için uygun değil.
    Tarih meselesi gerçekten karmaşık, bu yüzden kullanım senaryosuna göre yaklaşım gerekir
  • Yine de mobilde yıl seçilemeyen bir takvimden çok daha iyi olduğunu düşünüyorum
• Uluslararasılaşmadan söz ederken sadece Batı tipi tarih biçimlerini desteklemek komik
  Nepal için bir hastane sistemi yapıyorsanız Nepal takvimi ile Gregoryen takvimi birlikte desteklemeniz gerekir. Nepal takvimi çok karmaşıktır
  Etiyopya 13 aylık bir takvim kullanıyor ve son ayı 5-6 gün sürüyor
  Düzgün bir uluslararasılaştırılmış date picker için başvuru kaynağı bilen varsa duymak isterim
• Tarih girişinin bağlamı, hangi seçicinin kullanılacağını belirlemeli
  Örneğin akşam yemeği rezervasyonunda hafta sonu uygunluğunu görmek için takvim yararlıdır ama doğum tarihi girişinde sayılarla hızlı giriş yapmak daha verimlidir
• Kredi kartı bilgisi girerken olduğu gibi sayısal giriş akışının önemli olduğu durumlarda,
  “Ay adını seç → açılır menü → yılı seç” gibi bir süreç ritmi bozar
  Sadece sayı girmek çok daha doğaldır. Mobilde klavyenin sürekli açılıp kapanması bunu daha da rahatsız edici hale getirir
• Klavyeyle doğrudan giriş yapılabilen bir date picker görmek ferahlatıcı
  Varsayılan UI yerine özel bir seçici dayatmak tuhaf.
  Özellikle Android'de iOS tarzı çark döndürmeli saat seçiciyi web'de taklit etmek en kötüsüydü
• Bir Danimarkalı olarak “Pikaday” adı komik geliyor. “pik”, Danca'da erkek cinsel organı için argo anlamına geliyor
  • Hatta “O zaman Pokémon Danimarka'da da popüler mi?” diye şaka yapılacak kadar
• Sadece Date, Time ve DateTime seçiciler yeterli değil
  Ay bazlı, hafta bazlı ve özel aralık seçicilere de ihtiyaç var. Yerel form öğeleri fazla sınırlı
  • Firefox desteği dışında <input type="week"> veya <input type="month"> için başka ne eksik, merak ediyorum
  • Keşke Yunan tanrısı Kronos'un gücünü ödünç alan yapay zeka zaman seçici diye bir şey olsa
• Bu arada bu tartışmanın bağlamı Pikaday ile ilgili yazıda yer alıyor
  • Eskiden Pikaday adlı bir datepicker kütüphanesi kullanmış olduğumu da hatırlıyorum