İletişim formunun güzel görünmesi, kolay kullanılacağı anlamına gelmez. Kullanıcı hangi bilginin istendiğini anlayamıyor, hata yaptığında nasıl düzelteceğini göremiyor veya klavyeyle gönder düğmesine ulaşamıyorsa form temel görevini yerine getiremiyordur. Erişilebilirlik, bu sorunları tasarımın başında görünür hâle getirmeye yardımcı olur.
Bu rehberde küçük bir yazılım ajansının teklif formunu örnek alacağız. E-posta adresi ve proje açıklamasından oluşan sade bir başlangıç hazırlayıp etiketleri, hata durumlarını ve gönderim geri bildirimini değerlendireceğiz. Kod parçaları arayüz örneğidir; gerçek gönderim ve sunucu doğrulaması içermez.
Önce gerçekten gerekli alanları seçin
W3C WAI form rehberi, anlaşılır etiketleri, talimatları ve geri bildirimleri erişilebilir form tasarımının parçaları olarak ele alır. Alanları yalnızca görsel kutular olarak değil, kullanıcıya yöneltilen sorular olarak düşünmek yararlı bir başlangıçtır.
Örnek ajansımız ilk görüşme için bütçe, şirket büyüklüğü, telefon ve adres gibi çok sayıda bilgi isteyebilir. Ancak bunların hepsi ilk iletişimde zorunlu olmayabilir. Kullanıcıdan hangi kararı vermek için hangi bilginin gerektiğini belirlemek, daha kısa ve anlaşılır bir form tasarlamamızı sağlar.
Bizim örneğimizde geri dönüş için e-posta ve ihtiyacı anlamak için proje özeti yeterlidir. Daha sonra ek bilgi istenebilir. Bu bir evrensel alan sayısı kuralı değildir; örnek iş sürecimiz için verilmiş bir ürün kararıdır.
Her alanın görünür etiketi olsun
<label for="teklif-eposta">E-posta adresiniz (zorunlu)</label>
<p id="eposta-yardim">Teklifiniz hakkında bu adresten dönüş yapacağız.</p>
<input
id="teklif-eposta"
name="email"
type="email"
autocomplete="email"
required
aria-describedby="eposta-yardim">
<label for="proje-ozeti">Projenizi kısaca anlatın (zorunlu)</label>
<textarea
id="proje-ozeti"
name="project"
rows="6"
required></textarea>WAI etiketleme rehberinde gösterilen açık ilişkilendirme yaklaşımında, label öğesinin for değeri alanın id değeriyle eşleşir. Sayfada her id benzersiz olmalıdır. Alanın görünür adını yalnızca placeholder içine yazmak yerine, metin girildiğinde de görünen bir etiket kullanıyoruz.
Yardım metnini e-posta alanıyla aria-describedby üzerinden ilişkilendirdik. Bu metin, alan adını tekrar etmek yerine kullanıcıya neden istendiğini açıklıyor. Aynı yaklaşımı karmaşık biçim gerektiren alanlarda bir örnek göstermek için de değerlendirebilirsiniz.
Hataları düzeltilebilir biçimde anlatın
“Geçersiz giriş” gibi genel bir mesaj, kullanıcıya ne yapacağını söylemez. Örnek formumuzda e-posta biçimi uygun değilse “E-posta adresini ad@ornek.com biçiminde girin” gibi doğrudan bir açıklama daha yararlıdır. Mesaj, ilgili alanın yakınında görünmelidir.
Aşağıdaki parça, doğrulama sonucunda hata bulunduğunda oluşturulacak alan durumunu gösterir. Başlangıçtaki geçerli veya henüz değerlendirilmemiş alana hata durumu eklemek için kullanılmamalıdır:
<input
id="teklif-eposta"
name="email"
type="email"
required
aria-invalid="true"
aria-describedby="eposta-yardim eposta-hata">
<p id="eposta-hata">
E-posta adresini ad@ornek.com biçiminde girin.
</p>WAI bildirim rehberi, hata bildirimlerini ve başarılı gönderim geri bildirimini ele alır. Hataları yalnızca kırmızı kenarlıkla anlatmak yerine açıklayıcı metin kullanın. Birden fazla hata varsa formun başında ilgili alanlara bağlantı veren bir özet de tasarlanabilir.
Örnek uygulamamızda düzeltme sonrasında eski hata metnini ve aria-invalid durumunu güncellemek gerekir. Kullanıcı hatayı düzelttiği hâlde arayüzün hâlâ başarısız görünmesi, sonraki adımı belirsiz bırakır. Dinamik bildirimlerin yardımcı teknolojilerle nasıl duyurulduğu da ayrıca kontrol edilmelidir.
Görsel düzen kullanıcıyı yönlendirsin
Ajans formumuz için başlangıçta tek sütun seçebiliriz. E-posta alanının ardından proje açıklamasının gelmesi doğal bir okuma sırası oluşturur. İki sütuna geçmek yalnızca boş alan var diye gerekli değildir; özellikle uzun açıklamalarla daha karmaşık bir tarama düzeni yaratabilir.
Etiket, yardım metni ve alan arasındaki mesafeyi tutarlı tutmak önemlidir. Bir alanın açıklaması sonraki alanın etiketi gibi görünüyorsa, yalnızca renk değiştirerek sorunu çözmeye çalışmayın. Gruplamayı boşluk ve konum üzerinden de anlaşılır kılın.
Odak göstergesi için örnek bir başlangıç şöyle olabilir. Renklerin gerçek arka planlarınızda görünürlüğünü ayrıca değerlendirin:
input,
textarea,
button {
font: inherit;
}
input:focus-visible,
textarea:focus-visible,
button:focus-visible {
outline: 3px solid #1d4ed8;
outline-offset: 3px;
}Gönderim sırasında ne olacak?
Örnek akışımızda kullanıcı gönder düğmesine bastığında işlem sürüyorsa bu durum görünür biçimde belirtilmelidir. Bir hata olduğunda yazdığı proje açıklamasını kaybetmemesi gerekir. Başarılı sonuçta ise “Mesajınız alındı” gibi net bir geri bildirim verilmelidir.
Sunucudan başarılı yanıt gelmeden kesin başarı mesajı göstermekten kaçının. İstemci doğrulaması, sunucu tarafında veriyi doğrulamanın yerine geçmez. Ayrıca aynı isteğin yanlışlıkla tekrarlanması gibi iş mantığı sorunları erişilebilirlikten ayrı olarak ele alınmalıdır; bunun için idempotency yazımızı inceleyebilirsiniz.
Kontrolü gerçek görev üzerinden yapın
Formu fare kullanmadan doldurun. Etiketlere tıklayın, yanlış e-posta girin, hatayı düzeltin ve gönderim sırasında bağlantının kesildiği senaryoyu değerlendirin. Metni büyütün; hata açıklaması uzadığında alanların birbirine karışmadığını kontrol edin.
Yalnızca boş form ekranını onaylamak yeterli değildir. Boş, doldurulmuş, hatalı, gönderiliyor ve başarılı durumları ayrı tasarlayın. Kullanıcının her aşamada “Ne oldu, ne yapmalıyım?” sorularına cevap bulabilmesi, iyi bir iletişim formunun en temel ölçütlerinden biridir.
