Erişilebilirlik çoğu zaman geliştirme sürecinin sonuna bırakılan bir kontrol listesi gibi ele alınır: kontrastı düzeltmek, birkaç aria-label eklemek ve tarayıcı eklentisini çalıştırmak. Oysa kullanıcı bir formu klavyeyle tamamlayamıyor, açılan pencere odağını kaybediyor veya hata mesajını algılayamıyorsa sorun bir etiket eksikliği değil, ürün davranışındaki kopukluktur.
React arayüzlerinde durum değişimleri hızlı gerçekleşir: modal açılır, liste yenilenir, form hatası görünür, route değişir veya bir menü kapanır. Fare kullanan kişi bu geçişlerin çoğunu fark etmeyebilir. Klavye ya da ekran okuyucu kullanan kişi için ise odak, başlıklar ve duyurular arayüzün yol haritasıdır. Erişilebilir tasarım, bu haritanın her durumda tutarlı kalmasını sağlar.
Önce yerleşik HTML davranışını kullanın
En iyi ilk adım genellikle özel bileşen yazmak değil, HTML'in mevcut anlamını korumaktır. Bir eylem için <button>, sayfalar arası geçiş için <a>, gruplu alanlar için <fieldset> ve <legend>, tablo verisi için <table> kullanmak; klavye davranışını, odaklanmayı ve ekran okuyucu bilgisini ücretsiz getirir.
Tıklanabilir div ya da span ile düğme üretmek yalnızca onClick eklemekle tamamlanmaz. Enter ve Space tuşları, devre dışı durum, odak göstergesi, rol ve erişilebilir ad da yeniden inşa edilmelidir. Bu ayrıntıları tekrarlamak yerine gerçek düğme kullanmak hem daha az kod hem daha az hata demektir.
Başlık hiyerarşisi de görsel ölçekten ayrı düşünülmelidir. Sayfanın ana amacı bir h1 ile, alt bölümler mantıklı sırada başlıklarla ifade edilirse ekran okuyucu kullanan kişi sayfada hızla gezinebilir. Görsel tasarım için yalnızca kalın metin kullanmak, bu yapıyı sağlamaz.
Klavye akışını kullanıcı yolculuğuyla test edin
Bir sayfayı yalnızca Tab ve Shift+Tab ile gezmek, erişilebilirlik hatalarını hızlı biçimde ortaya çıkarır. Odak görünür mü? Sıra görsel ve işlevsel akışla uyumlu mu? Klavye odağı görünmeyen ama tıklanabilir öğelere takılıyor mu? Menü açıldığında hangi tuşlar çalışıyor? Bu sorular, bir bileşenin gerçekten kullanılabilir olup olmadığını gösterir.
Odak sırası DOM sırasından gelir. CSS ile ekrandaki konumu değiştirip DOM'u başka sırada bırakmak, klavye yolculuğunu şaşırtabilir. Pozitif tabindex değerleriyle sırayı elle düzeltmek yerine, anlamlı DOM sırası kurmak daha dayanıklıdır. tabindex="0" da yalnızca doğal olarak odaklanmayan, gerçekten etkileşimli bir öğe için düşünülmelidir.
Odak göstergesini tasarım uğruna kaldırmayın. Varsayılan çizgi marka diliyle uyuşmuyorsa daha belirgin bir alternatif tasarlayın; fakat odakta olan öğeyi kullanıcının açıkça görebilmesi korunmalıdır.
Modal ve açılır katmanlarda odağı yönetin
Bir modal açıldığında odak, kullanıcıya modalın başladığını anlatacak anlamlı bir öğeye taşınmalıdır. Genellikle modal başlığı veya ilk kullanılabilir kontrol uygundur. Modal açıkken Tab tuşu arka plandaki sayfaya kaçmamalı, kapandığında odak modalı açan tetikleyiciye dönmelidir.
Bu davranış React state değişiminden bağımsız değildir. Modal kapanırken tetikleyici hâlâ DOM'da mı, tetikleyici devre dışı mı, kullanıcı bir form hatası nedeniyle mi kapatıyor? Bu ayrıntılar tasarlanmalıdır. Hazır ve erişilebilirliği test edilmiş bir dialog bileşeni kullanmak, elle odak tuzağı kurmaktan genellikle daha güvenlidir.
Menü, popover ve autocomplete gibi daha küçük katmanlar da aynı soruyu taşır: Bileşen açıldığında klavye ile nasıl girilir, seçenekler arasında nasıl gezinilir, Escape ne yapar ve kapandığında odak nereye döner? Her açılır yüzey modal değildir; arka plan etkileşimini gereksiz yere kilitlemek de kullanıcı deneyimini bozabilir.
Durum değişimlerini anlamlı biçimde duyurun
Bir form gönderildiğinde ekranın altında küçük bir toast belirmesi, ekran okuyucu kullanan kişi için yeterli geri bildirim olmayabilir. Başarı, hata veya yükleme sonucunun uygun bir canlı bölge üzerinden duyurulması; ancak sürekli ve gereksiz mesaj yağmuru yaratmaması gerekir.
Form doğrulamasında hata yalnızca kırmızı kenarlık olmamalıdır. Alanın etiketi, hata metni ve açıklama programatik olarak ilişkilendirilmeli; gönderim başarısızsa odak ilk hatalı alana veya hata özetine yönlendirilmelidir. Hata özetindeki bağlantılar ilgili alana atlayabiliyorsa, uzun formlarda toparlanmak kolaylaşır.
Asenkron yükleme sırasında eski içerik görünür kalıyorsa, kullanıcıyı gereksiz duyurularla bölmeyin. İçeriği gerçekten değiştiren, hata yaratan veya işlem tamamlandığını bildiren durumlar önceliklidir. Duyuru metni “başarısız” demek yerine neyin başarısız olduğunu ve sonraki güvenli adımı anlatmalıdır.
Özel kontrollerde klavye modelini açıkça uygulayın
Sekmeler, combobox'lar, ağaç görünümleri ve sürükle-bırak alanları, standart HTML kontrollerinden daha karmaşıktır. Bu bileşenlerde yalnızca ARIA rolü eklemek yeterli değildir; rolün beklediği klavye etkileşimi de uygulanmalıdır. Ok tuşları, Home/End, Enter, Space ve Escape davranışları bileşenin türüne göre tutarlı olmalıdır.
Gerekli karmaşıklık yoksa daha basit bileşen seçmek daha erişilebilirdir. Örneğin filtre için tamamen özel combobox yerine doğru etiketlenmiş bir <select> yeterli olabilir. Özel kontrol gerekiyorsa, erişilebilir bileşen kütüphanesiyle başlamak ve projede ortak bir kullanım kuralı tanımlamak tekrar eden hataları azaltır.
Route değişiminde bağlamı koruyun
Tek sayfa uygulamalarında route değiştiğinde görsel içerik yenilenir ama tarayıcı odağı eski yerde kalabilir. Yeni sayfanın ana başlığına veya ana içerik bölgesine kontrollü odak taşımak, kullanıcıya navigasyonun tamamlandığını gösterir. Bunu her küçük filtre değişiminde yapmak yorucu olabilir; sayfa düzeyindeki gerçek geçişlerle sınırlamak daha dengelidir.
“İçeriğe atla” bağlantısı da tekrar eden navigasyonu kullanan klavye kullanıcıları için hızlı bir yol sağlar. Bağlantı ilk odaklanabilir öğelerden biri olmalı ve ana içeriğe belirgin şekilde taşımalıdır.
Testi otomasyondan insan davranışına taşıyın
Otomatik erişilebilirlik kontrolleri, eksik erişilebilir adlar veya geçersiz ARIA kullanımı gibi birçok hatayı erken yakalar. Fakat odak sırasının anlamlılığını, modalın gerçekten kullanılabilirliğini veya hata mesajının anlaşılır olup olmadığını tek başına kanıtlayamaz.
Her kritik akış için kısa manuel senaryo oluşturun: klavyeyle giriş yap, filtreyi değiştir, formu hatalı gönder, modalı aç-kapat, route değiştir. Bu senaryoları ekran okuyucu ve farklı cihazlarla periyodik denemek, bileşenler arasındaki sorunları görünür kılar. Test bileşeni de mümkün olduğunca gerçek kullanıcı eylemleriyle—tıklama, yazma, Tab ve Escape—etkileşmelidir.
Erişilebilirlik, ayrı bir kullanıcı grubu için eklenen yan özellik değildir. Semantik yapı, öngörülebilir odak, anlaşılır geri bildirim ve klavye desteği; herkes için daha az hata, daha iyi yön bulma ve daha dayanıklı bir React arayüzü demektir.