GitHub artık Toast kullanmıyor

 (primer.style)
16 puan yazan GN⁺ 2025-12-12 | 1 yorum | WhatsApp'ta paylaş
  • Toast bildirim arayüzü, erişilebilirlik sorunları nedeniyle artık GitHub’da önerilmiyor
  • Otomatik olarak kaybolan geçici bildirim yapısı, görsel ve işlevsel erişilebilirlik ölçütlerini (WCAG) ihlal etme riski taşıyor
  • GitHub, alternatif olarak banner ve dialog gibi kalıcı ve erişilebilir geri bildirim yöntemleri öneriyor
  • Toast’lar; büyük ekranlar, çoklu görev kullanımı ve banner körlüğü gibi pek çok kullanılabilirlik sorununu da içeriyor
  • Erişilebilirlik ve tutarlı kullanıcı deneyimi için Primer tasarım sisteminin genelinde Toast kullanımı sonlandırılıyor

Toast’lara genel bakış

  • Toast, ekranın alt köşesinde kısa süreliğine beliren küçük dikdörtgen bir bildirim penceresidir; kullanıcı veya sistem eylemleriyle tetiklenir
  • Belirli bir sürenin ardından otomatik olarak kaybolan bu yapı, erişilebilirlik ve kullanılabilirlik sorunlarını içinde barındırır
  • GitHub bu nedenle daha güvenilir ve erişilebilir iletişim yöntemlerini öneriyor

Toast yerine alternatifler

  • Kullanım amacına göre uygun arayüzün seçilmesi gerekir
    • Basit başarı bildirimlerinde, ek bir geri bildirim olmadan sonuç ekranının kendisiyle doğrulama yapılabilir
    • Karmaşık işlemlerde başarı durumu banner veya aşamalı içerik gösterimi ile iletilebilir
    • Başarısız işlemlerde hata bilgisi banner veya dialog üzerinden sunulabilir
  • Form gönderimi durumunda, basit formlarda ayrı bir onay gerekmez; karmaşık formlarda ara onay sayfası veya banner kullanılabilir
  • Girdi doğrulaması için Primer’ın mevcut form doğrulama bileşenleri kullanılmalı
  • Uzun süren işlemler için tamamlanma durumu banner ya da e-posta ve push bildirimleri gibi başka kanallar üzerinden iletilmeli
  • Oturum eşzamansızlığı oluştuğunda, yenileme gerekliliği dialog veya banner ile bildirilmeli

Erişilebilirlik değerlendirmeleri (Accessibility Considerations)

  • Toast arayüzü, çeşitli WCAG başarı ölçütlerini ihlal etme potansiyeline sahiptir
    • 2.2.1 Timing Adjustable (A) : kullanıcı kapatana kadar görünür kalması gerekir
    • 1.3.2 Meaningful Sequence (A) : DOM sırası ile görsel sıra arasındaki uyumsuzluk, yardımcı teknolojilerde kafa karışıklığı yaratabilir
    • 2.1.1 Keyboard (A) : toast içindeki etkileşimler klavyeyle kontrol edilebilir olmalıdır
    • 4.1.3 Status Messages (AA) : varlığı, yardımcı teknolojilere müdahalesiz biçimde duyurulmalıdır
    Reklam
  • Ayrıca ihlal riski taşıyan başka ölçütler de vardır
    • 1.4.4 Resize text (AA) : metin boyutu artırıldığında ekranı kapatma veya taşma riski oluşabilir
    • 1.4.10 Reflow (AA) : yatay kaydırma sırasında klavye erişilebilirliğinin korunması gerekir
    • 2.4.3 Focus Order (A) : odak sırasının karışma ihtimali vardır
    • 3.2.4 Consistent Identification (AA) : kod tarafında tutarlılığın korunması gerekir

Kullanılabilirlik değerlendirmeleri (Usability Considerations)

  • Büyük ekranlarda toast, görüş alanının dışında kalabilir ve fark edilmeyebilir
  • Otomatik kapanma durumunda, kullanıcı başka bir işle meşgulse mesajı kaçırma riski vardır
  • Arayüzü kapatma sorunu: toast, alttaki düğmeler gibi önemli öğelerin üzerini kapatabilir
  • Ekranı büyüterek kullanan kullanıcılar, büyütülen alanın dışındaki toast’ı göremeyebilir
  • Çalışma belleği sorunu: otomatik kaybolma nedeniyle bilgi tekrar kontrol edilemez
  • Banner körlüğü: aşırı kullanım nedeniyle kullanıcılar bunları görmezden gelmeye eğilimli olabilir
  • Konum uyumsuzluğu: tetiklenen arayüz ile toast arasındaki fiziksel mesafe, ilişkiyi anlamayı zorlaştırabilir
  • Hatalı kapatma davranışı: Esc tuşunun başka arayüzleri de birlikte kapatmasına yol açabilir

Ek kaynaklar

İlgili okumalar

1 yorum

 
GN⁺ 2025-12-12
Hacker News görüşleri
  • Erişilebilirlik üzerine ders verirken, tıklamadan sonra 3 saniyelik bir gecikme yaşandı ve hiçbir tepki yokmuş gibi hissettirdi
    • Banner’a tıklayınca hiçbir gösterge olmadan bekletiyor, sonra da alakasız bir sayfaya yönlendiriyordu; bu oldukça sinir bozucuydu
    • Sorunun, yükleme sürdüğünü bildiren geri bildirimin olmaması olduğunu düşünüyor
    • Birisi bunun sadece basit bir `` bağlantısı olduğunu, gecikmenin ise gereksiz yere ağır olan sayfadan kaynaklandığını söylüyor
    • Bir başkası ise yavaş 4G’de bile anında tepki verdiğini, dolayısıyla sorunun tarayıcı veya ağ kaynaklı olabileceğini öne sürüyor
  • GitHub Primer dokümanını ilgi çekici buldu
    • Her şeye katılmasanız bile öğrenilecek şeyler var ve sezgiyle hareket etmekten çok daha iyi hissettiriyor
    • Bilgi olarak, Apple ve Android de kendi tasarım yönergelerini sunuyor
  • Sonunda bu tür bir trendin yayılmasını umuyor
    • Toast bildirimleri yüzünden kaçırdığı çok fazla mesaj olmuş
    • Başka bir kullanıcı, “toast’lar erişilebilirlik sorunları nedeniyle önerilmez” ifadesine tamamen katıldığını; bir bildirim merkezi olsaydı biraz daha iyi olacağını ama bunun yine de kötü bir yaklaşım olduğunu vurguluyor
  • Toast’ları müdahalesiz onay için seviyor ama önemli bilgileri iletmek için uygun bulmuyor
    • Başka biri, toast kullanım bağlamlarını daha ayrıntılı biçimde ayırıyor
      • Butona tıklandıktan hemen sonra tepki gerekiyorsa → geri bildirimi butonun kendisinde vermek daha iyi
      • Kısayol tepkisi → uygun
      • Uzun süren bir işin tamamlandığını bildirme → uygun ama kalıcı bir bildirim kutusu gerekli
      • Sayfaya girerken uyarı gösterme → önemliyse sayfa içinde kalıcı bir bildirim olarak görünmeli
    • React’ta genel toast() çağrısı kolay olduğu için kötüye kullanılma eğilimi var; bunun yerine useAlerts() benzeri bir yapıya geçmenin çok daha iyi olacağını öneriyor
  • Toast’lar onun için turnike gibi
    • Acil sorunları geçici olarak durdurmakta faydalı ama uzun vadede tutulmamalı
    • Yeni projede geri bildirim eksikse geçici olarak ekleyip, UI iyileştikçe tek tek kaldırmak için kullanılmalı
    • GitHub gibi büyük organizasyonların böyle geçici çözümlere ihtiyacı yok ama küçük ekiplerde durum farklı olabilir
  • GitHub dokümanındaki “çok sayıda Issue oluşturulurken ek geri bildirim gerekir” kısmını beğenmiş
    • GitHub Actions tarafında da böyle bir geri bildirim olsa iyi olurdu; çalıştırdıktan sonra sonuçların görünmesi çok uzun sürüyor
  • UI genelinde eylem günlüğü olarak toast kullanma fikrini beğeniyor
    • Her tıklamada kaybolan geri bildirim yerine, Sonner gibi iyi uygulanmış örnekler var
  • Tarayıcı düzeyinde toast için yerel destek düşünmenin zamanı gelmiş gibi görünüyor
    • Zamanlama ayarı, bildirim merkezi, ekran okuyucu entegrasyonu gibi erişilebilirlik iyileştirmeleri mümkün olabilir
    • Görsel olarak fena değil ama çok hızlı kaybolduğu için sık sık kaçırılıyor
    • Görme engelli kullanıcıların yaşadığı sorunları doğrudan anlamanın zor olduğunu ama erişilebilirliği artırma yollarını duymak istediğini söylüyor
  • Toast’ların avantajı uygulamasının kolay olması ve tasarım yükünün az olması
    • Dezavantajı, kolayca gözden kaçabilmesi ve diğer bilgilerin üstüne binme riski taşıması
    • İmkân varsa tüm toast’ları kaldırmanın daha iyi olduğunu düşünüyor
    • Başka biri, “kolay yapıldığı için sorunu çözüyormuş gibi görünen bir yama olarak kötüye kullanılıyor” diye belirtiyor
    • Bir başkası ise toast’ı sadece iç rahatlatan bir geri bildirim olarak kullandığını söylüyor
    • Buna karşılık biri, “toast’lar düşük önemdeki olaylara anlık geri bildirim vermek için faydalı araçlar” diyerek modal pencere veya sabit alanlardan daha verimli olduğunu savunuyor
    • Bir aracın kötüye kullanılmasını gerekçe göstererek onu tamamen dışlayan siyah-beyaz yaklaşımı eleştiriyor
  • “GitHub’ın toast’ları kaldırmasının erişilebilirlik için kötü haber olduğu” yönünde bir yazı görmüş
    • Birisi bu iddiayı garip buluyor
      • GitHub toast’ları kaldırmak yerine W3C üzerinden tarayıcı standardı oluşturmalıydı demenin zorlama olduğunu düşünüyor
      • Oluşturulan öğelerin listede görünmesinin zaten yeterli geri bildirim olduğunu savunuyor
    • Başka biri de “toast’ların erişilebilirlik ve UX için kötü olduğunu söyleyip, GitHub’ı bunu tarayıcıya standartlaştırmadığı için eleştirmek çelişkili” diyor