Yazılarımız

OfisData

HTML FORM ELEMANLARINI DOĞRU KULLANMAK VE VALİDASYON PLANLAMAK

Formlar, ürün ve hizmet deneyiminin en kritik temas noktasıdır. Kullanıcı doğru alanı bulamaz, yanlış veri girer ya da hatayı anlamazsa dönüşüm düşer; destek yükü artar.

İyi tasarlanmış bir form, yalnızca “alanları yan yana dizmek” değildir: doğru HTML elemanını seçmek, tarayıcı yerleşik doğrulamasını akıllıca kullanmak, erişilebilirliği gözetmek ve istemci-sunucu validasyonunu birlikte planlamak gerekir.

Bu rehberde, form elemanlarını doğru kullanmaya, hataları öngörüp doğru mesajlarla yönetmeye ve ekip içinde sürdürülebilir bir validasyon yaklaşımı kurmaya odaklanacağız.

Form mimarisini doğru kurmak ve veri akışını netleştirmek

İlk adım, formun amacını ölçülebilir hale getirmektir: hangi veriler zorunlu, hangileri opsiyonel, hangi alanlar iş kuralına bağlı? Bu soruların yanıtı, alan sayısını azaltmaya ve formu daha anlaşılır kılmaya yardım eder.

Başlangıçta tek bir veri sözleşmesi tanımlayın: alan adı, beklenen tip, örnek değer, hata mesajı ve doğrulama kuralı. Böylece tasarım, geliştirme ve test aynı kaynaktan ilerler. Bu yaklaşım, özellikle çok adımlı akışlarda tutarsızlıkların önüne geçer.

Alan önceliği belirlemek ve gereksiz alanları elemek

“Mutlaka gerekli” olanlarla “güzel olur” olanları ayırın. Her ek alan, kullanıcı için ek sürtünme demektir. E-posta ve telefon gibi alanlarda, hangi kanalın gerçekten gerektiğini iş hedefiyle doğrulayın.

İsimlendirme standardı koymak ve hata takibini kolaylaştırmak

name/id gibi değerleri rastgele vermeyin. Analitik, hata loglama ve otomasyon testleri için tutarlı bir şema şarttır. Örneğin snake_case veya kebab-case üzerinde uzlaşın ve tüm formlarda aynı yaklaşımı kullanın.

Geliştiricinin form alanlarını düzenlediği arayüzde erişilebilir etiketler ve hata mesajı yerleşimi

Doğru HTML elemanını seçmek ve anlamı güçlendirmek

HTML’deki her form elemanı, tarayıcıya ve yardımcı teknolojilere bir anlam taşır. Bu anlam doğru seçilirse hem kullanıcı deneyimi iyileşir hem de doğrulama daha az kodla daha güvenilir çalışır.

Örneğin e-posta için type="email", telefon için type="tel", sayı için type="number" seçmek; mobil klavyeyi doğru açtırır, yerleşik doğrulama davranışlarını devreye sokar ve yanlış veri girişini azaltır.

Label ilişkisini kurmak ve klavye kullanımını desteklemek

Her input için görünen bir etiket kullanın ve label ile for ilişkisinin doğru olduğundan emin olun. Bu, ekran okuyucu kullananlar için kritik olduğu kadar, formu hızlı dolduran herkes için de faydalıdır. Placeholder metnini etiket yerine kullanmak, bağlam kaybına yol açabilir.

Seçim elemanlarında doğru kontrolü kullanmak

Tek seçim için radio, çoklu seçim için checkbox; geniş seçenek kümesi için select veya aramalı bileşen tercih edin. Seçim mantığını doğru elemanla ifade etmek, kullanıcıya “ne oluyor” sorusunu sordurmaz.

Yerleşik doğrulama kullanmak ve kullanıcıya doğru sinyal vermek

Tarayıcı yerleşik doğrulaması hızlı bir ilk savunma hattıdır. required, minlength, maxlength, pattern ve uygun input tipleriyle birçok hatayı daha kullanıcı gönder butonuna basmadan yakalayabilirsiniz.

Burada önemli nokta, kullanıcıya net geri bildirim vermektir. Hata mesajları “Geçersiz” gibi genel ifadeler yerine, neyin beklendiğini söylemelidir. Ayrıca hata durumunda odak (focus) yönetimi yapılmalı ve ilgili alan görünür olmalıdır.

Constraint Validation API ile tutarlı hata mesajı üretmek

Tarayıcı mesajları dil ve tasarıma göre değişebilir. Daha tutarlı bir deneyim için Constraint Validation API kullanabilir, mesajları kendi dilinizde ve tasarımınızla gösterebilirsiniz.

<form id="signup">
  <label for="email">E-posta</label>
  <input id="email" name="email" type="email" required />
  <p id="emailError" aria-live="polite"></p>

  <label for="password">Şifre</label>
  <input id="password" name="password" type="password" minlength="8" required />
  <p id="passwordError" aria-live="polite"></p>

  <button type="submit">Kaydol</button>
</form>

<script>
const form = document.getElementById('signup');
const email = document.getElementById('email');
const password = document.getElementById('password');

function setError(input, message) {
  const el = document.getElementById(input.id + 'Error');
  el.textContent = message;
  input.setAttribute('aria-invalid', 'true');
}

function clearError(input) {
  const el = document.getElementById(input.id + 'Error');
  el.textContent = '';
  input.removeAttribute('aria-invalid');
}

email.addEventListener('input', () => {
  if (email.validity.valid) return clearError(email);
  if (email.validity.valueMissing) return setError(email, 'E-posta alanını doldurun.');
  if (email.validity.typeMismatch) return setError(email, 'Geçerli bir e-posta adresi yazın.');
});

password.addEventListener('input', () => {
  if (password.validity.valid) return clearError(password);
  if (password.validity.valueMissing) return setError(password, 'Şifre alanını doldurun.');
  if (password.validity.tooShort) return setError(password, 'Şifre en az 8 karakter olmalı.');
});

form.addEventListener('submit', (e) => {
  if (!form.checkValidity()) {
    e.preventDefault();
    email.dispatchEvent(new Event('input'));
    password.dispatchEvent(new Event('input'));
    (email.validity.valid ? password : email).focus();
  }
});
</script>

İstemci ve sunucu validasyonunu birlikte planlamak

İstemci tarafı doğrulama kullanıcı deneyimini hızlandırır; ancak güvenlik için tek başına yeterli değildir. Sunucu tarafı doğrulama, her zaman nihai karar noktası olmalıdır. İdeal plan: istemcide hızlı geri bildirim, sunucuda kesin kontrol.

Bu ikili yapıda en sık görülen sorun, kuralların iki yerde farklılaşmasıdır. Bunu azaltmak için doğrulama kurallarını bir “tek kaynak”tan üretin veya en azından ortak bir şema tanımlayıp iki tarafta da aynı tanımı uygulayın.

Hata kodlarını standardize etmek ve arayüzde çevirmek

Sunucu, insan cümlesi yerine hata kodu dönerse arayüz bunu diline ve bağlamına göre gösterebilir. Böylece hem çok dillilik kolaylaşır hem de analitik tarafında hangi kuralın sık patladığı izlenebilir.

// Örnek: Sunucudan dönen hata formatı
{
  "errors": [
    { "field": "email", "code": "EMAIL_INVALID" },
    { "field": "password", "code": "PASSWORD_TOO_WEAK" }
  ]
}

// İstemcide gösterim sözlüğü
const messages = {
  EMAIL_INVALID: "Geçerli bir e-posta adresi yazın.",
  PASSWORD_TOO_WEAK: "Şifre daha güçlü olmalı: harf, sayı ve en az 8 karakter."
};
Hata kodlarının alanlara eşlendiği bir doğrulama akışı şeması ve kullanıcıya gösterilen mesaj kutuları

Erişilebilirlik, geri bildirim ve hata mesajı dili tasarlamak

Validasyon yalnızca “doğru/yanlış” değildir; kullanıcıya nasıl yardım ettiğinizdir. Hata mesajı dili, kısa ve yönlendirici olmalı; mümkünse örnek vermelidir. Ayrıca hata anında renk tek başına sinyal olmamalı; ikon, metin ve odak yönetimiyle desteklenmelidir.

ARIA kullanımı, doğru yapıldığında büyük fayda sağlar. Örneğin hata mesajını aria-live ile duyurmak, ekran okuyucu kullananların hatayı kaçırmamasını sağlar. Aynı zamanda hatalı alanlarda aria-invalid işaretlemesi net bir sinyal verir.

Form yardım metinlerini doğru yerde konumlandırmak

Gerektiğinde alan altına kısa ipuçları koyun: “En az 8 karakter” gibi. Bu metinler, hatayı beklemeden kullanıcıyı doğru yola sokar. Önleyici rehberlik çoğu zaman reaktif hata mesajından daha etkilidir.

Test etmek, izlemek ve iteratif iyileştirmeler yapmak

Doğrulama planı, canlıya çıktıktan sonra bitmez. Hangi alanların en çok hata ürettiğini, hangi cihazlarda terk oranının arttığını ve kullanıcıların hangi noktada takıldığını ölçmek gerekir.

Aşağıdaki pratik liste, ekiplerin hızlıca kontrol etmesine yardımcı olur:

  • Her alan için doğru input tipi kullanmak ve otomatik klavye desteği sağlamak
  • required ve uzunluk kurallarını netleştirmek; gereksiz zorunlu alanları kaldırmak
  • Hata mesajlarını kısa, eyleme dönük ve tutarlı yapmak
  • Sunucuda kesin doğrulama yapmak ve hata kodlarıyla standardize etmek
  • Analitik ve loglarla hataları izleyip formu düzenli iyileştirmek

Gerçek kullanıcı verisiyle kural revizyonu yapmak

Örneğin telefon alanında çok hata alıyorsanız, maskeleme yaklaşımı, ülke kodu seçimi veya örnek format metni yeniden düşünülmelidir. Aynı şekilde, parola kuralları kullanıcıyı gereksiz zorlamamalı; güvenlik ve kullanılabilirlik dengesi korunmalıdır.


Ekibin ortak dilini kurmak ve eğitimle standardı yaymak

Formlar çoğu projede tekrar tekrar yazılır. Bir ekip standardı oluşmazsa, her sayfada farklı bir doğrulama dili ve farklı hata davranışı görülür. Bu tutarsızlık, kullanıcı güvenini zedeler ve geliştirme maliyetini artırır.

Ortak bir “form rehberi” oluşturup örneklerle destekleyin: doğru eleman seçimi, mesaj şablonları, erişilebilirlik kontrol listesi ve test senaryoları. Bu rehberi ekip içi eğitimlerle pekiştirmek, yeni katılanların hızla uyumlanmasını sağlar.

Daha kapsamlı örnekler ve uygulamalı pratik için HTML eğitimi içeriğine göz atabilirsiniz; burada form semantiği ve doğrulama senaryoları adım adım işlenir.

Farklı cihazlarda form dolduran kullanıcılar ve aynı doğrulama kurallarını uygulayan bir arayüz örüntüsü

 Vimaj