Web sitesinde WCAG 2.2 AA uyumu nasıl kontrol edilir? Önce kapsam belirlenir, ardından otomatik tarama, klavye testi, ekran okuyucu kontrolü ve manuel içerik incelemesi birlikte uygulanır.
Tek bir erişilebilirlik aracı, sitenin WCAG 2.2 AA seviyesini kanıtlamaz. Otomatik araçlar yalnızca belirli kod hatalarını yakalar. Kullanıcı deneyimini etkileyen birçok sorun manuel test gerektirir.
WCAG 2.2 AA uyumu tam olarak neyi ifade eder?
WCAG 2.2 AA uyumu, sitenin Web Content Accessibility Guidelines 2.2 standardındaki A ve AA başarı kriterlerini karşılaması anlamına gelir.
WCAG kriterleri dört temel ilkeye ayrılır: algılanabilir, kullanılabilir, anlaşılabilir ve sağlam içerik. Bu ilkeler; metin kontrastından klavye erişimine, form hatalarından ekran okuyucu uyumuna kadar farklı alanları kapsar.
AA seviyesi, yalnızca görsel tasarımı değerlendirmez. Örneğin bir butonun rengi yeterli kontrasta sahip olabilir. Ancak buton klavyeyle seçilemiyorsa erişilebilirlik sorunu devam eder.
WCAG 2.2, önceki sürümlere ek olarak odak görünürlüğü, sürükle-bırak işlemlerine alternatif ve kimlik doğrulama gibi konularda yeni kriterler içerir. Denetim sırasında kullanılan sürüm açıkça yazılmalıdır.
Uyum kontrolünün ilk adımı, sitenin tüm kullanıcı akışlarını listelemektir. Ana sayfa, menü, arama, ürün sayfası, sepet, ödeme, iletişim formu ve üyelik ekranı ayrı ayrı incelenmelidir.
WCAG 2.2 AA denetimine başlamadan önce hangi sayfalar seçilir?
Denetime başlamadan önce sitenin şablonlarını ve kritik kullanıcı akışlarını temsil eden sayfalar seçilir.
E-ticaret sitesinde ana sayfa, kategori, ürün detay, sepet, ödeme, üyelik ve sipariş sonucu sayfaları minimum inceleme kapsamına alınmalıdır. Her sayfa farklı bir bileşen veya işlem içerir.
Kurumsal sitede hizmet sayfası, iletişim formu, kariyer başvurusu, blog yazısı, arama sonuçları ve mobil menü ayrıca test edilmelidir. Sadece ana sayfayı kontrol etmek yeterli değildir.
Tekrarlanan şablonlar için örnekleme yapılabilir. Ancak örnek sayfalar farklı içerik uzunluklarını, tablo kullanımını, görselleri, form alanlarını ve hata mesajlarını göstermelidir.
Yeni bir sayfa türü, üçüncü taraf bileşen veya kampanya modülü eklendiğinde kapsam yeniden değerlendirilir. Örneğin ödeme sağlayıcısının gömülü penceresi, ana sitenin kontrolünden ayrı incelenebilir.
Denetim kaydında URL, cihaz türü, tarayıcı, test tarihi ve kullanılan yardımcı teknoloji yazılmalıdır. Bu bilgiler olmadan aynı hatanın tekrar test edilmesi zorlaşır.
Otomatik erişilebilirlik araçları hangi hataları bulur?
Otomatik araçlar, HTML yapısı ve belirli WCAG kriterleriyle ilişkili ölçülebilir hataları hızlıca bulur.
Bu araçlar eksik alt metin, form etiketi bulunmaması, hatalı başlık sırası, düşük renk kontrastı, geçersiz ARIA kullanımı ve boş bağlantı metni gibi sorunları işaretleyebilir.
Tarama için Lighthouse, axe veya benzeri araçlar kullanılabilir. Aynı sayfayı en az iki farklı yöntemle taramak, araçların farklı kurallarını karşılaştırmayı sağlar.
Ancak otomatik sonuçlarda görülen her uyarı kesin hata değildir. Araç, bir görselin alt metninin varlığını kontrol edebilir. Metnin gerçekten görseli açıklayıp açıklamadığını değerlendiremez.
Otomatik tarama, özellikle dinamik içeriklerde eksik kalır. Açılır menü, modal pencere, takvim, canlı arama ve ödeme adımları kullanıcı etkileşimi olmadan tam incelenemez.
Yanlış: Sitede Lighthouse skoru 100 olduğu için WCAG 2.2 AA uyumludur. Doğru: Otomatik tarama sonuçları, manuel test ve kullanıcı akışı incelemesiyle birlikte değerlendirilir.
Her hata için URL, bileşen, ilgili WCAG kriteri, önem seviyesi, ekran görüntüsü ve önerilen düzeltme yazılmalıdır. Böylece geliştirici, belirsiz bir uyarı yerine uygulanabilir görev alır.
Klavyeyle kullanım testi nasıl yapılır?
Klavyeyle kullanım testi, fare kullanmadan sitenin tüm temel işlemlerini tamamlamaya çalışarak yapılır.
Test sırasında yalnızca Tab, Shift+Tab, Enter, Boşluk ve ok tuşları kullanılmalıdır. Odak göstergesi her adımda görünür olmalı ve odak sırası görsel akışla uyumlu ilerlemelidir.
Önce tarayıcı açılır ve imleç adres çubuğundan sayfaya geçirilir. Kullanıcı, ana içeriğe atlama bağlantısına ulaşabiliyor mu kontrol edilir. Bu bağlantı görünür veya odaklandığında görünür olabilir.
Ardından menü, arama alanı, filtreler, ürün seçimi, form alanları, hata mesajları ve modal pencereler test edilir. Klavye odağı kapalı bir pencerede takılı kalmamalıdır.
Bir modal açıldığında odak genellikle modal içindeki ilk uygun elemana taşınmalıdır. Modal kapandığında odak, pencereyi açan kontrolün mantıklı konumuna dönmelidir.
Odak stilinin yalnızca renk değişiminden oluşması bazı arka planlarda yetersiz kalabilir. CSS ile eklenen metin veya görsel işaretlerin anlaşılır olması ayrıca kontrol edilmelidir. Bu ayrım için Google'da CSS ile eklenen metin indekslenir mi? başlıklı içerikteki teknik yaklaşım da yararlı bir bağlam sunar.
Testin işe yaramadığı durum, yalnızca statik sayfaların gezilmesidir. Asıl risk; filtreleme, ödeme, takvim ve doğrulama gibi klavye etkileşimi gerektiren bileşenlerde ortaya çıkar.
Renk kontrastı ve görsel içerik nasıl kontrol edilir?
Renk kontrastı, metin ile arka plan arasındaki algılanabilirlik farkı ölçülerek kontrol edilir.
WCAG 2.2 AA kapsamında normal metin için kontrast oranı en az 4,5:1, büyük metin için en az 3:1 olmalıdır. Büyük metin değerlendirmesinde yazı boyutu ve kalınlığı birlikte dikkate alınır.
Kontrol yalnızca gövde metnine uygulanmaz. Buton yazısı, bağlantılar, hata mesajları, yer tutucu metinler ve grafik üzerindeki açıklamalar da incelenmelidir.
Arayüz bileşenlerinin sınırları ve odak göstergeleri için ayrı kontrast gereklilikleri bulunur. Bu nedenle açık gri kenarlıklı form alanları, metin okunuyor olsa bile sorun yaratabilir.
Renk tek başına bilgi aktarmamalıdır. “Zorunlu alanlar kırmızıyla gösterilir” yaklaşımı, renk görmeyen kullanıcılar için yetersizdir. Etiket, simge veya metinsel açıklama eklenmelidir.
Görsellerin alt metni bağlama göre yazılır. Dekoratif görseller boş alt niteliğiyle işaretlenebilir. Bilgi taşıyan görseller ise görseldeki anlamı kısa ve işlevsel biçimde açıklamalıdır.
Ürün görsellerinde “ürün görseli” ifadesi genellikle yetersizdir. Ürünün adı, rengi veya görseldeki önemli farkı gerekiyorsa alt metinde belirtilmelidir.
Kontrast aracı yalnızca renk oranını ölçer; alt metnin doğruluğunu veya grafiğin anlamını değerlendiremez. Bu nedenle görsel kontrolü, içerik editörü tarafından ayrıca yapılmalıdır.
Formlar, hata mesajları ve giriş alanları nasıl test edilir?
Form erişilebilirliği, her alanın etiketlenmesi ve hatanın kullanıcıya açık biçimde bildirilmesiyle kontrol edilir.
Bir giriş alanının yalnızca yer tutucu metinle tanımlanması yeterli değildir. Alanın kalıcı bir etiketi bulunmalı ve bu etiket HTML ilişkilendirmesiyle input elementine bağlanmalıdır.
Zorunlu alanlar yalnızca yıldız işaretiyle gösterilmemelidir. Formun başında yıldızın anlamı açıklanmalı veya alanın zorunlu olduğu metinsel olarak belirtilmelidir.
Hatalı veri gönderildiğinde hata mesajı, ilgili alanla ilişkilendirilmelidir. Kullanıcı hangi alanda sorun olduğunu, hatanın neden oluştuğunu ve nasıl düzelteceğini anlayabilmelidir.
Örneğin “Geçersiz giriş” mesajı çoğu durumda yetersizdir. “E-posta adresini [email protected] biçiminde yazın” ifadesi daha doğrudan bir düzeltme talimatı verir.
Form testinde boş gönderim, eksik alan, hatalı e-posta, yanlış telefon biçimi, kısa parola ve sunucu hatası ayrı ayrı denenmelidir. Sadece başarılı gönderim akışı test edilmemelidir.
Otomatik doldurma, parola gösterme, takvim seçimi ve doğrulama kodu bileşenleri de incelenmelidir. Kimlik doğrulama sürecinde kullanıcıdan yalnızca hatırlaması zor bir bulmacayı çözmesi beklenmemelidir.
Form bileşeni üçüncü taraf bir araçtan geliyorsa, sorumluluk tamamen sağlayıcıya bırakılmamalıdır. Gömülü alanlar da klavye, ekran okuyucu ve hata mesajı testlerinden geçirilmelidir.
Ekran okuyucu testi hangi adımlarla yapılır?
Ekran okuyucu testi, sayfanın görsel düzeninden bağımsız olarak anlamlı ve tamamlanabilir olup olmadığını gösterir.
Testte bir ekran okuyucu ve desteklenen bir tarayıcı birlikte kullanılmalıdır. İşletim sistemine göre farklı yardımcı teknolojiler tercih edilebilir; önemli olan kullanılan kombinasyonun rapora yazılmasıdır.
Önce sayfa başlığı, dil tanımı, ana başlık ve bölüm başlıkları dinlenir. Başlıklar görsel olarak büyük olsa bile HTML başlık hiyerarşisi doğru değilse gezinme zorlaşır.
Ardından bağlantı listesi ve düğme listesi incelenir. “Tıklayın”, “devamı” veya yalnızca ikon olarak okunan kontroller, hedefi açıklamıyorsa sorun oluşturur.
Görsellerin alt metinleri dinlenir. Aynı bilgi başlıkta zaten varsa gereksiz tekrarlar çıkarılmalıdır. Dekoratif görsellerin dosya adlarıyla okunması da düzeltilmesi gereken bir işarettir.
Form alanlarının etiketi, türü, zorunlu durumu ve hata mesajı birlikte duyulmalıdır. Kullanıcı, ekran okuyucu modundan çıkmadan formu doldurabilmeli ve gönderim sonucunu anlayabilmelidir.
Dinamik içerik için canlı bölgeler dikkatli kullanılmalıdır. Her küçük değişikliği seslendirmek kullanıcıyı yorabilir. Sadece önemli durum değişiklikleri uygun biçimde duyurulmalıdır.
Ekran okuyucu testi tek başına yeterli değildir. Ekran okuyucu kullanmayan düşük görme, motor veya bilişsel engelli kullanıcıların sorunları; büyütme, klavye ve sade dil kontrolleriyle ayrıca değerlendirilmelidir.
WCAG 2.2 AA denetim sonuçları nasıl raporlanır?
Denetim raporu, her bulguyu ilgili WCAG kriteri ve uygulanabilir düzeltme adımıyla eşleştirerek hazırlanır.
Raporun başında kapsam bulunmalıdır. Test edilen URL'ler, sayfa türleri, cihazlar, tarayıcılar, ekran okuyucu kombinasyonu ve test tarihi burada belirtilir.
Her bulgu için benzersiz bir kayıt numarası kullanılabilir. Örneğin A11Y-001 kodu; sorunun başlık sırasını, ürün detay sayfasında bulunduğunu ve açık olduğunu takip etmeyi kolaylaştırır.
Bulgular kritik, yüksek, orta ve düşük öncelik olarak sınıflandırılabilir. Öncelik; kriterin önemine, etkilenen sayfa sayısına ve işlemin tamamlanmasını engelleyip engellemediğine göre belirlenmelidir.
Bir ödeme düğmesinin klavyeyle kullanılamaması, dekoratif bir görseldeki alt metin eksikliğinden daha yüksek önceliklidir. Önceliklendirme bu tür kullanıcı etkisi üzerinden yapılmalıdır.
| Bulgu türü | Örnek | Kanıt | Önerilen işlem |
|---|---|---|---|
| Klavye | Menü açılıyor, odak menüye geçmiyor | Video veya adım kaydı | Odak yönetimini düzeltmek |
| Görsel | Bilgi taşıyan görselde eksik alt metin | URL ve ekran görüntüsü | Bağlama uygun alt metin eklemek |
| Kontrast | Buton metni 4,5:1 oranının altında | Kontrast ölçümü | Renk çiftini değiştirmek |
| Form | Hata mesajı alanla ilişkilendirilmemiş | Test adımları | Programatik hata bağlantısı kurmak |
Raporun sonunda düzeltme sonrası yeniden test tarihi ve sorumlu ekip bulunmalıdır. Aynı bulgunun kapatılması, yalnızca kodun değiştirilmesiyle değil, tekrar test sonucu ile doğrulanır.
WCAG 2.2 AA kontrol listesinde hangi maddeler bulunmalı?
Kontrol listesi, her sayfa ve bileşen için tekrarlanabilir test adımlarını içermelidir.
- Sayfada tek ve anlamlı bir ana başlık bulunuyor mu?
- Başlık seviyeleri görsel sırayla ve HTML yapısıyla uyumlu mu?
- Tüm işlevsel görsellerin bağlama uygun alt metni var mı?
- Dekoratif görseller ekran okuyucu tarafından gereksiz okunuyor mu?
- Tüm bağlantı ve düğmeler klavyeyle kullanılabiliyor mu?
- Odak göstergesi her interaktif kontrolde görünür mü?
- Menü, modal, açılır liste ve sekmelerde odak sırası doğru mu?
- Metin ve arka plan kontrastı AA gerekliliklerini karşılıyor mu?
- Bilgi yalnızca renk, şekil veya konumla aktarılıyor mu?
- Form alanlarının kalıcı ve programatik etiketleri var mı?
- Hata mesajları anlaşılır ve ilgili alanla bağlantılı mı?
- Mobil görünümde yatay kaydırma veya taşan içerik oluşuyor mu?
- Sayfa büyütüldüğünde metin, buton ve menüler kullanılabilir kalıyor mu?
- Animasyon, otomatik oynatma ve hareketli içerik durdurulabiliyor mu?
- Dinamik içerik değişiklikleri gerekli olduğunda yardımcı teknolojiye bildiriliyor mu?
Listeyi yalnızca işaret kutularından oluşan bir belge olarak kullanmak yeterli değildir. Her madde için sonuç, kanıt, sorumlu kişi ve yeniden test durumu eklenmelidir.
Kontrol listesi sürüm kontrollü tutulmalıdır. Tasarım sistemi, ortak buton, form ve modal bileşenleri değiştiğinde ilgili maddeler yeniden çalıştırılmalıdır.
Bu yaklaşım özellikle çok sayfalı kurumsal sitelerde işe yarar. Ancak içerik ekibi kontrol listesine dahil değilse yeni yüklenen kampanya görselleri ve PDF dosyaları gözden kaçabilir.
Denetimden sonra WCAG hataları hangi sırayla düzeltilir?
Hatalar, kullanıcı işlemini engelleyen ve birçok sayfada tekrar eden sorunlardan başlanarak düzeltilir.
İlk aşamada klavye ile erişilemeyen temel işlemler, görünmeyen odak, bozuk modal davranışı ve gönderilemeyen formlar ele alınmalıdır. Bu sorunlar doğrudan görev tamamlamayı engeller.
İkinci aşamada ortak bileşenler düzeltilir. Header, menü, buton, kart, form ve modal gibi bileşenler tek şablonda çözülürse birçok sayfadaki hata azalır.
Üçüncü aşamada renk kontrastı, başlık hiyerarşisi, bağlantı isimleri ve görsel alt metinleri ele alınabilir. Bu değişiklikler genellikle içerik ve tasarım ekiplerinin birlikte çalışmasını gerektirir.
Dördüncü aşamada üçüncü taraf içerikler, PDF belgeleri, gömülü videolar ve kampanya modülleri incelenir. Dış kaynak üzerinde değişiklik yapılamıyorsa kullanıcıya eşdeğer erişilebilir alternatif sunulmalıdır.
- Denetim kapsamını ve test ortamını sabitleyin.
- Otomatik tarama sonuçlarını sınıflandırın.
- Kritik kullanıcı akışlarını klavye ile tamamlayın.
- Ekran okuyucu ve büyütme testlerini uygulayın.
- Bulguları WCAG kriterleriyle eşleştirin.
- Ortak bileşenleri ve yüksek öncelikli hataları düzeltin.
- Düzeltmeleri aynı adımlarla yeniden test edin.
- Raporu tarih, kanıt ve sorumlularla güncelleyin.
Her düzeltme başarılı olmayabilir. Örneğin kontrastı artırmak marka rengini değiştirebilir, ancak yalnızca renk değişimi kullanıcı deneyimini çözmeyebilir. Tasarım kararı, kriter ve işlev birlikte değerlendirilmelidir.
Erişilebilirlik tek seferlik proje değildir. Yeni ürün, kampanya, form veya içerik yayınlandığında aynı kontrol akışının kısa sürümü uygulanmalıdır.
WCAG 2.2 AA uyumu SEO ve kullanıcı deneyimini nasıl etkiler?
WCAG uyumu, SEO için doğrudan bir puan garantisi vermez; ancak taranabilir, anlaşılır ve kullanılabilir içerik oluşturmayı destekler.
Anlamlı başlıklar, açıklayıcı bağlantı metinleri, doğru HTML yapısı ve metin alternatifleri arama motorlarının içeriği yorumlamasına yardımcı olabilir. Bunlar aynı zamanda yardımcı teknolojiler için de önemlidir.
Alt metin, anahtar kelime doldurma alanı değildir. Ürünü veya işlevi açıklamalıdır. Arama motorunda görünmek için alakasız terimler eklemek, kullanıcıya gereksiz bilgi verir.
Sayfa hızını artırmak için içeriği yalnızca görsel olarak sunmak da hatalıdır. Metin, HTML içinde erişilebilir biçimde bulunmalıdır. Bu konu, CSS ile eklenen metinlerin arama görünürlüğü bakımından da ayrıca incelenmelidir.
Formların ve menülerin klavyeyle çalışması, dönüşüm akışını daha geniş bir kullanıcı grubuna açar. Ancak erişilebilirlik düzeltmesi otomatik olarak satış artışı anlamına gelmez; hız, teklif ve güven unsurları ayrıca ölçülmelidir.
E-ticaret sitelerinde ödeme akışı özellikle önemlidir. Ürün varyantı seçimi, stok bilgisi, kargo tercihi ve ödeme onayı erişilebilir değilse kullanıcı satın alma işlemini tamamlayamaz.
Kurumsal sitelerde iletişim formu, telefon bilgisi ve hizmet açıklamaları test edilmelidir. Örneğin emlak danışmanı web sitesi gibi yoğun form ve ilan içeren yapılarda filtreler, harita bilgileri ve başvuru adımları ayrıca değerlendirilir.
KVKK ve çerez yönetimi erişilebilirlikten ayrı bir konudur. Ancak izin ekranlarının klavye ve ekran okuyucu ile kullanılabilir olması gerekir. Bu nedenle Dijital Pazarlamada KVKK ve Çerez Uyumu içeriğindeki yasal kontrol başlıklarıyla erişilebilirlik testleri birlikte planlanabilir.
Sonuç olarak WCAG 2.2 AA denetimi, tek araçla alınan bir skor değildir. Kapsam, otomatik tarama, manuel kullanım, ekran okuyucu testi, raporlama ve yeniden doğrulama adımlarının tamamı birlikte yürütülmelidir.
Sayfa türlerini, kritik kullanıcı akışlarını ve kullanılan bileşenleri listeleyerek başlayın. Medyografya, İzmir merkezli dijital reklam ajansı olarak web sitesi ve dijital içerik süreçlerinde teknik kapsamın netleştirilmesine yardımcı olabilir.
Sık Sorulan Sorular
WCAG 2.2 AA uyumu tek bir otomatik araçla kanıtlanabilir mi?
Hayır. Otomatik araçlar belirli kod ve kontrast hatalarını bulur. Klavye, ekran okuyucu, form ve dinamik bileşen testleri manuel yapılmalıdır.
WCAG 2.2 AA denetiminde hangi sayfalar test edilmelidir?
Ana sayfa, menü, arama, ürün veya hizmet sayfaları, formlar, sepet, ödeme, üyelik ve işlem sonucu sayfaları test edilmelidir.
WCAG 2.2 AA için normal metin kontrast oranı kaç olmalıdır?
Normal metin için kontrast oranı en az 4,5:1, büyük metin için en az 3:1 olmalıdır.
Klavyeyle erişilebilirlik testi nasıl yapılır?
Fare kullanmadan Tab, Shift+Tab, Enter, Boşluk ve ok tuşlarıyla menü, form, modal, filtre ve ödeme gibi temel işlemler tamamlanır.
Erişilebilirlik hataları hangi sırayla düzeltilmelidir?
Önce temel işlemleri engelleyen klavye, odak, modal ve form sorunları; ardından ortak bileşenler, kontrast, başlıklar ve alt metinler düzeltilmelidir.