Modal ve popup tasarımı: ne zaman, nasıl?

Kısaca

Modal, açılır pencerenin en sert halidir. Arkadaki sayfa onu kapatana kadar kullanılamaz. NN/g'nin tarifi kısa: modallar kullanıcıyı böler ve ondan bir eylem ister.

Popup ise daha geniş bir kelime. Günlük dilde bülten penceresi, kampanya kutusu ve sohbet balonu için de kullanılır. Bu sayfada ikisini birlikte ele alıyorum, çünkü sorunları aynı yerden çıkıyor.

Çerez ve KVKK onay bantları bu sayfanın konusu değil. Onların kuralları farklı.

Modal ne zaman kullanılır, ne zaman kullanılmaz?

Kısa cevap: kullanıcı o an o kararı vermek zorundaysa modal, değilse sayfanın kendisi. Therese Fessenden'in NN/g yazısı modalın bedelini açıkça sayar. Modal o anki işi durdurur, kullanıcıya bir hedef daha ekler. Üstelik önemli içeriği örtüp bağlamı ortadan kaldırabilir.

Aynı yazı modalın uygun olduğu dört durum sayar. İlki kritik hataları önleyen uyarılardır, ikincisi süren işin devamı için şart olan bilgidir. Karmaşık bir işi adımlara bölmek ve kullanıcının işini belirgin biçimde azaltacak bir soru sormak da listede. Aşağıdaki kartlarda en sık karşılaştığım durumları ikiye ayırdım: kullanın ve kullanmayın.

• Kullanın

  Geri alınamaz bir işlemden önce

  "Bu adresi silerseniz kayıtlı siparişlerinizden de kalkar." Kaydedilmemiş değişikliklerin kaybolacağı an da bu gruba girer.

• Kullanın

  Kullanıcının başlattığı iş eksik bilgi yüzünden duruyorsa

  Ürünü favorilere eklemek isteyen ama giriş yapmamış kullanıcıya giriş penceresi açmak buna örnektir.

• Kullanmayın

  Akışla ilgisi olmayan bilgi için

  Bülten kaydı ya da uygulama indirme çağrısı buna örnektir. Bunlar sayfada bir bant ya da kart olarak durabilir.

• Kullanmayın

  Ödeme gibi kritik bir akışın ortasında

  Ödeme adımında açılan bir kampanya penceresi dikkati dağıtır ve kullanıcının güvenini sarsabilir.

Form hatalarını da modalda göstermeyin. NN/g, formdaki bir hatanın sayfada, oluştuğu yerin yanında gösterilmesini önerir. Hata metnini nasıl yazacağınızı hata mesajları kalıbında anlattım.

Ödeme akışı için ayrı bir uyarı var. Fessenden, ödeme gibi riski yüksek akışları bölen modallardan kaçınmayı önerir. Gereksiz bir modal en iyi ihtimalle dikkati dağıtır, en kötü ihtimalle güveni sarsar. Checkout kalıbında bu adımları sade tutmanın başka yollarını da topladım.

Modal gerekmiyorsa modal olmayan bir pencere ya da sayfa içi bir alan seçin. Yeni e-posta yazma penceresini düşünün: yazarken arkadaki içeriği okumaya devam edebilirsiniz.

Açılış zamanlaması: sayfa açılır açılmaz popup

İlk sorun zamanlama. Anna Kaley'nin NN/g yazısına göre sayfa açılır açılmaz gelen popup, kullanıcıyı değer görmeden böler. Kaley yalnızca bir istisna tanır: site yasal olarak çerez onayı istemek ya da yaş doğrulamak zorundaysa.

Kaley'nin önerisi şu: popup'ı içerik kullanıcı için anlamlı hale geldiğinde gösterin. Bülten isteğini bir yazı okunduktan sonra sorun. Geri bildirim anketini kullanıcı ana işini bitirdiğinde açın.

Kaley birkaç yaygın hatayı daha sayar:

• Girişten hemen sonra açılan popup, kullanıcının bir sonraki adımını böler.
• Aynı anda açılan birden fazla popup, her birini ayrı ayrı kapattırır. Bir seferde tek pencere gösterin.
• Kritik bir işin ortasında açılan anket yerine sayfanın kenarında sabit bir geri bildirim bağlantısı yeter.

Kathryn Whitenton da NN/g'de benzer bir şey söyler. Ona göre en güvenli yol, pencereyi kullanıcının kendi tıklamasıyla ya da gerçekten acil mesajlar için açmaktır. Örneklerinden biri, ziyaretçi siteden ayrılmak üzereyken açılan ve bu yüzden onu bölmeyen bir penceredir.

İşin arama tarafı da var. Google Search Central, içeriği örten geçiş sayfalarının ve pencerelerin zayıf arama performansına yol açabileceğini söyler. Yerine ekranın küçük bir kısmını kaplayan bantları önerir.

Kapatma yolları: X, Esc ve dışarı tıklama

Modal açıyorsanız kapatmayı da kolaylaştırın. Whitenton iki şeyi açıkça ister: görünür bir kapatma komutu ve klavye kullanıcıları için Esc tuşu.

Dışarı tıklayınca kapanma ancak ek bir yol olabilir. Whitenton'a göre birçok kullanıcı bunu bilmez. Dokunmatik ekranda da pencere yanlışlıkla kapanabilir, bu yüzden bilgi isteyen pencerelere ayrıca bir Vazgeç butonu koyun.

Çarpıyı küçük ve soluk çizmek bence çoğu zaman bilinçli bir tercih. "Hayır, indirim istemiyorum" gibi kullanıcıyı utandıran kapatma metinleri de aynı aileden. Bu tür hileleri dark pattern rehberinde topladım. Çarpının basılabilir alanı için ölçüleri dokunma alanı kalıbında bulabilirsiniz.

Esc'in bir de erişilebilirlik tarafı var. WCAG 2.2'nin 2.1.2 Klavye Tuzağı Yok ölçütü A seviyesindedir. W3C'nin açıklamasına göre odağı modalın içinde tutmak ölçütü ihlal etmez, yeter ki kullanıcı oradan nasıl çıkacağını bilsin. W3C, Esc'i yaygın bir standart çıkış yolu olarak anar.

Odak tuzağı ve odak iadesi

Ekranda pencere açılınca gözümüz onu görür. Klavye ve ekran okuyucu kullanıcısı ise odak nereye giderse orayı görür. W3C'nin WAI-ARIA Yazım Pratikleri Rehberi (APG) modal pencere için şu davranışı tarif eder:

1. Açılınca odak içeri girer. Genelde ilk odaklanabilir öğeye gider. Uzun içerikte en üstteki sabit bir öğeye, geri dönüşsüz bir işlemde en az zararlı seçeneğe gidebilir.
2. Tab içeride döner. Son öğede Tab'a basınca odak ilk öğeye, ilk öğede Shift+Tab'a basınca son öğeye geçer.
3. Esc kapatır.
4. Kapanınca odak açan öğeye döner. O öğe artık yoksa akışa uygun başka bir öğeye gider.

APG ayrıca pencereye role="dialog", aria-modal="true" ve görünür başlığa bağlanan aria-labelledby ister. aria-modal yalnızca dışarıdaki tüm etkileşimler gerçekten engellenmişse ve dışarısı görsel olarak örtülmüşse kullanılmalı.

Bugün bunların çoğunu tarayıcı kendisi yapıyor. MDN'ye göre <dialog> öğesi showModal() ile açılınca sayfanın geri kalanı etkisiz hale gelir ve Esc pencereyi kapatır. Odak da içerideki ilk odaklanabilir öğeye gider.

Odak iadesini ise ben her zaman kendim yazarım. Aşağıdaki küçük örnek bunun için yeterli:

<button type="button" id="ac">Bültene katıl</button>

<dialog id="bulten" aria-labelledby="bulten-baslik">
  <h2 id="bulten-baslik">Bültene katılın</h2>
  <button type="button" id="kapat" aria-label="Kapat">×</button>
  ...
</dialog>

<script>
  const ac = document.getElementById('ac');
  const d = document.getElementById('bulten');
  ac.addEventListener('click', () => d.showModal());
  document.getElementById('kapat')
    .addEventListener('click', () => d.close());
  d.addEventListener('close', () => ac.focus());
</script>

Deneyin: kötü modal, iyi modal

İki modal da aynı bülten kutusunu gösteriyor. Fark, klavyeyle kullanınca ortaya çıkıyor. Önce kötü olanı açın ve Tab'a basın, sonra iyi olanla karşılaştırın.

Kötü modalda odak, örtülü sayfanın butonlarında dolaşır. Ekran okuyucu kullanıcısı modalın açıldığını hiç duymayabilir. İyi modalda Esc, Kapat, Vazgeç ve boş haldeyken dışarı tıklama pencereyi kapatır. Her seferinde odak açan butona döner.

Mobilde tam ekran

Masaüstünde ortada duran küçük kutu, telefonda çoğu zaman sorun çıkarır. Whitenton, kapatma kontrolleri ekran dışına taşan ya da yakınlaştırmayı engelleyen pencerelerin içeriği tamamen kilitleyebildiğini yazar. Kaydırmayı kapatmak da kullanıcıyı kontrollere ulaşamaz halde bırakabilir.

Fessenden'in yazısında da bir örnek var. Masaüstünde modal olmayan bir pencere mobilde tam ekran bir modala dönüşüyor. Aynı bileşen ekrana göre farklı davranabilir. Bunu baştan bilerek tasarlayın.

Benim tercihim şu: içinde form olan modal dar ekranda tam ekran açılır. Başlık ve Kapat butonu en üstte durur, ana buton tam genişliktir. Yukarıdaki iyi modal 600 pikselin altında böyle davranıyor. Telefonda klavye açıldığında alanların görünür kalması için mobil form ve klavye kalıbına bakın.

Benim notum

Audit'lerde en sık gördüğüm modal sorunu zamanlama. Ana sayfaya girer girmez bülten penceresi açılıyor, kapatınca bu kez sohbet balonu çıkıyor. Kullanıcı ürünü görmeden iki pencere kapatmış oluyor.

Onu odak iadesi izliyor. Pencere düzgün açılıyor, Esc ile kapanıyor, ama odak sayfanın başına düşüyor. Klavyeyle gezen kullanıcı kaldığı yeri baştan aramak zorunda kalıyor.

Küçük çarpı da listede üst sıralarda. Tasarım dosyasında küçük bir ikon olarak çiziliyor, kodda da o boyutta kalıyor. Telefonda başparmakla basmak için birkaç deneme gerekiyor.

Bunları bulmak için özel bir araca gerek yok. Fareyi bırakın ve pencereyle işinizi yalnızca Tab, Shift+Tab, Enter ve Esc ile bitirmeye çalışın. Sonra aynı denemeyi telefonda tek elle yapın.

Bir de şunu öneririm: yeni bir modal eklemeden önce aynı içeriğin sayfada durup duramayacağını sorun. Benim deneyimimde cevap çoğu zaman evet çıkıyor.

Kontrol listesi

Bir ürüne modal eklemeden önce bu listeye bakarım. Kendi ürününüzdeki pencereleri benim gözden geçirmemi isterseniz UX Audit bunu kapsar.

• Modal, kullanıcının o an vermesi gereken bir karar için açılıyor.
• Sayfa açılır açılmaz değil, kullanıcının bir eyleminden sonra açılıyor.
• Aynı anda tek pencere var.
• Görünür bir Kapat butonu var ve basılabilir alanı yeterince büyük.
• Esc pencereyi kapatıyor.
• Bilgi isteyen pencerede ayrıca bir Vazgeç butonu var.
• Açılınca odak pencerenin içine giriyor.
• Tab ve Shift+Tab pencerenin içinde dönüyor.
• Kapanınca odak açan öğeye dönüyor.
• Pencerenin görünür bir başlığı var ve aria-labelledby ile bağlı.
• Dar ekranda Kapat butonu ekranın dışına taşmıyor.