iToverDose/Yazılım· 18 MAYIS 2026 · 12:06

Erişilebilir hata mesajları: JAWS, NVDA ve VoiceOver ile uyumlu tasarım

Ekran okuyucu kullananlar için hata mesajları nasıl tasarlanmalı? Standart yöntemler neler ve hangi durumlarda başarısız oluyor? En iyi uygulamaları inceleyin.

DEV Community3 dk okuma0 Yorumlar

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:

  1. Hatanın ne olduğunu anlamak.
  2. İmleci ilgili forma geri getirmek.
  3. Girdiyi düzeltmek.
  4. 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-describedby bağ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-describedby bağ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.

Yorumlar

00
YORUM BIRAK
ID #F4TIUI

0 / 1200 KARAKTER

İnsan doğrulaması

2 + 4 = ?

Editör onayı sonrası yayına girer

Moderasyon · Spam koruması aktif

Henüz onaylı yorum yok. İlk yorumu sen bırak.