Lighthouse 100 Aldı Ama Hâlâ Erişilebilir Değil: Frontend'de Kaçırılan 7 Accessibility Problemi

011. Lighthouse Skoru Her Şeyi Söylemez

100 puan almak erişilebilir bir ürün geliştirdiğin anlamına gelmez

Accessibility testlerinde otomatik araçlar oldukça değerlidir ancak her problemi tespit edemez. Lighthouse veya benzeri araçlar belirli kuralları otomatik olarak kontrol eder; fakat bir kullanıcının klavye ile gerçekten rahat gezip gezemediğini, modal kapandıktan sonra focus'un doğru yere dönüp dönmediğini veya bir hata mesajının kullanıcı tarafından anlaşılabilir olup olmadığını her zaman değerlendiremez.

Bu nedenle accessibility bir skor problemi değil, kullanıcı deneyimi problemidir. Otomatik testler önemli bir başlangıç noktasıdır ancak manuel klavye testi ve ekran okuyucu testi de geliştirme sürecinin parçası olmalıdır.

022. Div'e onClick Eklemek Buton Yapmaz

Görsel olarak butona benzeyen her element gerçekten buton değildir

Frontend'de sık yapılan hatalardan biri div veya span elementini tıklanabilir hale getirerek buton gibi kullanmaktır. Mouse ile test edildiğinde çalışır ancak klavye kullanıcıları için aynı davranış garanti edilmez.

Örneğin aşağıdaki yapı görsel olarak bir buton gibi davranabilir ancak semantik olarak button değildir.

Gerçek bir button elementi Enter ve Space gibi klavye etkileşimlerini tarayıcının doğal davranışlarıyla destekler. Bu nedenle mümkün olduğunda mevcut HTML semantiğini kullanmak, davranışı JavaScript ile yeniden oluşturmaktan daha doğru bir yaklaşımdır.

033. Modal Açıldı Ama Focus Nerede?

Modal erişilebilirliğinde en çok gözden kaçan noktalardan biri focus yönetimidir

Bir modal açıldığında mouse kullanıcısı doğrudan modalı görür. Ancak klavye kullanan bir kullanıcı için modalın açılması tek başına yeterli değildir. Focus'un modal içerisindeki uygun bir elemente taşınması gerekir.

Modal açıkken Tab tuşuna basıldığında focus'un arka plandaki sayfa elementlerine kaçması da kullanıcı deneyimini bozabilir. Modal kapatıldığında ise focus'un modalı açan butona geri dönmesi beklenir.

Bu nedenle erişilebilir bir modal için yalnızca role="dialog" eklemek yeterli değildir. Focus yönetimi, klavye etkileşimi ve modalın kapanma davranışı birlikte düşünülmelidir.

044. Form Hatasını Kırmızı Yapmak Yeterli Değil

Kullanıcı hatayı görmeli, anlamalı ve hangi alanla ilişkili olduğunu anlayabilmeli

Bir form alanı hatalı olduğunda sadece border rengini kırmızı yapmak erişilebilir bir hata yönetimi değildir. Renk bilgisi bazı kullanıcılar için yeterli olmayabilir ve ekran okuyucu kullanan bir kullanıcı hatayı hiç duymayabilir.

Hata mesajının ilgili input ile ilişkilendirilmesi daha doğru bir yaklaşımdır.

Burada aria-invalid alanın geçersiz olduğunu belirtirken aria-describedby hata mesajının input ile ilişkilendirilmesine yardımcı olur. Böylece hata yalnızca görsel olarak değil, programatik olarak da ifade edilmiş olur.

055. Dinamik İçerik Değişti Ama Ekran Okuyucu Bilmiyor

React'te state değişmesi, yardımcı teknolojinin değişikliği otomatik olarak duyduğu anlamına gelmez

Modern frontend uygulamalarında sayfa yenilenmeden içerik sürekli değişir. Toast mesajları, form sonuçları, API cevapları, validation mesajları ve sepet güncellemeleri bunun örnekleridir.

Örneğin kullanıcı bir ürünü sepete eklediğinde ekranda 'Ürün sepete eklendi' mesajı görünebilir. Ancak ekran okuyucu kullanan kullanıcı bu değişikliği fark etmeyebilir.

Bu tür durumlarda uygun yerlerde aria-live gibi mekanizmalar kullanılabilir.

Ancak aria-live her dinamik içerikte kullanılacak bir çözüm değildir. Gereksiz veya agresif canlı bölgeler ekran okuyucu deneyimini karmaşıklaştırabilir. Burada önemli olan hangi değişikliğin kullanıcıya gerçekten duyurulması gerektiğini belirlemektir.

066. Görünmez Focus, Kullanıcıyı Kaybettirir

Outline'ı kaldırmak küçük bir CSS değişikliği gibi görünür ama ciddi bir kullanılabilirlik problemi oluşturabilir

Tasarım sırasında varsayılan focus göstergesinin kaldırılması oldukça yaygın bir durumdur. Örneğin outline: none kullanılarak focus görünümü tamamen ortadan kaldırılabilir.

Mouse ile kullanan bir kullanıcı için bu değişiklik fark edilmeyebilir. Ancak klavye ile gezinen kullanıcı hangi elementin aktif olduğunu göremediğinde sayfadaki konumunu kaybedebilir.

Bu nedenle focus stilini tamamen kaldırmak yerine tasarımla uyumlu, yeterince belirgin bir focus görünümü oluşturmak gerekir.

077. SPA'lerde Sayfa Değişti Ama Kullanıcı Nereye Geldiğini Bilmiyor

Client-side navigation accessibility açısından yeni problemler oluşturabilir

React ve Next.js gibi framework'lerle geliştirilen uygulamalarda sayfa geçişleri çoğu zaman browser'ın klasik tam sayfa yenileme davranışından farklıdır. URL değişebilir ve içerik ekranda güncellenebilir ancak kullanıcı deneyiminin erişilebilir şekilde devam etmesi ayrıca düşünülmelidir.

Örneğin kullanıcı bir linke tıkladığında yeni sayfanın içeriği ekrana geldiğinde focus'un nerede olduğu önem kazanır. Ekran okuyucu kullanan kullanıcı yeni içeriğin başladığını kolayca anlayabilmelidir.

Bu nedenle SPA uygulamalarında navigation, document title, heading yapısı ve focus yönetimi birlikte ele alınmalıdır. Sadece URL'nin değişmesi erişilebilir bir sayfa geçişi anlamına gelmez.

088. Accessibility Testi Nasıl Yapılmalı?

Tek bir araç yerine farklı test katmanlarını birlikte kullan

Erişilebilirlik testi için otomatik araçlar önemli bir başlangıç noktasıdır ancak tek başına yeterli değildir. Daha güvenilir bir kontrol için otomatik ve manuel testleri birlikte kullanmak gerekir.

İlk olarak Lighthouse veya benzeri otomatik kontrollerle temel problemler bulunabilir. Ardından sayfa yalnızca klavye kullanılarak test edilmelidir.

Özellikle Tab, Shift + Tab, Enter, Space ve Escape davranışları kontrol edilmelidir. Focus'un nerede olduğu, modal ve dropdown gibi bileşenlerde focus'un doğru yönetilip yönetilmediği gözlemlenmelidir.

Son aşamada kritik akışlar bir ekran okuyucu ile test edilebilir. Özellikle login, kayıt, ödeme, form gönderimi ve hata yönetimi gibi kullanıcı açısından önemli akışlar yalnızca görsel olarak test edilmemelidir.

099. Accessibility Bir Sprint Sonrası Kontrol Listesi Değildir

Erişilebilirlik sonradan eklenen bir özellik olmamalı

Accessibility'i projenin sonunda düzeltilecek bir checklist olarak görmek, özellikle component sayısı arttığında teknik borç oluşturabilir. Bir modal, form veya dropdown geliştirilirken erişilebilirlik davranışının da component ile birlikte tasarlanması daha sürdürülebilir bir yaklaşımdır.

Örneğin bir Button component'i oluşturuluyorsa yalnızca renk, padding ve hover davranışı değil; keyboard interaction, focus görünürlüğü ve disabled davranışı da component'in tasarımının parçası olmalıdır.

Aynı yaklaşım Modal, Select, Dialog, Tooltip ve FormField gibi tekrar kullanılan component'ler için de uygulanabilir. Böylece accessibility her sayfada yeniden düşünülmesi gereken bir detay olmaktan çıkar ve component mimarisinin bir parçası haline gelir.

1010. Sonuç: Erişilebilirlik Skordan Daha Büyük Bir Konu

Bir arayüzün erişilebilir olup olmadığını sadece otomatik test sonucu belirlemez

Accessibility konusunda en tehlikeli varsayımlardan biri 'Lighthouse 100 verdi, demek ki sorun yok' düşüncesidir. Otomatik araçlar geliştiriciye önemli ipuçları verir ancak gerçek kullanıcı deneyiminin tamamını ölçemez.

Gerçek bir accessibility yaklaşımı; semantic HTML, doğru keyboard interaction, görünür focus, doğru form hata yönetimi, dinamik içeriklerin duyurulması, modal focus yönetimi ve yardımcı teknolojilerle test gibi birçok katmanın birlikte düşünülmesini gerektirir.

Frontend geliştirirken asıl soru 'Bu element ekranda çalışıyor mu?' olmamalıdır. Daha kapsamlı soru şudur: 'Bu arayüzü mouse kullanmadan, ekranı görmeden veya yardımcı teknoloji kullanarak deneyen biri aynı görevi tamamlayabilir mi?'