Erişilebilir Web Tasarımı: Önce Neyi Düzeltmeli

Bir web sitesini fareye hiç dokunmadan, yalnızca Tab tuşuyla baştan sona gezmeyi deneyin. Ödeme butonuna ya da iletişim formunun gönder düğmesine ulaşamıyorsanız o site bir grup insan için kullanılamaz durumdadır ve bunu görmek beş dakika sürer. Erişilebilirlik tartışması çoğu zaman yönetmeliklerle, uyum rozetleriyle başlıyor; oysa işin büyük kısmı bu kadar basit kontrollerde bitiyor.

Engel sabit bir durum değil

Erişilebilirliği yalnızca kalıcı engeli olan kullanıcılar üzerinden düşünmek, yapılan işin karşılığını da küçültüyor. Kolunu kıran biri birkaç hafta tek elle yazar. Göz ameliyatı olan biri bir süre büyük punto ister. Güneşin altında telefonuna bakan, bebeği kucağında tek eliyle form dolduran, açık ofiste videonun sesini açamayan kullanıcı da aynı arayüz kararlarından etkilenir.

Bu durumların ortak yanı, çözümlerinin ayrı ayrı olmaması. Yeterli kontrast güneş altındaki ekranı da okunur yapar. Klavyeyle gezilebilen bir form, faresi bozulan kullanıcıyı da kurtarır. Videoya konan altyazı, sesi açamayan herkesin işine yarar. Interaction Design Foundation'ın erişilebilirlik yazısı bu örtüşmeyi ayrıntılı anlatıyor.

Önce kontrast ve klavye, sonra alt metin

Sınırlı vaktiniz varsa sıra şöyle kurulmalı. Kontrast ve klavye erişimi tema düzeyinde çözülür, bir kez düzeltince sitenin tamamını kapsar. Alt metin ise içerik başına tekrarlayan bir emektir, her yeni görselde yeniden karşınıza çıkar. Tema düzeyindeki işi bitirmeden içerik düzeyindeki işe girişmek, su alan bir tekneyi boyamaya benziyor.

WCAG 2.1 AA, normal boyuttaki metin için 4.5:1, yaklaşık 24px ya da kalın 19px üstündeki metin için 3:1 kontrast oranı ister. 2.1 ile gelen ve çoğu denetimde atlanan bir madde daha var: düğme kenarları, form çerçeveleri, ikonlar gibi arayüz bileşenleri de 3:1 istiyor. Açık gri çerçeveli beyaz form kutuları tam burada takılır.

Klavye tarafında en yaygın hata tek satırlık: odak halkasını çirkin bulup outline: none yazmak ve yerine bir şey koymamak. Site teknik olarak klavyeyle gezilebilir kalır ama kullanıcı nerede olduğunu göremez, bu da gezilememekle aynı kapıya çıkar.

SEO gerekçesi göründüğünden zayıf

Erişilebilirlik yazılarının neredeyse tamamı arama motoru faydasını öne sürer. Örtüşme gerçek, ama dar. Alt metin, anlamlı başlık hiyerarşisi, doğru tanımlanmış sayfa dili; bunlar hem ekran okuyucuya hem tarama botuna yarar. Buna karşılık kontrast oranı, odak göstergesi, klavye tuzağı, altyazı eşlemesi ve ARIA niteliklerinin doğruluğu Googlebot'u hiç ilgilendirmez. WCAG başarı ölçütlerinin ancak küçük bir bölümü SEO ile kesişiyor.

Pratik sonucu da şu oluyor: erişilebilirliği SEO bütçesiyle satarsanız ekip zaten SEO için yaptığı işleri erişilebilirlik hanesine yazar, gerçekten fark yaratan kısma hiç sıra gelmez. Alt metinleri eksiksiz tamamlanmış ama klavyeyle gezilemeyen siteler böyle ortaya çıkıyor. Erişilebilirliğin gerekçesi kullanıcının siteyi kullanabilmesidir, SEO yan etkidir.

Otomatik denetim nereye kadar

Lighthouse, WAVE ve axe hızlı bir başlangıç sağlar. Ama makine yalnızca makineyle sınanabilen kuralı yakalar: eksik alt niteliği, etiketsiz form alanı, atlanmış başlık seviyesi, hesaplanabilir kontrast oranı. Alt metnin doğru olup olmadığını kontrol edemez, çünkü alt="gorsel1" yazan bir sayfa denetimden tertemiz çıkar.

Aracın göremediklerinin listesi uzun: odak sırasının görsel sırayla uyuşup uyuşmadığı, hata mesajının ne yapılacağını söyleyip söylemediği, altyazının videodaki konuşmayla eşleşip eşleşmediği, açılır menünün Esc ile kapanıp kapanmadığı. Erişilebilirlik puanı 100 olan bir sayfa ekran okuyucuyla pekâlâ gezilemez olabilir. O puanı hedef değil, zemin kontrolü sayın.

WebAIM'in her yıl yürüttüğü büyük ölçekli tarama, en sık saptanan sorunun yıllardır düşük kontrastlı metin olduğunu gösteriyor. Yani otomatik araçların en kolay yakaladığı hata bile hâlâ düzeltilmiş değil.

Bir saatte yapılabilecekler

Durumu ölçmek için denetim aracı kurmayı beklemeye gerek yok. Aşağıdakiler tarayıcıdan başka bir şey istemiyor.

• Fareyi kenara bırakın, ana sayfadan formun gönder düğmesine kadar yalnızca Tab ile gidin. Her adımda odağın nerede olduğunu görebiliyor musunuz?
• Bir modal ya da açılır menü açın. Odak içeri giriyor mu, Esc kapatıyor mu, kapanınca odak onu açan düğmeye geri dönüyor mu?
• Tarayıcı yakınlaştırmasını %200 yapın. Üst üste binen, ekran dışına taşan, tıklanamaz hale gelen bir şey var mı?
• Formda kasten hata yapın. Uyarı alanın yanında metinle mi çıkıyor, yoksa sadece çerçeve kırmızıya mı dönüyor?

Son bir not, çünkü en pahalı hata burada yapılıyor. Bir div öğesine role="button" vermek onu düğmeye çevirmez: tabindex eklemeniz, Enter ve Space tuşlarını ayrı ayrı yakalamanız, devre dışı durumunu elle yönetmeniz gerekir. Bunların hepsi <button> etiketinde hazır gelir. ARIA'nın ilk kuralı da tam olarak bunu söyler ve WCAG uyumuna giden en kısa yol, doğru HTML etiketini seçmekten geçer.