Erişilebilir İletişim Formu: Etiketlerden Hata Mesajlarına Uygulama Rehberi

İletişim formunun iyi görünmesi, kullanılabildiği anlamına gelmez. Ziyaretçi hangi bilgiyi yazacağını anlayamıyor, klavyeyle gönder düğmesine ulaşamıyor veya hata sonrasında mesajını kaybediyorsa tasarım görevini tamamlamamıştır. Küçük bir işletme sitesi için bile formu yalnızca boş alanlar dizisi olarak değil, başlangıcı ve sonucu olan bir konuşma olarak düşünmek gerekir.

Bu rehberde e-posta ve mesaj alanlarından oluşan basit bir iletişim formunu ele alacağız. Amaç, özel bileşenler eklemeden anlaşılır bir temel kurmak ve yayın öncesinde bu temelin gerçekten çalıştığını kontrol etmek.

Önce neye ihtiyacınız olduğunu belirleyin

Bir teklif talebinde telefon numarası yararlı olabilir; ancak her soru için zorunlu olması gerekmez. Alanları eklemeden önce her biri için “Bu bilgi olmadan yanıt verebilir miyiz?” diye sorun. İhtiyaç duyulmayan şirket adı, adres veya uzun konu listeleri formu gereksiz yere uzatır. İsteğe bağlı alanları da açıkça belirtin; ziyaretçiyi hangi kutuları doldurması gerektiğini tahmin etmeye zorlamayın.

Örneğin bir tasarım stüdyosunun ilk temasında e-posta ve proje açıklaması yeterli olabilir. Bütçe ve teslim tarihi daha sonra konuşulabilir. Bu seçim aynı zamanda içerik kararını kolaylaştırır: Formun üstündeki açıklama, kullanıcıdan hangi ayrıntıları beklediğinizi kısa bir cümleyle anlatmalıdır.

Görünür etiketleri alanlarla ilişkilendirin

W3C'nin form etiketleme rehberi, alanların amacını belirten etiketleri ve HTML içindeki bağlantılarını açıklar. Pratik başlangıç, her alan için görünür bir label kullanmaktır. Etiketin for değeri, ilgili alanın benzersiz id değeriyle aynı olmalıdır. Böylece ilişki yalnızca görsel yakınlığa dayanmaz.

<form action="/iletisim" method="post">
  <p>İki alan da zorunludur.</p>

  <label for="iletisim-eposta">E-posta adresiniz</label>
  <input id="iletisim-eposta" name="email"
    type="email" autocomplete="email" required
    aria-describedby="eposta-yardim">
  <p id="eposta-yardim">Yanıtımızı bu adrese göndereceğiz.</p>

  <label for="iletisim-mesaj">Mesajınız</label>
  <textarea id="iletisim-mesaj" name="message"
    rows="7" required></textarea>

  <button type="submit">Mesajı gönder</button>
</form>

Bu örnek yalnızca ön yüz iskeletidir. /iletisim adresinde veriyi işleyen bir sunucu uygulaması olmadan mesaj göndermez. Blogger gibi bir platformda da HTML alanları eklemek tek başına teslimat sağlamaz; kullanılan form hizmetinin gönderim ve hata davranışları ayrıca değerlendirilmelidir.

Yer tutucu metni etiketin yerine kullanmayın. Alan dolunca kaybolan “E-postanız” yazısı, kullanıcının bilgiyi yeniden kontrol etmesini zorlaştırabilir. Yardımcı açıklama gerçekten gerekiyorsa onu alanın yanında tutun; uzun kullanım koşullarını küçük bir metin kutusunun içine sıkıştırmayın.

Doğrulamayı kullanıcıya yardımcı olacak şekilde kurun

required boş gönderimi, type="email" ise bazı biçim hatalarını tarayıcı düzeyinde yakalamaya yardımcı olur. Bunlar adresin gerçek bir kişiye ait olduğunu veya mesajın güvenli olduğunu kanıtlamaz. W3C doğrulama rehberinin de belirttiği gibi sunucu tarafında kontrol hâlâ gereklidir.

Bir kişi daha ilk harfi yazarken alanı kırmızıya boyamak yerine hatanın ne zaman gösterileceğini planlayın. “Geçersiz giriş” belirsizdir. “E-posta adresini ad@ornek.com biçiminde yazın” daha uygulanabilir bir yönlendirmedir. Mesaj uzunluğuna sınır koyuyorsanız sınırı yazmaya başlamadan önce açıklayın; gönderim anında sürpriz çıkarmayın.

Hata ve başarı durumlarını ayrıca tasarlayın

Hatalı gönderimde formun üstünde kısa bir özet, alanın yanında ise açıklayıcı metin kullanılabilir. Özetten sorunlu alana bağlantı vermek özellikle uzun formlarda gezinmeyi kolaylaştırır. Hata açıklamasını ilgili alanla aria-describedby üzerinden ilişkilendirin; doğrulama sonucunda geçersiz olduğu bilinen alan için aria-invalid="true" kullanın. Düzeltilen durumda bu bilgiyi güncelleyin.

W3C'nin kullanıcı bildirimleri rehberi, hata kadar başarı bilgisinin de açık olmasını vurgular. Form aynı sayfada güncelleniyorsa ekran okuyucunun değişikliği duyabileceği bir bildirim yaklaşımı gerekir. Ancak ekrana rastgele bir role="alert" eklemek bütün odak ve duyuru sorunlarını otomatik çözmez; gerçek akış test edilmelidir.

“Mesajınız alındı” bilgisini yalnızca sunucu başarılı kayıt veya kabul yanıtı verdikten sonra gösterin. Gönder düğmesine basılması tek başına teslimat kanıtı değildir. Ağ hatasında yazılmış mesajı koruyun, tekrar deneme yolunu belirtin ve henüz alınmayan mesaj için başarı bildirimi göstermeyin. Gerçek bir yanıt süresi taahhüdünüz yoksa otomatik olarak “24 saatte dönüş” sözü de eklemeyin.

Yayın öncesi küçük bir senaryo turu yapın

• Fareyi bırakın. Tab ve Shift+Tab ile her alana ve düğmeye ulaşın; odağın nerede olduğunu takip edin.
• Formu boş, hatalı e-postayla ve geçerli örnek bilgilerle ayrı ayrı deneyin.
• Sayfayı büyütün. Etiket, yardım ve hata metinlerinin kesilmediğini kontrol edin.
• Ekran okuyucuyla alan adının ve gerekli açıklamanın anlaşılır biçimde okunduğunu doğrulayın.
• Deneme ortamında başarısız gönderimi tetikleyin. Yazılan metnin korunmasını ve yeniden denemeyi kontrol edin.

Kontrol sonucunu “form çalışıyor” diye tek satırla kapatmayın. Hangi tarayıcıda hangi senaryonun denendiğini yazın. Özellikle tema veya form hizmeti değiştiğinde aynı kısa turu tekrarlamak, güzel görünen ama tamamlanamayan iletişim akışlarını yakalamanın pratik bir yoludur.

Teknik kaynak kontrolü: 17 Ekim 2026.