Web Erişilebilirlik: Klavye, ARIA ve Kontrast Rehberi

Web erişilebilirlik, bir arayüzü görme, işitme, motor veya bilişsel farklılıkları olan kişilerin de sorunsuz kullanabilmesi demektir. Çoğu geliştirici bunu yasal bir zorunluluk ya da son aşamada eklenecek bir “ekstra” sanır; oysa erişilebilirlik, baştan doğru kurulduğunda kodun kalitesini, SEO’sunu ve genel kullanılabilirliğini de yükselten temel bir pratiktir. Bu yazıda en çok fark yaratan üç alana odaklanıyoruz: klavye gezinmesi, doğru ARIA kullanımı ve renk kontrastı.

Erişilebilirlik neden temel bir gereksinim?

Dünya nüfusunun önemli bir kısmı kalıcı veya geçici bir engelle yaşıyor; ama erişilebilirlik sadece onlar için değil. Güneşte parlayan bir ekran, kırık bir fare, sessize alınmış bir video ya da yorgun bir göz — herkes zaman zaman “engelli” bir bağlamda gezinir. Erişilebilir bir site, ekran okuyucu ve klavye kullanıcılarına yardım ederken arama motorlarına da daha anlamlı bir yapı sunar.

• Anlamsal HTML işin %80’ini halleder: doğru etiket, doğru iş.
• WCAG (Web Content Accessibility Guidelines) ölçülebilir bir hedef verir; çoğu kurum AA seviyesini referans alır.
• Erişilebilir kod genelde daha sağlam ve bakımı kolay koddur.

Anlamsal HTML: erişilebilirliğin temeli

En sık yapılan hata, her şeyi <div> ve <span> ile kurmaktır. Tarayıcı bir <div>’in tıklanabilir olduğunu bilmez; ekran okuyucu da onu duyurmaz. Doğru elemanı kullanmak, klavye davranışını, odak yönetimini ve ekran okuyucu duyurularını bedavaya getirir.

<!-- Kötü: erişilebilirlik elle eklenmeli -->
<div class="btn" onclick="kaydet()">Kaydet</div>

<!-- İyi: klavye, odak ve rol hazır gelir -->
<button type="button" onclick="kaydet()">Kaydet</button>

Aynı mantık <nav>, <main>, <header>, <footer> ve form elemanları için de geçerli. Her <input> bir <label> ile bağlanmalı:

<label for="email">E-posta</label>
<input id="email" type="email" name="email">

Klavye gezinmesi: fare olmadan da çalışmalı

Bir arayüzü klavyeyle test etmek, erişilebilirliğin en hızlı kontrolüdür. Tab ile ileri, Shift+Tab ile geri gidin; tüm bağlantı, düğme ve form alanlarına ulaşabiliyor musunuz? Odak görünür mü?

• Odak halkasını asla outline: none ile silmeyin. Tasarımla çakışıyorsa :focus-visible ile şık bir hâle getirin.
• Mantıksal sıra için DOM düzenini kullanın; pozitif tabindex değerlerinden kaçının. Sadece tabindex="0" (odağa dahil et) ve tabindex="-1" (programatik odak) yeterlidir.
• Modal açıldığında odağı içine alın, kapanınca tetikleyen düğmeye geri verin.

/* Yalnızca klavye kullanıcısına net odak halkası */
:focus-visible {
  outline: 2px solid #4f46e5;
  outline-offset: 2px;
}

İçeriğe atlama bağlantısı (skip link) da klavye kullanıcıları için büyük kolaylıktır:

<a class="skip-link" href="#main">İçeriğe atla</a>
...
<main id="main"> ... </main>

ARIA: az kullanmak çok kullanmaktan iyidir

ARIA (Accessible Rich Internet Applications), HTML’in tek başına anlatamadığı durumları ekran okuyuculara aktarmak için vardır. Ama altın kural nettir: hiç ARIA, kötü ARIA’dan iyidir. Yanlış bir role ya da yanlış bir durum, doğru anlamsal HTML’i bozar.

• Mevcut bir HTML elemanı işi görüyorsa ARIA ekleme: <button>’a role="button" gereksizdir.
• Etiketi olmayan ikon düğmelerine erişilebilir ad verin: aria-label="Menüyü aç".
• Durumu duyurun: açılır menüde aria-expanded="true/false", seçili sekmede aria-selected.
• Anlık güncellemeleri aria-live="polite" ile bildirin (örneğin form hata mesajı).

<button aria-label="Menüyü aç" aria-expanded="false" aria-controls="menu">
  <svg aria-hidden="true"> ... </svg>
</button>
<ul id="menu" hidden> ... </ul>

Tamamen dekoratif görseller için alt="" bırakın ya da aria-hidden="true" kullanın; ekran okuyucu bunları atlasın. Anlam taşıyan görsellerde ise açıklayıcı bir alt metni şart.

Renk ve kontrast: okunabilirlik herkes için

Düşük kontrast, en yaygın ve en kolay düzeltilen erişilebilirlik hatasıdır. WCAG AA seviyesi normal metin için en az 4.5:1, büyük metin (18.66px kalın ya da 24px) için 3:1 kontrast oranı ister. Arayüz bileşenleri ve grafik öğeler için de 3:1 hedeflenir.

• Tarayıcının DevTools’u, bir metin seçtiğinizde kontrast oranını ve AA/AAA durumunu gösterir.
• Bilgiyi yalnızca renkle aktarmayın. “Kırmızı alan hatalı” yerine ikon, metin veya desen ekleyin — renk körü kullanıcılar için kritik.
• Bağlantıları sadece renkle değil, altı çizili ya da kalın gibi ikinci bir ipucuyla ayırt edin.
• Hareketten rahatsız olan kullanıcılar için animasyonları prefers-reduced-motion ile kısın.

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    transition-duration: 0.01ms !important;
  }
}

Test etme: araç ve insan birlikte

Otomatik araçlar hataların yalnızca bir kısmını yakalar; gerisi gerçek deneyim ister.

• Lighthouse veya axe DevTools ile hızlı bir tarama yapın.
• Klavyeyle baştan sona gezin: hiçbir tuzağa düşüyor musunuz?
• Bir ekran okuyucu deneyin: macOS’ta VoiceOver, Windows’ta NVDA ücretsizdir.
• Sayfayı %200 yakınlaştırın; içerik bozulmadan akıyor mu?

Sık Sorulan Sorular

WCAG AA mı AAA mı hedeflemeliyim?

Çoğu proje için AA seviyesi pratik ve yaygın kabul gören hedeftir; birçok yasal düzenleme de AA’yı referans alır. AAA bazı kriterlerde çok katıdır ve her içerikte sağlanması gerçekçi değildir, ama mümkün olan yerde uygulamak güzeldir.

ARIA, anlamsal HTML’in yerini tutar mı?

Hayır. ARIA yalnızca HTML’in yetmediği durumlarda anlamı zenginleştirir; davranış eklemez. Bir <div>’e role="button" verseniz bile klavye olaylarını ve odağı elle yazmanız gerekir. Doğru eleman her zaman daha güvenlidir.

Erişilebilirlik SEO’ya yardım eder mi?

Evet. Anlamsal yapı, alt metinleri, mantıklı başlık hiyerarşisi ve hızlı okunabilir içerik hem ekran okuyuculara hem arama motorlarına aynı netliği verir; ikisi büyük ölçüde örtüşür.

Erişilebilir bir arayüz, daha iyi bir arayüzdür. Sitenizi klavye, ARIA ve kontrast açısından gözden geçirmek ya da baştan erişilebilir kurmak isterseniz benimle iletişime geçin.