Mari kita mulai dengan formulir pendaftaran. Sebagian besar perusahaan menginginkan hubungan jangka panjang dengan penggunanya. Untuk melakukan itu, mereka membutuhkan pengguna untuk mendaftar. Dan untuk melakukan itu , mereka perlu memberikan nilai kepada pengguna sebagai imbalannya. Tidak ada yang ingin mendaftar ke layanan Anda — mereka hanya ingin mengakses apa pun yang Anda tawarkan, atau janji pengalaman yang lebih cepat saat mereka berkunjung lagi nanti.

Terlepas dari tampilan dasar formulir pendaftaran, ada banyak hal yang perlu dipertimbangkan: elemen primitif yang membentuk formulir (label, tombol, dan input), cara mengurangi upaya (bahkan pada formulir kecil seperti ini), hingga formulir validasi.

Dalam memilih bentuk yang begitu sederhana, kita dapat memperbesar kualitas dasar yang ditemukan dalam bentuk yang dirancang dengan baik.

## Bagaimana Mungkin Terlihat

Formulir ini terdiri dari empat bidang dan tombol kirim. Setiap bidang terdiri dari kontrol (input) dan label yang terkait.

Berikut HTMLnya:

 <form> <label for="firstName">First name</label> <input type="text" name="firstName"> <label for="lastName">Last name</label> <input type="text" name="lastName"> <label for="email">Email address</label> <input type="email" name="email"> <label for="password">Create password</label> <input type="password" name="password" placeholder="Must be at least 8 characters"> <input type="submit" value="Register"> </form>

Label adalah tempat diskusi kita dimulai.

## Label

Dalam Aksesibilitas Untuk Semua Orang , Laura Kalbag menetapkan empat parameter umum yang meningkatkan pengalaman pengguna untuk semua orang:

• Visual : membuatnya mudah dilihat.
• Auditori : membuatnya mudah didengar.
• Motor : memudahkan untuk berinteraksi.
• Kognitif : membuatnya mudah dipahami.

Dengan melihat label dari masing-masing sudut pandang ini, kita dapat melihat betapa pentingnya label. Pengguna dengan gangguan penglihatan dapat membacanya, pengguna dengan gangguan penglihatan dapat mendengarnya dengan menggunakan pembaca layar, dan pengguna dengan gangguan motorik dapat lebih mudah mengatur fokus ke bidang berkat area hit yang lebih besar. Itu karena mengklik label menyetel fokus ke elemen formulir terkait.

Untuk alasan ini, setiap kontrol yang menerima input harus memiliki <label> tambahan. Tombol kirim tidak menerima input, sehingga tidak memerlukan label tambahan — atribut value , yang merender teks di dalam tombol, bertindak sebagai label yang dapat diakses.

Untuk menghubungkan input ke label, id input dan atribut for label harus cocok dan unik untuk halaman. Dalam hal bidang email, nilainya adalah "email":

 html < label for = "email" > Email address </ label > < input id = "email" >

Gagal menyertakan label berarti mengabaikan kebutuhan banyak pengguna, termasuk mereka yang memiliki gangguan fisik dan kognitif. Dengan berfokus pada hambatan yang diakui bagi penyandang disabilitas, kami dapat membuat formulir kami lebih mudah dan lebih kuat untuk semua orang.

Misalnya, area pukulan yang lebih besar sangat penting bagi pengguna dengan gangguan motorik, tetapi lebih mudah untuk dipukul bagi mereka yang tidak memiliki gangguan juga.

## Placeholder

Atribut placeholder dimaksudkan untuk menyimpan petunjuk. Ini memberi pengguna panduan ekstra saat mengisi bidang — sangat berguna untuk bidang yang memiliki aturan kompleks seperti bidang kata sandi.

Karena teks placeholder bukan nilai sebenarnya, teks ini berwarna abu-abu sehingga dapat dibedakan dari nilai yang dimasukkan pengguna.

Tidak seperti label, petunjuk bersifat opsional dan tidak boleh digunakan sebagai hal biasa. Hanya karena atribut placeholder ada tidak berarti kita harus menggunakannya. Anda tidak memerlukan placeholder "Masukkan nama depan Anda" ketika labelnya adalah "Nama depan" — itu duplikasi yang tidak perlu.

Placeholder menarik karena estetikanya yang minimal dan hemat-ruang. Ini karena teks placeholder ditempatkan di dalam bidang. Tapi ini adalah cara bermasalah untuk memberi petunjuk kepada pengguna.

Pertama, mereka menghilang saat pengguna mengetik. Teks yang hilang sulit untuk diingat, yang dapat menyebabkan kesalahan jika, misalnya, pengguna lupa untuk memenuhi salah satu aturan sandi. Pengguna sering salah mengira teks placeholder sebagai nilai, menyebabkan bidang dilewati, yang lagi-lagi akan menyebabkan kesalahan di kemudian hari. Teks abu-abu-putih tidak memiliki kontras yang memadai, sehingga umumnya sulit dibaca. Dan yang terpenting, beberapa browser tidak mendukung placeholder, beberapa pembaca layar tidak mengumumkannya, dan teks petunjuk panjang mungkin terpotong.

Itu banyak masalah untuk apa yang pada dasarnya hanya teks. Semua konten, terutama petunjuk formulir, tidak boleh dianggap bagus untuk dimiliki. Jadi daripada menggunakan placeholder, lebih baik menempatkan teks petunjuk di atas kontrol seperti ini:

 <div class="field"> <label for="password"> <span class="field-label">Password</span> <span class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</span> </label> <input type="password" name="password"> </div>

Petunjuk ditempatkan di dalam label dan di dalam <span> sehingga dapat ditata secara berbeda. Dengan menempatkannya di dalam label, itu akan dibaca oleh pembaca layar, dan selanjutnya memperbesar area hit.

Seperti kebanyakan hal dalam desain, ini bukan satu-satunya cara untuk mencapai fungsi ini. Kita bisa menggunakan atribut ARIA untuk mengaitkan petunjuk dengan input:

 <div class="field"> <label for="password">Password</label> <p class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</p> <input type="password" name="password"> </div>

Atribut aria-describedby digunakan untuk menghubungkan petunjuk dengan id -nya — sama seperti atribut for untuk label, tetapi sebaliknya. Itu ditambahkan ke label kontrol dan dibacakan setelah jeda singkat. Dalam contoh ini, "sandi [jeda] harus berisi delapan karakter plus dengan setidaknya satu angka dan satu huruf besar."

Ada perbedaan lain juga. Pertama, mengklik petunjuk (a <p> dalam kasus ini) tidak akan memfokuskan kontrol, yang mengurangi area hit. Kedua, terlepas dari meningkatnya dukungan ARIA, itu tidak akan pernah didukung sebaik elemen asli. Dalam kasus khusus ini, Internet Explorer 11 tidak mendukung aria-describedby . Inilah sebabnya mengapa aturan pertama ARIA adalah tidak menggunakan ARIA:

“Jika Anda dapat menggunakan elemen atau atribut HTML asli dengan semantik dan perilaku yang Anda perlukan yang sudah ada di dalamnya , alih-alih membuat ulang elemen dan menambahkan peran, status, atau properti ARIA untuk membuatnya dapat diakses, lakukanlah .”

Label Terapung

Pola label float oleh Matt Smith adalah teknik yang menggunakan label sebagai pengganti. Label dimulai di dalam kontrol, tetapi mengapung di atas kontrol saat pengguna mengetik, karena itulah namanya. Teknik ini sering dipuji karena kualitasnya yang unik, minimalis, dan hemat tempat.

Sayangnya, ada beberapa masalah dengan pendekatan ini. Pertama, tidak ada ruang untuk petunjuk karena label dan petunjuk adalah satu dan sama. Kedua, mereka sulit dibaca, karena kontrasnya yang buruk dan teks yang kecil, seperti yang biasanya dirancang. (Kontras yang lebih rendah diperlukan agar pengguna memiliki kesempatan untuk membedakan antara nilai nyata dan placeholder.) Ketiga, seperti placeholder, mereka mungkin disalahartikan sebagai nilai dan dapat dipotong.

Dan label float sebenarnya tidak menghemat ruang. Label membutuhkan ruang untuk bergerak di tempat pertama. Bahkan jika mereka menghemat ruang, itu bukan alasan yang baik untuk mengurangi kegunaan bentuk.

“Sepertinya banyak upaya ketika Anda dapat dengan mudah meletakkan label di atas input & mendapatkan semua manfaat/tidak ada masalah.”
— Luke Wroblewski pada label pelampung

Antarmuka yang unik dan minimalis tidak membuat pengguna merasa luar biasa — antarmuka yang jelas, inklusif, dan tangguh melakukannya. Mengurangi ketinggian bentuk secara artifisial seperti ini tidak menarik dan bermasalah.

Sebaliknya, Anda harus memprioritaskan memberi ruang untuk label yang selalu ada dan tersedia (dan memberi petunjuk jika perlu) di awal proses desain. Dengan cara ini Anda tidak perlu memasukkan konten ke dalam ruang kecil.

Kami akan membahas beberapa, sedikit teknik buatan untuk mengurangi ukuran formulir segera.

## Protokol Pertanyaan

Salah satu cara yang ampuh dan alami untuk mengurangi ukuran formulir adalah dengan menggunakan protokol pertanyaan. Ini membantu memastikan Anda tahu mengapa Anda menanyakan setiap pertanyaan atau menyertakan bidang formulir.

Apakah formulir pendaftaran perlu mengumpulkan nama depan, nama belakang, alamat email, dan kata sandi? Apakah ada cara yang lebih baik atau alternatif untuk meminta informasi ini yang menyederhanakan pengalaman?

Kemungkinan besar, Anda tidak perlu menanyakan nama depan dan belakang pengguna agar mereka mendaftar. Jika Anda membutuhkan informasi itu nanti, untuk alasan apa pun, mintalah saat itu. Dengan menghapus bidang ini, kita dapat membagi dua ukuran formulir. Semua tanpa menggunakan pola baru dan bermasalah.

### Tanpa Kata Sandi Masuk

Salah satu cara untuk menghindari meminta kata sandi kepada pengguna adalah dengan menggunakan pola masuk tanpa kata sandi . Ia bekerja dengan memanfaatkan keamanan email (yang sudah membutuhkan kata sandi). Pengguna hanya memasukkan alamat email mereka, dan layanan mengirimkan tautan khusus ke kotak masuk mereka. Setelah itu log pengguna ke dalam layanan segera.

Ini tidak hanya mengurangi ukuran formulir menjadi hanya satu bidang, tetapi juga menghemat pengguna karena harus mengingat kata sandi lain. Meskipun ini menyederhanakan formulir secara terpisah, dengan cara lain ini menambahkan beberapa kerumitan ekstra bagi pengguna.

Pertama, pengguna mungkin kurang terbiasa dengan pendekatan ini, dan banyak orang khawatir tentang keamanan online. Kedua, harus pindah dari aplikasi ke akun email Anda bertele-tele, terutama bagi pengguna yang mengetahui kata sandi mereka, atau menggunakan pengelola kata sandi.

Bukan berarti satu teknik selalu lebih baik dari yang lain. Protokol pertanyaan mendesak kita untuk memikirkan hal ini sebagai bagian dari proses desain. Jika tidak, Anda akan tanpa berpikir menambahkan bidang kata sandi pada formulir dan selesai dengan itu.

### Frasa sandi

Kata sandi umumnya pendek, sulit diingat, dan mudah diretas. Pengguna sering kali harus membuat kata sandi lebih dari delapan karakter, terdiri dari setidaknya satu huruf besar dan satu huruf kecil, dan sebuah angka. Interaksi mikro ini hampir tidak ideal.

"Maaf, tapi kata sandi Anda harus berisi huruf besar, angka, haiku, tanda geng, hieroglif, dan darah perawan."
— Meme internet anonim

Alih-alih kata sandi, kami dapat meminta kata sandi kepada pengguna. Frasa sandi adalah rangkaian kata seperti “monkeysinmygarden” (maaf, itu yang pertama kali terlintas di pikiran). Biasanya lebih mudah diingat daripada kata sandi, dan lebih aman karena panjangnya — frasa sandi harus setidaknya 16 karakter.

Kelemahannya adalah bahwa frasa sandi kurang umum digunakan dan, oleh karena itu, tidak dikenal. Hal ini dapat menyebabkan kecemasan bagi pengguna yang sudah khawatir tentang keamanan online.

Baik itu pola masuk tanpa kata sandi atau frasa sandi, kita hanya boleh menjauh dari konvensi setelah kita melakukan penelitian pengguna yang menyeluruh dan beragam. Anda tidak ingin menukar satu set masalah dengan yang lain tanpa sadar.

## Penataan Bidang

Cara Anda menata komponen formulir Anda, setidaknya sebagian, akan ditentukan oleh produk atau merek perusahaan Anda. Namun, posisi label dan gaya fokus merupakan pertimbangan penting.

### Label Posisi

Tes pelacakan mata Matteo Penzo menunjukkan bahwa memposisikan label di atas (sebagai lawan di samping) kontrol bentuk bekerja paling baik.

“Menempatkan label tepat di atas bidang inputnya memungkinkan pengguna untuk menangkap kedua elemen dengan satu gerakan mata.”

Tetapi ada alasan lain untuk menempatkan label di atas bidang. Pada viewports kecil tidak ada ruang di samping kontrol. Dan pada area pandang yang besar, memperbesar memperbesar kemungkinan teks menghilang dari layar.

Juga, beberapa label berisi banyak teks, yang menyebabkannya terbungkus menjadi beberapa baris, yang akan mengganggu ritme visual jika ditempatkan di sebelah kontrol.

Meskipun Anda harus berusaha menjaga label tetap singkat, itu tidak selalu memungkinkan. Menggunakan pola yang mengakomodasi berbagai konten — dengan memposisikan label di atas kontrol — adalah strategi yang baik.

### Tampilan, Ukuran, dan Ruang

Bidang formulir akan terlihat seperti bidang formulir. Tapi apa artinya itu sebenarnya?

Ini berarti bahwa kotak teks akan terlihat seperti kotak teks. Kotak kosong menandakan "isi saya" karena kosong, seperti buku mewarnai. Ini terjadi menjadi bagian dari alasan placeholder tidak membantu. Mereka menghapus keterjangkauan yang dirasakan oleh kotak teks kosong yang seharusnya disediakan.

Ini juga berarti bahwa ruang kosong harus dikotak-kotakkan (berbatasan). Menghapus perbatasan, atau hanya memiliki batas bawah, misalnya, menghilangkan kemampuan yang dirasakan. Batas bawah mungkin pada awalnya tampak sebagai pemisah. Bahkan jika Anda tahu Anda harus mengisi sesuatu, apakah nilainya berada di atas garis atau di bawahnya?

Secara spasial, label harus paling dekat dengan kontrol formulirnya, bukan kontrol bidang sebelumnya. Hal-hal yang tampak berdekatan menunjukkan bahwa mereka milik bersama. Memiliki jarak yang sama mungkin meningkatkan estetika, tetapi itu akan mengorbankan kegunaan.

Terakhir, label dan kotak teks itu sendiri harus cukup besar untuk dibaca dan diketuk. Ini mungkin berarti ukuran font minimal 16 piksel, dan idealnya target tap keseluruhan minimal 44 piksel.

### Gaya Fokus

Gaya fokus adalah prospek yang lebih sederhana. Secara default, browser menempatkan garis besar di sekitar elemen dalam fokus sehingga pengguna, terutama mereka yang menggunakan keyboard, tahu di mana mereka berada. Masalah dengan gaya default adalah sering kali redup dan sulit dilihat, dan agak jelek.

Meskipun demikian, jangan tergoda untuk menghapusnya, karena hal itu akan sangat mengurangi pengalaman pengguna bagi mereka yang melintasi layar dengan keyboard. Kita dapat mengganti gaya default untuk membuatnya lebih jelas dan lebih estetis.

 input:focus { outline: 4px solid #ffbf47; }

## Bidang Email

Meskipun penampilannya sederhana, ada beberapa detail penting yang telah dimasukkan ke dalam konstruksi lapangan yang memengaruhi pengalaman.

Seperti disebutkan sebelumnya, beberapa bidang memiliki petunjuk selain label, itulah sebabnya label berada di dalam rentang anak. Kelas field-label memungkinkan kita menatanya melalui CSS.

 <div class="field"> <label for="email"> <span class="field-label">Email address</span> </label> <input type="email" name="email"> </div>

Labelnya sendiri adalah “Alamat email” dan menggunakan huruf besar/kecil. Dalam “Membuat kasus untuk kasus surat,” John Saito menjelaskan bahwa kasus kalimat (sebagai lawan dari kasus judul) umumnya lebih mudah dibaca, ramah, dan membuatnya lebih mudah untuk menemukan kata benda. Apakah Anda mengindahkan saran ini terserah Anda, tetapi gaya apa pun yang Anda pilih, pastikan untuk menggunakannya secara konsisten.

Atribut type input disetel ke email , yang memicu keyboard layar khusus email di perangkat seluler. Ini memberi pengguna akses mudah ke @ dan . (titik) simbol yang harus ada di setiap alamat email.

Orang yang menggunakan browser yang tidak mendukung akan melihat input teks standar ( <input type="text"> ). Ini adalah bentuk peningkatan progresif, yang merupakan landasan dalam merancang pengalaman inklusif.

### Peningkatan Progresif

Peningkatan progresif adalah tentang pengguna. Kebetulan membuat hidup kita sebagai desainer dan pengembang juga lebih mudah. Alih-alih mengikuti serangkaian browser dan perangkat (yang tidak mungkin!), kita bisa fokus pada fitur.

Pertama dan terpenting, peningkatan progresif adalah tentang selalu memberikan pengalaman yang wajar kepada pengguna, terlepas dari browser, perangkat, atau kualitas koneksi mereka. Ketika ada yang salah — dan mereka akan melakukannya — pengguna tidak akan menderita karena mereka masih bisa menyelesaikan sesuatu.

Ada banyak cara sebuah pengalaman bisa salah. Mungkin lembar gaya atau skrip gagal dimuat. Mungkin semuanya dimuat, tetapi browser pengguna tidak mengenali beberapa HTML, CSS, atau JavaScript. Apa pun yang terjadi, menggunakan peningkatan progresif saat merancang pengalaman akan menghentikan pengguna dari waktu yang sangat buruk.

Dimulai dengan HTML untuk struktur dan konten. Jika CSS atau JavaScript tidak dimuat, tidak apa-apa karena kontennya ada di sana.

Jika semuanya dimuat dengan baik, mungkin berbagai elemen HTML tidak dikenali. Misalnya, beberapa browser tidak memahami <input type="email"> . Tidak apa-apa, karena pengguna akan mendapatkan kotak teks ( <input type="text"> ) sebagai gantinya. Pengguna masih dapat memasukkan alamat email; mereka hanya tidak mendapatkan keyboard khusus email di ponsel.

Mungkin browser tidak memahami beberapa CSS mewah, dan itu akan mengabaikannya. Dalam kebanyakan kasus, ini bukan masalah. Katakanlah Anda memiliki tombol dengan border-radius: 10px . Browser yang tidak mengenali aturan ini akan menampilkan tombol dengan sudut miring. Diperdebatkan, keterjangkauan tombol yang dirasakan berkurang, tetapi pengguna tidak dirugikan. Dalam kasus lain, mungkin berguna untuk menggunakan kueri fitur.

Lalu ada JavaScript, yang lebih rumit. Ketika browser mencoba mengurai metode yang tidak dikenalinya, itu akan menimbulkan kecocokan. Ini dapat menyebabkan skrip Anda yang lain (valid dan didukung) gagal. Jika skrip Anda tidak terlebih dahulu memeriksa apakah metode tersebut ada (deteksi fitur) dan berfungsi (pengujian fitur) sebelum menggunakannya, maka pengguna mungkin mendapatkan antarmuka yang rusak. Misalnya, jika penangan klik tombol memanggil metode yang tidak dikenali, tombol tidak akan berfungsi. Itu buruk.

Begitulah cara Anda meningkatkan. Tapi yang lebih baik adalah tidak membutuhkan peningkatan sama sekali. HTML dengan sedikit CSS dapat memberikan pengalaman yang luar biasa kepada pengguna. Itu adalah konten yang diperhitungkan dan Anda tidak memerlukan JavaScript untuk itu. Semakin Anda dapat mengandalkan konten (HTML) dan gaya (CSS), semakin baik. Saya tidak bisa cukup menekankan ini: begitu sering, pengalaman dasar adalah yang terbaik dan paling berkinerja. Tidak ada gunanya meningkatkan sesuatu jika tidak menambah nilai (lihat prinsip desain inklusif 7).

Tentu saja, ada kalanya pengalaman dasar tidak sebaik yang seharusnya — itulah saatnya untuk meningkatkan. Tetapi jika kita mengikuti pendekatan di atas, ketika sepotong CSS atau JavaScript tidak dikenali atau dijalankan, semuanya akan tetap berfungsi.

Peningkatan progresif membuat kita berpikir tentang apa yang terjadi ketika sesuatu gagal. Ini memungkinkan kita untuk membangun pengalaman dengan ketahanan yang tertanam. Namun sama, itu membuat kita berpikir tentang apakah peningkatan diperlukan sama sekali; dan jika ya, bagaimana cara terbaik untuk melakukannya.

## Kolom Kata Sandi

Kami menggunakan markup yang sama dengan bidang email yang dibahas sebelumnya. Jika Anda menggunakan bahasa template, Anda akan dapat membuat komponen yang mengakomodasi kedua jenis bidang. Ini membantu menegakkan prinsip desain inklusif 3, konsisten .

 <div class="field"> <label for="password"> <span class="field-label">Choose password</span> <span class="field-hint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</span> </label> <input type="password" name="password"> </div>

Bidang kata sandi berisi petunjuk. Tanpa satu, pengguna tidak akan memahami persyaratan, yang kemungkinan akan menyebabkan kesalahan setelah mereka mencoba untuk melanjutkan.

Atribut type="password" menutupi nilai input dengan mengganti apa yang diketik pengguna dengan titik hitam kecil. Ini adalah tindakan keamanan yang menghentikan orang melihat apa yang Anda ketik jika mereka berada di dekat Anda.

### Kata Sandi Terungkap

Mengaburkan nilai saat pengguna mengetik membuatnya sulit untuk memperbaiki kesalahan ketik. Jadi ketika satu dibuat, seringkali lebih mudah untuk menghapus seluruh entri dan memulai lagi. Ini membuat frustrasi karena sebagian besar pengguna tidak menggunakan komputer dengan orang yang melihat dari balik bahu mereka.

Karena meningkatnya risiko kesalahan ketik, beberapa formulir pendaftaran menyertakan bidang "Konfirmasi kata sandi" tambahan. Ini adalah tindakan pencegahan yang mengharuskan pengguna mengetikkan kata sandi yang sama dua kali, menggandakan upaya dan menurunkan pengalaman pengguna. Alih-alih, lebih baik membiarkan pengguna mengungkapkan kata sandi mereka, yang sesuai dengan prinsip 4 dan 5, masing-masing memberikan kontrol dan menawarkan pilihan . Dengan cara ini pengguna dapat memilih untuk mengungkapkan kata sandi mereka ketika mereka tahu tidak ada yang melihat, mengurangi risiko kesalahan ketik.

Versi terbaru dari Internet Explorer dan Microsoft Edge menyediakan perilaku ini secara asli. Karena kita akan membuat solusi kita sendiri, kita harus menekan fitur ini menggunakan CSS seperti ini:

 input[type=password]::-ms-reveal { display: none; }

Pertama, kita perlu menyuntikkan tombol di sebelah input. Elemen <button> harus menjadi elemen masuk Anda untuk mengubah apa pun dengan JavaScript — kecuali, untuk mengubah lokasi, untuk itulah tautan. Saat diklik, itu harus mengaktifkan atribut type antara password dan text ; dan label tombol antara "Tampilkan" dan "Sembunyikan".

 function PasswordReveal(input) { // store input as a property of the instance // so that it can be referenced in methods // on the prototype this.input = input; this.createButton(); }; PasswordReveal.prototype.createButton = function() { // create a button this.button = $('<button type="button">Show password</button>'); // inject button $(this.input).parent().append(this.button); // listen to the button's click event this.button.on('click', $.proxy(this, 'onButtonClick')); }; PasswordReveal.prototype.onButtonClick = function(e) { // Toggle input type and button text if(this.input.type === 'password') { this.input.type = 'text'; this.button.text('Hide password'); } else { this.input.type = 'password'; this.button.text('Show password'); } };

#### Sintaks JavaScript dan Catatan Arsitektur

Karena ada banyak ragam JavaScript, dan berbagai cara untuk merancang komponen, kita akan menelusuri pilihan yang digunakan untuk membuat komponen pengungkapan kata sandi, dan semua komponen yang akan datang dalam buku ini.

Pertama, kami menggunakan konstruktor. Konstruktor adalah fungsi yang secara konvensional ditulis dalam huruf kapital — PasswordReveal , bukan passwordReveal . Ini diinisialisasi menggunakan kata kunci new , yang memungkinkan kita menggunakan kode yang sama untuk membuat beberapa contoh komponen:

 var passwordReveal1 = new PasswordReveal(document.getElementById('input1')); var passwordReveal2 = new PasswordReveal(document.getElementById('input2'));

Kedua, metode komponen didefinisikan pada prototipe — misalnya, PasswordReveal.prototype.onButtonClick . Prototipe adalah cara yang paling efektif untuk berbagi metode di beberapa instance dari komponen yang sama.

Ketiga, jQuery digunakan untuk membuat dan mengambil elemen, dan mendengarkan acara. Sementara jQuery mungkin tidak diperlukan atau disukai, menggunakannya berarti buku ini dapat fokus pada bentuk dan bukan pada kompleksitas komponen lintas-browser.

Jika Anda seorang desainer yang sedikit mengkode, maka jQuery di mana-mana dan hambatan masuk yang rendah akan membantu. Dengan cara yang sama, jika Anda memilih untuk tidak menggunakan jQuery, Anda tidak akan kesulitan untuk memfaktorkan ulang komponen agar sesuai dengan preferensi Anda.

Anda mungkin juga memperhatikan penggunaan fungsi $.proxy . Ini adalah implementasi jQuery dari Function.prototype.bind . Jika kita tidak menggunakan fungsi ini untuk mendengarkan event, maka event handler akan dipanggil dalam konteks elemen ( this ). Dalam contoh di atas, this.button tidak akan terdefinisi. Tetapi kami ingin this menjadi objek pengungkapan kata sandi, sehingga kami dapat mengakses properti dan metodenya.

#### Opsi Antarmuka Alternatif

Antarmuka pengungkapan kata sandi yang kami buat di atas mengaktifkan label tombol antara "Tampilkan kata sandi" dan "Sembunyikan kata sandi." Beberapa pengguna pembaca layar dapat menjadi bingung saat label tombol diubah; begitu pengguna menemukan tombol, mereka berharap tombol itu tetap ada. Meskipun tombolnya persisten, mengubah label membuatnya tampak tidak .

Jika penelitian Anda menunjukkan ini sebagai masalah, Anda dapat mencoba dua pendekatan alternatif.

Pertama, gunakan kotak centang dengan label tetap "Tampilkan kata sandi." Status akan ditandai oleh atribut yang checked . Pengguna pembaca layar akan mendengar "Tampilkan kata sandi, kotak centang, dicentang" (atau serupa). Pengguna yang terlihat akan melihat tanda centang kotak centang. Masalah dengan pendekatan ini adalah bahwa kotak centang adalah untuk memasukkan data, bukan untuk mengontrol antarmuka. Beberapa pengguna mungkin berpikir kata sandi mereka akan diungkapkan ke sistem.

Atau, kedua, ubah state tombol — bukan labelnya. Untuk menyampaikan status kepada pengguna pembaca layar, Anda dapat mengganti atribut aria-pressed antara true (ditekan) dan false (tidak ditekan).

 <button type="button" aria-pressed="true"> Show password </button>

Saat memfokuskan tombol, pembaca layar akan mengumumkan, "Tampilkan kata sandi, tombol sakelar, ditekan" (atau serupa). Untuk pengguna yang dapat melihat, Anda dapat mengatur gaya tombol agar terlihat ditekan atau tidak ditekan sesuai dengan menggunakan pemilih atribut seperti ini:

 [aria-pressed="true"] { box-shadow: inset 0 0 0 0.15rem #000, inset 0.25em 0.25em 0 #fff; }

Pastikan bahwa gaya yang tidak ditekan dan yang ditekan jelas dan berbeda, jika tidak, pengguna yang dapat melihat mungkin kesulitan untuk membedakan di antara mereka.

### Mikrokopi

Label diatur ke "Pilih kata sandi" daripada "Kata Sandi". Yang terakhir ini agak membingungkan dan dapat meminta pengguna untuk mengetikkan kata sandi yang sudah mereka miliki, yang bisa menjadi masalah keamanan. Secara lebih halus, ini mungkin menyarankan pengguna sudah terdaftar, menyebabkan pengguna dengan gangguan kognitif berpikir mereka masuk.

Di mana "Kata Sandi" ambigu, "Pilih kata sandi" memberikan kejelasan.

## Gaya Tombol

Apa itu tombol? Kami merujuk ke berbagai jenis komponen pada halaman web sebagai tombol. Sebenarnya, saya sudah membahas dua jenis tombol yang berbeda tanpa memanggilnya. Ayo lakukan itu sekarang.

Tombol yang mengirimkan formulir adalah “tombol kirim” dan biasanya diberi kode sebagai <input type="submit"> atau <button type="submit"> . Elemen <button> lebih mudah dibentuk karena Anda dapat menyarangkan elemen lain di dalamnya. Tapi jarang ada kebutuhan untuk itu. Sebagian besar tombol kirim hanya berisi teks.

Catatan: Di versi Internet Explorer yang lebih lama, jika Anda memiliki beberapa <button type="submit"> s, formulir akan mengirimkan nilai semua tombol ke server, terlepas dari yang diklik. Anda harus mengetahui tombol mana yang diklik sehingga Anda dapat menentukan tindakan yang tepat untuk diambil, itulah sebabnya elemen ini harus dihindari.

Tombol lain disuntikkan ke antarmuka untuk meningkatkan pengalaman dengan JavaScript — seperti yang kami lakukan dengan komponen pengungkapan kata sandi yang dibahas sebelumnya. Itu juga <button> tetapi type disetel ke button (bukan submit ).

Dalam kedua kasus tersebut, hal pertama yang perlu diketahui tentang tombol adalah bahwa tombol tersebut bukan tautan. Tautan biasanya digarisbawahi (berdasarkan gaya agen pengguna) atau ditempatkan secara khusus (di bilah navigasi) sehingga dapat dibedakan di antara teks biasa. Saat mengarahkan kursor ke tautan, kursor akan berubah menjadi penunjuk. Ini karena, tidak seperti tombol, tautan memiliki persepsi keterjangkauan yang lemah.

Dalam Resilient Web Design , Jeremy Keith membahas gagasan kejujuran materi. Dia mengatakan: “Satu bahan tidak boleh digunakan sebagai pengganti yang lain. Kalau tidak, hasil akhirnya menipu. ” Membuat tautan terlihat seperti tombol secara material tidak jujur. Ini memberi tahu pengguna bahwa tautan dan tombol adalah sama padahal tidak.

Tautan dapat melakukan hal-hal yang tidak dapat dilakukan tombol. Tautan dapat dibuka di tab baru atau di-bookmark untuk nanti, misalnya. Oleh karena itu, tombol tidak boleh terlihat seperti tautan, juga tidak boleh memiliki kursor penunjuk. Sebaliknya, kita harus membuat kancing terlihat seperti kancing, yang memiliki persepsi keterjangkauan yang kuat secara alami. Apakah mereka memiliki sudut membulat, bayangan jatuh, dan batas terserah Anda, tetapi mereka harus terlihat seperti tombol.

Tombol masih dapat memberikan umpan balik saat mengarahkan kursor (dan fokus) dengan mengubah warna latar belakang, misalnya.

### Penempatan

Tombol kirim biasanya ditempatkan di bagian bawah formulir: dengan sebagian besar formulir, pengguna mengisi bidang dari atas ke bawah, lalu mengirimkan. Tetapi haruskah tombolnya disejajarkan ke kiri, kanan, atau tengah? Untuk menjawab pertanyaan ini, kita perlu memikirkan di mana pengguna akan mencarinya secara alami.

Label bidang dan kontrol formulir disejajarkan ke kiri (dalam bahasa bacaan kiri-ke-kanan) dan dijalankan dari atas ke bawah. Pengguna akan mencari bidang berikutnya di bawah yang terakhir. Maka, tentu saja, tombol kirim juga harus diposisikan di lokasi itu: di sebelah kiri dan tepat di bawah bidang terakhir. Ini juga membantu pengguna yang memperbesar, karena tombol rata kanan dapat lebih mudah menghilang di luar layar.

### Teks

Teks tombol sama pentingnya dengan gayanya. Teks harus secara eksplisit menggambarkan tindakan yang diambil. Dan karena itu adalah tindakan, itu harus menjadi kata kerja. Kita harus bertujuan untuk menggunakan kata-kata sesedikit mungkin karena lebih cepat untuk dibaca. Tapi kita tidak boleh menghapus kata-kata dengan mengorbankan kejelasan.

Kata-kata yang tepat dapat cocok dengan nada suara merek Anda, tetapi jangan menukar kejelasan dengan keanehan.

Bahasa yang sederhana dan lugas mudah dipahami semua orang. Kata-kata yang tepat akan tergantung pada jenis layanan. Untuk formulir pendaftaran kami, "Daftar" tidak masalah, tetapi tergantung pada layanan Anda, "Bergabung" atau "Daftar" mungkin lebih tepat.

## Validasi

Terlepas dari upaya kami untuk menciptakan pengalaman pendaftaran yang inklusif, sederhana, dan bebas gesekan, kami tidak dapat menghilangkan kesalahan manusia. Orang membuat kesalahan dan ketika mereka melakukannya, kita harus memperbaikinya semudah mungkin.

Ketika datang ke validasi formulir, ada sejumlah detail penting yang perlu dipertimbangkan. Dari memilih kapan harus memberikan umpan balik, hingga bagaimana menampilkan umpan balik itu, hingga perumusan pesan kesalahan yang baik — semua hal ini perlu diperhitungkan.

### Validasi HTML5

Validasi HTML5 telah ada untuk sementara waktu sekarang. Dengan menambahkan hanya beberapa atribut HTML, browser pendukung akan menandai bidang yang salah saat formulir dikirimkan. Browser yang tidak mendukung kembali ke validasi sisi server.

Biasanya saya akan merekomendasikan menggunakan fungsionalitas yang disediakan browser secara gratis karena seringkali lebih berperforma, kuat, dan dapat diakses. Belum lagi, ini menjadi lebih akrab bagi pengguna karena semakin banyak situs yang mulai menggunakan fungsionalitas standar.

Meskipun dukungan validasi HTML5 cukup baik, itu tidak diterapkan secara seragam. Misalnya, atribut yang diperlukan dapat menandai bidang sebagai tidak valid sejak awal, yang sebenarnya tidak diinginkan. Beberapa browser, seperti Firefox 45.7, akan menampilkan kesalahan "Silakan masukkan alamat email" meskipun pengguna memasukkan sesuatu di dalam kotak, sedangkan Chrome, misalnya, mengatakan "Silakan sertakan '@' di alamat email," yang lebih bermanfaat.

Kami juga ingin memberikan antarmuka yang sama kepada pengguna apakah kesalahan ditemukan di server atau klien. Untuk alasan ini kami akan merancang solusi kami sendiri. Hal pertama yang harus dilakukan adalah mematikan validasi HTML5: <form novalidate>

### Menangani Pengajuan

Saat pengguna mengirimkan formulir, kami perlu memeriksa apakah ada kesalahan. Jika ada, kami perlu mencegah formulir mengirimkan detail ke server.

 function FormValidator(form) { form.on('submit', $.proxy(this, 'onSubmit')); } FormValidator.prototype.onSubmit = function(e) { if(!this.validate()) { e.preventDefault(); // show errors } };

Perhatikan bahwa kami mendengarkan acara pengiriman formulir, bukan acara klik tombol. Yang terakhir akan menghentikan pengguna untuk dapat mengirimkan formulir dengan menekan Enter saat fokus berada dalam salah satu bidang. Ini juga dikenal sebagai penyerahan formulir implisit .

### Menampilkan Umpan Balik

Semuanya mendeteksi dengan sangat baik adanya kesalahan, tetapi pada titik ini pengguna tidak lebih bijaksana. Ada tiga bagian berbeda dari antarmuka yang perlu diperbarui. Kami akan berbicara tentang masing-masing sekarang.

#### Judul dokumen

<title> dokumen adalah bagian pertama dari halaman web yang dibaca oleh pembaca layar. Karena itu, kami dapat menggunakannya untuk memberi tahu pengguna dengan cepat bahwa ada yang tidak beres dengan kiriman mereka. Ini sangat berguna ketika halaman dimuat ulang setelah permintaan server.

Meskipun kami meningkatkan pengalaman pengguna dengan menangkap kesalahan pada klien dengan JavaScript, tidak semua kesalahan dapat ditangkap dengan cara ini. Misalnya, memeriksa bahwa alamat email belum diambil hanya dapat diperiksa di server. Dan bagaimanapun, JavaScript rentan terhadap kegagalan sehingga kami tidak bisa hanya mengandalkan ketersediaannya.

Di mana judul halaman asli mungkin terbaca "Daftar untuk [layanan]," pada kesalahan itu harus membaca "(2 kesalahan) Daftar untuk [layanan]" (atau serupa). Kata-kata yang tepat agak tergantung pada pendapat.

JavaScript berikut memperbarui judul:

 document.title = "(" + this.errors.length + ")" + document.title;

Seperti disebutkan di atas, ini terutama untuk pengguna pembaca layar, tetapi seperti yang sering terjadi pada desain inklusif, apa yang membantu satu set pengguna membantu semua orang juga. Kali ini, judul yang diperbarui bertindak sebagai pemberitahuan di tab.

Ringkasan Kesalahan

Dibandingkan dengan elemen judul, ringkasan kesalahan lebih menonjol, yang memberi tahu pengguna yang dapat melihat bahwa ada sesuatu yang salah. Tapi itu juga bertanggung jawab untuk membiarkan pengguna memahami apa yang salah dan bagaimana memperbaikinya.

Itu diposisikan di bagian atas halaman sehingga pengguna tidak perlu menggulir ke bawah untuk melihatnya setelah halaman di-refresh (jika kesalahan tertangkap di server). Secara konvensional, kesalahan diwarnai merah. Namun, mengandalkan warna saja bisa mengecualikan pengguna buta warna. Untuk menarik perhatian pada ringkasan, pertimbangkan juga untuk menggunakan posisi, ukuran, teks, dan ikonografi.

Panel menyertakan judul, "Ada masalah," untuk menunjukkan masalah tersebut. Perhatikan itu tidak mengatakan kata "Kesalahan," yang sangat tidak ramah. Bayangkan Anda mengisi detail Anda untuk membeli mobil di ruang pamer dan membuat kesalahan. Penjual tidak akan mengatakan "Kesalahan" — sebenarnya akan aneh jika mereka mengatakan itu.

 <div class="errorSummary" role="group" tabindex="-1" aria-labelledby="errorSummary-heading"> <h2>There's a problem</h2> <ul> <li><a href="#emailaddress">Enter an email address</a></li> <li><a href="#password">The password must contain an uppercase letter</a></li> </ul> </div>

Wadah memiliki role group , yang digunakan untuk mengelompokkan sekumpulan elemen antarmuka: dalam hal ini, judul dan tautan kesalahan. Atribut tabindex diatur ke -1 , sehingga dapat difokuskan secara terprogram dengan JavaScript (ketika formulir dikirimkan dengan kesalahan). Ini memastikan panel ringkasan kesalahan digulir ke tampilan. Jika tidak, antarmuka akan tampak tidak responsif dan rusak saat dikirimkan.

Catatan: Menggunakan tabindex="0" berarti akan dapat difokuskan secara permanen melalui tombol Tab , yang merupakan kegagalan 2.4.3 Urutan Fokus WCAG. Jika pengguna dapat tab ke sesuatu, mereka berharap itu benar-benar akan melakukan sesuatu.

 FormValidator.prototype.showSummary = function () { // ... this.summary.focus(); };

Di bawahnya, ada daftar tautan kesalahan. Mengklik tautan akan mengatur fokus ke bidang yang salah, yang memungkinkan pengguna melompat ke formulir dengan cepat. Atribut href tautan diatur ke id kontrol, yang di beberapa browser cukup untuk mengatur fokusnya. Namun, di browser lain, mengklik tautan hanya akan menggulir input ke tampilan, tanpa memfokuskannya. Untuk memperbaikinya, kita dapat memfokuskan input secara eksplisit.

 FormValidator.prototype.onErrorClick = function(e) { e.preventDefault(); var href = e.target.href; var id = href.substring(href.indexOf("#"), href.length); $(id).focus(); };

Jika tidak ada kesalahan, panel ringkasan harus disembunyikan. Ini memastikan bahwa hanya ada satu panel ringkasan di halaman, dan panel itu muncul secara konsisten di lokasi yang sama baik kesalahan dibuat oleh klien atau server. Untuk menyembunyikan panel kita perlu menambahkan kelas hidden .

 <div class="errorSummary hidden" ...></div>

 .hidden { display: none; }

Catatan: Anda dapat menggunakan atribut/properti hidden untuk mengaktifkan visibilitas elemen, tetapi dukungan untuk itu kurang. Desain inklusif adalah tentang membuat keputusan yang Anda tahu tidak mungkin mengecualikan orang. Menggunakan kelas sejalan dengan filosofi ini.

#### Kesalahan Sebaris

Kita perlu menempatkan pesan kesalahan yang relevan tepat di atas bidang. Ini menghemat pengguna menggulir ke atas dan ke bawah halaman untuk memeriksa pesan kesalahan, dan membuat mereka terus bergerak ke bawah formulir. Jika pesan ditempatkan di bawah bidang, kami akan meningkatkan kemungkinan dikaburkan oleh panel pelengkapan otomatis browser atau keyboard layar.

 <div class="field"> <label for="blah"> <span class="field-error"> <svg width="1.5em" height="1.5em"><use xmlns:xlink="https://www.w3.org/1999/xlink" xlink:href="#warning-icon"></use></svg> Enter your email address. </span> <span class="field-error">Enter an email address</span> </label> </div>

Seperti pola petunjuk yang disebutkan sebelumnya, pesan kesalahan disuntikkan ke dalam label. Saat bidang difokuskan, pengguna pembaca layar akan mendengar pesan dalam konteks, sehingga mereka dapat dengan bebas menelusuri formulir tanpa harus merujuk ke ringkasan.

Pesan kesalahan berwarna merah dan menggunakan ikon peringatan SVG untuk menarik perhatian pengguna. Jika kami hanya menggunakan perubahan warna untuk menunjukkan kesalahan, ini akan mengecualikan pengguna buta warna. Jadi ini bekerja dengan sangat baik untuk pengguna yang dapat melihat — tetapi bagaimana dengan pengguna pembaca layar?

Untuk memberikan pengalaman yang setara kepada pengguna yang dapat melihat dan tidak dapat melihat, kita dapat menggunakan atribut aria-invalid yang didukung dengan baik. Saat pengguna memfokuskan input, sekarang akan mengumumkan "Tidak Valid" (atau serupa) di pembaca layar.

 <input aria-inval>

Catatan: Formulir pendaftaran hanya terdiri dari input teks. Dalam bab 3, “Formulir Pemesanan Penerbangan”, kita akan melihat cara memasukkan kesalahan secara mudah untuk kelompok bidang seperti tombol radio.

### Mengirimkan Formulir Lagi

Saat mengirimkan formulir untuk kedua kalinya, kami perlu menghapus kesalahan yang ada dari tampilan. Jika tidak, pengguna mungkin melihat kesalahan duplikat.

 FormValidator.prototype.onSubmit = function(e) { this.resetPageTitle(); this.resetSummaryPanel(); this.removeInlineErrors(); if(!this.validate()) { e.preventDefault(); this.updatePageTitle(); this.showSummaryPanel(); this.showInlineErrors(); } };

### Inisialisasi

Setelah selesai mendefinisikan komponen FormValidator , sekarang kita siap untuk menginisialisasinya. Untuk membuat instance FormValidator , Anda harus meneruskan elemen form sebagai parameter pertama.

 var validator = new FormValidator(document.getElementById('registration'));

Untuk memvalidasi bidang email, misalnya, panggil metode addValidator() :

 validator.addValidator('email', [{ method: function(field) { return field.value.trim().length > 0; }, message: 'Enter your email address.' },{ method: function(field) { return (field.value.indexOf('@') > -1); }, message: 'Enter the 'at' symbol in the email address.' }]);

Parameter pertama adalah name kontrol, dan yang kedua adalah larik objek aturan. Setiap aturan berisi dua properti: method dan message . method adalah fungsi yang menguji berbagai kondisi untuk mengembalikan nilai true atau false . False menempatkan bidang ke status kesalahan, yang digunakan untuk mengisi antarmuka dengan kesalahan seperti yang dibahas sebelumnya.

#### Memaafkan Kesalahan Sepele

Dalam The Design of Everyday Things , Don Norman berbicara tentang mendesain untuk kesalahan. Dia berbicara tentang cara orang berbicara:

“Jika seseorang mengatakan sesuatu yang kami yakini salah, kami mempertanyakan dan berdebat. Kami tidak mengeluarkan sinyal peringatan. Kami tidak berbunyi bip. Kami tidak memberikan pesan kesalahan. […] Dalam percakapan normal antara dua teman, salah saji dianggap biasa, sebagai perkiraan untuk apa yang sebenarnya dimaksudkan.”

Tidak seperti manusia, mesin tidak cukup cerdas untuk menentukan arti dari sebagian besar tindakan, tetapi mereka sering kali jauh lebih tidak memaafkan kesalahan daripada yang seharusnya. Jared Spool membuat lelucon tentang ini di "Apakah Desain Ditentang Secara Metrik?" (sekitar 42 menit dalam):

"Dibutuhkan satu baris kode untuk mengambil nomor telepon dan menghapus semua tanda hubung dan tanda kurung dan spasi, dan dibutuhkan sepuluh baris kode untuk menulis pesan kesalahan yang Anda tinggalkan."

Metode addValidator (ditunjukkan di atas) mendemonstrasikan bagaimana merancang aturan validasi sehingga mereka memaafkan kesalahan sepele. Aturan pertama, misalnya, memangkas nilai sebelum memeriksa panjangnya, mengurangi beban pengguna.

### Validasi Inline Langsung

Validasi sebaris langsung memberikan umpan balik kepada pengguna saat mereka mengetik atau saat mereka meninggalkan bidang ( onblur ). Ada beberapa bukti yang menunjukkan bahwa validasi sebaris langsung meningkatkan akurasi dan mengurangi waktu penyelesaian dalam formulir panjang. Ini sebagian berkaitan dengan memberikan umpan balik kepada pengguna ketika persyaratan bidang masih segar di benak pengguna. Tetapi validasi inline langsung (atau singkatnya validasi langsung) menimbulkan beberapa masalah.

Untuk entri yang memerlukan jumlah karakter tertentu, penekanan tombol pertama akan selalu merupakan entri yang tidak valid. Ini berarti pengguna akan terganggu lebih awal, yang dapat menyebabkan mereka beralih konteks mental, dari memasukkan informasi ke memperbaikinya.

Atau, kita bisa menunggu sampai pengguna memasukkan karakter yang cukup sebelum menampilkan kesalahan. Tapi ini berarti pengguna hanya mendapatkan umpan balik setelah mereka memasukkan nilai yang benar, yang agak sia-sia.

Kita bisa menunggu sampai pengguna meninggalkan bidang ( onblur ), tetapi ini sudah terlambat karena pengguna telah mempersiapkan mental (dan sering mulai mengetik) bidang berikutnya. Selain itu, beberapa pengguna mengganti jendela atau menggunakan pengelola kata sandi saat menggunakan formulir. Melakukannya akan memicu peristiwa blur, menyebabkan kesalahan ditampilkan sebelum pengguna selesai. Semua sangat frustasi.

Ingat, tidak ada masalah dengan memberikan umpan balik kepada pengguna tanpa penyegaran halaman. Juga tidak ada masalah dengan menempatkan pesan kesalahan sebaris (di sebelah bidang) — kami sudah melakukannya. Masalah dengan umpan balik langsung adalah bahwa itu mengganggu pengguna terlalu dini atau terlambat, yang sering kali menghasilkan pengalaman yang menggelegar.

Jika pengguna sering melihat kesalahan, mungkin ada sesuatu yang salah di tempat lain. Fokus pada mempersingkat formulir Anda dan memberikan panduan yang lebih baik (pelabelan yang baik dan teks petunjuk). Dengan cara ini pengguna tidak akan melihat lebih dari kesalahan aneh. Kita akan melihat bentuk yang lebih panjang di bab berikutnya.

### Pola Afirmasi Daftar Periksa

Variasi dari validasi langsung melibatkan menandai aturan (menandainya sebagai lengkap) saat pengguna mengetik. Ini kurang invasif daripada validasi langsung tetapi tidak cocok untuk setiap jenis bidang. Berikut adalah contoh formulir pendaftaran MailChimp, yang menggunakan teknik ini untuk bidang kata sandi.

Anda harus meletakkan aturan di atas bidang. Jika tidak, keyboard di layar dapat mengaburkan umpan balik. Akibatnya, pengguna dapat berhenti mengetik dan menyembunyikan keyboard untuk kemudian memeriksa umpan balik.

### Catatan tentang Menonaktifkan Tombol Kirim

Beberapa formulir dirancang untuk menonaktifkan tombol kirim hingga semua bidang menjadi valid. Ada beberapa masalah dengan ini.

Pertama, pengguna dibiarkan bertanya-tanya apa yang sebenarnya salah dengan entri mereka. Kedua, tombol yang dinonaktifkan tidak dapat difokuskan, yang membuat tombol sulit ditemukan oleh pengguna tunanetra yang menavigasi menggunakan tombol Tab . Ketiga, tombol yang dinonaktifkan sulit dibaca karena berwarna abu-abu.

Karena kami memberikan umpan balik yang jelas kepada pengguna, ketika pengguna mengharapkannya, tidak ada alasan yang baik untuk mengambil kendali dari pengguna dengan menonaktifkan tombol.

### Membuat Pesan Kesalahan yang Baik

Tidak ada yang lebih penting dari konten. Pengguna tidak datang ke situs web Anda untuk menikmati desainnya. Mereka datang untuk menikmati konten atau hasil dari penggunaan suatu layanan.

Bahkan pengalaman yang paling dipikirkan, inklusif dan dirancang dengan indah tidak berarti apa-apa jika kita mengabaikan kata-kata yang digunakan untuk membuat pesan kesalahan. Satu studi menunjukkan bahwa menampilkan pesan kesalahan khusus meningkatkan konversi sebesar 0,5% yang setara dengan lebih dari £250.000 dalam pendapatan tahunan.

“Konten adalah pengalaman pengguna.”
— Ginny Redish

Seperti label, petunjuk, dan konten lainnya, pesan kesalahan yang baik memberikan kejelasan dalam kata-kata sesedikit mungkin. Biasanya, kita harus mengarahkan desain antarmuka berdasarkan konten — bukan sebaliknya. Namun dalam kasus ini, memahami bagaimana dan mengapa Anda menampilkan pesan kesalahan memengaruhi desain kata. Inilah sebabnya mengapa Jared Spool mengatakan “konten dan desain adalah mitra kerja yang tidak dapat dipisahkan.”

Kami menampilkan pesan dalam ringkasan di bagian atas layar dan di samping bidang. Mempertahankan dua versi dari pesan yang sama adalah penjualan yang sulit untuk keuntungan yang tidak meyakinkan. Sebagai gantinya, rancang pesan kesalahan yang berfungsi di kedua tempat. "Masukkan simbol 'at'" membutuhkan konteks dari label bidang agar masuk akal. “Alamat email Anda memerlukan simbol 'at'” berfungsi dengan baik di kedua tempat.

Hindari basa-basi, seperti memulai setiap pesan kesalahan dengan "Tolong." Di satu sisi, ini tampak sopan; di sisi lain, itu menghalangi dan menyiratkan sebuah pilihan.

Pendekatan apa pun yang Anda ambil, akan ada pengulangan karena sifat kontennya. Dan pengujian biasanya melibatkan pengiriman formulir tanpa memasukkan informasi sama sekali. Hal ini membuat pengulangan menjadi sangat jelas, yang dapat menyebabkan kita keluar. Tapi seberapa sering ini terjadi? Sebagian besar pengguna tidak mencoba merusak antarmuka.

Kesalahan yang berbeda memerlukan pemformatan yang berbeda. Instruksi seperti "Masukkan nama depan Anda" adalah hal yang wajar. Namun "Masukkan nama depan yang terdiri dari 35 karakter atau kurang" lebih panjang, lebih banyak kata, dan kurang alami daripada deskripsi seperti "Nama depan harus 35 karakter atau kurang".

Berikut daftar periksanya:

• Singkat. Jangan menggunakan lebih banyak kata daripada yang diperlukan, tetapi jangan menghilangkan kata-kata dengan mengorbankan kejelasan.
• Konsisten. Gunakan nada yang sama, kata-kata yang sama, dan tanda baca yang sama.
• Jadilah spesifik. Jika Anda tahu mengapa ada yang tidak beres, katakan saja. "Emailnya tidak valid." ambigu dan membebani pengguna. "Email membutuhkan simbol 'at'" jelas.
• Jadilah manusia, hindari jargon. Jangan menggunakan kata-kata seperti tidak sah, terlarang, dan wajib.
• Gunakan bahasa yang sederhana. Pesan kesalahan bukanlah kesempatan untuk mempromosikan nada suara lucu merek Anda.
• Gunakan suara aktif. Ketika kesalahan adalah instruksi dan Anda memberi tahu pengguna apa yang harus dilakukan. Misalnya, "Masukkan nama Anda", bukan "Nama depan harus dimasukkan".
• Jangan salahkan pengguna. Beri tahu mereka apa yang salah dan cara memperbaikinya.

## Ringkasan

Dalam bab ini kami memecahkan beberapa tantangan desain formulir mendasar yang dapat diterapkan dengan baik di luar formulir pendaftaran sederhana. Dalam banyak hal, bab ini berisi tentang apa yang tidak boleh dilakukan, juga tentang apa yang harus kita lakukan. Dengan menghindari pola hemat ruang baru dan buatan untuk fokus pada pengurangan jumlah bidang yang kami sertakan, kami menghindari beberapa kegagalan kegunaan sekaligus membuat formulir lebih menyenangkan.

### Hal yang Harus Dihindari

• Menggunakan atribut placeholder sebagai mekanisme untuk menyimpan label dan teks petunjuk.
• Menggunakan jenis input yang salah.
• Tombol styling dan link sama.
• Memvalidasi bidang saat pengguna mengetik.
• Menonaktifkan tombol kirim.
• Menggunakan jargon yang kompleks dan mikroskop yang dipengaruhi merek.

Dan itu saja. Jika Anda menyukai bab pertama dari Pola Desain Formulir ini, Anda bisa segera mendapatkan bukunya. Selamat membaca!