HTML Forms Inputs Labels Validation Accessibility
HTML1 September 20269 menit baca
Selesai membaca dokumentasi ini?
Kembali ke rujukan utama HTML untuk melanjutkan topik lainnya.
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:
formmenjadi pembungkus utama interaksilabelmemberi nama yang jelas pada setiap kontrolnamedipakai untuk identitas data saat submittypememberi perilaku dan validasi bawaanrequired,minlength, dan atribut lain menambah validasi nativefieldsetdanlegendmembantu 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-labeluntuk field yang sebenarnya bisa diberilabelnyata - 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:
numberbukan selalu pilihan terbaik untuk semua data angka- untuk nomor identitas, kode pos, atau nomor telepon,
type="text"sering lebih aman numberbisa 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/tidakradio: 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 diisiminlength/maxlength— panjang inputmin/max— batas nilai numerik atau tanggalpattern— pola regex untuk validasi formattype="email",type="url",type="number"— validasi dasar dari tipe inputstep— 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:
Loading diagram...
Urutan yang perlu diingat
- user mengisi field
- browser melakukan validasi native
submitevent berjalan kalau lolos- JavaScript bisa menambah validasi atau memproses data
- 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-describedbyjika 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
aria-* bukan pengganti semantik native
Kalau elemen HTML sudah menyediakan perilaku bawaan yang tepat, gunakan itu dulu.
Contoh:
- pakai
button, bukandivyang 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=
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
labeldenganinputlewatfordanid. - Pilih
typeberdasarkan 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
fieldsetdanlegend. - 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, danbutton. - 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