Web sitesinde WCAG 2.2 AA nasıl kontrol edilir?

Web sitesinde WCAG 2.2 AA, otomatik tarama araçları ve manuel kullanıcı testleri birlikte uygulanarak kontrol edilir.

Tek başına Lighthouse, axe veya benzeri bir tarama sonucu yeterli değildir. Çünkü araçlar renk kontrastı ve eksik alternatif metinleri bulabilir. Ancak klavye sırasını, hata mesajlarının anlaşılabilirliğini ve ekran okuyucu deneyimini bütünüyle değerlendiremez.

Kontrol süreci; kapsam belirleme, otomatik tarama, klavye kullanımı, ekran okuyucu, mobil görünüm, formlar, giriş işlemleri ve raporlama adımlarından oluşur. Her bulgu, ilgili WCAG başarı ölçütüyle eşleştirilmelidir.

WCAG 2.2 AA kontrolüne nereden başlanır?

WCAG 2.2 AA kontrolüne, test edilecek sayfa ve kullanıcı akışlarını belirleyerek başlanır.

Önce sitenin kapsamını listeleyin. Ana sayfa, menü, arama, iletişim formu, ürün veya hizmet sayfası, sepet, ödeme, üyelik ve hata sayfaları başlangıç örneklemini oluşturur. Tek bir ana sayfayı test etmek, tüm sitenin uyumlu olduğunu göstermez.

E-ticaret sitelerinde ürün filtreleri, varyant seçimi, sepet güncelleme ve ödeme adımları ayrıca incelenmelidir. Kurumsal sitelerde ise iletişim, başvuru, doküman indirme ve lokasyon bulma akışları öncelik taşır.

Her sayfa için şu bilgileri kaydedin: URL, sayfa amacı, kullanılan bileşenler, giriş gerekip gerekmediği ve işlem sonucu. Aynı bileşen farklı sayfalarda kullanılıyorsa, bir örnek sayfa üzerinde ayrıntılı test yapın.

WCAG 2.2, dört temel ilkeye dayanır: algılanabilir, kullanılabilir, anlaşılabilir ve sağlam içerik. AA seviyesi, A ve AA düzeyindeki başarı ölçütlerinin karşılanmasını gerektirir. Bu nedenle yalnızca görsel düzeni kontrol etmek yeterli değildir.

Test planında masaüstü ve mobil görünümü ayrı senaryolar olarak yazın. Ekran genişliği değiştiğinde içerik kayboluyor, yatay kaydırma oluşuyor veya sabit panel odaklanan alanı kapatıyorsa ayrıca kayıt açın.

Otomatik erişilebilirlik taraması hangi sorunları bulur?

Otomatik erişilebilirlik taraması, kod ve arayüzdeki tekrarlanan hataları kısa sürede bulur; fakat WCAG 2.2 AA kararını tek başına vermez.

axe DevTools, Lighthouse, WAVE ve Accessibility Insights gibi araçlar farklı kuralları tarar. Eksik form etiketi, düşük renk kontrastı, yinelenen kimlik değeri, eksik alternatif metin ve bazı ARIA kullanım hataları bu araçlarla görülebilir.

Tarama sonuçlarını üç gruba ayırın: kesin hata, inceleme gerektiren uyarı ve bilgi. “Button does not have discernible text” sonucu genellikle doğrudan incelenmelidir. Ancak görselin dekoratif mi içerik taşıyan bir görsel mi olduğu insan kararı gerektirir.

Her aracı aynı sayfada çalıştırıp sonuçları karşılaştırın. Bir araçta çıkmayan sorun, otomatik olarak yok sayılmamalıdır. Araçların kuralları, tarama kapsamı ve kullandığı analiz yöntemleri farklı olabilir.

Dinamik içerik de ayrıca test edilmelidir. Modal pencere, açılır menü, filtre, bildirim, çerez paneli ve tek sayfa uygulamalarındaki ekran güncellemeleri, sayfa ilk açıldığında görünmeyebilir. Tarama sırasında bu bileşenleri açın ve işlem sonrasını yeniden tarayın.

Otomatik tarama raporunda URL, hata türü, ilgili HTML öğesi, başarı ölçütü ve ekran görüntüsü bulunmalıdır. Aynı hata 40 sayfada tekrarlanıyorsa, kök nedenin tasarım sistemi veya ortak bileşen olduğu belirtilmelidir.

Yanlış: “Tarama aracında hata çıkmadı, site WCAG 2.2 AA uyumlu.” Doğru: “Otomatik taramada görülen hatalar kapatıldı; manuel ve senaryo testleri ayrıca tamamlandı.”

Web sitesinde klavye erişimi nasıl test edilir?

Klavye erişimi, yalnızca Tab tuşuyla bağlantıları dolaşarak değil, sitenin tüm işlemlerini fare olmadan tamamlayarak test edilir.

Test için fareyi kullanmadan yeni bir gizli pencere açın. Tab tuşuyla ilerleyin, Shift ve Tab ile geri dönün, Enter veya Space ile kontrolleri çalıştırın. Açılır menüler, sekmeler, karuseller, modal pencereler ve formlar bu yöntemle denenmelidir.

Her odaklanan öğenin görünür bir odak göstergesi bulunmalıdır. Odak rengi arka planla yeterince ayrışmıyorsa veya tasarım kuralı nedeniyle tamamen kaldırılmışsa sorun kaydı açın. CSS ile outline: none kullanılması, yerine görünür bir stil konulmadığında risk oluşturur.

Tab sırası görsel ve işlevsel sırayı takip etmelidir. Kullanıcı önce menüye, sonra içerik alanına ve ardından form kontrollerine ulaşamıyorsa gezinme zorlaşır. Bir öğe DOM içinde bulunup ekranda başka yerde görünüyorsa sıra ayrıca incelenmelidir.

Modal açıldığında odak modalın içine taşınmalı, kullanıcı içerideyken arka plandaki öğelere geçmemelidir. Modal kapandığında odak, modalı açan kontrole dönmelidir. Bu davranış klavye ve ekran okuyucu kullanıcıları için kritik bir kontroldür.

Klavyeyle tamamlanamayan işlem varsa bunu adım adım yazın. Örneğin “ürün filtresi açıldı, seçenek seçildi, fakat filtreyi kapatmak mümkün olmadı” kaydı, genel bir “klavye sorunu” ifadesinden daha işlevseldir.

Bu testi ayrıntılı uygulamak için web sitesinde klavye erişiminin nasıl test edildiğini ayrıca inceleyebilirsiniz. Klavye testi, otomatik taramada görünmeyen birçok işlevsel sorunu ortaya çıkarır.

Ekran okuyucu ve görsel içerik nasıl incelenir?

Ekran okuyucu testi, sayfanın görsel düzeninden bağımsız olarak içerik sırasını, kontrol adlarını ve durum değişikliklerini dinleyerek yapılır.

Windows üzerinde NVDA, macOS ve iOS üzerinde VoiceOver kullanılabilir. Android tarafında TalkBack ile test yapılabilir. Tek bir ekran okuyucuda olumlu sonuç almak, tüm kombinasyonlarda aynı sonucu garanti etmez; ancak temel sorunları görünür hale getirir.

Önce sayfanın başlık yapısını kontrol edin. Ekran okuyucu kullanıcıları başlıklar arasında dolaşarak sayfanın yapısını anlamaya çalışır. H1, H2 ve H3 seviyeleri görsel boyuta göre değil, içerik hiyerarşisine göre kullanılmalıdır.

Bağlantı metinleri tek başına anlaşılır olmalıdır. Aynı sayfada beş kez “Daha fazla bilgi” bağlantısı bulunması, hedeflerin ayırt edilmesini zorlaştırır. Bağlantı metni, mümkünse hedef içeriği belirtmelidir.

Form kontrollerinde etiket, talimat, zorunluluk bilgisi ve hata mesajı birlikte değerlendirilir. Ekran okuyucu, kullanıcının hangi bilgiyi gireceğini ve hatayı nasıl düzelteceğini söylemelidir. Sadece kırmızı kenarlık kullanmak yeterli değildir.

Görseller için alternatif metin kararı içerik amacına göre verilir. Ürün fotoğrafı ürünün özelliklerini aktarıyorsa açıklama gerekir. Sadece dekoratif bir şekilse boş alternatif metin kullanılabilir. Dosya adını alternatif metin olarak bırakmak doğru yaklaşım değildir.

Dinamik bildirimleri de dinleyin. Sepete ürün eklenmesi, form gönderimi veya filtre sonucunun değişmesi ekran okuyucuya aktarılmalıdır. Kullanıcı değişikliği fark edemiyorsa, işlem teknik olarak gerçekleşse bile deneyim erişilebilir değildir.

Renk, yazı, yakınlaştırma ve mobil görünüm nasıl kontrol edilir?

Görsel erişilebilirlik kontrolü, renk kontrastını ölçmenin yanında metin büyütme, yeniden akış ve dokunmatik hedefleri de kapsar.

Normal metin ile arka plan arasında en az 4,5:1 kontrast oranı, büyük metin ile arka plan arasında en az 3:1 oranı aranır. Büyük metin değerlendirmesinde kullanılan yazı boyutu ve kalınlığı birlikte dikkate alınmalıdır.

Arayüz bileşenleri ve grafik nesneleri için de kontrast kontrolü yapılır. Form kenarlığı, odak göstergesi, ikon ve düğme sınırı arka planda kaybolmamalıdır. Kontrast ölçümü için Colour Contrast Analyser veya tarayıcı tabanlı araçlar kullanılabilir.

Renk, bilginin tek göstergesi olmamalıdır. “Kırmızı alanları doldurun” yerine alanın yanında metinle hata açıklaması gösterin. Başarı ve hata durumlarında ikon, metin veya programatik durum bilgisi ekleyin.

Tarayıcı yakınlaştırmasını yüzde 200 seviyesine çıkarın. İçerik, kontrol ve metinlerin kullanılabilir kalıp kalmadığını inceleyin. Masaüstünde 400 seviyesinde yeniden akış gerektiren durumlar için yatay kaydırma, kırpılma ve üst üste binme sorunlarını da gözlemleyin.

Mobil görünümde yatay kaydırma, küçük dokunmatik hedefler ve sabit çerez panelleri sık görülür. WCAG 2.2, bazı işlevler için en az 24 x 24 CSS piksel hedef boyutu ister; komşu hedeflerin aralıkları da değerlendirilmelidir.

Yakınlaştırma testi, tasarımın bozulup bozulmadığını değil, kullanıcının görevi tamamlayıp tamamlayamadığını ölçmelidir. Bir buton görünür olsa bile başka bir sabit panel tarafından kapatılıyorsa işlem erişilebilir sayılmaz.

Formlar, hata mesajları ve giriş işlemleri nasıl test edilir?

Form testi, alan etiketlerini, veri türlerini, hata düzeltme sürecini ve başarılı gönderim bilgisini birlikte inceleyerek yapılır.

Her alanın görünür veya programatik olarak ilişkili bir etiketi olmalıdır. Placeholder metni tek başına etiket değildir; kullanıcı yazmaya başladığında kaybolabilir. Ad, e-posta, telefon ve adres alanlarında beklenen biçim açıkça belirtilmelidir.

Zorunlu alanlar yalnızca renk veya yıldız işaretiyle gösterilmemelidir. “Bu alan zorunludur” bilgisi, ekran okuyucu tarafından da erişilebilir olmalıdır. Hatalı girişten sonra odak, ilk hatalı alana veya hata özetine mantıklı biçimde taşınmalıdır.

Hata mesajı, sorunun nedenini ve çözümünü anlatmalıdır. “Geçersiz giriş” ifadesi tek başına yeterli değildir. “E-posta adresini [email protected] biçiminde yazın” gibi bir açıklama kullanıcının düzeltme yapmasını kolaylaştırır.

Form gönderildikten sonra başarı durumu test edilmelidir. Kullanıcı aynı düğmeye tekrar basmak zorunda kalıyor, gönderimin gerçekleştiğini fark edemiyor veya veriler sessizce kayboluyorsa sorun kaydı açın.

Giriş ve kimlik doğrulama akışında yalnızca ezberlenmesi zor bir bulmaca kullanılmamalıdır. WCAG 2.2, erişilebilir kimlik doğrulama yaklaşımında kopyala-yapıştır, parola yöneticisi ve alternatif doğrulama yöntemleri gibi seçenekleri önemser.

Şifre alanlarında parola yöneticisinin çalışıp çalışmadığını da kontrol edin. Kullanıcı, parola yöneticisi veya kopyala-yapıştır kullanamadığında yalnızca görsel hafızaya dayalı bir süreçle karşılaşıyorsa erişim engeli oluşabilir.

WCAG 2.2 AA testinde hangi araçlar ve yöntemler kullanılmalı?

WCAG 2.2 AA testi için araçlar hızlı tarama, manuel inceleme ve gerçek görev senaryoları şeklinde üç katmanda kullanılmalıdır.

İlk katmanda tarayıcı eklentileri ve kod analiz araçları kullanılır. Bu katman; eksik etiket, kontrast, başlık sırası ve bazı ARIA hatalarını belirler. Sonuçları dışa aktararak URL ve bileşen bazında takip etmek gerekir.

İkinci katmanda klavye, yakınlaştırma, mobil görünüm ve ekran okuyucu testleri yapılır. Bu aşamada araçtan gelen “inceleyin” uyarıları insan tarafından karara bağlanır. Örneğin alternatif metnin doğru olup olmadığı yalnızca HTML özniteliğinin bulunmasıyla anlaşılmaz.

Üçüncü katmanda görev senaryoları kullanılır. “Klavye ile ürünü bul ve sepete ekle”, “ekran okuyucu ile iletişim formunu gönder” veya “mobilde çerez tercihini değiştir” gibi senaryolar yazın.

Her senaryo için başlangıç koşulu, işlem adımları, beklenen sonuç ve gerçekleşen sonuç bulunmalıdır. Test uzmanı aynı işlemi tamamlayamıyorsa, sorunun hangi adımda oluştuğu kaydedilmelidir.

Araç raporlarını doğrudan uyum belgesi gibi kullanmayın. Otomatik araçlar, toplam başarı ölçütlerinin yalnızca bir bölümünü değerlendirebilir. Özellikle anlam, işlem akışı, zaman sınırlamaları ve bileşen davranışları manuel inceleme ister.

Test ortamını da yazın. Tarayıcı adı, işletim sistemi, ekran genişliği, yakınlaştırma oranı, ekran okuyucu ve test tarihi kaydedilmelidir. Aynı hata düzeltildikten sonra aynı koşullarda yeniden denenmelidir.

Bulunan erişilebilirlik hataları nasıl önceliklendirilir?

Erişilebilirlik hataları, kullanıcıyı engelleme düzeyi, etkilenen sayfa sayısı ve işlemin ticari veya hukuki önemi birlikte değerlendirilerek önceliklendirilir.

Önce görevi tamamen durduran sorunları ele alın. Klavye ile menünün açılamaması, formun gönderilememesi, odak göstergesinin kaybolması ve ödeme adımının ekran okuyucuda kullanılamaması yüksek önceliklidir.

İkinci sırada çok sayıda sayfayı etkileyen ortak bileşenleri değerlendirin. Header, çerez paneli, modal, tasarım sistemi düğmesi veya form bileşeni tek düzeltmeyle birçok URL'deki sorunu giderebilir.

Üçüncü sırada anlaşılabilirlik ve verimlilik sorunları bulunur. Belirsiz bağlantı metinleri, karmaşık hata açıklamaları ve tutarsız başlık yapısı kullanıcıyı her zaman tamamen engellemeyebilir. Ancak görevin tamamlanma süresini ve hata olasılığını artırabilir.

Her bulguya önem derecesi, başarı ölçütü, etkilenen kullanıcı grubu, yeniden üretim adımı ve önerilen düzeltme ekleyin. “Erişilebilir değil” yerine “Tab ile açılan menüde odak görünmüyor; 2.4.7 ve 2.4.11 açısından incelenmeli” gibi yazın.

Düzeltme sonrası yalnızca hatalı satırı değil, çevresindeki akışı da test edin. Bir odak stilini değiştirmek, kontrastı artırırken başka bir bileşenin görünümünü bozabilir. Ortak CSS veya JavaScript değişiklikleri regresyon testi gerektirir.

İzleme tablosunda durum seçenekleri kullanın: yeni, inceleniyor, geliştiricide, düzeltildi, yeniden test bekliyor ve kapatıldı. Kapanan her hata için kanıt, test koşulu ve sonuç saklanmalıdır.

WCAG 2.2 AA kontrol sonucu nasıl raporlanır?

WCAG 2.2 AA kontrol sonucu, kapsamı, kullanılan yöntemi, bulunan hataları ve test sınırlarını açıkça belirten bir raporla sunulmalıdır.

Raporun ilk bölümünde test edilen alanları yazın. Örnek sayfalar, giriş gerektiren ekranlar, üçüncü taraf bileşenler ve test dışı bırakılan bölümler ayrı belirtilmelidir. “Site test edildi” ifadesi tek başına kapsam göstermez.

İkinci bölümde araçları ve manuel yöntemleri listeleyin. Kullanılan tarayıcılar, işletim sistemleri, ekran okuyucular, mobil cihazlar ve yakınlaştırma seviyeleri kayıt altına alınmalıdır. Test tarihi de eklenmelidir.

Üçüncü bölümde başarı ölçütü bazlı bulgular yer almalıdır. Her satırda ölçüt numarası, hata açıklaması, URL, yeniden üretim adımı, etkisi, ekran görüntüsü ve önerilen çözüm bulunabilir.

Rapor, “uyumlu” veya “uyumsuz” gibi tek cümlelik bir sonuca indirgenmemelidir. Test edilen örneklemin sınırları varsa bu sınırlar açıkça yazılmalıdır. Dinamik olarak üretilen içerikler ve üçüncü taraf iframe'ler ayrıca belirtilmelidir.

Siteye bir erişilebilirlik bildirimi eklemek istiyorsanız, bildirimin test kapsamı ve kullanıcıların ulaşabileceği iletişim yöntemiyle tutarlı olması gerekir. Web sitesine erişilebilirlik bildirimi nasıl eklenir? rehberinde bildirim içeriği ve yapılandırması ayrıca ele alınır.

Rapor yayınlandıktan sonra süreç bitmez. Yeni tasarım bileşeni, kampanya açılış sayfası, ödeme sağlayıcısı veya çerez yöneticisi eklendiğinde ilgili akış yeniden test edilmelidir. Erişilebilirlik kontrolü, sürüm öncesi kalite sürecinin parçası olmalıdır.

WCAG 2.2 AA kontrolü için uygulanabilir adımlar nelerdir?

Uygulanabilir bir kontrol planı, aynı sayfaları ve akışları tekrar test edebilecek şekilde yazılı, ölçülebilir ve kanıtlanabilir olmalıdır.

1. Test kapsamını belirleyin: sayfaları, kullanıcı rollerini ve kritik işlemleri listeleyin.
2. Sayfaları otomatik araçlarla tarayın ve kesin hataları ayırın.
3. Fareyi bırakıp Tab, Shift ve Tab, Enter ve Space ile tüm işlemleri deneyin.
4. Yakınlaştırma, yeniden akış, mobil görünüm ve dokunmatik hedefleri kontrol edin.
5. Form etiketlerini, hata mesajlarını, başarı bildirimlerini ve giriş işlemlerini inceleyin.
6. NVDA, VoiceOver veya TalkBack ile başlık, bağlantı ve durum akışını test edin.
7. Bulguları WCAG başarı ölçütü, URL ve yeniden üretim adımıyla kaydedin.
8. Düzeltmeleri aynı koşullarda yeniden test edin ve regresyonları ayrıca kontrol edin.

Bu sıranın amacı, pahalı manuel testlere başlamadan önce kolayca düzeltilebilecek tekrarlı hataları görmektir. Ancak otomatik tarama sonuçlarının temiz olması, sonraki adımların atlanabileceği anlamına gelmez.

Başlangıç kontrol listesi olarak aşağıdaki maddeleri kullanabilirsiniz:

• Her sayfada anlamlı ve sıralı başlık yapısı var mı?
• Fare olmadan menü, form, modal ve ödeme işlemi tamamlanabiliyor mu?
• Odak göstergesi her etkileşimli kontrolde görünür mü?
• Metin, bileşen ve odak renkleri yeterli kontrasta sahip mi?
• Görsellerin alternatif metni amacını doğru anlatıyor mu?
• Hata mesajları çözüm öneriyor ve ekran okuyucuya ulaşıyor mu?
• Yakınlaştırma ve mobil görünümde içerik kayboluyor mu?
• Yeni içerik ve durum değişiklikleri kullanıcıya bildiriliyor mu?

Çerez paneli gibi üçüncü taraf veya ortak bileşenler de bu listeye dahil edilmelidir. Reklam ve analiz çerezleri için rıza akışını değerlendirirken, web sitesinde reklam çerezi için rıza alma sürecinin klavye ve ekran okuyucu kullanımını da kontrol edin.

Sonuçları düzenli aralıklarla değil, önemli arayüz değişikliklerinden sonra da gözden geçirin. Böylece kontrol, yalnızca tek seferlik rapor değil, sürekli kalite adımı olarak çalışır.