Erişilebilirlik testi, statik HTML sayfalarını kontrol etmekten, karmaşık JavaScript ile çalışan uygulamaları ele almaya evrildi. Erken web erişilebilirliği, anlamsal işaretleme ve görseller için alternatif metin üzerinde yoğunlaşıyordu. Modern tek sayfa uygulamaları (SPA'lar) ise içerik güncellemelerinin dinamik olarak gerçekleştiği zorlukları beraberinde getiriyor, bu da ekran okuyucuların değişiklikleri tespit etmesini zorlaştırıyor.
Temel sorun, dinamik arayüzlerde ARIA canlı bölgeleri ve odak yönetimidir. Gerçek zamanlı veri akışları DOM'u güncellediğinde, NVDA veya JAWS gibi ekran okuyucular kritik değişiklikleri bildirmeyebilir veya daha kötüsü, kullanıcıları önemsiz güncellemelerle kesintiye uğratabilir. Modal diyaloglar, odak yönetiminde yanlış kapanmalar veya kapanma esnasında kullanıcıyı tetikleyen öğeye geri döndürmeme ile bu durumu karmaşıklaştırır, bu da WCAG 2.1 Başarı Kriteri 1.3.1 ve 2.4.3'ü ihlal eder.
Klavye navigasyonu testi, ekran okuyucu doğrulaması ve bilişsel akış analizini birleştiren sistematik bir manuel test protokolü uygulayın. İlk olarak, tüm etkileşimli öğelerin fare bağımlılığı olmadan Tab tuşu navigasyonu ile erişilebilir olduğunu doğrulayın. İkinci olarak, gerçek ekran okuyucularla test ederek canlı bölgelerin uygun nazik ayarları kullanıp kullanmadığını doğrulayın (aria-live="nazik" ile "sert"). Üçüncüsü, tarayıcı geliştirici araçlarını kullanarak odak sırasını belgeleyin, böylece mantıklı bir sıralamanın görsel düzenle eşleştiğinden emin olun.
Gerçek zamanlı kripto para birimi fiyat güncellemeleri gösteren ve kullanıcıların modal diyaloglar aracılığıyla işlemler gerçekleştirmesine izin veren bir finansal ticaret panelini test etme görevi verildi. Uygulama, görme engelli olduğu için ekran okuyuculara güvenen profesyonel yatırımcıları hedefliyordu; bu nedenle fiyat uyarılarının hemen bildirilmesi ve çalışma akışının sürekliliği sağlanması gerekiyordu. Risk yüksekti, çünkü kaçırılan uyarılar, kullanıcılar için önemli finansal kayıplara yol açabilirdi.
İlk testlerde, fiyat düşüşü uyarılarının ekran okuyucu kullanıcılarına bildirilmediğini keşfettik, bu da kritik ticaret fırsatlarının kaçırılmasına sebep oldu. Ayrıca, ticaret onay modalını açarken, odak arka plan öğelerinde kalmıştı ve kullanıcılar Tab tuşları ile gezinirken yanlışlıkla işlemleri tetikleyebiliyorlardı. Modal kapatma düğmesi de odaklanmayı tetikleyen öğeye geri döndürmeyi başaramıyordu, bu da kullanıcıların sayfanın üstünden yeniden gezinmek zorunda kalmasına neden oluyordu.
Olası ihlalleri hızla yakalamak için axe DevTools ve Lighthouse gibi otomatik erişilebilirlik tarayıcılarını kullanmayı düşündük. Bu araçlar, eksik alt etiketlerini ve yetersiz renk kontrastı oranlarını etkili bir şekilde belirledi. Ancak, canlı bölge bildirimleriyle ilgili zamanlama sorunlarını ve modalın React Portal uygulamasına özgü odak yönetimi problemlerini tamamen göz ardı ettiler. Statik analiz, bir ekran okuyucunun içeriği doğru zamanda bildirip bildirmediğini veya odak tuzaklarının gerçek yardımcı teknolojilerle çalışıp çalışmadığını doğrulamaz.
İkinci yaklaşım, yapısal test senaryoları olmadan Windows'da NVDA ve macOS'da VoiceOver ile tamamen manuel test yapmayı içeriyordu. Bu yöntem belirli odak tuzağı sorunlarını yakalarken, tutarsız ve zaman alıcıydı. Farklı testçiler, ekran okuyucudaki uzmanlık seviyelerine bağlı olarak çelişkili sonuçlar bildirdi. Bu yöntem ayrıca, geliştiricilerin sorunları düzeltmeleri için tekrar edilebilir adımlar oluşturmakta başarısız oldu, çünkü anekdot gözlemleri test oturumları arasında farklılık gösteriyordu.
Yapısal test şemalarıyla hedefli yardımcı teknoloji doğrulamasını birleştiren karma bir yöntem uyguladık. Screen Reader Compatibility için NVDA ile Firefox ve VoiceOver ile Safari ana birleşimleri kullanarak özel test senaryoları geliştirdim. Her test senaryosu, canlı bölge naziklik seviyelerini doğrulamak, modal içindeki tam Tab navigasyon sırasını belgelemek ve ekran okuyucu konuşma izleyicilerini kullanarak bildirim davranışlarını kaydetmek için belirli adımlar içeriyordu. Bu yaklaşım, kapsamlılıkla tekrar edebilirlik arasında bir denge sağladı.
Karma yapısal yaklaşımı seçtik çünkü bu, geliştiricilere spesifik ARIA özellik yapılandırma hatalarını içeren somut, tekrarlanabilir hata raporları sağladı. Bu metodoloji, kontrolsüz testlerin tutarsızlıklarını ortadan kaldırırken, otomatik tarayıcıların kaçırdığı sorunları yakaladı. Yapısal format ayrıca, erişilebilirlik testine aşina olmayan daha genç QA mühendislerine bilgi aktarımını sağladı.
Bu yaklaşım, geliştirme ekibinin tüm fiyat güncellemeleri için aria-live="sert" uyguladığını tespit etti ve bu da sürekli kesintilere yol açtı. Kritik uyarıları "sert" ve standart güncellemeleri "nazik" olarak değiştirmeyi önerdik. Modallar için, react-focus-lock kütüphanesini kullanarak odak tuzaklarını uyguladık ve odaklanmanın tetikleyici öğelere geri döndüğünden emin olduk. Düzeltme sonrası doğrulama, test edilen ekran okuyucu kullanıcılarının %100'ünün uyarıları kaçırmadan veya navigasyon bağlamını kaybetmeden ticaret akışlarını başarıyla tamamlayabildiğini gösterdi.
Modal diyalog bir kapandığında odak yönetiminin düzgün çalıştığını nasıl doğrularsınız?
Birçok aday, modalın görsel olarak kaybolduğunu kontrol etmeyi önerir. Doğru yaklaşım, WCAG 2.1 Başarı Kriteri 2.4.3'ü anlamayı gerektirir (Odak Sırası). Modal, Escape tuşu veya kapatma düğmesi ile kapandığında, odak orijinal olarak modalı açan öğeye geri dönmelidir; DOM'un en üstüne değil. Bunu, modali açarak, kapatarak ve ardından odaklanmanın tetikleyici öğeden sonraki mantıksal ilk öğeye geçtiğini doğrulamak için Tab tuşuna bir kez basarak test edin. Ayrıca, modal görünürlüğü sırasında, Tab navigasyonu yalnızca modal öğeleri içinde döngü yapmalıdır (odak tuzaklaması) böylece yanlışlıkla arka planla etkileşimleri önleyebilir.
Nazik ve sert canlı bölgeler arasındaki fark nedir ve ekran okuyucularla davranışlarını nasıl test edersiniz?
Adaylar genellikle bu ARIA özelliklerini karıştırır veya aynı şekilde çalıştıklarını öne sürer. Aria-live="nazik" bildirimleri, ekran okuyucu mevcut konuşmayı bitirene kadar sıraya alır; bu da otomatik kaydetme onayları gibi kritik olmayan güncellemeler için uygundur. Aria-live="sert" hemen kullanıcıyı kesintiye uğratır, kritik hatalar için ayrılmıştır; örneğin işlem hataları. Test etmek için, gerçek ekran okuyucularla (NVDA, JAWS veya VoiceOver) tarayıcı araçları yerine kullanarak, her iki bölge türü güncellenirken ekran okuyucunun diğer içerikleri söylediği senaryolar oluşturun. Birçok testçi, aria-atomic ve aria-relevant özelliklerinin yalnızca canlı bölgenin bazı kısımları değiştiğinde bildirim davranışını daha fazla kontrol ettiğini gözden kaçırır.
Tam sayfa yenilemeleri olmaksızın React Router gibi çerçevelerde yönlendirme değişiklikleri için erişilebilirlik testini nasıl ele alırsınız?
Çoğu junior testçi, görsel URL değişikliklerini kontrol eder ancak ekran okuyucuların yeni bir görünüme geçişi bildirmek için sayfa başlığı güncellemelerine ve odak değişikliklerine güvendiğini gözden kaçırır. SPA'lar, geleneksel sayfa yükleme olaylarını tetiklemediğinden, yardımcı teknolojiler kullanıcılara yeni bir görünüme geçtiklerini bildirmeyebilir. Çözüm, rota değişikliklerinin programlı olarak document.title'ı güncellediğinden ve odaklanmayı H1 başlığına veya main işaretine JavaScript aracılığıyla taşıdığından emin olmayı gerektirir. Ekran okuyucu aktifken rotalarda gezinerek yeni sayfa başlığını veya başlık içeriğini duyurduğunu doğrulayarak test edin. Adaylar, SPA'lar'da ekran okuyucularla tarayıcının geri düğmesi davranışını test etmeyi genellikle gözden kaçırır; burada odak geçmişinin korunması gerekir ki kullanıcılar navigasyon yığını içinde kaybolmasınlar.