Checkbox ve Radio Button: Fark, Varsayılan Seçim ve Erişilebilirlik

Checkbox çoklu seçim, radio tek seçim. Herkesin bildiği kısım bu ve kararların çoğunu açıklamıyor. İki kontrol arasındaki daha sessiz fark, seçimin geri alınabilir olup olmaması; varsayılan seçim, zorunlu alanlar ve sunucuya giden veri konusundaki sorunların çoğu oradan çıkıyor.

Asıl ayrım çoklu seçim değil, geri alınabilirlik

İşaretlediğiniz checkbox'ın işaretini kaldırabilirsiniz. Radio grubunda bunu yapamazsınız: bir seçenek seçildikten sonra kullanıcının grubu tekrar boş hale getirmesinin yolu yoktur. Seçili radio'ya tekrar tıklamak onu bırakmaz, klavyeyle de bırakamazsınız; tek çıkış formu sıfırlamaktır.

Bunun pratik sonucu şu: radio grubu "henüz cevaplamadım" ile "cevap vermek istemiyorum" durumlarını taşıyamaz. Taşıması gerekiyorsa bu durumu listede açık bir seçenek olarak yazmanız gerekir. Zorunlu olmayan bir soruyu radio ile sorup kullanıcıya geri dönüş bırakmamak, yanlışlıkla tıklanan ilk seçeneği kalıcı veriye çevirir.

Varsayılan seçim tavsiyesi sanıldığı kadar masum değil

"Radio grubunda en sık tercih edilen seçenek işaretli gelsin" tavsiyesi hemen her form rehberinde var. Yarısı doğru. Ayar niteliğindeki, sonucu tersine çevrilebilir sorularda, mesela teslimat hızında, işaretli bir varsayılan tıklama sayısını azaltır ve kimseyi yanıltmaz.

Veri topladığınız sorularda tam tersi olur. Önceden işaretli bir seçeneği kullanıcı hiç okumamış olabilir, ama kayıtta bilinçli bir cevaptan ayırt edilemez. Üstelik bir önceki bölümdeki kısıtla birleşince durum kapanır: kullanıcı grubu boşaltamadığı için elinizde "cevaplanmadı" diye bir değer kalmaz. Anket sonucuna bakıp dağılımı yorumlayan kişi, aslında kendi varsayılanınızı ölçmüş olur. Kararın pratik hali: tercih sorusunda varsayılan koyma, ayarda koy.

Cinsiyet sorusu kötü bir radio örneği

Kaynak metinlerde radio'nun klasik örneği hep cinsiyet seçimidir. İki değerin birbirini dışlaması bir arayüz kuralı değil, sizin veri modeliniz hakkında bir tercih. Bu veriyi gerçekten bir yerde kullanmıyorsanız soruyu formdan çıkarın; kullanıyorsanız seçenekleri eksiksiz listeleyin ya da serbest metin alanı bırakın. Zorunlu, iki şıklı ve geri alınamaz bir soru, formu terk etme sebebi olabilecek kadar sert.

Checkbox her zaman "gönder"i beklemez

"Kullanıcının seçimleri form gönderilene kadar uygulanmamalı" kuralı form bağlamında doğru, ama ayar ekranlarında artık öyle çalışmıyor. Bildirim tercihlerinde, karanlık temada, gizlilik ayarlarında beklenen davranış seçimin anında kaydedilmesi.

Bu durumda kontrolün görünümü de değişmeli. Kare bir onay kutusu kullanıcıya "bir yere basman gerekecek" der; toggle switch ise "oldu" der. Ekranda gönder düğmesi varsa checkbox, yoksa switch. Aynı ekranda ikisini karıştırıp bazısını anında bazısını gönderimde uygulamak, kullanıcının hangi değişikliğin geçtiğini bilmemesine yol açıyor.

Etiket, klavye ve 24 piksel

Yerleşik checkbox tarayıcıda 13 piksel civarında çizilir. WCAG 2.2'nin 2.5.8 kriteri (Target Size, Minimum, AA seviyesi) dokunma hedefi için 24x24 CSS pikseli istiyor. Yani kutunun kendisi tek başına hiçbir zaman yeterli değil; tıklanabilir alanı büyüten şey etiket.

• Etiketi kontrole bağlayın: ya <label for='kvkk'> ile id eşleyin, ya input'u label'ın içine alın. İkincisi id uydurmaktan kurtarır.
• Etikete dikey padding verin, böylece 24 pikselin altına düşmeyin. Metni uzun etiketlerde satır boyunca tıklanabilir bırakın.
• İlişkili seçenekleri fieldset ve legend ile gruplayın; ekran okuyucu soruyu seçeneklerden ayırt etmek için buna bakıyor.

Kontrolü div ve ikonla yeniden yazarken kaybedilen şey genelde klavye davranışı oluyor. Yerleşik radio grubunda Tab gruba girer ve çıkar, seçim ok tuşlarıyla değişir; checkbox'ların her biri ayrı bir Tab durağıdır ve boşluk tuşuyla durumunu değiştirir. Bunu sıfırdan yazarsanız odak yönetimini, aria-checked değerini ve ok tuşlarını elle kurmanız gerekir. Görsel özelleştirmenin tamamı zaten CSS ile mümkün olduğu için bu maliyete girmeye değmez.

Sunucuda işaretsiz kutu diye bir şey yok

Arayüz tarafında üç durum görüyorsunuz: işaretli, işaretsiz, hiç sorulmamış. İstek gövdesinde iki durum var. İşaretlenmemiş bir checkbox hiç gönderilmez, dolayısıyla sunucuda false değil, alanın yokluğunu görürsünüz. Kullanıcının bilinçli olarak işareti kaldırdığı bir ayarı güncellerken bu sessizce yanlış sonuç verir, çünkü "gönderilmedi" ile "kapatıldı" aynı görünür.

Çözüm eski ve hâlâ geçerli: her checkbox'tan önce aynı adla gizli bir input koyup varsayılan değeri yazmak, ya da formun hangi alanları taşıdığını sunucuda ayrıca bildirmek. Çoklu seçimde name='ilgi[]' biçimini kullanmak listeyi toplamayı kolaylaştırır ama bu sorunu çözmez: hiçbiri seçilmediğinde dizi de gelmez (modern framework'lerin bir kısmı bunu kendi içinde hallediyor, bir kısmı hallettiğini iddia ediyor).

Bu konunun SEO ile ilgisi yok

Form kontrollerinin SEO başlığı altında anlatılması yaygın, ama altı boş. Checkbox'ı kare mi yuvarlak mı çizdiğiniz, etiketi bağlayıp bağlamadığınız arama sonuçlarında bir karşılığa dönüşmüyor. Etiketi bağlamanın gerekçesi erişilebilirlik ve tamamlanma oranı; bunlar yeterince güçlü gerekçeler, araya sıralama vaadi sıkıştırmaya gerek yok.