Web formlarında hata yönetimi, sadece kullanıcı deneyimini değil, erişilebilirliği de doğrudan etkiliyor. Peki, ekran okuyucu kullanan kişiler için hata mesajları nasıl kurgulanmalı? En yaygın hatalardan bazıları, çözümleriyle birlikte bu içeriğimizde.
Ekran okuyucular için hata mesajlarında ortaya çıkan temel sorunlar
Birçok geliştirici, form doğrulama hatalarını standart yöntemlerle yönetiyor: aria-live="assertive" kullanımı, aria-invalid="true" ataması ve masaüstü tarayıcılarda fareyle yapılan testler. Bu yaklaşım masaüstünde çalışsa da, ekran okuyucu kullanıcıları için yetersiz kalabiliyor.
Gerçek dünya senaryolarında, hata mesajları farklı durumlarda beklenen etkiyi gösteremiyor. Örneğin:
- JAWS kullanıcısı formu doldurduğunda, hata mesajı hiç duyulmuyor ya da alana geri dönüldüğünde mesaj kaybolmuş oluyor.
- NVDA kullanıcısı, hata mesajını anlasa da, bilgiyi kaydedemeden ekran değişiyor.
- VoiceOver kullanıcısıysa, mesajın kaybolduğunu fark etmeden formu göndermeye çalışıyor.
Bu durumlar, sadece kullanıcı deneyimini değil, erişilebilirlik standartlarını da ihlal ediyor.
Kritik hata #1: Kaybolan bildirimler ve zaman sınırlamaları
Bir eğitim platformunun canlı ders sistemi, doğrulama hatalarını 8 saniye boyunca gösteren kayan pencerelerle yönetiyordu. Bu süre, masaüstü kullanıcılar için yeterli gibi görünse de ekran okuyucu kullanıcıları için oldukça yetersizdi.
Ekran okuyucu kullanan bir kişi, hatayı duyduğunda aşağıdaki adımları takip etmek zorunda:
- Hatanın ne olduğunu anlamak.
- İmleci ilgili forma geri getirmek.
- Girdiyi düzeltmek.
- Formu yeniden göndermek.
Karmaşık bir formda bu süreç 8 saniyeden daha uzun sürebiliyor. Dahası, WCAG 2.2.1 standardına göre, zaman sınırlamaları kullanıcı tarafından ayarlanabilir veya kaldırılabilir olmalıdır. Kritik bilgiler için kayan pencereler kullanmak, erişilebilirlik açısından doğrudan bir ihlal anlamına geliyor.
Çözüm: Kritik hata mesajlarını kayan pencerelerde değil, doğrudan ilgili form alanına yakın bir şekilde gösterin. Mesajlar, kullanıcı hatayı düzeltinceye kadar görüntülenmeye devam etmeli. Kayan pencereler ise sadece düşük önemdeki bildirimler için kullanılmalı.
Kritik hata #2: Odak değişimiyle kaybolan mesajlar
Başka bir projede, form alanına odaklanıldığında hata mesajı gösteriliyor, ancak kullanıcı başka bir alana geçtiğinde (onblur olayında) hata mesajı gizleniyordu. Bu durumda, sadece "Geçersiz giriş" gibi bir uyarı duyuluyor, fakat detaylar hiçbir zaman okunmuyordu.
Bu tasarımda iki temel sorun vardı:
- Kullanıcı form alanından çıktığında hata mesajı kayboluyordu. Bu da, alana geri dönüldüğünde mesajın artık görünmemesi anlamına geliyordu.
- Hata mesajıyla ilgili form alanı arasında
aria-describedbybağlantısı bulunmuyordu. Dolayısıyla, JAWS ve NVDA gibi ekran okuyucular, hata mesajını odaklandıklarında bile okumuyordu.
Doğru yaklaşım: Hata mesajlarını kalıcı hale getirin ve form alanlarıyla aria-describedby aracılığıyla programatik olarak ilişkilendirin. Odak değişimlerine bağlı olarak mesajları gizlemeyin. Kullanıcı hatayı düzeltip formu gönderebilene kadar mesajlar kalıcı olmalı.
Uygulamaya yönelik en iyi yöntemler
Erişilebilir hata mesajları tasarlamak için aşağıdaki adımları izleyin:
- Programatik bağlantılar oluşturun: Her hata mesajını, ilgili form alanına
aria-describedbyözelliğiyle bağlayın. Örnek:
<label for="email">E-posta Adresi</label>
<input type="email" id="email" aria-describedby="email-error" aria-invalid="true">
<span id="email-error" class="error-message">Lütfen geçerli bir e-posta adresi girin.</span>- Mesajları kalıcı hale getirin: Hata mesajları, kullanıcı hatayı düzeltinceye kadar görünür kalmalı. Kayan pencerelerde gösterilen mesajlar, sadece düşük önemdeki bildirimler için tercih edilmeli.
- Zaman sınırlamalarından kaçının: Kritik bilgiler için zaman sınırı uygulamayın. Kullanıcının hata mesajını anlama ve düzeltme sürecine müdahale etmeyin.
- Ekran okuyucu testleri yapın: Geliştirme sürecinde JAWS, NVDA ve VoiceOver gibi araçlarla testler gerçekleştirin. Bu sayede, farklı senaryolarda hata mesajlarının nasıl okunduğunu gözlemleyebilirsiniz.
iOS ve Safari kombinasyonundaki özel durumlar
VoiceOver ve Safari kombinasyonu, masaüstü tarayıcılara göre bazı farklı davranışlar sergileyebiliyor. Özellikle mobil formlarda karşılaşılan yaygın sorunlar şunlar:
- Odaklanılan form alanından hızlıca kaybolan hata mesajları.
aria-describedbybağlantılarının VoiceOver tarafından düzgün okunmaması.- Klavye gezinmesi sırasında oluşan beklenmedik davranışlar.
Bu durumlara yönelik çözümler arasında, mobil form alanlarına özel ARIA etiketleri eklemek ve VoiceOver’un odak yönetimini daha yakından takip etmek yer alıyor.
Sonuç: Erişilebilirliğin temelinde kalıcı ve bağlantılı mesajlar var
Erişilebilir formların temelinde, hata mesajlarının kalıcı ve ilgili form alanlarıyla programatik olarak bağlantılı olması yatıyor. Bu yaklaşım, ekran okuyucu kullanan tüm kullanıcıların hataları anlamasını ve düzeltmesini kolaylaştırıyor.
Geliştirme sürecinde, sadece masaüstü tarayıcılarda değil, farklı ekran okuyucu ve cihaz kombinasyonlarında da testler gerçekleştirin. Unutmayın ki, iyi bir hata mesajı sadece kullanıcıya yardımcı olmakla kalmaz, aynı zamanda erişilebilirlik standartlarına da uyum sağlar.
Yapay zeka özeti
Ekran okuyucu kullananlar için hata mesajları nasıl tasarlanmalı? Kalıcı bağlantılar, zaman sınırlamalarının riskleri ve en iyi ARIA uygulamaları hakkında rehber.