HTML Forms Inputs Labels Validation Accessibility

Definisi

Form HTML adalah struktur untuk mengumpulkan input dari pengguna dan mengirimkannya ke browser, JavaScript, atau server. Di dalam form, elemen seperti input, textarea, select, button, dan label bekerja sebagai satu sistem, bukan sebagai elemen terpisah.

Topik ini penting karena form adalah titik interaksi paling sensitif di banyak halaman web. Di sini, detail kecil seperti hubungan label-input, tipe input, urutan field, dan validasi native langsung memengaruhi usability, aksesibilitas, dan tingkat error pengguna.

Kenapa penting

Banyak form terlihat “jalan”, tetapi sebenarnya rapuh:

• label tidak terhubung ke input
• tipe input dipilih sembarangan
• validasi hanya mengandalkan JavaScript
• pesan error tidak jelas
• fokus keyboard tersesat setelah submit
• screen reader tidak mendapat konteks yang cukup

Kalau fondasinya salah, form akan terasa melelahkan dipakai meskipun tampilannya rapi.

Struktur Form yang Benar

Struktur form yang sehat biasanya mengikuti pola ini:

html

<form action="/register" method="post">
  <fieldset>
    <legend>Data akun</legend>
 
    <div>
      <label for="name">Nama lengkap</label>
      <input id="name" name="name" type="text" autocomplete="name" required />
    </div>
 
    <div>
      <label for="email">Email</label>
      <input id="email" name="email" type="email" autocomplete="email" required />
    </div>
 
    <div>
      <label for="password">Kata sandi</label>
      <input
        id="password"
        name="password"
        type="password"
        autocomplete="new-password"
        minlength="8"
        required
        /
      >
    </div>
  </fieldset>
 
  <button type="submit">Daftar</button>
</form>

Pola di atas menunjukkan beberapa prinsip dasar:

• form menjadi pembungkus utama interaksi
• label memberi nama yang jelas pada setiap kontrol
• name dipakai untuk identitas data saat submit
• type memberi perilaku dan validasi bawaan
• required, minlength, dan atribut lain menambah validasi native
• fieldset dan legend membantu mengelompokkan field yang satu topik

Kapan pakai fieldset

fieldset cocok saat beberapa field berada dalam satu kelompok logis, misalnya:

• data akun
• alamat pengiriman
• informasi pembayaran
• preferensi notifikasi

Kalau field hanya satu-dua dan tidak perlu pengelompokan semantik, fieldset bisa tidak dipakai. Tapi begitu form mulai panjang, pengelompokan jadi sangat membantu pembaca dan teknologi bantu.

Hubungan Label dan Input

Hubungan label dan input itu inti dari accessibility form.

Cara yang disarankan

Hubungkan label dengan input memakai for dan id:

html

<label for="email">Email</label>
<input id="email" name="email" type="email" />

Keuntungan pola ini:

• klik pada label memfokuskan input
• screen reader bisa membacakan nama field dengan jelas
• area klik jadi lebih luas
• struktur form lebih eksplisit

Alternatif: membungkus input di dalam label

html

<label>
  Email
  <input name="email" type="email" />
</label>

Pola ini valid, tetapi untuk form yang lebih kompleks, penggunaan for dan id biasanya lebih mudah dibaca, lebih gampang di-scan, dan lebih konsisten saat layout berubah.

Yang harus dihindari

• memakai placeholder sebagai pengganti label
• memberi label visual lewat teks biasa tanpa relasi semantik
• mengandalkan aria-label untuk field yang sebenarnya bisa diberi label nyata
• menduplikasi nama field di tempat lain lalu lupa memberi hubungan yang benar

Placeholder boleh dipakai sebagai petunjuk tambahan, tetapi tidak boleh menjadi satu-satunya nama field. Begitu pengguna mulai mengetik, placeholder menghilang, sementara label tetap harus tersedia.

Tipe Input Penting

Memilih type yang tepat bukan soal kosmetik. Browser memakai type untuk mengubah keyboard mobile, validasi native, dan perilaku default field.

text

Dipakai untuk teks umum yang tidak punya format khusus.

Contoh: nama, judul, kota.

email

Dipakai untuk alamat email.

Browser biasanya akan:

• memvalidasi format dasar email
• menampilkan keyboard yang lebih sesuai di mobile
• membantu autofill

password

Dipakai untuk kata sandi.

Perilakunya berbeda karena karakter disamarkan. Gunakan dengan autocomplete yang tepat, misalnya current-password atau new-password.

number

Dipakai untuk angka yang memang berupa nilai numerik.

Catatan penting:

• number bukan selalu pilihan terbaik untuk semua data angka
• untuk nomor identitas, kode pos, atau nomor telepon, type="text" sering lebih aman
• number bisa memunculkan spinner dan validasi format yang tidak selalu cocok dengan kebutuhan data

tel

Dipakai untuk nomor telepon.

Browser tidak memvalidasi format telepon secara ketat, jadi format tetap perlu dikelola sesuai kebutuhan aplikasi.

url

Dipakai untuk alamat URL.

Cocok jika field memang harus berupa link lengkap dengan skema, misalnya https://....

date, time, datetime-local

Dipakai untuk input waktu dan tanggal.

Keunggulannya:

• UI native di browser tertentu
• nilai lebih terstruktur
• validasi lebih konsisten dibanding input teks manual

Tetapi dukungan UI bisa berbeda antar browser, jadi tetap perlu diuji.

checkbox dan radio

Dipakai untuk pilihan diskret.

• checkbox: pilihan bisa lebih dari satu atau ya/tidak
• radio: satu pilihan dari beberapa opsi

Untuk grup radio, semua input yang terkait harus punya name yang sama agar browser memperlakukan mereka sebagai satu grup pilihan.

file

Dipakai untuk upload file.

Biasanya dipasangkan dengan accept jika tipe file perlu dibatasi.

textarea

Dipakai untuk teks panjang, bukan input biasa.

Cocok untuk:

• catatan
• deskripsi
• pesan
• komentar

select

Dipakai saat pilihan terbatas dan paling baik dipilih dari daftar.

Cocok untuk:

• negara
• kategori
• status
• opsi yang punya daftar resmi

Validasi Native

Validasi native adalah validasi bawaan browser melalui atribut HTML. Ini biasanya langkah pertama yang paling murah dan paling stabil.

Atribut yang paling sering dipakai

• required — field wajib diisi
• minlength / maxlength — panjang input
• min / max — batas nilai numerik atau tanggal
• pattern — pola regex untuk validasi format
• type="email", type="url", type="number" — validasi dasar dari tipe input
• step — kelipatan nilai pada input numerik atau waktu

Contoh:

html

<input
  id="username"
  name="username"
  type="text"
  minlength="3"
  maxlength="20"
  pattern="[a-zA-Z0-9_]+"
  required
/>

Apa yang dilakukan browser

Saat form disubmit, browser akan mengecek constraint validation yang sudah terpasang. Kalau ada field yang tidak valid, browser bisa:

• menahan submit
• menyorot field yang bermasalah
• menampilkan pesan bawaan
• memindahkan fokus ke field yang gagal validasi

Perilaku ini berguna karena user mendapat feedback langsung tanpa harus menunggu request server atau script tambahan.

Kapan cukup pakai validasi native

Validasi native sering cukup untuk:

• field wajib
• format dasar email atau URL
• panjang minimum/maksimum
• nilai numerik sederhana
• batas tanggal

Kalau aturan bisnisnya lebih kompleks, barulah tambahkan validasi JavaScript atau server-side. Intinya, native validation bukan pengganti semua validasi lain, tetapi fondasi pertama yang sangat berguna.

Alur Submit dan Validasi

Alur form yang sehat biasanya seperti ini:

Urutan yang perlu diingat

1. user mengisi field
2. browser melakukan validasi native
3. submit event berjalan kalau lolos
4. JavaScript bisa menambah validasi atau memproses data
5. server tetap harus memvalidasi ulang

Poin terakhir penting: validasi di client tidak pernah cukup sebagai satu-satunya pengaman. Client bisa dimodifikasi, dilewati, atau dimatikan.

Accessibility Dasar pada Form

Accessibility form bukan tambahan belakangan. Ia harus ikut dirancang sejak struktur awal.

Prinsip utama

• selalu beri label yang jelas pada kontrol
• gunakan elemen native sebelum memakai komponen custom
• pastikan urutan tab masuk akal
• jangan mengandalkan warna saja untuk menandai error
• sampaikan error di dekat field yang bermasalah
• gunakan aria-describedby jika perlu menghubungkan helper text atau pesan error
• pastikan fokus tetap terjaga setelah submit gagal

Contoh helper text dan error

html

<label for="email">Email</label>
<input
  id="email"
  name="email"
  type="email"
  aria-describedby="email-help email-error"
  required
  /
>
<p id="email-help">Gunakan alamat email aktif.</p>
<p id="email-error" role="alert">Format email tidak valid.</p>

aria-* bukan pengganti semantik native

Kalau elemen HTML sudah menyediakan perilaku bawaan yang tepat, gunakan itu dulu.

Contoh:

• pakai button, bukan div yang diklik
• pakai label, bukan teks biasa
• pakai input type="checkbox", bukan komponen custom tanpa alasan

ARIA berguna untuk melengkapi, bukan untuk menambal semua hal yang seharusnya bisa diselesaikan oleh HTML native.

Jebakan Umum

1. Placeholder dianggap label

Ini jebakan paling klasik. Placeholder hilang saat user mengetik, jadi konteks field bisa menghilang.

2. Semua angka dipakai type="number"

Tidak semua data numerik cocok dengan number. Nomor telepon, kode pos, dan nomor identitas sering lebih aman sebagai teks.

3. Validasi hanya di JavaScript

Kalau hanya bergantung pada JS, form jadi rapuh saat script gagal, dimatikan, atau belum selesai termuat.

4. Pesan error terlalu umum

Pesan seperti “input tidak valid” tidak cukup membantu. Lebih baik jelaskan field mana yang salah dan kenapa.

5. Label tidak klikabel

Kalau label tidak terhubung ke input, pengguna keyboard dan screen reader kehilangan kenyamanan dasar.

6. Urutan tab kacau

Kalau DOM dan visual layout tidak selaras, navigasi keyboard bisa terasa lompat-lompat.

7. State validasi tidak terlihat

Field error yang hanya berubah warna tipis sering tidak cukup. Tambahkan teks atau indikator yang lebih jelas.

8. Lupa validasi server-side

Semua validasi client-side tetap harus diulang di server. Client-side hanya UX, bukan trust boundary.

Contoh Form Ringkas

html

<form action="/contact" method="post">
  <div>
    <label for="name">Nama</label>
    <input id="name" name="name" type="text" autocomplete="name" required />
  </div>
 
  <div>
    <label for="email">Email</label>
    <input id="email" name="email" type="email" autocomplete="email" required />
  </div>
 
  <div>
    <label for="message">Pesan</label>
    <textarea
      id="message"
      name="message"
      rows="5"
      minlength="10"
      required></textarea
    >
  </div>
 
  <button type="submit">Kirim</button>
</form>

Contoh ini memang sederhana, tetapi sudah menunjukkan fondasi yang benar:

• semua field punya label
• tipe input sesuai kebutuhan
• field wajib ditandai dengan required
• teks panjang memakai textarea
• tombol submit jelas

Catatan Implementasi

• Pakai elemen native dulu, custom belakangan jika memang perlu.
• Selalu pasangkan label dengan input lewat for dan id.
• Pilih type berdasarkan makna data, bukan semata bentuk UI.
• Gunakan validasi native sebagai lapisan pertama.
• Jangan pakai placeholder sebagai nama field utama.
• Server tetap harus memvalidasi semua data yang datang.
• Untuk form panjang, kelompokkan field dengan fieldset dan legend.
• Pastikan pesan error bisa dipahami tanpa bergantung pada warna.

Istilah

• Constraint validation: mekanisme validasi bawaan browser berbasis atribut HTML.
• Native input: elemen form bawaan browser seperti input, textarea, select, dan button.
• Accessible name: nama yang dibaca teknologi bantu untuk mengenali sebuah kontrol.
• Autocomplete: petunjuk untuk browser agar mengisi field lebih akurat.
• Server-side validation: validasi data di sisi server sebelum data disimpan atau diproses.

Referensi

• MDN Web Docs: HTML forms
• MDN Web Docs: <input>, <label>, <textarea>, <select>
• MDN Web Docs: Constraint validation
• WAI-ARIA Authoring Practices
• WHATWG HTML Living Standard