Erişilebilirlik denetimi nasıl yapılır?

Kısaca

Erişilebilirlik denetimi, ürününüzü görme, işitme, hareket ya da bilişsel engeli olan biri gibi kullanmaya çalışmaktır. Ölçüt WCAG'dir. Ben denetimlerde WCAG 2.2'nin AA seviyesini hedef alırım.

Erişilebilirlik testi, web erişilebilirlik denetimi ve a11y audit aynı işin farklı adlarıdır. "a11y", İngilizce accessibility kelimesinin kısaltmasıdır: baştaki a ile sondaki y arasında 11 harf var.

Ben erişilebilirliği ayrı bir ürün olarak satmıyorum. UX Audit içinde WCAG 2.2'nin temel kontrolleri zaten var. Kriterlerin ne dediğini WCAG rehberinde anlattım. Bu sayfa testin kendisini, yani nereye nasıl baktığımı anlatıyor.

• Otomatik tarama yalnızca başlangıçtır. Asıl testi bir insan klavyeyle, ekran okuyucuyla ve 320 piksel genişlikte yapar.
• Her bulgu bir ekrana, bir WCAG kriterine ve bir düzeltme önerisine bağlanır.

Ne zaman denetim yaptırmalısınız

Denetim en ucuz, tasarım henüz Figma'dayken olur. Soluk bir yardım metni ya da yalnızca renkle gösterilen bir hata orada birkaç dakikada düzelir. Yayından sonra aynı düzeltme için kod değişikliği ve yeni bir sürüm gerekir.

Şu durumlarda denetim öneririm:

• Yeni bir ürün ya da büyük bir yeniden tasarım yayına çıkmadan önce.
• Bir kullanıcı ekran okuyucuyla ya da klavyeyle bir işi bitiremediğini yazdığında.
• Tasarım sistemine yeni bir bileşen eklendiğinde. Butondaki bir hata, butonun kullanıldığı her ekrana yayılır.
• Bir kurum ya da müşteri sizden WCAG uyumu istediğinde. Türkiye'deki düzenlemeyi WCAG rehberinde anlattım.

Denetimi kimin yapacağı da önemli. Ürünü her gün kullanan ekip, ekranın nasıl çalışması gerektiğini bildiği için engeli kolay atlar. Dışarıdan gelen biri, menünün klavyeyle açılmadığını ilk denemede fark eder.

WAI de farklı engelleri olan insanların web'i nasıl kullandığını ilk elden bilen uzmanlardan söz eder. Bu uzmanlar, tek tek kullanıcıların bulamayacağı sorunları da değerlendirebilir.

Ben denetimde kendi kontrollerimi yaparım. Mümkün olduğunda ekibe gerçek kullanıcılarla kısa bir test turu da öneririm.

Denetimi yılda bir yapılan bir tören gibi görmeyin. Her büyük sürümde ana akışı klavyeyle bir kez gezmek, hataların birikmesini önler.

Otomatik ve elle test farkı

Otomatik araçlar hızlıdır ama son sözü söyleyemez. W3C'nin Web Erişilebilirliği Girişimi (WAI) bunu açıkça yazar: değerlendirme araçları erişilebilirliği belirleyemez, yalnızca buna yardımcı olur.

WAI'nin araç seçme rehberine göre bazı kontroller otomatikleştirilemez ve insan yargısı ister. Aynı rehber, araçların zaman zaman yanlış ya da yanıltıcı sonuç verebildiğini de söyler. Bu yüzden araç raporundaki sıfır hata, sitenin erişilebilir olduğunu göstermez.

Alternatif metin bunu iyi gösterir. WAI'nin Easy Checks sayfasına göre otomatik test, alt özniteliğinin eksik olup olmadığını söyleyebilir. Metnin uygun olup olmadığına ise görseli bağlamında gören biri karar verir.

Aşağıdaki tabloyu kendi pratiğimden yazdım:

Kontrol	Araç ne yapar	İnsan ne yapar
Alternatif metin	alt özniteliği eksik mi, bakar.	Metin görselin işini anlatıyor mu, karar verir.
Form etiketi	Etiketi olmayan alanı bulur.	Etiket alanın ne istediğini söylüyor mu, okur.
Kontrast	Düz zemindeki metnin oranını ölçer.	Fotoğraf ya da geçişli zemin üstündeki metni elle ölçer.
Odak	Çoğu zaman sessiz kalır.	Halka görünüyor mu, sıra mantıklı mı, Tab ile gezerek görür.

Kullanıcı testi de tek başına yetmez. WAI'nin kullanıcıları dahil etme sayfasına göre engelli kullanıcılarla test, uyum değerlendirmesinin tek başına bulamadığı kullanılabilirlik sorunlarını ortaya çıkarır. Aynı sayfa, kullanıcı testinin de bir sitenin erişilebilir olup olmadığını tek başına belirleyemeyeceğini ekler.

İyi bir denetim bu yüzden iki yöntemi birlikte kullanır.

Benim sıram

Otomatik taramayı ilk elle turdan sonra çalıştırırım. Önce ekranı bir kullanıcı gibi gezerim ve takıldığım yerleri not ederim. Böylece aracın listesi dikkatimi baştan dağıtmaz.

Tarama bitince iki listeyi yan yana koyarım. Araç bir şey bulduysa ve ben kaçırdıysam, o ekrana geri dönerim. Araç bir şeyi hata sayıyor ama ekranda bir engel göremiyorsam, kodu açıp kendim bakarım. Raporda yalnızca kendi gözümle doğruladığım bulgular yer alır.

WAI'nin kullanıcı sayfası bir şeyi daha hatırlatır. Engelli bir kullanıcı, aynı engele sahip başka insanların web'i nasıl kullandığını bilmeyebilir. Bu yüzden tek bir kullanıcının yorumunu da genel kural gibi okumam.

Adım adım denetim

Denetime bir kapsam yazarak başlarım: hangi akışlara ve hangi WCAG seviyesine göre bakacağım. W3C'nin değerlendirme yöntemi WCAG-EM'de de ilk adım kapsamı tanımlamaktır. Sonra seçtiğim her ekranda aşağıdaki sırayla ilerlerim.

Her adımın yanında ilgili WCAG 2.2 kriterini yazdım. Kriterlerin tam listesi WCAG rehberinde var.

1. Klavye (2.1.1, A)

Fareyi bırakın ve ana akışı yalnızca Tab, Shift+Tab, Enter, boşluk ve ok tuşlarıyla bitirmeye çalışın. WCAG 2.2'ye göre içeriğin tüm işlevleri klavye arayüzüyle kullanılabilir olmalı. Açılan menüye, pencereyi kapatan çarpıya ve tarih seçiciye özellikle bakarım.

Tek istisna, serbest çizim gibi kullanıcının çizdiği yola bağlı işlevlerdir. Bir kartı listeye sürüklerken izlenen yol önemli değildir. Bu yüzden sürükleme istisnaya girmez, klavyeyle de yapılabilmelidir.

2. Odak (2.4.3, A; 2.4.7 ve 2.4.11, AA)

Klavyeyle gezerken üç soru sorarım. Odak halkası her öğede görünüyor mu? Odak ekrandaki okuma sırasını izliyor mu? Odaktaki öğe yapışkan bir başlığın ya da çerez bandının altında kalıyor mu?

2.4.11, odaktaki öğenin sayfayı yapanların eklediği içerikle tamamen örtülmemesini ister. W3C bu içeriğe tipik örnek olarak yapışkan başlık ve altbilgileri verir. Aşağıdaki demoda ilk iki soruyu kendiniz deneyebilirsiniz.

3. Kontrast (1.4.3, AA)

Normal metinde metinle zemin arasındaki kontrast oranı en az 4,5:1, büyük metinde en az 3:1 olmalı. WCAG'ye göre büyük metin en az 18 punto ya da 14 punto kalın yazıdır. W3C'nin hesabıyla bu yaklaşık 24 ve 18,5 piksele denk gelir.

Gövde metni, yardım metni, yer tutucu yazı, butondaki yazı ve hata mesajını ayrı ayrı ölçerim. İki rengin oranını kontrast hesaplayıcıda bulabilirsiniz.

4. Alternatif metin (1.1.1, A)

Bilgi taşıyan her görselin aynı işi gören bir metin karşılığı olmalı. Ürün fotoğrafının alt metni ürünü anlatır, örneğin "Lacivert keten gömlek, uzun kollu". "Görsel" kelimesi ya da dosya adı bu işi görmez.

Süs görselleri için kural tersidir. W3C, bunların yardımcı teknolojilerin görmezden gelebileceği şekilde kodlanmasını ister. W3C'nin HTML tekniği bunun için boş alt metin kullanır, yani alt="".

5. Başlıklar (1.3.1, A)

Ekranda başlık gibi görünen her şey kodda da başlık olmalı, yani h1 ile h6 arasında bir etiket taşımalı. Easy Checks, başlık hiyerarşisinin anlamlı olup olmadığına da bakar.

Ben ekran okuyucuda sayfayı bir kez de başlıktan başlığa atlayarak gezerim. Kalın yazılmış bir paragraf bu turda hiç duyulmaz. Sonra başlık listesini çıkarıp tek başına okunuyor mu diye bakarım.

6. Form etiketleri (3.3.2, A)

Kullanıcıdan bilgi istenen her yerde bir etiket ya da yönerge olmalı. W3C'ye göre etiket herkese gösterilir, erişilebilir ad ise yalnızca yardımcı teknolojiye açık olabilir. Yani aria-label ile ad verilmiş bir alan, etiket herkese gösterilmiyorsa bu kriteri karşılamaz.

Benim yorumum şu: yalnızca yer tutucu yazıyla etiketlenen alanlar riskli. Kullanıcı yazmaya başlayınca yazı kaybolur ve alanın ne istediği ekrandan gider. Etiketi alanın üstüne, kalıcı olarak koyun.

7. Ekran okuyucu

Mac ve iPhone'da VoiceOver'ı, Android'de TalkBack'i açıp ana akışı ekrana bakmadan tamamlamaya çalışırım. Burada kriterden önce bir soru sorarım: duyduğum şey, ekranda gördüğümle aynı işi anlatıyor mu?

En sık yakaladığım şeyler adı olmayan ikon butonlar ve sessiz kalan durum mesajlarıdır. "Buton" diye okunan bir çarpı, kullanıcıya neyi kapattığını söylemez. "Sepete eklendi" yazısı ekranda çıkıp duyulmuyorsa, kullanıcı işin olup olmadığını bilemez.

8. Yeniden akış ve büyütme (1.4.10, AA)

İçerik 320 CSS piksel genişlikte, iki yönlü kaydırma gerektirmeden kullanılabilmeli. W3C'nin notuna göre bu, 1280 piksel genişlikteki bir pencereyi %400 büyütmeye denk gelir.

Testi iki yoldan yaparım. Masaüstü tarayıcıda sayfayı %400'e büyütürüm, sonra geliştirici araçlarında genişliği 320 piksele indiririm. Yatay kaydırma çubuğu çıkıyorsa ya da bir buton ekrandan taşıyorsa not alırım.

9. Hareket ve yanıp sönme (2.2.2 ve 2.3.1, A)

Kendiliğinden başlayan, başka içerikle birlikte görünen ve beş saniyeden uzun süren hareketin durdurulabilmesi gerekir. Kayan bir kampanya bandı ya da otomatik dönen bir slayt buna örnektir.

Ayrıca hiçbir şey bir saniyede üç kereden fazla yanıp sönmemeli. Kriterin tek istisnası, yanıp sönmenin W3C'nin tanımladığı eşiklerin altında kalmasıdır. Bunun üstüne kendi pratiğimden bir kontrol eklerim: işletim sisteminde hareketi azaltma ayarını açıp sayfanın buna uyup uymadığına bakarım.

Bu dokuz adım neyi kapsamıyor

Bu liste bir ilk turdur. Tam bir uyum testi daha fazlasını ister. WAI de Easy Checks için aynı uyarıyı yapar: bir sayfa bu kontrollerden geçiyor gibi görünüp yine de ciddi engeller taşıyabilir.

Videolu bir ürününüz varsa altyazı, döküm metni ve sesli betimleme ayrı bir tur ister. Sayfa başlığının her sayfada farklı ve açıklayıcı olması da Easy Checks listesindeki kontrollerden biridir. Bunlara hangi ekranlarda bakacağımı kapsam belgesine önceden yazarım.

Deneyin: Tab tuşuyla gezin

Aşağıdaki küçük formda iki hata var. Teste başla butonuna basın ve Tab tuşuyla formun sonuna kadar ilerleyin. Sarı kutu, her öğede hangi kriterin karşılandığını ya da ihlal edildiğini söyler.

Sonra Düzeltilmiş hal seçeneğine geçip aynı turu tekrarlayın. Ekranda hiçbir şey değişmiyor gibi görünür, ama klavyeyle gezince fark hemen anlaşılır.

Tab tuşuyla gezin

Örnek: diş kliniği randevu talebi

Ad soyad

E-posta

Telefon

Randevudan bir gün önce hatırlatma istiyorum

Randevu iste

JavaScript kapalı olduğu için form düzeltilmiş haliyle duruyor. İki hatanın anlatımı demonun altında.

Örnek form bir şey göndermez. Sorunlu halde iki hata bilerek bırakıldı: Telefon ile E-posta alanlarının kod sırası ters, butonun odak halkası kaldırılmış. Klavyeniz yoksa Tab sırasını göster butonuna basın, sıra numaralarla görünür.

Hata 1: Odak sırası bozuk (2.4.3, A)

Ekranda E-posta, Telefon'un üstünde duruyor. Kodda ise Telefon önce geliyor ve CSS ikisinin yerini değiştiriyor. Tab tuşu kodu izlediği için odak aşağı atlayıp geri döner. Düzeltme: kod sırasını görsel sırayla aynı yapın, sırayı CSS ile kurmayın.

Hata 2: Odak halkası yok (2.4.7, AA)

Butonun tarayıcıdan gelen odak çizgisi kaldırılmış, yerine bir şey konmamış. Klavye kullanan biri butona geldiğini göremez. Düzeltme: :focus-visible için kalın ve kontrastlı bir çerçeve tanımlayın.

Bu iki hatayı bu kadar sık görmemin bir sebebi var: ikisi de fareyle bakan birine görünmez. Tasarım incelemesinde ekran doğru görünür, hata ancak biri klavyeyle gezince ortaya çıkar.

Raporlama

WCAG-EM'nin son adımı bulguları toplamak ve raporlamaktır. Benim raporum bir uyum puanından çok bir iş listesidir. Ekip onu açtığında hangi maddeye bugün başlayacağını görebilmeli.

Her bulguda şunlar yazar:

• Hangi ekranda ya da akışın hangi adımında olduğu.
• Ne olduğu, kullanıcının gözünden tek cümleyle.
• WCAG 2.2 kriter numarası ve seviyesi.
• Kimi etkilediği ve nasıl test ettiğim.
• Bir düzeltme önerisi ve önem derecesi.

Örnek bulgu gerçek bir müşteri işinden alınmadı, yukarıdaki demodan yazıldı.

Önem derecesi için kullandığım 0–4 ölçeğini UX audit rehberinde anlattım. Erişilebilirlik bulgularında bir kuralım var: kullanıcının işi bitirmesini engelleyen her şey en üst sıraya çıkar.

Rapor kimin için

Raporu tasarımcı, geliştirici ve ürün yöneticisi farklı amaçlarla okur. Bu yüzden her bulguyu düzeltmenin yapılacağı yere göre etiketlerim. Kontrast ve etiket metni tasarım dosyasında, odak sırası ve ekran okuyucu adları kodda düzelir.

Raporun başına ürün yöneticisi için kısa bir giriş yazarım. Orada kaç bulgu olduğunu ve hangilerinin bir işi tamamen engellediğini söylerim. Kriter numaraları ise geliştiricinin aradığı yerde, bulgunun içinde durur.

Raporu teslim ettikten sonra iş bitmez. Düzeltmeler yayına girince aynı adımları aynı ekranlarda tekrar ederim. Kapanan maddeyi ancak o zaman listeden çıkarırım.

Benim notum

Erişilebilirliği kullanılabilirliğin bir parçası olarak görüyorum. Bu yüzden ayrı bir paket yapmadım. Bir akışı incelerken klavyeyi ve kontrastı da aynı turda kontrol ederim.

Ekiplerin en çok yanıldığı yer, otomatik tarama raporundaki yeşil işarettir. Rapor temiz çıkar ve herkes rahatlar. Sonra biri Tab tuşuna basar ve ödeme butonuna hiç ulaşamaz.

Kendiniz denemek isterseniz dokuz adımın ilk ikisiyle başlayın: klavye ve odak. Bir saatlik bir tur, en görünür engelleri ortaya çıkarır. Geri kalanını isterseniz UX Audit içinde sizin ekranlarınızda ben yaparım.