Erken web uygulamaları basit sayfalama ile statik HTML tabloları kullanıyordu. Modern veri ızgaraları, DOM sanallaştırması aracılığıyla milyonlarca satırı işleyecek şekilde evrildi ve React veya Vue ile karmaşık durum yönetimi ile iyimser güncellemeler aracılığıyla anında geri bildirim sağladı. Bu değişim, test metodolojilerinde bir boşluk yarattı; geleneksel tablo testleri sıralama ve filtreleme üzerine odaklanırken, modern ızgaralar WCAG 2.1 uyumunun, eşzamanlılık yönetiminin ve yüksek frekanslı güncellemeler sırasında erişilebilirliğin aynı anda doğrulanmasını gerektiriyor.
Sanallaştırma, görünmez DOM düğümlerini kaldırır, bu da standart erişilebilirlik ağacı denetimini güvenilmez hale getirir. Satır içi düzenleme, ızgaranın bileşim widget deseni ile gömülü form kontrolleri arasında odak yönetimi çatışmaları oluşturur. İyimser güncellemeler, arka uçta asla görünmeyecek geçici UI durumları yaratır ve manuel testçilerin, görsel gecikmeyi gerçek veri kalıcı hatalarından ayırt etmesi gereken hata kurtarma yollarının doğrulanmasını zorlaştırır.
Sistematik bir metodoloji, screen reader geçiş protokolleri, klavye navigasyon matrisleri ve durum uzlaştırma kontrol noktaları içerir. Sanallaştırma bilincine sahip erişilebilirlik denetimi, denetimden önce erişilebilirlik ağacını doldurmak için zorlanmış kaydırma noktasına ihtiyaç duyar. Odak tuzağı tespiti, input, select ve button öğelerini içeren bileşim hücrelerinden geçerken sistematik Tab ve Yay Arrow tuşu geçişi kullanır. İyimser durum doğrulaması, düzenleme sırasında ağ hatalarını kasıtlı olarak tetiklemeyi içerir, böylece geri alma animasyonlarını ve veri geri dönüşünü doğrular. Son olarak, canlı bölge izleme, toplu güncellemeler için ARIA bildirimlerinin bilişsel yük sınırlarını aşmadığından emin olur.
200 ms'de gerçek zamanlı fiyat güncellemeleri ile 50.000+ pozisyon gösteren bir finansal ticaret platformunun portföy ızgarasını test ediyordum. Izgara, satır içi P&L düzenlemesi ve varlık sınıfına göre sürükleyip bırakma gruplama içeriyordu. JAWS ekran okuyucu kullanıcılarının, off-screen satırların fiyat güncellemelerini duyması (karışıklık yaratıyordu), klavye kullanıcılarının ızgara içindeki tarih seçici hücrelerinde tuzağa düşmesi (navigasyon akışını kırıyordu) ve arka uç, piyasa kapanması nedeniyle bir düzenlemeyi reddettiğinde iyimser UI'nin düzenlemeyi 3 saniye gösterip net bir belirti olmadan geri dönüş yapması (ticaretçilerin değişikliklerin kaydedildiğini düşünmesine neden oluyordu) gibi sorunlar keşfedildi.
Çözüm A: Axe-core ile otomatik erişilebilirlik taraması
Test yürütümü sırasında otomatik Axe taramaları uygulamayı düşündük. Avantajı hız ve tekrarlanabilirlikti, temel ARIA ihlallerini anında yakalıyordu. Ancak, ana dezavantajı Axe'ın canlı bölgelerin zamanlama yönlerini doğrulayamaması veya yalnızca belirli kullanıcı etkileşim sıralarında meydana gelen odak tuzaklarını tespit edememesiydi (örneğin, veri yenilenirken bir metin girişinden bir açılır menüye hızlıca geçerken). Ayrıca, off-screen içeriğin erişilebilirlik ağacında "görünür" olarak yanlış etiketlendiği sanallaştırmaya özgü sorunları kaçırıyordu.
Çözüm B: Yardımcı teknolojilerle saf manuel keşif testleri
Testçilerin, NVDA ve VoiceOver ile senaryosuz her hücre kombinasyonunu manuel olarak gezmesini değerlendirip, yüksek-fide bağlı kullanıcı simülasyonu ve ince bilişsel yük sorunlarının keşfi sağlanıyordu. Dezavantajı, aşırı zaman tüketimiydi—50.000 satırı sanal olarak test etmek manuel olarak imkansızdı ve hızlı 200 ms güncelleme sıklığı, bildirimler ve düzenlemeler arasındaki yarış koşullarını sürekli olarak yakalamayı zorlaştırıyordu.
Çözüm C: Hedeflenmiş ekran okuyucu protokolleri ile yapılandırılmış heuristik değerlendirme
Belirli test protokolleri oluşturarak hibrit bir yaklaşımı seçtik. Anchor-point testing, testçilerin ekran okuyucu doğrulamasından önce belirli sanallaştırılmış indekslere (0, 1000, ortada, son) kaydırmalarını gerektirir. Klavye matrisleri, bileşim hücreleri aracılığıyla beklenen odak yollarını belgelemektedir. Ağ kısıtlaması, manüel düzenleme işlemleri ile uzlaştırma hatalarını zorlar. Bu yaklaşım, titizlik ile verimliliği dengelemektedir.
Hangi çözüm seçildi ve neden
Sanallaştırma uç durumları için gerekli kapsama sağladığı ve sprint zaman dilimlerinde uygulanabilir olduğu için Çözüm C'yi seçtik. Tam otomasyonun (Çözüm A) yanı sıra, geçici bildirim çakışmalarını yakalayabiliyordu. Tam manuel testin (Çözüm B) yanı sıra, regresyon testleri için tekrarlanabilir adımlar sağlıyordu. Metodoloji, otomatik araçların algılayamadığı iyimser UI'nin "görünmez" durumlarını özellikle ele aldı.
Sonuç
Izgaranın sanallaştırılmış satırlarda aria-rowindex özniteliklerinin eksik olduğunu ve bunun ekran okuyucuların hatalı pozisyonları duyurmasına neden olduğunu tespit ettik. Tarih seçici tuzağının, odak geri döndürme için Escape anahtarı işlemesinin eksik olmasından kaynaklandığını keşfettik. Sistematik test protokolünü uyguladıktan sonra WCAG ihlalleri %90 düştü, klavye navigasyon akış metriği iyileşti ve ticarette değişikliklerin kalıcılığı konusunda kullanıcı anketlerine dayalı güven arttı.
Sürekli geri dönüşümlü DOM öğeleri içeren sanallaştırılmış bir liste veya ızgarada erişilebilirliği nasıl manuel olarak test edersiniz?
Birçok acemi, erişilebilirliği yalnızca otomatik araçları çalıştırarak veya ilk birkaç görünür satırı kontrol ederek test etmeye çalışır. Doğru yaklaşım, DOM geri dönüşümü kavramını anlamaktır; bu, React Window veya AG Grid gibi kütüphanelerde geçerlidir. Izgarayı belirli kaydırma konumlarına (üst, orta, alt ve rastgele ofsetler) zorlamalı ve ardından her bir bağlantı noktasında erişilebilirlik ağacını denetlemelisiniz. Ek olarak, ekran okuyucuların "Satır 50,000'in 50,000'i" şeklinde bildirim yapmasını sağlamak için aria-rowcount ve aria-rowindex'in doğru şekilde uygulanmasını doğrulamalsınız; bu, yalnızca 20 DOM düğümü mevcut olduğunda bile geçerlidir. Acemiler genellikle ekran okuyucuların kendi sanal tamponlarını koruduğunun farkında değildir, bu nedenle hızlı kaydırma ile test edilmesi, tampon güncellemelerinin görsel UI'nın gerisinde kalmadığını sağlamak için gereklidir; aksi takdirde ekran okuyucu "boş" veya eski içeriği okuyabilir.
İyimser UI güncellemeleri ile kötümser UI güncellemeleri arasındaki fark nedir ve neden iyimser UI özel hata yol testi gerektirir?
Adaylar genellikle her iki modeli aynı şekilde ele alır ve yalnızca başarı yolunu kontrol ederler. Kötümser UI, arayüzü güncellemeden önce sunucu onayını bekler. İyimser UI, başarı varsayımı ile değişiklikleri anında uygular. Kritik kayıp, "uzlaştırma penceresi"nin test edilmemesidir—iyimser uygulama ve sunucu yanıtı arasındaki süredir. Manuel testçilerin, HTTP 409 veya 500 hatalarını tetiklemek amacıyla ağ hızını kasıtlı olarak düşürmesi gerekmektedir; bu, UI'nin temiz bir şekilde geri dönmesini doğrularken, ekran okuyucu kullanıcıları için odak yönetiminin de sürdürülebilir olmasını sağlamak içindir.
Yüksek frekanslı güncelleme senaryosunda ARIA canlı bölgelerinin WCAG 2.1 başarı kriteri 2.2.2 (Duraklat, Durdur, Gizle) veya bilişsel aşırı yük yaratmadığını nasıl doğruluyorsunuz?
Birçok testçi, duyurunun sessizlikten daha iyi olduğunu düşünmektedir. Ancak, WCAG 2.1 sürekli bilgi hareketlerinin duraklatılabileceğini gerektirir. Canlı bölgeler için, bu duyuruların oranının sınırlandırılması anlamına gelmektedir. Manuel testte, NVDA gibi bir ekran okuyucu kullanarak, güncellemeler başladığında birincil bir görevi (bir hücreyi düzenlemek gibi) tamamlayıp tamamlayamayacağınızı öznel olarak değerlendirirsiniz. Teknik, var olan toplama mekanizmalarının (örneğin, "5 fiyat güncellendi" yerine 5 ayrı duyuru) ve kritik olmayan güncellemeler için aria-live="nazik" yerine "sert" kullanıldığını doğrulamayı içerir.