Değişim Körlüğü: Arayüzdeki Güncellemeyi Kullanıcıya Fark Ettirmek

Kullanıcı ekrana bakarken bile arayüzdeki değişikliği görmeyebilir. Hata mesajı sayfaya düşer, filtre sonucu yenilenir, menüdeki aktif bölüm değişir; kullanıcı hiçbirini fark etmez ve aynı butona tekrar basar. Buna değişim körlüğü deniyor ve çözümü değişikliği büyütmek değil, doğru yere koymak.

Sinyal üretmeyen değişiklik yok sayılır

Göz ekranın tamamını taramaz, bir noktaya kilitlenir ve çevresini kabaca görür. Bakılan noktanın dışındaki bir değişiklik ancak kendi hareket sinyalini üretirse fark edilir: renk değişimi ya da kısa bir kayma hareketi.

Bu sinyali iki şey yok eder. Birincisi kesinti: sayfa yenilenir, ekranın tamamı bir anda değişir, küçük ekleme bu büyük değişimin içinde kaybolur. İkincisi mesafe: değişiklik görüş alanının dışında kalır, sinyal üretilse bile kimsenin gözüne girmez.

Hata mesajını kullanıcının baktığı yere koy

Form gönderildi, sunucu 422 döndü, mesaj sayfanın en üstüne yazıldı. Kullanıcı o sırada ortadaki alana bakıyordu, mesajı görmedi, butona basmayı sürdürüyor. Hatalı alanın hemen altına yazılan tek satır, sayfanın tepesindeki kırmızı kutudan daha iyi çalışır; gözün zaten bulunduğu yerdedir.

Kritik hatayı köşede açılıp kaybolan bir toast bildirimine bırakmam. Toast hem odak noktasından uzakta hem de süreli, kullanıcı iki saniye başka yere baktıysa mesaj hiç var olmamış sayılır. Toast geri alınabilir işlemler için iyi bir yer: silme, arşivleme. Kullanıcının düzeltmesi gereken hata için değil.

"Sayfa yenileme, AJAX kullan" tavsiyesinin eksik yarısı

Tavsiye yanlış değil ama yarısı söylenmemiş. Tam sayfa yenileme ekranın tamamını değiştirdiği için küçük eklemeyi gizler, bu yüzden kötü. AJAX ile yalnızca ilgili bölümü güncellemek kesintiyi kaldırır, yerine sessizliği koyar: bölüm güncellenirken kullanıcının gözü başka yerdeyse fark edilecek bir şey kalmaz. Güncellemenin görünür olması, güncellenen alanın o anda ekranda olmasına bağlı.

Bunu tahmin etmek yerine ölçebilirsin. IntersectionObserver ile hedef elemanın görünür olup olmadığına bak; görünür değilse mesajı oraya değil kullanıcının bulunduğu yere taşı ya da güncellenen bölüme götüren bir bağlantı göster. Ek kütüphane gerekmiyor.

Ekran okuyucuda değişiklik DOM'a düşmekle duyurulmuş olmaz

Görsel sinyal ekran okuyucuya hiçbir şey anlatmaz. DOM'a eklenen mesaj, canlı bölge olarak işaretlenmediği sürece sessizce eklenir. aria-live="polite", hata içinse role="alert" bunu çözer, tek şartla: canlı bölge kabı sayfada önceden durmalı, mesaj sonradan içine yazılmalı. Kabı ve mesajı aynı anda eklersen çoğu ekran okuyucu yeni düğümü duyurmaz, çünkü izlediği bir bölge yoktur.

Pratikte şu demek: boş bir <div aria-live="polite"></div> şablonda hazır dursun, filtre sonucu döndüğünde içine "38 ürün listelendi" gibi bir cümle yaz. Görsel kullanıcı bu metni görmez, görmesi de gerekmez.

Animasyon tek sinyal olmasın

Geçiş animasyonu değişimi görünür kılmanın en kolay yolu. Ama kullanıcıların bir bölümü işletim sisteminde hareketi kapatıyor ve prefers-reduced-motion sorgusuna uyuyorsan animasyon o kullanıcıda hiç çalışmaz. Animasyon devre dışıyken geriye ne kalıyorsa gerçek sinyal odur. Renk kontrastı ve alan büyümesi hareketsiz de iş görür.

Fark edildi mi, nasıl anlarsın

Kullanıcıya "mesajı gördünüz mü" diye sormanın faydası yok, insanlar gördüklerini sanır. Bunun yerine kayıtta zaten duran bir şeye bak: hata döndükten sonra aynı forma kaç kez daha POST geldiği. Aynı oturumda iki dakika içinde üçüncü kez gelen gönderim, hata mesajının görülmediğini sorup öğrenmekten daha net söyler. Ölçmesi bedava, çünkü log zaten tutuluyor.