Web Erişilebilirliği: Otomatik Denetimin Gördüğü ve Göremediği

Bir sayfanın erişilebilir olup olmadığını anlamanın en hızlı yolu fareyi bırakıp Tab tuşuna basmaktır. Otomatik denetim araçları bunu yapmaz: kodda arayabildikleri kalıpları arar, geri kalanını sessizce geçer. Aradaki boşluk, raporu yeşil çıkan bir sitede kullanıcının hâlâ neden takıldığını açıklıyor.

WebAIM'in %96,8'i tavan değil, taban

WebAIM her yıl en çok ziyaret edilen bir milyon ana sayfayı tarayıp otomatik olarak yakalanabilen WCAG hatalarını sayıyor; 2022 taramasında sayfaların %96,8'inde en az bir hata çıktı. Sayıyı okurken atlanan nokta, tarayıcının yalnızca makinenin kesin karar verebildiği ölçütlere bakması. Odak sırasının mantıklı olup olmadığını, bir alternatif metnin görseli gerçekten anlatıp anlatmadığını, hata mesajının kullanıcıya ne yapması gerektiğini söyleyip söylemediğini hiçbir araç ölçemez.

Yani %96,8 hatalı sayfa oranının üst sınırı değil, otomatik olarak kanıtlanabilen alt sınırı. Kalan %3,2 de temiz demek değil; sadece makinenin bakabildiği yerlerde temiz.

Aracın göremediği yerler

Denetim araçları varlık kontrolü yapar, anlam kontrolü değil. Birkaç örnek:

• alt="IMG_2043.jpg" yazan bir görsel alternatif metin testini geçer. Ekran okuyucu kullanan biri için hiçbir şey ifade etmez.
• Kontrast hesabı metin rengiyle arka plan rengi arasında yapılır. Metin bir fotoğrafın üzerindeyse araç çoğunlukla hesabı yapamaz ve sessiz kalır.
• aria-label ile verilen isim düğmenin gerçekte yaptığı işle çelişiyorsa, bu bir hata olarak değil doldurulmuş bir alan olarak görünür.
• Modal açıldığında odağın arka plandaki bağlantılara kaçması DOM'da tamamen geçerli bir yapıdır.

Klavyeyle on dakika

Klavyeyle geçirilen on dakikayı otomatik denetim raporunun tamamından daha güvenilir bulurum. Rapor kodun ne söylediğini anlatır, klavye kullanıcının nereye sıkıştığını gösterir.

Test basit: sayfanın başından Tab'a basmaya başlayın ve şunlara bakın. Odak her adımda gözle görülüyor mu, sıra ekrandaki düzenle uyuşuyor mu, menüler klavyeyle açılıyor mu, açılan modaldan Esc ile çıkılıyor mu, form hatayla dönünce odak hata mesajına gidiyor mu. Çoğu sitede bu sorulardan en az biri hayırla cevaplanır.

Peki ekran okuyucuyu hiç açmadan olur mu?

Olmaz. Klavye testi yapıyı gösterir ama sayfanın sesli halinin nasıl bir şeye dönüştüğünü göstermez. Windows'ta NVDA ücretsiz, macOS'ta VoiceOver zaten kurulu. İlk yarım saat rahatsız edici geçer, sonrasında kendi arayüzünüzü tanımadığınızı fark edersiniz. Başlık hiyerarşisi kurulmamış bir sayfa ekran okuyucuda tek parça bir metin yığınına dönüşür, çünkü kullanıcının atlayarak ilerleyebileceği hiçbir işaret yoktur.

Erişilebilirlikle SEO'yu aynı kefeye koymak

İkisinin kesiştiği yerler var: anlamlı başlık hiyerarşisi, açıklayıcı bağlantı metni, alternatif metin. Ama kesişim sanıldığı kadar geniş değil. Odak sırası, Esc davranışı, aria-live bölgeleri, klavye tuzakları; bunların hiçbirinin arama sıralamasına katkısı yok.

Erişilebilirliği SEO getirisiyle savunmanın sorunu da burada ortaya çıkıyor. Getirisi olmayan ilk düzeltmeye geldiğinizde elinizde gerekçe kalmaz. Gerekçe zaten kullanıcının siteyi kullanabilmesiydi, trafiğin artması değil.

Nereden başlanır

Ucuz olanlardan. Kontrast oranını düzeltmek çoğu projede birkaç CSS değişkenine dokunmak demek. Form alanlarına <label for> bağlamak dakikalar sürer ve WebAIM'in saydığı hataların büyük bölümünü kapatır. Bunlar bittikten sonra odak yönetimi ve klavye akışı gelir; orası tasarım kararlarına dokunduğu için daha uzun sürer ve tek başına geliştiricinin işi değildir.

Ölçüt olarak W3C Web Erişilebilirlik İnisiyatifi'nin yayımladığı WCAG 2.1 belgeleri yeterli. Hepsini baştan okumaya gerek yok; hata listenizdeki her madde için ilgili başarı ölçütüne bakmak çok daha hızlı ilerletir.