Tıklanabilir Alan Boyutu: WCAG'in 24 Piksel Kuralı ve İstisnaları
Bir butonun ne kadar büyük olması gerektiği tasarım zevki gibi görünür, oysa WCAG 2.2 bunun için sayı veriyor: 24x24 piksel. Sayının kendisi kolay, sorun sayının neyi ölçtüğü ve ne zaman geçerli olmadığı. Kuralı ezberleyip uygulayan ekiplerin çoğu istisnaları atlıyor, sonuçta ya gereksiz büyük arayüzler ya da denetimden geçmeyen küçük ikonlar çıkıyor.
Sayı neyi ölçüyor
WCAG 2.2'de hedef boyutuyla ilgili iki başarı ölçütü var. SC 2.5.8 (Target Size - Minimum) AA seviyesinde 24x24 piksel istiyor, SC 2.5.5 (Target Size - Enhanced) AAA seviyesinde 44x44 piksele çıkıyor. Kamuya açık işlerin çoğunda hedeflenen seviye AA olduğu için pratikte konuşulan sayı 24.
Buradaki piksel, ekranın fiziksel pikseli değil CSS pikseli. Bu ayrım tasarımcıyla geliştirici arasında en çok karışan yer: tasarım dosyasındaki 24 birim, 2x veya 3x yoğunluklu bir telefonda 48 ya da 72 fiziksel piksele denk gelir, ama ölçüt yine 24 CSS pikselidir. Yani ölçüyü tasarım dosyasında 1x ölçeğinde kontrol etmek yeterli. Ölçülen şey elemanın görünen kutusu değil, tıklama veya dokunma olayını alan alan; bu ikisi birbirinden ayrılabilir ve çoğu zaman ayrılmalıdır da.
İstisnalar kuralın yarısı kadar önemli
SC 2.5.8 mutlak bir taban değil. Ölçütün kendi metninde beş istisna sayılıyor ve bunları bilmeden yazılan denetim raporları gereksiz yere hata üretiyor.
- Aralık: Hedef 24 pikselden küçük olabilir; yeter ki her hedefin sınır kutusunun merkezine oturtulan 24 piksel çaplı daire, komşu hedefin dairesiyle kesişmesin. Yeterince seyrek yerleştirilmiş küçük ikonlar bu maddeyle uyumludur.
- Eşdeğer: Aynı sayfada, aynı işi yapan ve boyutu tutan başka bir kontrol varsa küçük olan sorun değil.
- Satır içi: Cümlenin içindeki bağlantılar kapsam dışı. Boyutları metnin satır yüksekliğine bağlı olduğu için zaten yazarın kontrolünde değil.
- Tarayıcı varsayılanı: Boyutu tarayıcı belirliyorsa ve siz değiştirmediyseniz sorumluluk sizde değil.
- Zorunlu sunum: Hedefin o boyutta olması işin doğası gereğiyse veya yasal olarak öyle isteniyorsa.
Aralık istisnası en çok işe yarayanı, çünkü ölçütü "her şeyi büyüt" olmaktan çıkarıp "ya büyüt ya ayır" haline getiriyor. Yoğun bir tablonun satır sonundaki düzenle ve sil ikonlarını 24'e şişirmek yerine aralarına boşluk koymak hem uyumlu hem daha okunaklı bir sonuç verir.
Padding büyütür, margin büyütmez
CSS tarafında en sık yapılan hata bu. Padding elemanın kendi kutusunu büyütür, dolayısıyla tıklanabilir alanı da büyütür. Margin ise elemanın dışında boşluk bırakır, o boşluk tıklamayı almaz. 16x16 bir ikona her yönden 4 piksel padding vermek 24x24'e çıkarır; 4 piksel margin vermek hiçbir şeye yaramaz.
Padding'in de bir sınırı var: kutuyu büyüttüğü için ızgarayı bozar, sıkı bir araç çubuğunda ikonlar birbirini iter. Ben bu durumu genelde konumlandırılmış bir pseudo-element ile çözerim, görsel kutu 16x16 kalır, üstüne oturan görünmez bir ::after katmanı hedefi 24'e ya da 44'e taşır:
.icon-btn { position: relative; } .icon-btn::after { content: ""; position: absolute; inset: -8px; }Böylece hizalama bozulmadan dokunma alanı büyür. Tek dikkat edilecek nokta, komşu butonların genişletilmiş alanlarının üst üste binmemesi.
Platform kılavuzları neden farklı sayı söylüyor
Apple 44x44 punto, Google 48x48 dp öneriyor. Bu sayılar WCAG'i geçersiz kılmıyor, onun üstüne kendi platform deneyimlerini koyuyorlar. İkisi çelişmez, biri uyum tabanı diğeri tasarım tavsiyesi.
Eski bir alışkanlık, dokunmatik cihazlara medya sorgusuyla ayrı boyut vermek. Çevrilebilir dizüstüler ve kalemle kullanılan tabletler yüzünden bu ayrım artık güvenilir değil; aynı cihaz dakika içinde hem fare hem parmak girdisi alabiliyor. Girdi türünü tahmin etmeye çalışmak yerine büyük hedefi varsayılan yapmak daha az bakım gerektiriyor.
Ne zaman 24'ün üstüne çıkmalı
Uyum tabanı 24, ama tasarım kararı olarak 24 bana çoğu arayüzde düşük geliyor. Tasarım sistemi kuruyorsanız varsayılan buton yüksekliğini 40 civarına oturtup 24'ü yalnızca yoğun tablo hücreleri ve araç çubukları için özel bir varyant olarak bırakmak daha isabetli. Şu üç durumda daha da yukarı çıkmak gerekiyor: tek elle ve hareket halinde kullanılan uygulamalar, motor kontrolünün zayıfladığı kullanıcı gruplarına yönelik arayüzler, hata maliyetinin yüksek olduğu işlemler.
Ters yönü de var. Sonsuz büyüyen hedefler yanlış tıklamayı artırır, özellikle silme ve onaylama gibi geri dönüşü zor eylemler yan yanaysa. Orada çözüm hedefi büyütmek değil, aralarına mesafe koymak veya yıkıcı eylemi menünün içine almak.
Kaynaklar