Bir başvuru formu düşünün: boşlukları dengeli, renkleri markayla uyumlu ve gönder düğmesi dikkat çekici. Fakat fareyi bıraktığınızda düğmeye ulaşamıyor, hata yaptığınızda hangi alanın düzeltilmesi gerektiğini anlayamıyorsunuz. Görsel olarak tamamlanmış bir ekran, kullanıcının işini tamamlamasına izin vermeyebilir.
Erişilebilir web tasarımı bu farkı kapatmayı amaçlar. Yalnızca ayrı bir ayar paneli eklemek değil, temel etkileşimleri farklı kullanım biçimleri için çalışır hâle getirmektir. Klavye, kontrast ve formlar bunun somut başlangıç noktalarıdır; ancak erişilebilirliğin bütün kapsamını oluşturmaz.
Bu rehber, varsayımsal bir hizmet başvuru akışı üzerinden geliştirme ve test yaklaşımı önerir. Seçilen WCAG 2.2 ölçütleri teknik dayanak sağlar; buradaki kontrollerin tamamlanması tek başına tam uygunluk beyanı anlamına gelmez.
Önce gerçek bir işi klavyeyle tamamlayın
Ana sayfadan başvuru formuna ilerleyin, alanları doldurun, açılan yardım penceresini kullanın ve başvuruyu gönderin. Tab ile ilerlerken Shift+Tab ile geri dönmeyi de deneyin. Amaç yalnızca her öğeye ulaşmak değil, işin anlamlı sırayla tamamlanabilmesidir.
WCAG'nin klavye ölçütü, hareket yoluna bağlı girdiler gibi tanımlanmış istisnalar dışında işlevlerin klavye arayüzüyle kullanılabilmesini ister. Bir başvuru düğmesini yalnızca fare tıklamasına bağlamak bu temel beklentiyi karşılamaz. W3C: Keyboard.
Geliştirmede gezinme için bağlantı, işlem için düğme gibi yerleşik HTML öğeleriyle başlayın. Tıklanabilir bir kutu oluşturup klavye davranışını sonradan taklit etmek, unutulabilecek yeni sorumluluklar doğurur. Görsel sırayla belge sırası ayrışıyorsa düzeni düzeltin; pozitif tabindex değerleriyle uzun bir sıra yönetmek kırılgan olabilir.
Odak nerede olduğunu göstermeli
Kullanıcı Tab tuşuna bastığında aktif öğeyi ayırt edebilmelidir. Varsayılan odak çizgisini kaldırıyorsanız yerine açıkça görülebilen bir gösterge koyun. Yalnızca fareyle üzerine gelindiğinde görünen renk değişimi yeterli bir klavye geri bildirimi değildir. W3C: Focus Visible.
Sabit üst menü ve çerez bildirimiyle de test yapın. WCAG 2.2 AA düzeyindeki 2.4.11 ölçütü, odaklanan bileşenin yazarın oluşturduğu içerik tarafından tamamen gizlenmemesini ister; hiç kısmen örtülmemesiyle aynı eşik değildir. Tasarımda bileşenin tamamını görünür tutmayı hedeflemek daha kullanışlı bir sonuç verir. W3C: Focus Not Obscured.
Açılan pencere odağı kaybetmemeli
Başvuru sırasında yardım penceresi açıldığında odağı anlamlı bir başlangıç noktasına taşıyın. Gerçek bir modal açıkken klavye odağı arka plandaki forma kaçmamalı; kapatıldığında genellikle açan düğmeye dönmelidir. Escape davranışı ve görünür kapatma kontrolü de akışın parçasıdır. W3C: Modal Dialog Pattern.
Kontrastı renk adlarıyla değil ölçümle değerlendirin
“Gri biraz koyulaştı” bir kabul ölçütü değildir. WCAG AA için normal metinde en az 4,5:1, büyük metinde en az 3:1 kontrast aranır. Büyük metin eşiği normal ağırlıkta 18 punto veya kalın yazıda 14 puntodur; her başlık otomatik olarak bu sınıfa girmez. Ölçüt logo ve pasif bileşenler gibi tanımlı istisnalar içerir. W3C: Contrast Minimum.
Kontrolü yalnızca tasarım dosyasındaki renk örneklerinde yapmayın. Saydam bir alan, fotoğraf veya renk geçişi üzerinde gerçek arka plan farklılaşabilir. Formun normal, odaklanmış ve hatalı durumlarını ayrı inceleyin. Koyu temanın bulunması da kendi başına okunabilirlik sağlamaz.
Arayüz öğelerini tanımak için gereken görsel bilgilerde ve ilgili grafiklerde komşu renklere karşı 3:1 ölçütü ayrıca değerlendirilir. Bu, sayfadaki her dekoratif çizginin aynı zorunluluğa sahip olduğu anlamına gelmez. W3C: Non-text Contrast.
Form, bilgiyi ve hatayı açıkça anlatmalı
Başvuru formundaki e-posta alanının görünür etiketi olsun ve etiket alanla programatik olarak ilişkilendirilsin. Placeholder örnek verebilir; kullanıcı yazmaya başladığında kaybolduğu için kalıcı etiketin yerini almamalıdır. Beklenen biçim veya zorunluluk bilgisi gerekiyorsa doldurmadan önce anlaşılabilmelidir. W3C: Forms Tutorial.
Hatalı alanı yalnızca kırmızı kenarlıkla belirtmek yerine sorunu yazıyla açıklayın. “Geçersiz giriş” yerine “E-posta adresinde @ işareti ve alan adı bulunmalı” gibi düzeltmeye yardım eden bir ifade kullanın. Başvuruyu yeniden göndermek için kullanıcının doğru doldurduğu bütün alanları silmeyin.
Hata mesajıyla alan arasındaki ilişki yardımcı teknolojilere de aktarılmalıdır. Uygun durumda aria-describedby açıklamayı bağlayabilir, aria-invalid alanın hatalı durumunu ifade edebilir. Bir hata özeti kullanılıyorsa kullanıcıyı ilgili alana götüren bağlantılar yararlıdır. Bu özellikleri eklemekten sonra gerçekten duyurulup duyurulmadığını test edin. W3C: Form Notifications.
Başarı ekranını da test kapsamına alın
Form kaydedildiğinde kullanıcı ne olduğunu anlayabilmelidir. Yalnızca düğmenin bir an yeşile dönmesiyle yetinmeyin. Başvurunun alındığını açıklayan kalıcı bir sonuç ve bundan sonra ne olacağına ilişkin kısa bilgi gösterin.
Örneğin başvuru numarası üretildiyse bunu kopyalanabilir metin olarak sunabilirsiniz. Başvurunun kaydı başarısız olduğunda aynı başarı ekranını göstermeyin. Erişilebilirlik testinin iş kurallarından kopması, teknik olarak gezilebilen fakat yanıltıcı bir akış bırakabilir.
Sorunları tekrar üretilebilir görevler hâline getirin
“Form erişilebilir değil” yerine ortamı, adımları ve beklenen sonucu yazın. Örnek kayıt: “Başvuru sayfasında yardım penceresini açınca Tab odağı arka plandaki gönder düğmesine geçiyor; odak modal içinde kalmalı.” Böyle bir görev geliştirilebilir ve aynı adımlarla yeniden sınanabilir.
Testte tarayıcıyı, kullanılan yardımcı teknolojiyi ve sürümlerini not edin. Yakınlaştırma açıkken, dar ekranda ve uzun hata mesajlarıyla da temel işi tamamlayın. Otomatik tarama, klavye incelemesi ve ekran okuyucuyla deneme birbirinin yerine değil, yanına konmalıdır.
Önceliklendirmede önce başvuruyu tamamen engelleyen sorunları ele alın. Sonra yanlış yönlendiren etiketleri, görünmeyen odağı ve okunabilirliği iyileştirin. Tek bir bileşen düzeltildiğinde aynı bileşenin diğer sayfalardaki örneklerini de kontrol edin; sorun yalnızca görüldüğü ekrana ait olmayabilir.
Uygulama kontrol listesi
- Ana kullanıcı işini fare kullanmadan tamamlayın.
- İleri ve geri klavye sırasının anlamlı olduğunu doğrulayın.
- Odak göstergesini sabit menüler ve bildirimlerle sınayın.
- Modal açılışını, kapanışını ve odak dönüşünü kontrol edin.
- Gerçek arka planlarda metin ve bileşen kontrastını ölçün.
- Alanlara kalıcı etiket ve gereken açıklamaları ekleyin.
- Hata mesajlarını alanlarla ilişkilendirin; girilmiş veriyi koruyun.
- Başarı, hata ve bekleme durumlarını ayrı ayrı deneyin.
- Düzeltmeleri aynı kullanıcı akışıyla yeniden test edin.
WebWizz ile bir arayüzü değerlendirmek isterseniz yalnızca ekran görüntüsünü değil, kullanıcının tamamlaması gereken işi de bizimle paylaşın. Tasarım ve geliştirme kapsamını bu gerçek akış üzerinden belirleyebiliriz.
Sık sorulan sorular
Otomatik testte yüksek puan almak yeterli mi?
Hayır. Bir etiketin varlığı ölçülebilir, fakat iş bağlamında anlaşılır olması ayrıca değerlendirilir. Klavyeyle işlem tamamlama ve yardımcı teknoloji testleri gibi manuel kontrolleri atlamayın.
Bütün metinler için 3:1 kontrast kullanılabilir mi?
Hayır. Bu eşik büyük metin için geçerlidir; normal metin için AA eşiği 4,5:1'dir. Yazının gerçekten büyük metin tanımına girip girmediğini kontrol edin.
ARIA eklemek bozuk klavye davranışını düzeltir mi?
Tek başına düzeltmez. Rol veya durum bilgisi, tıklanabilir kutuya otomatik olarak bütün düğme davranışlarını kazandırmaz. Uygun yerleşik öğeyi seçin ve etkileşimi ayrıca sınayın.
Bu liste bitince WCAG AA uygunluğu ilan edilebilir mi?
Hayır. Tam uygunluk, yalnızca bu üç alanı değil ilgili A ve AA ölçütlerini, tam sayfaları ve tamamlanan süreçleri kapsar. İncelenen kapsamı ve bulunan sınırlamaları açıkça belgeleyin. W3C: Conformance Requirements.