Mobil Dokunma Hedefi: 3 cm Tavsiyesi Neden Ekrana Sığmıyor

Mobil kullanılabilirlik listelerinde dolaşan bir tavsiye var: dokunmatik hedefleri en az 3 cm yap. Rakam kulağa cömert geliyor, kimse hesabı yapmadığı için de itiraz görmüyor. Hesabı yapınca tavsiye çöküyor, geriye kullanılabilir bir taban kalıyor. Aşağıda o tabanı ve yanında yürüyen üç iddiayı (ses, animasyon, her yöne kaydırma) ayrı ayrı ele alıyorum.

3 cm hesabı tutmuyor

CSS'te 1 cm 37,8 piksele karşılık gelir. 3 cm, yaklaşık 113 piksel eder. Yaygın bir telefon viewport genişliği 390 piksel. Yan yana üç hedef 340 piksel tutar, araya 8 piksellik boşluk koysanız 356'da kalır, sığar. Dördüncüsü 453 piksele çıkar ve taşar.

Yani 3 cm kuralı, dört sekmeli bir alt menüyü imkânsız kılıyor. Beş sekmeli olanı hiç konuşmuyoruz. Tavsiyeyi verenlerin aklındaki arayüz, ekranda tek bir büyük düğme olan arayüz; gerçek uygulamalarda böyle bir ekran neredeyse yok.

Taban 24, hedef 44, güvenli 48

Kullanılabilir sayılar şunlar. WCAG 2.2'nin 2.5.8 Target Size (Minimum) ölçütü 24x24 CSS pikselini alt sınır olarak koyuyor; bu gerçekten alt sınır, konfor değil. Aynı standardın gelişmiş seviyesi (2.5.5) 44 piksel istiyor. Apple'ın kendi kılavuzu 44 pt, Google'ın Material'i 48 dp diyor. Santimetreye çevirirsek 44 pt yaklaşık 1,16 cm, 48 dp yaklaşık 1,27 cm. Önerilen 3 cm'in neredeyse üçte biri.

İkisi arasında seçim yapmak gerekirse 48 dp'yi 44 pt'den daha güvenilir bir taban bulurum: dokunma hedefi görsel kutuyla aynı şey değil, ikonun kendisi 24 piksel kalıp çevresine dolgu eklendiğinde 48 rakamı parmak payını daha rahat tutuyor. Ayrıca ekranın köşelerine yakın hedeflerde isabet oranı düşer, oradaki düğmeyi zaten tabanın üstünde tutmanız gerekir.

Boyutu büyütmenin bedava olmadığını da söylemek lazım. Hedefi büyütmek demek, aynı ekrana daha az şey koymak demek. Bir listede satır yüksekliğini 40'tan 56 piksele çıkardığınızda kaydırmadan görünen satır sayısı dörtte bir azalır. Bu bir tasarım kararı, iyileştirme değil.

Ses geri bildirimi mobilde çalışmıyor

"Yazı yerine sesli geri bildirim verin" tavsiyesi masaüstü alışkanlığından geliyor. Telefonlar sessizde duruyor. Sessizdeki bir cihazda ses geri bildirimine dayanan tasarım, hiç geri bildirim vermeyen tasarımdır.

Mobilde karşılığı titreşim. Tarayıcıda navigator.vibrate(), native tarafta haptic API'leri bunu yapar. İkisinin de sınırı var: iOS'ta Safari titreşimi desteklemiyor, dolayısıyla web tarafında titreşimi ana kanal değil, destek kanalı olarak kurmak gerekir. Asıl geri bildirim görsel kalır: dokunulan ögenin durum değiştirmesi, düğmenin basılı görünmesi, işlemin ilerlediğini gösteren bir şey. Bunu üç satır CSS ile çözersiniz, kütüphaneye gerek yok.

Animasyon iddiası erişilebilirlik iddiasıyla çakışıyor

Aynı metinde "canlı animasyonlar kullanın" ve "erişilebilir tasarım yapın" yan yana durursa biri yanlıştır. Hareket, vestibüler rahatsızlığı olan kullanıcılarda baş dönmesi ve bulantı yaratır; işletim sistemleri bu yüzden "hareketi azalt" ayarı sunar, CSS de prefers-reduced-motion ile bunu okur. Dikkat çekmek için konan animasyon, bu ayarı açmış kullanıcı için zarardır.

Doğru kurgu şu: animasyon dekor değil, durum değişimini anlatan bir araç. Panel nereden açıldı, öge listeden nereye gitti. Bunun dışındaki hareketi prefers-reduced-motion: reduce altında kapatın. Kapatınca arayüz anlaşılmaz hale geliyorsa animasyona anlam yüklemişsiniz demektir, o anlamı başka yere taşımanız gerekir.

Her yöne kaydırma: maliyeti kim ödüyor

"Sadece yukarı aşağı değil, sağa sola ve çapraz da kaydırılabilsin" tavsiyesi arayüzü zenginleştirmiyor, çakıştırıyor. Yatay kaydırma hareketi iOS'ta geri gitme, Android'de kenar menüsü ile aynı alanı paylaşır. Çapraz hareket ise sistem tarafında tanımlı değil, yani eşik ve açı hesabını kendiniz yazarsınız; dikey listeyle iç içe geçtiğinde kaydırma mı sürükleme mi olduğunu ayırmak için uğraşırsınız. Tek bir jestin hata ayıklama maliyeti, getirdiği kolaylığı kolayca aşar.

Jest sayısı arttıkça keşfedilebilirlik düşer. Kullanıcı görünmeyen hareketi tahmin etmez. Dolayısıyla kural tersi: mobilde bir jest ancak eşdeğer bir görünür kontrol varsa eklenir.

Kaynak metnin bir doğru yanı

Talimat okunmadığı tespiti doğru. Kullanıcı açıklama kutusunu geçer, deneyip görmeye çalışır. Buradan çıkan sonuç "metin yazma" değil, "metni etikete indir": düğmenin üzerinde ne yaptığı yazsın, altında üç satır açıklama olmasın. İkonu yalnız bırakmayın, yanına kelime koyun; tanınmayan ikon kullanıcıya hiçbir şey anlatmaz.

Yaşlı kullanıcı, çocuk ya da acele eden herkes aynı davranışı gösterir: okumaz, dener. Arayüzü denemeye açık ve geri dönülebilir yapmak, bu kitlelerin hepsini birden kapsar. Geri alma düğmesi, onay ekranından daha iyi çalışır.