Siteni erişilebilirlik standardına taşı (WCAG)

Erişilebilirlik ayrı bir proje değildir. Tasarım ve geliştirme sırasında verilen bir dizi karardan oluşur ve bu kararların çoğu maliyetsizdir — yeter ki zamanında verilsin.

Bu rehber sekiz adımı sırayla veriyor. Sıra tesadüfi değil: ilk adım en ucuz ve en çok sorun bulan olan, sonrakiler ise gittikçe daha fazla iş isteyen adımlar.

Referans standart WCAG 2.2; W3C'nin erişilebilirlik çalışmaları için önerdiği güncel sürüm bu. Her adımın sonunda ne yapılacağı, kimin sorumlu olduğu ve elinizde ne kalacağı yazıyor.

Erişilebilirlik, sitenin görme, işitme, hareket ya da bilişsel açıdan farklı yetilere sahip kullanıcılar tarafından da kullanılabilmesidir.

Sık yapılan iki yanlış anlama var.

Birincisi: "bu bizim kullanıcı kitlemiz değil." Erişilebilirlik için yapılan iyileştirmelerin büyük kısmı herkesin işine yarar. Yüksek kontrast, güneş altında telefonuna bakan kullanıcıya da yarar. Altyazı, gürültülü ortamdakine de. Klavyeyle gezinebilen bir form, faresi bozulan kullanıcıya da.

İkincisi: "sonradan ekleriz." Eklenmez. Bir arayüzün okuma sırası, başlık yapısı ve odak davranışı, kurulduğu anda belirlenir. Yayına girdikten sonra düzeltmek aynı işi ikinci kez yapmak demektir.

Erişilebilirlik ile kullanılabilirlik de aynı şey değil; ikisinin nerede ayrıldığını kullanılabilirlik yazımızda ele aldık.

WCAG üç uyum seviyesi tanımlar: A, AA ve AAA.

• A asgari seviyedir; karşılanmadığında bazı kullanıcılar siteyi hiç kullanamaz.
• AA kurumsal projelerde yaygın olarak hedeflenen seviyedir. Sözleşmelerde de genellikle bu seviye yazılır.
• AAA en yüksek seviyedir ama W3C'nin kendisi de tüm içerik için AAA uyumunun her zaman mümkün olmadığını belirtir. Tamamı için hedef koymak gerçekçi değildir; belirli sayfalarda hedeflenebilir.

Ne yapılır: Hedef seviyeyi projenin başında yazın ve sözleşmeye koyun. "Erişilebilir olacak" cümlesi ölçülemez; "WCAG 2.2 AA hedeflenecek" ölçülebilir.

Çıktı: Yazılı hedef seviye ve kapsam — hangi sayfa türleri dahil.

En ucuz test bu ve en çok sorun bulan da bu. Hiçbir araç gerektirmez.

Ne yapılır: Fareyi bırakın. Sekme tuşuyla sayfayı baştan sona gezin ve şunlara bakın:

• Her tıklanabilir öğeye sekme ile ulaşabiliyor musunuz?
• Şu anda nerede olduğunuz görünüyor mu? Odak göstergesi silinmiş mi?
• Sekme sırası sayfadaki görsel sıraya uyuyor mu?
• Açılan menü ya da pencereden sekme ile çıkabiliyor musunuz, yoksa içinde mi kalıyorsunuz?
• Formu baştan sona yalnız klavyeyle doldurup gönderebiliyor musunuz?

Bu beş sorudan biri bile "hayır" ise, o sayfayı yalnız klavyeyle kullanan biri orada takılıyor demektir.

Kim sorumlu: Geliştirme; tasarım tarafında odak göstergesinin kaldırılmamış olması gerekir.

Çıktı: Klavyeyle geçilemeyen noktaların listesi.

Kontrast, ölçülebilir ve tartışmasız bir eşiği olan tek başlıklardan biri.

Ne yapılır: Gövde metni ile arka plan arasındaki kontrast oranı, WCAG'ın AA seviyesinde istediği gibi en az 4,5:1 olmalı. Büyük punto metinlerde eşik daha düşüktür.

Kontrol edilecek yerler yalnız gövde metni değil: düğme üzerindeki yazı, form alanı sınırları, yer tutucu metinler, pasif hale getirilmiş öğeler ve fotoğraf üzerine yazılan başlıklar.

Bir kural daha var ve teknik değil kavramsal: rengi tek başına ayırt edici olarak kullanmayın. Hatayı yalnız kırmızıyla göstermek, rengi ayırt edemeyen kullanıcı için hiçbir şey göstermemektir. Renge her zaman bir metin, simge ya da biçim eşlik etmelidir.

Kim sorumlu: Tasarım.

Çıktı: Palet üzerinde doğrulanmış kontrast oranları ve düzeltilecek kombinasyonların listesi.

Ne yapılır: Her görsel için alternatif metin yazılır — ama hepsi için aynı biçimde değil.

Bilgi taşıyan görsel, taşıdığı bilgiyi anlatan bir metin alır. Yalnız süs amaçlı görsel ise boş alternatif metinle geçilir; ekran okuyucunun onu okuması kullanıcıyı yorar.

Sık yapılan hatalar: dosya adını alternatif metin olarak bırakmak, "görsel" yazmak, ya da grafikte anlatılan veriyi hiç yazmamak. Bir tabloyu ya da şemayı görsel olarak koyduysanız içindeki bilgi metinle de bulunmalı.

Kim sorumlu: İçerik; teknik uygulama geliştirmede.

Çıktı: Görsel envanteri ve her biri için alternatif metin kararı.

Ekran okuyucu sayfanın görünümünü değil yapısını okur. Bu yüzden görsel hiyerarşi ile yapısal hiyerarşi ayrı ayrı kurulmalıdır.

Ne yapılır: Başlıklar sırayla kullanılır; bir metni yalnız büyük ve kalın yapmak onu başlık yapmaz. Sayfada tek bir ana başlık bulunur, alt başlıklar seviye atlamadan iner.

Aynı mantık listeler, tablolar ve form grupları için de geçerli: görünüşü liste olan bir şey, yapısı da liste olmalıdır.

Bir de sayfa dili tanımlanmalı; ekran okuyucu metni doğru telaffuz etmek için buna bakar.

Kim sorumlu: İçerik ve geliştirme birlikte.

Çıktı: Başlık hiyerarşisi denetlenmiş sayfa şablonları.

Formlar erişilebilirlik sorunlarının en yoğun olduğu yerdir, çünkü hem yapı hem geri bildirim içerir.

Ne yapılır:

• Her alanın görünür ve kalıcı bir etiketi olsun. Yalnız yer tutucu metin kullanmak yetmez; yazmaya başlandığında kaybolur.
• Zorunlu alanlar yalnız yıldızla değil, metinle de belirtilsin.
• Hata mesajı alanın yanında, ne yapılacağını söyleyerek görünsün. "Geçersiz giriş" bir hata mesajı değildir.
• Hata yalnız renkle gösterilmesin.
• Uzun formlar mantıklı bölümlere ayrılsın ve kullanıcının hangi adımda olduğu belirtilsin.

Kim sorumlu: Tasarım ve geliştirme birlikte.

Çıktı: Form şablonlarının etiket, hata ve odak davranışı kontrolü.

Burada iki ayrı ölçü karıştırılıyor ve ayırmak gerekiyor.

Parmağın ölçüsü: MIT Touch Lab'in dokunma duyusu mekaniği araştırmasında ortalama parmak yastığı 10-14 mm, parmak ucu 8-10 mm olarak ölçülmüştür. Bu fiziksel bir bulgudur ve piksel karşılığı ekran yoğunluğuna göre değiştiği için tasarım reçetesi olarak kullanılamaz.

Hedefin ölçüsü: Uygulanacak sayı WCAG 2.2'nin eşikleridir — AA seviyesinde en az 24×24 CSS pikseli, AAA seviyesinde en az 44×44 CSS pikseli. Apple'ın arayüz kılavuzu da 44 punto önerir.

Buna ek olarak birbirine yakın tıklanabilir öğeler arasında boşluk bulunmalı ve form alanları klavye açıldığında ekran dışında kalmamalı.

Kim sorumlu: Tasarım.

Çıktı: Mobil şablonlarda hedef boyutu ve aralık denetimi.

Ne yapılır: Otomatik oynayan, kayan ya da yanıp sönen içerik kullanıcı tarafından durdurulabilmelidir. Otomatik ilerleyen bir slayt, yavaş okuyan kullanıcıyı içeriğe yetişemez halde bırakır.

Süreli işlemler — oturum zaman aşımı, geri sayımlı formlar — uzatılabilir olmalı ya da en azından uyarı vermeli.

Hareket duyarlılığı olan kullanıcılar için, işletim sisteminde hareketi azaltma tercihi açıksa animasyonlar buna uymalıdır.

Kim sorumlu: Geliştirme.

Çıktı: Hareketli bileşenlerin denetim listesi.

Kurumsal sitelerde en çok atlanan başlık bu, çünkü video genellikle projenin sonunda ekleniyor ve kontrol listesine hiç girmiyor.

Ne yapılır:

• Altyazı. Konuşma içeren kayıtlı videolarda altyazı, WCAG'ın temel gerekliliklerinden biridir. Otomatik üretilen altyazı bir başlangıçtır ama düzeltilmeden bırakılmamalı; marka adları, ürün isimleri ve teknik terimler neredeyse her zaman yanlış çıkar.
• Transkript. Sesli içeriğin tam metni. Erişilebilirlik dışında ikinci bir faydası daha var: metin haline gelen içerik aranabilir ve alıntılanabilir hale gelir.
• Sesli betimleme. Ekranda görülüp seste anlatılmayan bilgi varsa gerekir. Videoyu tasarlarken önemli bilgiyi sesle de söyletmek, sonradan betimleme eklemekten kolaydır.
• Otomatik oynatma. Ses otomatik başlamamalı. Başlıyorsa kullanıcı hemen durdurabilmeli.

Kim sorumlu: İçerik ve prodüksiyon.

Çıktı: Video envanteri ve her biri için altyazı-transkript durumu.

Otomatik denetim araçları işe yarar ama tek başına yeterli değildir ve bu sınırı bilmek gerekir.

Bulur: eksik alternatif metin, yetersiz kontrast oranı, eksik form etiketi, eksik sayfa dili, bozuk başlık sıralaması.

Bulamaz: alternatif metnin doğru olup olmadığı, okuma sırasının mantıklı olup olmadığı, hata mesajının anlaşılır olup olmadığı, klavyeyle bir görevi baştan sona tamamlanabilir olup olmadığı.

Yani araç sözdizimini denetler, anlamı denetleyemez. Otomatik denetimi tarama olarak kullanın, sertifika olarak değil.

Bir de kendiniz dinleyin. Yaygın işletim sistemlerinde ekran okuyucu yerleşik gelir; kurulum gerektirmez. Amaç uzmanlaşmak değil, en çok kullanılan sayfanızı baştan sona dinlemek. İlk deneme rahatsız edici olur ve bu normaldir — asıl mesele şu: dinlerken sayfanın anlattığı sıra, gördüğünüz sırayla aynı mı? Yarım saatlik bir deneme, otomatik raporun hiç göstermediği şeyleri gösterir.

Çıktı: Otomatik denetim raporu ve elle yapılan kontrollerin ayrı listesi.

Sırası maliyeti belirliyor.

Tasarım aşamasında gözetildiğinde erişilebilirlik neredeyse ek maliyet üretmez: kontrast palet seçilirken belirlenir, başlık yapısı şablon kurulurken oturur, odak davranışı bileşen tasarlanırken tanımlanır.

Yayına girmiş bir siteyi sonradan uyumlu hale getirmek ise farklı bir iştir. Renk paleti değişebilir, bileşenler yeniden yazılabilir, bazı sayfaların yapısı baştan kurulabilir. Aynı sonuç için ikinci kez ödeme yaparsınız.

Bu yüzden erişilebilirlik, teklif aşamasında kapsam dışı bırakılmaması gereken kalemlerden biridir. Kurumsal projede hangi aşamada ne yapıldığını kurumsal web sitesi rehberimizde anlattık.

Bugün yapabileceğiniz üç şey var ve üçü de araç gerektirmiyor:

1. Klavye testi. En çok ziyaret alan üç sayfanızı fareyi bırakıp sekme tuşuyla gezin. Bulduklarınız muhtemelen listenin en kritik maddeleri olacak.
2. Kontrast kontrolü. Palet üzerindeki gövde metni ve düğme renklerini oranla doğrulayın.
3. Hedef seviyeyi yazın. Sonraki projede "WCAG 2.2 AA" ifadesini kapsam notuna koyun.

Arayüz tarafındaki kuralların tamamını ve her birinin bozulduğunda ne olduğunu UI/UX altın kuralları yazımızda ele aldık.