Erişilebilirlik kontrolünü yalnızca görsellere alternatif metin eklemek olarak görmek, günlük kullanımda karşılaşılan birçok sorunu kaçırır. Bir kullanıcı menüyü klavyeyle açamıyor, form hatasının hangi alana ait olduğunu anlayamıyor veya odağını kaybediyorsa sayfa teknik olarak yüklenmiş olsa da görevini tamamlayamaz. Codex ile yapılacak incelemede başlangıç noktası, kullanıcıya ait küçük ve somut bir akış seçmektir.
Tek bir kullanıcı görevini izleyin
Örneğimizde okuyucu bir blog yazısını bulup e-posta aboneliğine kaydoluyor. Bu akışta gezinme menüsü, arama kutusu, sonuç bağlantısı ve kayıt formu bulunuyor. Bütün site için belirsiz bir puan istemek yerine bu adımlarda neyin kullanılabilir olduğunu inceleyin. Böylece bulunan sorunların kullanıcı üzerindeki etkisi açıkça anlatılabilir.
İncelemeye yalnızca fare kullanarak başlamayın. Klavyeyle sayfadaki etkileşimli öğelere sırayla ulaşın. Görsel olarak görünen bir öğenin odak alması veya odaklanan öğenin görünür olması aynı şey değildir. Özellikle sabit başlıklar, açılan paneller ve ekran dışındaki içerikler gerçek akış içinde değerlendirilmelidir. Kaynak kod incelemesi bu davranışa dair ipucu verir; tarayıcıda gözlem farklı bir kanıttır.
Codex'ten davranış ve kodu ilişkilendirmesini isteyin
Örnek görev metni:
Arama ve abonelik akışını erişilebilirlik açısından incele. Önce klavyeyle ulaşılabilir öğeleri, odak sırasını ve form etiketlerini değerlendir. Bulguları kullanıcı etkisi, ilgili öğe ve yeniden üretim adımıyla yaz. Araç erişimin yoksa tarayıcı kontrolü yaptığını söyleme. Otomatik kontrolün kapsamadığı durumları ayrı belirt; incelemeyi bir uygunluk sertifikası olarak sunma.
Bu istek Codex'in bir standarda otomatik olarak tam uyum sağladığı iddiasını içermez. Bir inceleme görevi tanımlar. Projenin hedeflediği erişilebilirlik ölçütleri varsa ayrıca belirtin ve ayrıntılı değerlendirmeyi o ölçütler üzerinden yapın.
Düzeltmeyi öğenin anlamıyla çözün
Tıklanabilir bir metin, aslında işlem yapıyorsa uygun bir düğme yapısı gerektirebilir; bir adrese gidiyorsa bağlantı olarak kalmalıdır. Sorunu her öğeye klavye olayı ekleyerek çözmek yerine mevcut HTML anlamını değerlendirin. Gereksiz ek durumlar, bakım sırasında fare ve klavye davranışının ayrışmasına yol açabilir.
Form alanlarında görünen etiket, yardım metni ve hata mesajı arasındaki ilişkiyi inceleyin. Yanlış e-posta girildiğinde hata yalnızca kırmızı renk olarak mı beliriyor, yoksa hangi bilginin düzeltilmesi gerektiği de söyleniyor mu? Kullanıcının yazdığı değer korunuyor mu? Bunlar küçük metin kararları gibi görünse de görevin başarıyla bitirilmesini doğrudan etkiler.
Doğrulamayı birkaç farklı yöntemle yapın
Kaynak incelemesi, klavye denemesi ve varsa otomatik araç çıktısı birbirini tamamlar. Otomatik taramanın temiz olması bütün etkileşimlerin sorunsuz olduğunu göstermez. Ekran okuyucu testi yapıldıysa kullanılan ortamı ve denenen akışı kaydedin. Yapılmadıysa bunu sonuç raporunda açıkça söyleyin; tahmini gözlem gibi sunmayın.
Düzeltmeden sonra başlangıçtaki görev tekrar denenmelidir. Aramayı açmak, sonuç seçmek ve form hatasını düzeltmek hâlâ aynı mantıklı sırada ilerliyor mu? Son açıklamada dosya sayısı yerine bu davranışı anlatın. Erişilebilirlik çalışması böylece genel bir kontrol listesi olmaktan çıkar; insanların sayfada yapmak istediği işi tamamlamasını kolaylaştıran somut bir iyileştirme olur.
İnceleme bulgularını tekrar üretilebilir tutmak için başlangıç odağını da tarif edin. “Menü açılmıyor” yerine hangi tuşa basıldığını, odaklanan öğenin adını ve gözlenen sonucu yazın. Böylece sonraki geliştirici farklı bir giriş noktasından deneyip sorunu yok sanmaz. Birden fazla yöntemle yapılan kontrolün sonuçları ayrı ayrı değerlendirilebilir.
Resmî kaynak: OpenAI — Prompting.
