Techno

#9 Menangani Error Form yang Aksesibel: Jangan Biarkan Screen Reader Menebak

09 July 2026 370 Kali Dilihat Oleh Administrator

Bayangkan Anda sedang memesan makanan melalui layanan drive-thru. Setelah membayar, petugas tidak memberikan pesanan dan juga tidak mengatakan apa pun.

Ternyata ada tulisan kecil di balik jendela dapur:

"Maaf, keju sedang habis."

Masalahnya, tulisan itu tidak pernah terlihat oleh Anda yang berada di dalam mobil.

Anda pun hanya menunggu tanpa mengetahui apa yang sebenarnya terjadi.

Situasi seperti inilah yang sering dialami pengguna screen reader ketika mengisi formulir pada website yang tidak aksesibel.

Ketika mereka menekan tombol Kirim, sistem mendeteksi ada kesalahan, misalnya kata sandi terlalu pendek atau alamat email tidak valid.

Di layar memang muncul teks merah yang menjelaskan kesalahan tersebut.

Namun screen reader tidak mengumumkan apa pun.

Akibatnya pengguna hanya mengetahui bahwa formulir gagal dikirim, tetapi tidak memahami bagian mana yang harus diperbaiki.

Pada artikel ini kita akan mempelajari cara membuat pesan kesalahan (error message) yang dapat dikenali oleh browser, screen reader, dan pengguna keyboard sesuai prinsip WCAG.

Kesalahan yang Sering Terjadi

Banyak formulir hanya menampilkan pesan kesalahan secara visual.

Misalnya seperti berikut.

Kata Sandi

</label>

<input

id="password"

type="password"

class="border-red-500">

Kata sandi harus minimal 8 karakter.

</p>

</div>

Secara visual tidak ada masalah.

Namun bagi teknologi bantu, hubungan antara kolom input dan pesan kesalahan tersebut belum jelas.

Selain itu, apabila pesan muncul secara dinamis menggunakan JavaScript, screen reader belum tentu langsung memberitahukannya kepada pengguna.

Mengapa Hal Ini Menjadi Masalah?

Terdapat beberapa hambatan yang sering muncul.

Pengguna tidak mengetahui kolom mana yang mengalami kesalahan.
Screen reader tidak mengetahui bahwa teks tersebut adalah pesan kesalahan.
Warna merah menjadi satu-satunya indikator adanya kesalahan.
Setelah menekan tombol Kirim, fokus keyboard tetap berada di tombol sehingga pengguna harus mencari sendiri letak kesalahan.

Semua kondisi tersebut dapat membuat proses pengisian formulir menjadi membingungkan.

Solusi: Gunakan Atribut ARIA yang Tepat

WCAG menyediakan beberapa mekanisme agar browser dan teknologi bantu memahami bahwa suatu kolom sedang mengalami kesalahan.

Yang paling sering digunakan adalah:

aria-invalid
aria-describedby
role="alert" atau aria-live

Mari kita bahas satu per satu.

1. aria-invalid

Atribut ini menunjukkan apakah nilai pada sebuah kolom valid.

Contohnya:

<input

id="password"

type="password"

aria-invalid="true">

Nilainya dapat berupa:

Nilai	Arti
false	Tidak ada kesalahan.
true	Nilai pada kolom tidak valid.

Atribut ini hanya perlu diubah ketika proses validasi dilakukan.

Tidak perlu langsung diberi aria-invalid="true" saat halaman pertama kali dimuat.

2. aria-describedby

Atribut ini menghubungkan sebuah input dengan informasi tambahan.

Informasi tersebut dapat berupa:

petunjuk pengisian;
pesan kesalahan;
penjelasan format data.

Contohnya:

<input

id="password"

type="password"

aria-describedby="password-error">

Kata sandi minimal terdiri dari 8 karakter.

</p>

Ketika fokus berada pada kolom tersebut, screen reader dapat membacakan informasi tambahan tersebut secara otomatis.

3. role="alert" atau aria-live

Sering kali pesan kesalahan baru muncul setelah pengguna menekan tombol Kirim.

Karena perubahan ini terjadi secara dinamis, screen reader perlu diberi tahu bahwa ada informasi baru.

Salah satu caranya adalah menggunakan:

id="password-error"

role="alert">

Kata sandi harus minimal 8 karakter.

</p>

atau

id="password-error"

aria-live="assertive">

Kata sandi harus minimal 8 karakter.

</p>

Dengan demikian screen reader dapat segera mengumumkan pesan tersebut tanpa pengguna harus mencarinya sendiri.

Catatan: Jangan menggunakan role="alert" untuk semua elemen. Gunakan hanya pada pesan yang memang perlu segera diketahui pengguna, seperti kesalahan validasi atau informasi penting.

Contoh Struktur yang Direkomendasikan

Berikut contoh struktur formulir yang lebih lengkap.

Kata Sandi

</label>

<input

id="password"

type="password"

required

aria-invalid="true"

aria-describedby="password-help password-error">

Minimal terdiri dari 8 karakter.

</p>

id="password-error"

role="alert">

Kata sandi harus minimal 8 karakter.

</p>

</div>

Dengan struktur tersebut:

label dikenali dengan benar;
petunjuk pengisian tetap tersedia;
pesan kesalahan terhubung ke kolom yang benar;
screen reader dapat mengumumkan perubahan ketika validasi gagal.

Jangan Hanya Mengandalkan Warna

Kesalahan formulir tidak boleh hanya ditunjukkan dengan warna merah.

Misalnya seperti ini.

❌ Border berubah menjadi merah tanpa penjelasan.

Sebaliknya, gunakan beberapa indikator sekaligus.

warna;
ikon;
teks yang jelas;
atribut ARIA.

Contohnya:

⚠ Kata sandi harus minimal 8 karakter.

Dengan demikian informasi tetap dapat dipahami oleh pengguna yang mengalami buta warna maupun pengguna screen reader.

Pindahkan Fokus ke Error Pertama

Apabila validasi gagal setelah pengguna menekan tombol Kirim, praktik yang sangat disarankan adalah memindahkan fokus keyboard ke kolom pertama yang mengalami kesalahan.

Misalnya:

passwordInput.focus();

Cara ini membantu pengguna keyboard langsung mengetahui bagian mana yang perlu diperbaiki tanpa harus menelusuri seluruh formulir.

Contoh Validasi Sederhana

const passwordInput = document.getElementById("password");

const passwordError = document.getElementById("password-error");

function validateForm() {

if (passwordInput.value.length < 8) {

passwordInput.setAttribute("aria-invalid", "true");

passwordError.hidden = false;

passwordInput.focus();

} else {

passwordInput.setAttribute("aria-invalid", "false");

passwordError.hidden = true;

}

Pada contoh tersebut:

aria-invalid berubah sesuai hasil validasi;
pesan kesalahan ditampilkan atau disembunyikan menggunakan atribut hidden;
fokus dipindahkan ke kolom yang bermasalah sehingga pengguna dapat langsung memperbaikinya.

Kesalahan yang Sering Terjadi

❌ Praktik yang Kurang Tepat	✅ Praktik yang Direkomendasikan
Hanya memberi warna merah pada input	Tambahkan pesan kesalahan yang jelas.
Pesan error tidak terhubung ke input	Gunakan `aria-describedby`.
Tidak memberi tahu screen reader saat error muncul	Gunakan `role="alert"` atau `aria-live` sesuai kebutuhan.
Fokus tetap berada pada tombol Kirim setelah validasi gagal	Pindahkan fokus ke kolom pertama yang bermasalah.
Semua pesan menggunakan `role="alert"`	Gunakan hanya untuk informasi yang perlu segera diumumkan.

Praktik Cepat: Audit Formulir Anda

Coba buka salah satu formulir pada website yang sedang Anda kembangkan.

Kemudian lakukan pengujian berikut.

Isi formulir dengan data yang sengaja dibuat salah.
Tekan tombol Kirim.
Periksa beberapa hal berikut.
Apakah setiap kesalahan dijelaskan dengan teks yang mudah dipahami?
Apakah pesan kesalahan tidak hanya ditunjukkan dengan warna?
Apakah input yang bermasalah memiliki aria-invalid="true"?
Apakah pesan kesalahan terhubung menggunakan aria-describedby?
Apakah fokus keyboard berpindah ke kolom pertama yang mengalami kesalahan?

Jika semua pertanyaan tersebut dapat dijawab ya, berarti formulir Anda sudah jauh lebih ramah bagi pengguna keyboard maupun teknologi bantu.

Pesan kesalahan yang baik bukan hanya terlihat di layar, tetapi juga dapat dipahami oleh semua pengguna, termasuk mereka yang menggunakan screen reader.

Gunakan aria-invalid untuk menandai kolom yang tidak valid, aria-describedby untuk menghubungkan pesan kesalahan dengan kolom yang sesuai, dan role="alert" atau aria-live apabila pesan muncul secara dinamis. Lengkapi dengan indikator visual yang jelas dan arahkan fokus ke kolom pertama yang bermasalah ketika validasi gagal.

Dengan menerapkan teknik-teknik tersebut, formulir tidak hanya memenuhi prinsip-prinsip WCAG, tetapi juga memberikan pengalaman yang lebih mudah, cepat, dan inklusif bagi seluruh pengguna.

Komentar (0)

Belum ada komentar. Jadilah yang pertama berkomentar!

Tinggalkan Komentar

Nama *

Email *

Komentar *