Kaydırma ve Scrollbar Tasarımı: Neye Dokunulur, Neye Dokunulmaz

Tarayıcı kaydırmayı zaten doğru yapıyor. Sorunlar neredeyse her zaman onun üstüne eklediğimiz şeylerden çıkıyor: yanlış genişlik hesapları, gizlenen çubuklar, içine ikinci bir kaydırma alanı yerleştirilmiş kartlar. Aşağıda bu eklemelerin hangisinin işe yaradığını, hangisinin geri alınması gerektiğini ayırıyorum.

Kaydırmayı kim yönetiyor

Bir sayfada üç ayrı kaydırma katmanı var. Birincisi belgenin kendisi, yani kök kaydırıcı. İkincisi taşan her bloğun kendi kaydırma alanı. Üçüncüsü kullanıcının işletim sisteminden gelen davranış: çubuk sürekli mi görünür, yoksa kaydırma sırasında mı belirir, tekerlek kaç satır ilerletir. Tasarımcı pratikte yalnızca ikinci katmana karışabiliyor, oysa şikayetlerin büyük kısmı birinciden geliyor.

Yatay kaydırma neredeyse hiç tasarım kararı değil

Yatay taşma bilinçli bir tercih olarak çok az karşımıza çıkar. Genelde tek bir elemanın yanlış genişlik hesabıdır. En sık suçlu 100vw: bu birim görünür alanı dikey scrollbar dahil ölçer, yani çubuğun yer kapladığı masaüstü tarayıcılarda 100vw genişliğindeki bir blok sayfayı çubuk kalınlığı kadar, tipik olarak 15-17 piksel taşırır. Bir projede yatay kaydırmanın kaynağını üç gün aradık, sorun tam ekran bir duyuru şeridinin width: 100vw satırıydı.

Suçluyu aramak için elemanlara tek tek bakmaya gerek yok. Konsola şu satır genellikle yetiyor:

[...document.querySelectorAll('*')].filter(e => e.getBoundingClientRect().right > document.documentElement.clientWidth)

"Varsayılanı kullan" ile "ok ekle" aynı anda tutmaz

Klasik scrollbar tavsiyesi iki madde içerir ve bu iki madde birbirini keser. Birincisi platformun varsayılan çubuğundan sapmamayı söyler. İkincisi kaydırma yönünü gösteren okları ihmal etmemeyi. Oysa macOS ve iOS'un varsayılan çubuklarında ok yok, Android'de de yok; ok yalnızca Windows'un klasik çubuğunda duruyor. Varsayılana uyarsanız okları eklemiyorsunuz, oklara sahip çıkarsanız varsayılandan sapıyorsunuz.

Hangisi? Varsayılan. Ok, kaydırmanın keşfedilebilirliği için bir dönem gerçekten gerekliydi; bugün kullanıcı kaydırılabilir bir alanı oktan değil, içeriğin kesilme biçiminden anlıyor. Doğru soru da bu yüzden çubuğun görünürlüğü değil: alanın alt kenarında sahte bir dip oluşuyor mu? Kart tam bir satırın bittiği yerde bitiyorsa kullanıcı içeriğin de orada bittiğini sanır. Son satırı yarıdan kesmek, en belirgin çubuktan daha çok iş yapar.

Kaydırılabilir alanı klavyeyle deneyin

Bir div'e overflow: auto verdiğinizde fare tekerleği çalışır, klavye çalışmaz. Alanın içinde odaklanabilir bir eleman yoksa oraya sekme tuşuyla hiç ulaşamazsınız, dolayısıyla yön tuşlarıyla kaydıramazsınız. Uzun kod blokları, log pencereleri, yana kayan tablolar, takvim ızgaraları: hepsi tam olarak bu durumda.

Çözüm tek satır:

<div class="log" tabindex="0" role="region" aria-label="Sistem günlüğü">

tabindex="0" alanı sekme sırasına sokar, role ve erişilebilir ad ekran okuyucuya orada gezinilecek bir bölge olduğunu söyler. Adı atlamak bu satırın en sık yapılan hatası: adsız bir role="region" landmark listesinde hiç görünmez, yani yazılmamış sayılır.

İç içe kaydırma ve zıplayan düzen

Kaydırma alanı içine kaydırma alanı koymak kendiliğinden hata değil. İki yan etkisi var ve ikisinin de tek satırlık karşılığı var.

İçteki alanın sonuna gelindiğinde kaydırma arkadaki sayfaya devrediliyorsa (modal açıkken en sık görülen şey) overscroll-behavior: contain bunu durdurur. İçerik uzadıkça çubuk belirip sayfa yana zıplıyorsa scrollbar-gutter: stable yeri baştan ayırır. İkisi de sayfayı overflow: hidden ile dondurmaktan iyi çalışır; o yöntem iOS Safari'de kaydırma konumunu kaybettiriyor ve modal kapanınca kullanıcıyı bıraktığı yerden başka bir noktaya düşürüyor.

Özel scrollbar ne zaman gerekir

Neredeyse hiç. Gerçekten gerektiği durum, çubuğun bulunduğu yüzeyle kontrastının yetmemesidir: koyu bir panelin üstünde ince gri bir çubuk görünmez olur. Orada scrollbar-color ile iki değer vermek (çubuk ve oluk) yeter, geometriye dokunmadan. Çubuğu inceltmek, köşelerini yuvarlamak, belirme animasyonu eklemek ise kullanıcının çözülmesini beklediği bir problem değil. Kaydırma, fark edilmediği zaman doğru tasarlanmış demektir.