Desain Form Login

Adam Silver adalah desainer interaksi yang berfokus pada sistem desain dan desain inklusif. Dia suka membantu organisasi memberikan produk dan layanan sehingga … Selengkapnya tentang Adam

Buletin Email

Email Anda (menghancurkan)

Kiat mingguan tentang front-end & UX .
Dipercaya oleh 190.000 orang.

Ringkasan cepat Dengan senang hati kami mengumumkan buku baru Adam Silver, Form Design Patterns . Dalam kutipan dari buku ini, Adam melihat kualitas dasar dari bentuk yang dirancang dengan baik dan bagaimana memikirkannya. Anda juga bisa mendapatkan bukunya segera →

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.

Formulir pendaftaran dengan empat bidang: nama depan, nama belakang, alamat email, dan kata sandi.

Berikut HTMLnya:

<form>
  <label for="firstName">First name</label>
  <input type="text" id="firstName" name="firstName">
  <label for="lastName">Last name</label>
  <input type="text" id="lastName" name="lastName">
  <label for="email">Email address</label>
  <input type="email" id="email" name="email">
  <label for="password">Create password</label>
  <input type="password" id="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.

Label meningkatkan area hit bidang.

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

Untuk menghubungkan input ke label, atribut input iddan label forharus 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 placeholderini dimaksudkan untuk menyimpan petunjuk. Ini memberi pengguna panduan ekstra saat mengisi bidang — sangat berguna untuk bidang yang memiliki aturan kompleks seperti bidang kata sandi.

As placeholder text is not a real value, it’s grayed out so that it can be differentiated from user-entered values.

The placeholder’s low-contrast, gray text is hard to read.

Unlike labels, hints are optional and shouldn’t be used as a matter of course. Just because the placeholder attribute exists doesn’t mean we have to use it. You don’t need a placeholder of “Enter your first name” when the label is “First name” — that’s needless duplication.

The label and placeholder text have similar content, making the placeholder unnecessary.

Placeholders are appealing because of their minimal, space-saving aesthetic. This is because placeholder text is placed inside the field. But this is a problematic way to give users a hint.

First, they disappear when the user types. Disappearing text is hard to remember, which can cause errors if, for example, the user forgets to satisfy one of the password rules. Users often mistake placeholder text for a value, causing the field to be skipped, which again would cause errors later on. Gray-on-white text lacks sufficient contrast, making it generally hard-to-read. And to top it off, some browsers don’t support placeholders, some screen readers don’t announce them, and long hint text may get cut off.

The placeholder text is cut off as it’s wider than the text box.

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:

Teks petunjuk ditempatkan di atas kotak teks alih-alih teks placeholder di dalamnya.

<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" id="password" name="password">
</div>

Petunjuk ditempatkan di dalam label dan di dalam a <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" id="passwordhint">Must contain 8+ characters with at least 1 number and 1 uppercase letter.</p>
  <input type="password" id="password" name="password" aria-describedby="passwordhint">
</div>

Atribut aria-describedbydigunakan untuk menghubungkan petunjuk dengannya id— 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 ( <p>dalam hal 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 mendukungaria-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.

Pola label mengambang. Di sebelah kiri, bidang teks yang tidak fokus menunjukkan label di dalamnya; di sebelah kanan, saat bidang teks menerima fokus, label bergerak di atas bidang.

Unfortunately, there are several problems with this approach. First, there is no space for a hint because the label and hint are one and the same. Second, they’re hard to read, due to their poor contrast and small text, as they’re typically designed. (Lower contrast is necessary so that users have a chance to differentiate between a real value and a placeholder.) Third, like placeholders, they may be mistaken for a value and could get cropped.

And float labels don’t actually save space. The label needs space to move into in the first place. Even if they did save space, that’s hardly a good reason to diminish the usability of forms.

“Seems like a lot of effort when you could simply put labels above inputs & get all the benefits/none of the issues.”
— Luke Wroblewski on float labels

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.

Layar masuk tanpa kata sandi Medium.

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

Passwords are generally short, hard to remember, and easy to crack. Users often have to create a password of more than eight characters, made up of at least one uppercase and one lowercase letter, and a number. This micro-interaction is hardly ideal.

“Sorry but your password must contain an uppercase letter, a number, a haiku, a gang sign, a hieroglyph, and the blood of a virgin.”
— Anonymous internet meme

Instead of a password, we could ask users for a passphrase. A passphrase is a series of words such as “monkeysinmygarden” (sorry, that’s the first thing that comes to mind). They are generally easier to remember than passwords, and they are more secure owing to their length — passphrases must be at least 16 characters long.

Kelemahannya adalah bahwa frasa sandi kurang umum digunakan dan, oleh karena itu, tidak dikenal. Hal ini dapat menimbulkan kecemasan bagi pengguna yang sudah mengkhawatirkan 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 sebenarnya?

It means that a text box should look like a text box. Empty boxes signify “fill me in” by virtue of being empty, like a coloring-in book. This happens to be part of the reason placeholders are unhelpful. They remove the perceived affordance an empty text box would otherwise provide.

This also means that the empty space should be boxed in (bordered). Removing the border, or having only a bottom border, for example, removes the perceived affordances. A bottom border might at first appear to be a separator. Even if you know you have to fill something in, does the value go above the line or below it?

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.

Bidang email.

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

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

The label itself is “Email address” and uses sentence case. In “Making a case for letter case,” John Saito explains that sentence case (as opposed to title case) is generally easier to read, friendlier, and makes it easier to spot nouns. Whether you heed this advice is up to you, but whatever style you choose, be sure to use it consistently.

The input’s type attribute is set to email, which triggers an email-specific onscreen keyboard on mobile devices. This gives users easy access to the @ and . (dot) symbols which every email address must contain.

Android’s onscreen keyboard for the email field.

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.

There are a lot of ways an experience can go wrong. Perhaps the style sheet or script fails to load. Maybe everything loads, but the user’s browser doesn’t recognize some HTML, CSS, or JavaScript. Whatever happens, using progressive enhancement when designing experiences stops users having an especially bad time.

It starts with HTML for structure and content. If CSS or JavaScript don’t load, it’s fine because the content is there.

If everything loads OK, perhaps various HTML elements aren’t recognized. For example, some browsers don’t understand <input type="email">. That’s fine, though, because users will get a text box (<input type="text">) instead. Users can still enter an email address; they just don’t get an email-specific keyboard on mobile.

Maybe the browser doesn’t understand some fancy CSS, and it will just ignore it. In most cases, this isn’t a problem. Let’s say you have a button with border-radius: 10px. Browsers that don’t recognize this rule will show a button with angled corners. Arguably, the button’s perceived affordance is reduced, but users are left unharmed. In other cases it might be helpful to use feature queries.

Then there is JavaScript, which is more complicated. When the browser tries to parse methods it doesn’t recognize, it will throw a hissy fit. This can cause your other (valid and supported) scripts to fail. If your script doesn’t first check that the methods exist (feature detection) and work (feature testing) before using them, then users may get a broken interface. For example, if a button’s click handler calls a method that’s not recognized, the button won’t work. That’s bad.

That’s how you enhance. But what’s better is not needing an enhancement at all. HTML with a little CSS can give users an excellent experience. It’s the content that counts and you don’t need JavaScript for that. The more you can rely on content (HTML) and style (CSS), the better. I can’t emphasize this enough: so often, the basic experience is the best and most performant one. There’s no point in enhancing something if it doesn’t add value (see inclusive design principle 7).

Of course, there are times when the basic experience isn’t as good as it could be — that’s when it’s time to enhance. But if we follow the approach above, when a piece of CSS or JavaScript isn’t recognized or executed, things will still work.

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 .

Bidang kata sandi menggunakan pola teks petunjuk.

<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" id="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.

Owing to the increased risk of typos, some registration forms include an additional “Confirm password” field. This is a precautionary measure that requires the user to type the same password twice, doubling the effort and degrading the user experience. Instead, it’s better to let users reveal their password, which speaks to principles 4 and 5, give control and offer choice respectively. This way users can choose to reveal their password when they know nobody is looking, reducing the risk of typos.

Recent versions of Internet Explorer and Microsoft Edge provide this behavior natively. As we’ll be creating our own solution, we should suppress this feature using CSS like this:

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

The password field with a “Show password” button beside it.

Pertama, kita perlu menyuntikkan tombol di sebelah input. Elemen <button>tersebut harus menjadi elemen masuk Anda untuk mengubah apa pun dengan JavaScript — kecuali, untuk mengubah lokasi, untuk apa tautan itu. Saat diklik, atribut type harus dialihkan antara passworddan 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 cara berbeda untuk merancang komponen, kita akan menelusuri pilihan yang digunakan untuk membangun 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 newkata kunci, yang memungkinkan kita menggunakan kode yang sama untuk membuat beberapa instance 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 $.proxyfungsi tersebut. 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.buttonakan menjadi tidak terdefinisi. Tetapi kami ingin thismenjadi objek pengungkapan kata sandi, sehingga kami dapat mengakses properti dan metodenya.

#### Opsi Antarmuka Alternatif

The password reveal interface we constructed above toggles the button’s label between “Show password” and “Hide password.” Some screen reader users can get confused when the button’s label is changed; once a user encounters a button, they expect that button to persist. Even though the button is persistent, changing the label makes it appear not to be.

If your research shows this to be a problem, you could try two alternative approaches.

First, use a checkbox with a persistent label of “Show password.” The state will be signaled by the checked attribute. Screen reader users will hear “Show password, checkbox, checked” (or similar). Sighted users will see the checkbox tick mark. The problem with this approach is that checkboxes are for inputting data, not controlling the interface. Some users might think their password will be revealed to the system.

Or, second, change the button’s state — not the label. To convey the state to screen reader users, you can switch the aria-pressed attribute between true (pressed) and false (unpressed).

<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 dikodekan sebagai salah satu <input type="submit">atau <button type="submit">. Elemen <button>ini lebih lunak karena Anda dapat membuat sarang 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 a <button>tetapi typedisetel ke button(not 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 harus 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. Kita akan berbicara tentang masing-masing sekarang.

#### Judul dokumen

Dokumen <title>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 juga, 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.

Judul tab browser yang diawali dengan "(2 kesalahan)" bertindak sebagai pemberitahuan kuasi.

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 ringkasan kesalahan diposisikan di bagian atas layar.

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 id="errorSummary-heading">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 roledari group, yang digunakan untuk mengelompokkan satu set elemen antarmuka: dalam hal ini, judul dan tautan kesalahan. Atribut tabindexdisetel 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 menetapkan fokus ke bidang yang salah, yang memungkinkan pengguna melompat ke formulir dengan cepat. Atribut tautan hrefdiatur 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 hiddenatribut/properti untuk mengaktifkan visibilitas elemen, tetapi dukungannya 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.

Pola kesalahan sebaris dengan teks kesalahan merah dan ikon peringatan tepat di atas bidang.

<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 bagi pengguna yang dapat melihat dan tidak dapat melihat, kita dapat menggunakan aria-invalidatribut yang didukung dengan baik. Saat pengguna memfokuskan input, sekarang akan mengumumkan "Tidak Valid" (atau serupa) di pembaca layar.

<input aria-invalid="false">

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 FormValidatorkomponen, sekarang kita siap untuk menginisialisasinya. Untuk membuat turunan dari FormValidator, Anda harus meneruskan elemen formulir sebagai parameter pertama.

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

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

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 kontrol name, dan yang kedua adalah larik objek aturan. Setiap aturan berisi dua properti: methoddan message. The methodadalah fungsi yang menguji berbagai kondisi untuk mengembalikan salah satu trueatau 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 seringkali jauh lebih tidak memaafkan kesalahan daripada yang seharusnya. Jared Spool membuat lelucon tentang ini di “ Apakah Desain Ditentang Secara Metrik? ” (sekitar 42 menit):

"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) menunjukkan 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 yang 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 tidak berguna.

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 terlalu 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 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.

Bidang kata sandi MailChimp dengan instruksi yang ditandai saat pengguna memenuhi persyaratan.

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.

Ringkasan kesalahan yang berisi dinding pesan kesalahan membuat awal kata tampak terlalu berulang.

Kesalahan yang berbeda memerlukan pemformatan yang berbeda. Instruksi seperti "Masukkan nama depan Anda" adalah 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 jauh melampaui 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 placeholderatribut 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.