Erişilebilir web butonları için kısa ve görüşlü bir kontrol listesi

Buton erişilebilirliği tavsiyelerindeki sorun

Buton erişilebilirliğiyle ilgili rehberlerin çoğu iki uçtan birine düşer: Ya kimsenin okumadığı 40 sayfalık bir WCAG yorumu olur ya da uygulanabilir adımlar olmadan “butonları erişilebilir yapın” gibi belirsiz bir öneri. Perşembe günü bir özellik yayına alırken ikisi de yardımcı olmaz.

Bu kontrol listesi, üretimde en sık gördüğümüz beş buton erişilebilirliği hatasını kapsar. Sizi bir WCAG uzmanı yapmaz, ancak kullanıcıları gerçekten etkileyen sorunları yakalar.

1. Butonlar için button öğesini kullanın

Bir şey buton gibi davranıyorsa, bir <button> öğesi olmalıdır. onclick içeren bir <div> değil, role="button" atanmış bir <span> değil, href="#" ve preventDefault kullanılan bir <a> değil.

<button> öğesi size klavye ile gezinmeyi, odak yönetimini ve ekran okuyucu duyurularını hazır olarak sağlar. Bir <div> kullandığınızda, tüm bunları sıfırdan yeniden inşa edersiniz — ve yanlış yaparsınız.

Tek istisna: eylem yeni bir sayfaya gidiyor veya URL’yi değiştiriyorsa, bir <a> öğesi kullanın. Bağlantılar ve butonlar anlamsal olarak farklıdır. Ekran okuyucu kullanıcıları öğe türüne göre gezinir; butonların eylem gerçekleştirmesini, bağlantıların ise gezinme yapmasını beklerler.

2. Tıklama hedefini en az 44×44 piksel yapın

WCAG 2.5.5 (Düzey AAA), etkileşimli öğelerin minimum hedef boyutunun 44×44 CSS piksel olmasını gerektirir. Bu görsel boyutla ilgili değildir — tıklanabilir alanla ilgilidir.

Yeterli padding’e sahip küçük görsel bir butonunuz olabilir veya tıklama hedefini bir pseudo-element ile genişletebilirsiniz. Önemli olan, kullanıcının tam isabetle hedeflemesi gerekmemesidir.

Mobil kullanıcılar, motor beceri kısıtları olan kişiler ve hareket halindeki bir cihazı kullanan herkes küçük hedefleri kaçırır. 24×24 piksellik bir ikon butonu temiz görünebilir, ancak bu bir kullanılabilirlik hatasıdır.

3. Yalnızca tarayıcı varsayılanları olmayan görünür odak durumları sağlayın

Tarayıcının varsayılan odak halkası hiç olmamasından iyidir, ancak tarayıcılar arasında tutarsızdır ve bazı arka planlarda çoğu zaman görünmez. Tasarım sisteminizde çalışan özel bir odak durumuna ihtiyacınız vardır.

İyi bir odak göstergesi üç niteliğe sahiptir:

• Yüksek kontrast: bitişik renklere karşı en az 3:1
• Görünür boşluk: butonun kendi kenarlığı veya arka planı tarafından gizlenmemeli
• Tutarlı şekil: kullanıcılar bunu arayüzünüz genelinde bir odak göstergesi olarak tanıyabilmeli

outline: none değerini daha iyi bir şeyle değiştirmeden kaldırmayın. Ayrıca odak durumlarını yalnızca sizin kusursuz ışık koşullarında görebileceğiniz kadar incelikli yapmayın.

4. Bağlam dışında da anlamlı olan buton etiketleri yazın

Ekran okuyucu kullanıcıları çoğu zaman butonlar arasında atlayarak gezinir. Bunu yaptıklarında, çevresindeki bağlam olmadan bir buton etiketleri listesi duyarlar.

Bu listede “Daha fazla bilgi” etiketli bir buton işe yaramaz. “Buraya tıklayın” veya “Gönder” de öyle. Etiket eylemi açıklamalıdır: “Erişilebilirlik kontrol listesini indir”, “Güncellemelere abone ol”, “Bu yorumu sil”.

Tasarımınız kısa bir görsel etiket gerektiriyorsa, açıklayıcı bir alternatif sağlamak için aria-label kullanın. Ancak daha iyi çözüm, herkes için işe yarayan etiketler yazmaktır.

Yalnızca ikon içeren butonlar için aria-label zorunludur. Sadece büyüteç ikonuna sahip bir butonun aria-label="Search" veya eşdeğer metne ihtiyacı vardır. İkon, ekran okuyucular için erişilebilir değildir.

5. Yeterli renk kontrastı sağlayın

WCAG 2.1, normal metin için en az 4.5:1, büyük metin için (18pt veya 14pt kalın) 3:1 kontrast oranı gerektirir. Buton etiketleri genellikle normal metindir.

Beyaz bir buton üzerindeki açık gri metin başarısız olur. Açık mavi arka plan üzerindeki soluk mavi başarısız olur. Bu kombinasyonlar sofistike görünebilir, ancak az gören, renk körlüğü olan veya ekranı parlak güneş ışığında görüntüleyen kullanıcıları dışarıda bırakır.

Kontrast denetleyiciyi yayından sonra değil, tasarım sırasında kullanın. Üretimde kontrast sorunlarını düzeltmek pahalıdır çünkü çoğu zaman tasarım sistemi değişiklikleri gerektirir.

Görüntü işleme araçlarıyla çalışıyorsanız, client-side processing can help preserve privacy while generating accessible visual assets — özellikle renk kombinasyonlarını test ederken veya önizleme durumları oluştururken — yardımcı olabilir.

Bu kontrol listesinin kapsamadıkları

Bu liste özellikle eksiktir. Devre dışı durum semantiğini, yükleme durumlarını, hata işlemeyi veya split buttons ya da dropdown triggers gibi karmaşık buton kalıplarını kapsamaz. Bu kalıpların kendi rehberliğine ihtiyacı vardır.

Ayrıca butonun ne zaman diğer etkileşimli öğeler yerine kullanılacağına dair daha geniş soruyu da kapsamaz. Bunun için semantic HTML ve accessibility tree’yi anlamanız gerekir — bunlar kendi makalelerini hak eden konulardır.

Kapsadığı şey ise kolay kazanımlardır: neredeyse her kod incelemesinde ortaya çıkan, en çok kullanıcıyı etkileyen ve geliştirme sırasında düzeltilmesi en kolay olan hatalar.

Bunu iş akışınıza nasıl entegre edersiniz

Erişilebilirlik kontrol listeleri yalnızca geliştirme sürecinin parçasıysa işe yarar; sonradan eklenirse değil. Bunu şöyle sağlayabilirsiniz:

Tasarımda: tasarım dosyalarınıza odak durumları ve tıklama hedefi notları ekleyin. Bunları geliştiricilerin tahmin etmesine bırakmayın.

Kod incelemesinde: <button> öğelerini, ikon butonlarındaki aria-label değerlerini ve odak durumu CSS’ini kontrol edin. Bunları hızlıca fark etmek kolaydır.

Testte: klavyeyle arayüzünüzde tab ile gezinin. Bir butona ulaşamıyorsanız veya odağın nerede olduğunu göremiyorsanız, kullanıcılarınız da göremez.

Dokümantasyonda: bileşen kütüphanenize buton erişilebilirliği gereksinimlerini ekleyin. Doğru şeyi yapmayı, yanlış şeyi yapmaktan daha kolay hale getirin.

Üretim sorunlarını debug ediyorsanız, tools for inspecting HTTP headers and redirects, yardımcı teknolojilerin markup’ınızı nasıl yorumladığını anlamanıza yardımcı olabilir — özellikle gezinme sonrası odak yönetimi sorunlarını giderirken.

Bu işi atlamanın maliyeti

Erişilebilir olmayan butonlar yalnızca WCAG uyumluluğunu başarısız kılmaz — iş akışlarını bozar. Gönder butonuna tıklayamayan bir kullanıcı formu tamamlayamaz. Odak durumlarını göremeyen bir kullanıcı klavyeyle gezinemaz. Buton metnini arka plandan ayırt edemeyen bir kullanıcı etiketi okuyamaz.

Bunlar uç durumlar değildir. Küresel nüfusun yaklaşık %15’inde bir tür engellilik vardır ve geçici kısıtlar (bozuk fare, parlak güneş ışığı, bebek taşımak) eninde sonunda herkesi etkiler.

İyi haber şu: buton erişilebilirliği çoğunlukla çözülmüş sorunlardan oluşur. Yeni kalıplar icat etmeniz veya tarayıcı desteğini beklemeniz gerekmez. Yalnızca platformu doğru kullanmanız ve çalışmanızı test etmeniz gerekir.

Öne çıkanlar

• Butonlar için <button> öğelerini, gezinme için <a> öğelerini kullanın — anlamsal fark yardımcı teknolojiler için önemlidir
• Motor beceri kısıtlarını ve mobil kullanıcıları desteklemek için tıklama hedeflerinin en az 44×44 CSS piksel olduğundan emin olun
• Tasarım sisteminiz genelinde çalışan görünür, yüksek kontrastlı odak durumları sağlayın
• Tek başına okunduğunda anlamlı olan buton etiketleri yazın ve yalnızca ikon içeren butonlar için aria-label kullanın
• Pahalı geriye dönük düzeltmelerden kaçınmak için renk kontrastını yayından sonra değil, tasarım sırasında kontrol edin

FAQ

Q: Klavye işleyicileri eklersem bir <div> üzerinde role="button" kullanabilir miyim?

A: Kullanabilirsiniz, ancak kullanmamalısınız. Enter, Space, odak yönetimi ve devre dışı durumları elle işlemeniz gerekir — ve kaçınılmaz olarak bir şeyi atlarsınız. <button> öğesi tüm bunları varsayılan olarak doğru şekilde yapar. Onu kullanın.

Q: Oynat/duraklat butonu gibi durumu değiştiren butonlar ne olacak?

A: Geçerli durumu belirtmek için aria-pressed="true" veya aria-pressed="false" kullanın. Buton etiketi de mevcut durumu değil, tıklanınca gerçekleşecek eylemi yansıtmalıdır (oynatılıyorken “Duraklat”, duraklatılmışken “Oynat”). Ekran okuyucu kullanıcılarının sistemin hangi durumda olduğunu değil, butonun ne yapacağını bilmesi gerekir.

Q: Devre dışı butonların kontrast gereksinimlerini karşılaması gerekir mi?

A: WCAG 2.1, devre dışı kontrolleri kontrast gereksinimlerinden muaf tutar (1.4.3), ancak bu tartışmalıdır. Düşük kontrastlı devre dışı butonları herkesin algılaması zordur. Devre dışı bir buton gösterecekseniz, okunabilir yapın. Daha da iyisi, gizleyin veya neden devre dışı olduğunu açıklayın.

Q: Ekran okuyucu olmadan buton erişilebilirliğini nasıl test ederim?

A: Klavyenizi kullanın. Arayüzde tab ile gezinin ve her butona ulaşabildiğinizi, odağın nerede olduğunu görebildiğinizi ve butonları Enter veya Space ile etkinleştirebildiğinizi doğrulayın. Bu, sorunların çoğunu yakalar. Daha derin test için, hesaplanan rolü ve etiketi kontrol etmek üzere Chrome veya Firefox DevTools içindeki accessibility inspector’ı kullanın.

Q: aria-label ile aria-labelledby arasındaki fark nedir?

A: aria-label doğrudan bir metin dizesi sağlar. aria-labelledby, metin içeriği etiket haline gelen başka bir öğenin ID’sine başvurur. Etiket metni DOM’da zaten başka bir yerde varsa aria-labelledby kullanın. Ekranda görünmeyen bir etiket sağlamanız gerektiğinde aria-label kullanın.

Kaynaklar

• Web Content Accessibility Guidelines (WCAG) 2.1 — W3C
• Inclusive Components: Toggle Buttons — Heydon Pickering
• The ARIA Button Pattern — W3C ARIA Authoring Practices Guide
• WebAIM: Keyboard Accessibility — WebAIM