แนวทางปฏิบัติแนะนำสำหรับแบบฟอร์มลงชื่อเข้าใช้

ใช้ฟีเจอร์เบราว์เซอร์ข้ามแพลตฟอร์มเพื่อสร้างแบบฟอร์มลงชื่อเข้าใช้ที่ปลอดภัย เข้าถึงได้ง่าย และใช้งานง่าย

หากผู้ใช้จำเป็นต้องเข้าสู่ระบบของเว็บไซต์ การออกแบบฟอร์มการลงชื่อเข้าใช้ที่ดีเป็นสิ่งสำคัญ โดยเฉพาะอย่างยิ่งสำหรับผู้ที่มีการเชื่อมต่อที่ไม่ดี ใช้งานบนอุปกรณ์เคลื่อนที่ ที่กำลังรีบ หรือรู้สึกเครียด แบบฟอร์มลงชื่อเข้าใช้ที่ออกแบบมาไม่ดีจะได้รับอัตราตีกลับสูง การตีกลับแต่ละครั้งอาจทำให้ผู้ใช้เสียดายและไม่พอใจ ไม่ใช่แค่พลาดโอกาสในการลงชื่อเข้าใช้เท่านั้น

ต่อไปนี้เป็นตัวอย่างของแบบฟอร์มลงชื่อเข้าใช้ง่ายๆ ที่แสดงให้เห็นแนวทางปฏิบัติที่ดีที่สุดทั้งหมด

เช็กลิสต์

• ใช้องค์ประกอบ HTML ที่มีความหมาย: <form>, <input>, <label> และ <button>
• ติดป้ายกำกับอินพุตแต่ละรายการด้วย <label>
• ใช้แอตทริบิวต์เอลิเมนต์เพื่อเข้าถึงฟีเจอร์เบราว์เซอร์ในตัว ได้แก่ type, name, autocomplete, required
• ให้แอตทริบิวต์อินพุต name และ id เป็นค่าคงที่ที่ไม่เปลี่ยนแปลงระหว่างการโหลดหน้าเว็บหรือการทำให้เว็บไซต์ใช้งานได้
• ใส่การลงชื่อเข้าใช้ในองค์ประกอบ <form> ของตัวเอง
• ตรวจสอบว่าส่งแบบฟอร์มสำเร็จ
• ใช้ autocomplete="new-password" และ id="new-password" เพื่อป้อนรหัสผ่านในแบบฟอร์มลงชื่อสมัครใช้ และใช้รหัสผ่านใหม่ในแบบฟอร์มรีเซ็ตรหัสผ่าน
• ใช้ autocomplete="current-password" และ id="current-password" เพื่อป้อนรหัสผ่านการลงชื่อเข้าใช้
• ระบุฟังก์ชันแสดงรหัสผ่าน
• ใช้ aria-label และ aria-describedby สำหรับการป้อนรหัสผ่าน
• อย่าเพิ่มข้อมูลซ้ำ 2 เท่า
• ออกแบบรูปแบบให้แป้นพิมพ์บนอุปกรณ์เคลื่อนที่ไม่บดบังอินพุตหรือปุ่ม
• ตรวจสอบว่าแบบฟอร์มใช้งานได้ในอุปกรณ์เคลื่อนที่โดยใช้ข้อความที่อ่านได้ชัดเจน และตรวจสอบว่าอินพุตและปุ่มมีขนาดใหญ่พอที่จะทำงานเป็นเป้าหมายการสัมผัส
• รักษาแบรนด์และสไตล์บนหน้าลงชื่อสมัครใช้และลงชื่อเข้าใช้ของคุณ
• ทดสอบในช่องและห้องทดลอง: สร้างการวิเคราะห์หน้าเว็บ การวิเคราะห์การโต้ตอบ และการวัดประสิทธิภาพที่เน้นผู้ใช้เป็นศูนย์กลางในขั้นตอนการลงชื่อสมัครใช้และการลงชื่อเข้าใช้
• ทดสอบในเบราว์เซอร์และอุปกรณ์ต่างๆ: ลักษณะการทำงานของแบบฟอร์มจะแตกต่างกันไปในแต่ละแพลตฟอร์ม

ใช้ HTML ที่สื่อความหมาย

ใช้องค์ประกอบที่สร้างขึ้นสำหรับงาน: <form>, <label> และ <button> รายการเหล่านี้เปิดใช้ฟังก์ชันของเบราว์เซอร์ในตัว ปรับปรุงการช่วยเหลือพิเศษ และเพิ่มความหมายให้กับมาร์กอัปของคุณ

ใช้ <form>

คุณอาจอยากรวมอินพุตไว้ใน <div> และจัดการการส่งข้อมูลอินพุตด้วย JavaScript เท่านั้น โดยทั่วไปแล้ว ควรใช้องค์ประกอบ <form> แบบเก่าแบบธรรมดา วิธีนี้ทำให้โปรแกรมอ่านหน้าจอและอุปกรณ์อำนวยความสะดวกอื่นๆ เข้าถึงเว็บไซต์ได้ อีกทั้งยังเปิดใช้ฟีเจอร์ของเบราว์เซอร์ในตัวมากมาย สร้างการลงชื่อเข้าใช้ที่ทำงานพื้นฐานสำหรับเบราว์เซอร์รุ่นเก่าได้ง่ายขึ้น และยังคงทำงานได้แม้ว่า JavaScript จะไม่ทำงานก็ตาม

ใช้ <label>

หากต้องการติดป้ายกำกับอินพุต ให้ใช้ <label>!

<label for="email">Email</label>
<input id="email" …>

เหตุผล 2 ประการ ได้แก่

• การแตะหรือคลิกป้ายกำกับจะย้ายโฟกัสไปยังอินพุตของป้ายกำกับนั้น เชื่อมโยงป้ายกำกับกับอินพุตโดยใช้แอตทริบิวต์ for ของป้ายกำกับกับ name หรือ id ของอินพุต
• โปรแกรมอ่านหน้าจอจะแจ้งข้อความในป้ายกำกับเมื่อป้ายกำกับหรืออินพุตของป้ายกำกับได้รับโฟกัส

อย่าใช้ตัวยึดตำแหน่งเป็นป้ายกำกับอินพุต ผู้ใช้ไม่จำเป็นต้องลืมว่าข้อมูลที่ป้อนนั้นมีไว้เพื่ออะไรเมื่อเริ่มป้อนข้อความ โดยเฉพาะอย่างยิ่งถ้าผู้ใช้ทำให้สับสน ("ฉันป้อนอีเมล หมายเลขโทรศัพท์ หรือรหัสบัญชีหรือเปล่า") ยังมีปัญหาอื่นๆ อีกมากมายที่อาจเกิดขึ้นกับตัวยึดตำแหน่ง เช่น ดูอย่าใช้ แอตทริบิวต์ตัวยึดตำแหน่งและตัวยึดตำแหน่งในช่องของแบบฟอร์ม เป็นอันตรายหากคุณไม่แน่ใจ

การใส่ป้ายกำกับไว้เหนืออินพุตอาจเป็นการดีที่สุด วิธีนี้ทําให้มีการออกแบบที่สอดคล้องกันทั้งในอุปกรณ์เคลื่อนที่และเดสก์ท็อป และการวิจัย AI ของ Google ช่วยให้ผู้ใช้สแกนได้เร็วขึ้น คุณจะได้ป้ายกำกับความกว้างเต็มและอินพุต และไม่จำเป็นต้องปรับป้ายกำกับและความกว้างของอินพุตให้พอดีกับข้อความของป้ายกำกับ

เปิดภาพกลิทช์ตำแหน่งของป้ายกำกับในอุปกรณ์เคลื่อนที่เพื่อดูด้วยตัวเอง

ใช้ <button>

ใช้ <button> เป็นปุ่ม องค์ประกอบปุ่มมีลักษณะการทำงานที่เข้าถึงได้และฟังก์ชันการส่งแบบฟอร์มในตัว ทั้งยังจัดรูปแบบได้ง่าย ไม่มีประโยชน์ในการใช้ <div> หรือองค์ประกอบอื่นๆ ที่แอบอ้างเป็นปุ่ม

ตรวจสอบว่าปุ่ม "ส่ง" ระบุถึงหน้าที่ของปุ่ม ตัวอย่างเช่น สร้างบัญชี หรือลงชื่อเข้าใช้ ไม่ใช่ส่ง หรือเริ่มต้น

ตรวจสอบว่าการส่งแบบฟอร์มประสบความสำเร็จ

ช่วยให้เครื่องมือจัดการรหัสผ่านเข้าใจว่ามีการส่งฟอร์มแล้ว โดยมี 2 วิธีดังนี้

• ไปที่หน้าอื่น
• จำลองการนำทางด้วย History.pushState() หรือ History.replaceState() และนำแบบฟอร์มรหัสผ่านออก

เมื่อใช้คำขอ XMLHttpRequest หรือ fetch โปรดตรวจสอบว่ามีการรายงานการลงชื่อเข้าใช้ที่สำเร็จในการตอบสนองและจัดการโดยนำแบบฟอร์มออกจาก DOM และบอกสถานะความสำเร็จให้ผู้ใช้ทราบ

ลองปิดใช้ปุ่มลงชื่อเข้าใช้เมื่อผู้ใช้แตะหรือคลิกปุ่มนั้น ผู้ใช้หลายคนคลิกปุ่มหลายครั้ง แม้จะอยู่ในเว็บไซต์ที่เร็วและตอบสนองตามอุปกรณ์ก็ตาม ทำให้การโต้ตอบช้าลงและ เพิ่มภาระงานของเซิร์ฟเวอร์

ในทางกลับกัน โปรดอย่าปิดใช้การส่งแบบฟอร์มที่รอการป้อนข้อมูลจากผู้ใช้ ตัวอย่างเช่น อย่าปิดใช้ปุ่มลงชื่อเข้าใช้หากผู้ใช้ยังไม่ได้ป้อน PIN ลูกค้า ผู้ใช้อาจพลาดบางสิ่งในแบบฟอร์ม จากนั้นลองแตะปุ่มลงชื่อเข้าใช้ (ปิดใช้อยู่) ซ้ำๆ แล้วคิดว่าใช้งานไม่ได้ อย่างน้อยที่สุดหากคุณต้องปิดใช้การส่งแบบฟอร์ม ให้อธิบายให้ผู้ใช้ทราบถึงข้อมูลที่ขาดหายไปเมื่อคลิกปุ่มปิดใช้

อย่าเพิ่มอินพุตเป็น 2 เท่า

บางเว็บไซต์บังคับให้ผู้ใช้ป้อนอีเมลหรือรหัสผ่าน 2 ครั้ง ซึ่งอาจช่วยลดข้อผิดพลาดสำหรับผู้ใช้บางส่วน แต่ทำให้การทำงานสำหรับผู้ใช้ทั้งหมดเพิ่มขึ้น รวมถึงเพิ่มอัตราการหยุดกลางคัน นอกจากนี้ การถามซ้ำ 2 ครั้งก็ไม่สมเหตุสมผลที่เบราว์เซอร์จะเติมที่อยู่อีเมลอัตโนมัติหรือแนะนำรหัสผ่านที่รัดกุม ควรอนุญาตให้ผู้ใช้ยืนยันอีเมลของตน (ยังไงก็ต้องทำแบบนั้น) และทำให้ผู้ใช้รีเซ็ตรหัสผ่านได้ง่าย หากจำเป็น

ใช้ประโยชน์สูงสุดจากแอตทริบิวต์ขององค์ประกอบ

นี่คือที่ที่เวทมนตร์เกิดขึ้นจริงๆ เบราว์เซอร์มีฟีเจอร์ในตัวที่เป็นประโยชน์หลายอย่างที่ใช้แอตทริบิวต์องค์ประกอบอินพุต

รักษารหัสผ่านให้เป็นส่วนตัว แต่อนุญาตให้ผู้ใช้ดูรหัสผ่านได้เมื่อต้องการ

รหัสผ่านที่ป้อนควรมี type="password" เพื่อซ่อนข้อความของรหัสผ่าน และช่วยให้เบราว์เซอร์เข้าใจว่าข้อมูลที่ป้อนสำหรับรหัสผ่าน (โปรดทราบว่าเบราว์เซอร์ใช้เทคนิคที่หลากหลายเพื่อทำความเข้าใจบทบาทการป้อนข้อมูลและตัดสินใจว่าจะเสนอให้บันทึกรหัสผ่านหรือไม่)

คุณควรเพิ่มปุ่มสลับแสดงรหัสผ่านเพื่อให้ผู้ใช้ตรวจสอบข้อความที่ป้อนได้ และอย่าลืมเพิ่มลิงก์ลืมรหัสผ่านด้วย โปรดดูเปิดใช้การแสดงรหัสผ่าน

ให้ผู้ใช้อุปกรณ์เคลื่อนที่แป้นพิมพ์ที่ถูกต้อง

ใช้ <input type="email"> เพื่อให้ผู้ใช้อุปกรณ์เคลื่อนที่มีแป้นพิมพ์ที่เหมาะสมและ เปิดใช้การตรวจสอบอีเมลพื้นฐานในตัวโดยเบราว์เซอร์... ไม่ต้องใช้ JavaScript!

หากต้องการใช้หมายเลขโทรศัพท์แทนอีเมล <input type="tel"> จะเปิดใช้ปุ่มกดโทรศัพท์ในอุปกรณ์เคลื่อนที่ นอกจากนี้คุณยังใช้แอตทริบิวต์ inputmode ในกรณีที่จำเป็นได้ด้วย โดย inputmode="numeric" จะเหมาะสำหรับหมายเลข PIN ทุกสิ่งที่คุณอยากรู้เกี่ยวกับ inputmode มีรายละเอียดเพิ่มเติม

ป้องกันไม่ให้แป้นพิมพ์บนอุปกรณ์เคลื่อนที่มาบดบังปุ่มลงชื่อเข้าใช้

ขออภัย หากไม่ระมัดระวัง แป้นพิมพ์บนอุปกรณ์เคลื่อนที่อาจบังแบบฟอร์มของคุณ หรืออาจบดบังปุ่มลงชื่อเข้าใช้บางส่วน ผู้ใช้อาจเลิกล้มก่อนที่จะ รู้ตัวว่าเกิดอะไรขึ้น

หากเป็นไปได้ โปรดหลีกเลี่ยงปัญหานี้โดยแสดงเฉพาะช่องป้อนอีเมล/โทรศัพท์และรหัสผ่านและปุ่มลงชื่อเข้าใช้ที่ด้านบนของหน้าลงชื่อเข้าใช้ ใส่เนื้อหาอื่นด้านล่าง

ทดสอบกับอุปกรณ์ชนิดต่างๆ

คุณจะต้องทดสอบบนอุปกรณ์ต่างๆ สำหรับกลุ่มเป้าหมาย และปรับเปลี่ยนตามความเหมาะสม BrowserStack ช่วยให้สามารถทดสอบโปรเจ็กต์โอเพนซอร์สฟรีในอุปกรณ์และเบราว์เซอร์จริงที่หลากหลาย

พิจารณาใช้หน้า 2 หน้า

บางเว็บไซต์ (รวมถึง Amazon และ eBay) หลีกเลี่ยงปัญหาด้วยการขออีเมล/โทรศัพท์และรหัสผ่านในหน้าเว็บ 2 หน้า วิธีการนี้ยังช่วยลดความยุ่งยากให้กับประสบการณ์การใช้งานด้วย กล่าวคือ ผู้ใช้จะทำได้เพียงครั้งละ 1 อย่างเท่านั้น

ตามหลักแล้ว ควรใช้ <แบบฟอร์ม> เดียว ใช้ JavaScript เพื่อแสดงเฉพาะอินพุตอีเมลในตอนแรก จากนั้นจึงซ่อนและแสดงอินพุตรหัสผ่าน หากคุณต้องบังคับให้ผู้ใช้ไปยังหน้าเว็บใหม่ระหว่างป้อนอีเมลและรหัสผ่าน แบบฟอร์มในหน้าที่ 2 ควรมีองค์ประกอบอินพุตที่ซ่อนไว้พร้อมกับค่าอีเมลเพื่อช่วยให้เครื่องมือจัดการรหัสผ่านเก็บค่าที่ถูกต้องได้ ตัวอย่างโค้ดสำหรับรูปแบบของแบบฟอร์มรหัสผ่านที่ Chromium เข้าใจ

ช่วยให้ผู้ใช้หลีกเลี่ยงการป้อนข้อมูลซ้ำ

คุณช่วยให้เบราว์เซอร์จัดเก็บข้อมูลอย่างถูกต้องและการป้อนข้อมูลอัตโนมัติได้ เพื่อที่ผู้ใช้จะได้ไม่ต้องจดจำค่าอีเมลและรหัสผ่าน วิธีนี้สำคัญมากในอุปกรณ์เคลื่อนที่ และสำคัญต่อการป้อนข้อมูลอีเมล ซึ่งจะมีอัตราการหยุดกลางคันสูง

ซึ่งแบ่งออกเป็น 2 ส่วน ดังนี้

1. แอตทริบิวต์ autocomplete, name, id และ type ช่วยให้เบราว์เซอร์เข้าใจบทบาทของอินพุตเพื่อจัดเก็บข้อมูลที่ต่อมาจะใช้สำหรับการป้อนข้อความอัตโนมัติได้ เบราว์เซอร์สมัยใหม่ยังกำหนดให้อินพุตต้องมีค่า name หรือ id ที่เสถียร (ไม่สร้างแบบสุ่มในการโหลดหน้าเว็บแต่ละครั้งหรือการทำให้เว็บไซต์ใช้งานได้) และต้องอยู่ใน <แบบฟอร์ม> ที่มีปุ่ม submit เพื่อให้จัดเก็บข้อมูลสำหรับการป้อนข้อความอัตโนมัติได้

2. แอตทริบิวต์ autocomplete ช่วยให้เบราว์เซอร์ป้อนข้อความอัตโนมัติอย่างถูกต้องโดยใช้ข้อมูลที่จัดเก็บไว้

สำหรับอินพุตอีเมล ให้ใช้ autocomplete="username" เนื่องจากเครื่องมือจัดการรหัสผ่านจะรู้จัก username ในเบราว์เซอร์รุ่นใหม่ แม้ว่าคุณจะใช้ type="email" และอาจต้องการใช้ id="email" และ name="email" ก็ตาม

สำหรับการป้อนรหัสผ่าน ให้ใช้ค่า autocomplete และ id ที่เหมาะสมเพื่อช่วยให้เบราว์เซอร์แยกความแตกต่างระหว่างรหัสผ่านใหม่กับรหัสผ่านปัจจุบันได้

ใช้ autocomplete="new-password" และ id="new-password" เพื่อรับรหัสผ่านใหม่

• ใช้ autocomplete="new-password" และ id="new-password" เพื่อป้อนรหัสผ่านในแบบฟอร์มลงชื่อสมัครใช้ หรือใช้รหัสผ่านใหม่ในแบบฟอร์มการเปลี่ยนรหัสผ่าน

ใช้ autocomplete="current-password" และ id="current-password" สำหรับรหัสผ่านที่มีอยู่

• ใช้ autocomplete="current-password" และ id="current-password" เพื่อป้อนรหัสผ่านในแบบฟอร์มลงชื่อเข้าใช้ หรืออินพุตสำหรับรหัสผ่านเดิมของผู้ใช้ในแบบฟอร์มเปลี่ยนรหัสผ่าน ซึ่งจะบอกเบราว์เซอร์ว่าคุณต้องการให้ใช้รหัสผ่านปัจจุบันที่เบราว์เซอร์จัดเก็บไว้สำหรับเว็บไซต์

สำหรับแบบฟอร์มลงชื่อสมัครใช้:

<input type="password" autocomplete="new-password" id="new-password" …>

สำหรับการลงชื่อเข้าใช้:

<input type="password" autocomplete="current-password" id="current-password" …>

เครื่องมือจัดการรหัสผ่านที่รองรับ

เบราว์เซอร์แต่ละชนิดจะจัดการการป้อนข้อความอัตโนมัติและการแนะนำรหัสผ่าน แต่แตกต่างกัน แต่ผลที่ได้จะเหมือนกันมาก ใน Safari 11 ขึ้นไปบนเดสก์ท็อป เครื่องมือจัดการรหัสผ่านจะปรากฏขึ้น จากนั้นจะใช้การตรวจสอบสิทธิ์ด้วยข้อมูลไบโอเมตริก (ลายนิ้วมือหรือการจดจำใบหน้า) (หากมี)

Chrome บนเดสก์ท็อปจะแสดงคำแนะนำอีเมล แสดงเครื่องมือจัดการรหัสผ่าน และป้อนรหัสผ่านอัตโนมัติ

รหัสผ่านของเบราว์เซอร์และระบบป้อนข้อความอัตโนมัตินั้นไม่ง่ายนัก อัลกอริทึมสำหรับการคาดเดา จัดเก็บ และแสดงค่าไม่ได้เป็นมาตรฐาน และจะแตกต่างกันไปตามแพลตฟอร์ม ตัวอย่างเช่น ตามที่ Hidde de Vries ได้ชี้ให้เห็น: "เครื่องมือจัดการรหัสผ่านของ Firefox ช่วยเสริมการเรียนรู้ของระบบด้วยระบบสูตร"

ป้อนข้อความอัตโนมัติ: สิ่งที่นักพัฒนาเว็บควรทราบแต่ไม่ต้องมีข้อมูลเพิ่มเติมเกี่ยวกับการใช้ name และ autocomplete ข้อกำหนดของ HTML จะแสดงค่าที่เป็นไปได้ทั้งหมด 59 ค่า

เปิดใช้เบราว์เซอร์เพื่อแนะนำรหัสผ่านที่รัดกุม

เบราว์เซอร์ที่ทันสมัยใช้การเรียนรู้เพื่อตัดสินใจว่าจะแสดง UI ของเครื่องมือจัดการรหัสผ่านเมื่อใดและแนะนำรหัสผ่านที่รัดกุม

นี่คือการทำงานของ Safari บนเดสก์ท็อป

(คำแนะนำเกี่ยวกับรหัสผ่านที่ไม่ซ้ำที่รัดกุมมีให้ใช้งานใน Safari ตั้งแต่เวอร์ชัน 12.0)

โปรแกรมสร้างรหัสผ่านของเบราว์เซอร์ที่มีในตัวทำให้ผู้ใช้และนักพัฒนาซอฟต์แวร์ไม่ต้องมาคิดว่า "รหัสผ่านที่รัดกุม" คืออะไร เนื่องจากเบราว์เซอร์สามารถจัดเก็บรหัสผ่านและป้อนรหัสผ่านอัตโนมัติตามที่จำเป็นได้ จึงไม่จำเป็นต้องให้ผู้ใช้จดจำหรือป้อนรหัสผ่าน นอกจากนี้ การส่งเสริมให้ผู้ใช้ใช้ประโยชน์จากโปรแกรมสร้างรหัสผ่านในเบราว์เซอร์ในตัวยังหมายความว่า ผู้ใช้มีแนวโน้มที่จะใช้รหัสผ่านที่ไม่ซ้ำกันและรัดกุมในเว็บไซต์มากขึ้น และมีแนวโน้มที่จะใช้รหัสผ่านที่อาจถูกบุกรุกในที่อื่นๆ น้อยลง

ช่วยป้องกันไม่ให้ผู้ใช้ป้อนข้อมูลสูญหายโดยไม่ตั้งใจ

เพิ่มแอตทริบิวต์ required ทั้งในช่องอีเมลและรหัสผ่าน เบราว์เซอร์ที่ทันสมัยจะส่งข้อความแจ้งโดยอัตโนมัติและโฟกัสสําหรับข้อมูลที่ขาดหายไป ไม่ต้องใช้ JavaScript

ออกแบบสำหรับนิ้วมือและนิ้วโป้ง

ขนาดเบราว์เซอร์เริ่มต้นสำหรับข้อมูลทุกอย่างที่เกี่ยวข้องกับองค์ประกอบและปุ่มอินพุต มีขนาดเล็กเกินไป โดยเฉพาะบนอุปกรณ์เคลื่อนที่ เรื่องนี้อาจจะฟังดูชัดเจน แต่เป็นปัญหา ที่พบบ่อยกับแบบฟอร์มลงชื่อเข้าใช้ในหลายไซต์

ตรวจสอบว่าอินพุตและปุ่มมีขนาดใหญ่พอ

ขนาดและระยะห่างจากขอบเริ่มต้นของอินพุตและปุ่มเล็กเกินไปบนเดสก์ท็อป และแย่กว่าบนอุปกรณ์เคลื่อนที่

ตามคำแนะนำการช่วยเหลือพิเศษของ Android ขนาดเป้าหมายที่แนะนำสำหรับวัตถุที่เป็นหน้าจอสัมผัสคือ 7-10 มม. หลักเกณฑ์สำหรับอินเทอร์เฟซของ Apple แนะนำไว้ที่ 48x48 พิกเซล และ W3C แนะนำว่าพิกเซล CSS อย่างน้อย 44x44 พิกเซล จากนั้นเพิ่มระยะห่างจากขอบ (อย่างน้อย) ประมาณ 15 พิกเซลลงในองค์ประกอบและปุ่มสำหรับอุปกรณ์เคลื่อนที่ และประมาณ 10 พิกเซลบนเดสก์ท็อป ลองใช้อุปกรณ์เคลื่อนที่จริง และนิ้วโป้งหรือนิ้วโป้งจริงๆ คุณควรจะแตะอินพุตและปุ่มแต่ละรายการได้อย่างสะดวก

เป้าหมายการแตะมีขนาดที่ไม่เหมาะสม การตรวจสอบ Lighthouse ช่วยให้กระบวนการตรวจหาองค์ประกอบอินพุตที่มีขนาดเล็กเกินไปเป็นระบบอัตโนมัติได้

ออกแบบสำหรับนิ้วโป้ง

ค้นหาเป้าหมายการสัมผัส แล้วคุณจะเห็นรูปภาพนิ้วชี้จำนวนมาก แต่ในโลกแห่งความเป็นจริง ผู้คนจำนวนมาก ใช้นิ้วโป้งโต้ตอบกับโทรศัพท์ ปุ่ม "ชอบ" ใหญ่กว่านิ้วชี้ และจะควบคุมได้แม่นยำกว่า ทั้งหมดนี้เป็นเหตุผลว่าทำไม เป้าหมายการสัมผัสที่มีขนาดเหมาะสม

ทำให้ข้อความใหญ่พอ

เช่นเดียวกับขนาดและระยะห่างจากขอบ ขนาดแบบอักษรเริ่มต้นของเบราว์เซอร์สําหรับองค์ประกอบและปุ่มอินพุตมีขนาดเล็กเกินไป โดยเฉพาะในอุปกรณ์เคลื่อนที่

เบราว์เซอร์บนแพลตฟอร์มต่างๆ จะมีขนาดฟอนต์แตกต่างกัน จึงยากที่จะระบุขนาดตัวอักษรที่ใช้ได้ดีในทุกที่ แบบสำรวจสั้นๆ เกี่ยวกับเว็บไซต์ยอดนิยมจะแสดงขนาด 13-16 พิกเซลบนเดสก์ท็อป โดยการกำหนดขนาดเท่ากับขนาดจริงขั้นต่ำที่เหมาะสำหรับข้อความในอุปกรณ์เคลื่อนที่

นั่นหมายความว่าคุณต้องใช้ขนาดพิกเซลที่ใหญ่ขึ้นบนอุปกรณ์เคลื่อนที่: 16px ใน Chrome สำหรับเดสก์ท็อปนั้นอ่านออกได้ง่าย แต่แม้ว่าจะมองเห็นได้ดีแล้ว ก็ยังยากที่จะอ่านข้อความ 16px ใน Chrome สำหรับ Android คุณตั้งค่าขนาดพิกเซลแบบอักษรที่แตกต่างกันสำหรับขนาดวิวพอร์ตต่างๆ ได้โดยใช้คำค้นหาสื่อ 20px สามารถทำได้จากอุปกรณ์เคลื่อนที่โดยตรง แต่คุณควรทดลองใช้กับเพื่อนหรือเพื่อนร่วมงานที่มีสายตาเลือนราง

เอกสารไม่ได้ใช้ขนาดแบบอักษรที่อ่านง่าย การตรวจสอบ Lighthouse ช่วยให้กระบวนการตรวจหาข้อความมีขนาดเล็กเกินไปได้โดยอัตโนมัติ

เว้นระยะห่างระหว่างอินพุตเพียงพอ

เพิ่มระยะขอบให้เพียงพอเพื่อให้อินพุตทํางานได้ดีกับเป้าหมายการสัมผัส กล่าวคือ ให้เน้นระยะขอบ ประมาณ 1 นิ้ว

ตรวจสอบว่าข้อมูลที่ป้อนมองเห็นได้อย่างชัดเจน

การจัดรูปแบบเส้นขอบเริ่มต้นสำหรับอินพุตทำให้ดูยาก แทบจะมองไม่เห็น ในบางแพลตฟอร์ม เช่น Chrome สำหรับ Android

นอกเหนือจากระยะห่างจากขอบแล้ว ให้เพิ่มเส้นขอบ: บนพื้นหลังสีขาว กฎทั่วไปที่ดีคือใช้ #ccc หรือสีเข้มกว่านั้น

ใช้ฟีเจอร์ในตัวของเบราว์เซอร์เพื่อเตือนค่าอินพุตที่ไม่ถูกต้อง

เบราว์เซอร์มีฟีเจอร์ในตัวในการตรวจสอบความถูกต้องของแบบฟอร์มพื้นฐานสำหรับอินพุตที่มีแอตทริบิวต์ type เบราว์เซอร์จะเตือนเมื่อคุณส่งแบบฟอร์มที่มีค่าไม่ถูกต้อง และตั้งโฟกัสที่อินพุตที่มีปัญหา

คุณใช้ตัวเลือก CSS :invalid เพื่อไฮไลต์ข้อมูลที่ไม่ถูกต้องได้ ใช้ :not(:placeholder-shown) เพื่อหลีกเลี่ยงการเลือกอินพุตที่ไม่มีเนื้อหา

input[type=email]:not(:placeholder-shown):invalid {
  color: red;
  outline-color: red;
}

ลองใช้วิธีต่างๆ ในการไฮไลต์อินพุตที่มีค่าไม่ถูกต้อง

ใช้ JavaScript เมื่อจำเป็น

สลับการแสดงรหัสผ่าน

คุณควรเพิ่มปุ่มสลับแสดงรหัสผ่านเพื่อให้ผู้ใช้ตรวจสอบข้อความที่ป้อนได้ ความสามารถในการใช้งานจะได้รับผลกระทบเมื่อผู้ใช้ไม่เห็นข้อความที่ป้อน ปัจจุบันยังไม่มีวิธีติดตั้งในตัว แต่มีแผนสำหรับการนำไปใช้งาน คุณจะต้องใช้ JavaScript แทน

โค้ดต่อไปนี้ใช้ปุ่มข้อความเพื่อเพิ่มฟังก์ชันแสดงรหัสผ่าน

HTML:

<section>
  <label for="password">Password</label>
  <button id="toggle-password" type="button" aria-label="Show password as plain text. Warning: this will display your password on the screen.">Show password</button>
  <input id="password" name="password" type="password" autocomplete="current-password" required>
</section>

นี่คือ CSS ที่จะทำให้ปุ่มมีลักษณะเหมือนข้อความธรรมดา

button#toggle-password {
  background: none;
  border: none;
  cursor: pointer;
  /* Media query isn't shown here. */
  font-size: var(--mobile-font-size);
  font-weight: 300;
  padding: 0;
  /* Display at the top right of the container */
  position: absolute;
  top: 0;
  right: 0;
}

และ JavaScript สำหรับแสดงรหัสผ่าน ให้ทำดังนี้

const passwordInput = document.getElementById('password');
const togglePasswordButton = document.getElementById('toggle-password');

togglePasswordButton.addEventListener('click', togglePassword);

function togglePassword() {
  if (passwordInput.type === 'password') {
    passwordInput.type = 'text';
    togglePasswordButton.textContent = 'Hide password';
    togglePasswordButton.setAttribute('aria-label',
      'Hide password.');
  } else {
    passwordInput.type = 'password';
    togglePasswordButton.textContent = 'Show password';
    togglePasswordButton.setAttribute('aria-label',
      'Show password as plain text. ' +
      'Warning: this will display your password on the screen.');
  }
}

นี่คือผลลัพธ์สุดท้าย:

กำหนดให้ป้อนรหัสผ่านได้

ใช้ aria-describedby เพื่อร่างกฎรหัสผ่านโดยระบุรหัสขององค์ประกอบที่อธิบายข้อจำกัด โปรแกรมอ่านหน้าจอจะระบุข้อความป้ายกำกับ ประเภทการป้อนข้อมูล (รหัสผ่าน) และคำอธิบาย

<input type="password" aria-describedby="password-constraints" …>
<div id="password-constraints">Eight or more characters with a mix of letters, numbers and symbols.</div>

เมื่อคุณเพิ่มฟังก์ชันแสดงรหัสผ่าน อย่าลืมใส่ aria-label เพื่อเตือนว่ารหัสผ่านจะแสดงด้วย มิฉะนั้น ผู้ใช้อาจ เปิดเผยรหัสผ่านโดยไม่ตั้งใจ

<button id="toggle-password"
        aria-label="Show password as plain text.
                    Warning: this will display your password on the screen.">
  Show password
</button>

คุณดูการทำงานจริงของฟีเจอร์ ARIA ทั้ง 2 ฟีเจอร์ได้ในกลิทช์ต่อไปนี้

การสร้างฟอร์มที่เข้าถึงได้มีเคล็ดลับเพิ่มเติมที่จะช่วยทำให้เข้าถึงแบบฟอร์มได้

ตรวจสอบแบบเรียลไทม์และก่อนส่ง

องค์ประกอบและแอตทริบิวต์ของแบบฟอร์ม HTML มีฟีเจอร์ในตัวสำหรับการตรวจสอบขั้นพื้นฐาน แต่คุณควรใช้ JavaScript เพื่อทำการตรวจสอบที่มีประสิทธิภาพมากยิ่งขึ้นขณะที่ผู้ใช้ป้อนข้อมูลและเมื่อพยายามส่งแบบฟอร์ม

ขั้นตอนที่ 5 ของแบบฟอร์มการลงชื่อเข้าใช้ Codelab จะใช้ Constraint Validation API (ซึ่งรองรับในวงกว้าง) เพื่อเพิ่มการตรวจสอบที่กำหนดเองโดยใช้ UI ของเบราว์เซอร์ในตัวเพื่อตั้งโฟกัสและแสดงข้อความแจ้ง

ดูข้อมูลเพิ่มเติม: ใช้ JavaScript เพื่อตรวจสอบความถูกต้องแบบเรียลไทม์ที่ซับซ้อนมากขึ้น

Analytics และ RUM

"สิ่งที่คุณไม่สามารถวัดผลได้และคุณไม่สามารถปรับปรุงได้" เป็นจริงโดยเฉพาะอย่างยิ่งสำหรับแบบฟอร์มลงชื่อสมัครใช้และลงชื่อเข้าใช้ คุณต้องตั้งเป้าหมาย วัดความสำเร็จ ปรับปรุงเว็บไซต์ และทำซ้ำ

การทดสอบความสามารถในการใช้งานอาจมีประโยชน์สำหรับการลองใช้การเปลี่ยนแปลงต่างๆ แต่คุณต้องใช้ข้อมูลจริงเพื่อทำความเข้าใจประสบการณ์ของผู้ใช้ที่มีต่อแบบฟอร์มลงชื่อสมัครใช้และการลงชื่อเข้าใช้

• การวิเคราะห์หน้าเว็บ: การดูหน้าเว็บสำหรับการลงชื่อสมัครใช้และการลงชื่อเข้าใช้ อัตราตีกลับ และการออก
• ข้อมูลวิเคราะห์การโต้ตอบ: ช่องทางเป้าหมาย (ผู้ใช้ออกจากขั้นตอนการลงชื่อเข้าใช้หรือลงชื่อเข้าใช้ที่จุดใด) และเหตุการณ์ (ผู้ใช้ดำเนินการอย่างไรเมื่อโต้ตอบกับแบบฟอร์ม)
• ประสิทธิภาพของเว็บไซต์: เมตริกที่เน้นผู้ใช้เป็นหลัก (แบบฟอร์มการลงชื่อสมัครใช้และการลงชื่อเข้าใช้ของคุณช้าด้วยเหตุผลบางอย่าง หากใช่ เกิดจากอะไร)

คุณอาจต้องพิจารณาใช้การทดสอบ A/B เพื่อลองใช้วิธีต่างๆ ในการลงชื่อสมัครใช้และลงชื่อเข้าใช้ และการเปิดตัวแบบทีละขั้นเพื่อตรวจสอบการเปลี่ยนแปลงกับผู้ใช้กลุ่มย่อยก่อนที่จะเผยแพร่การเปลี่ยนแปลงให้แก่ผู้ใช้ทั้งหมด

หลักเกณฑ์ทั่วไป

UI และ UX ที่ออกแบบมาอย่างดีจะช่วยลดการละทิ้งฟอร์มลงชื่อเข้าใช้กลางคันได้

• อย่าทำให้ผู้ใช้ต้องค้นหาการลงชื่อเข้าใช้! ใส่ลิงก์ไปยังแบบฟอร์มลงชื่อเข้าใช้ไว้ที่ด้านบนของหน้า โดยใช้ถ้อยคำที่เข้าใจกัน เช่น ลงชื่อเข้าใช้ สร้างบัญชี หรือลงทะเบียน
• ตั้งใจทำให้เต็มที่! แบบฟอร์มลงชื่อสมัครใช้ไม่ใช่ที่ที่จะเบี่ยงเบนความสนใจของผู้ใช้ด้วยข้อเสนอและฟีเจอร์อื่นๆ ของเว็บไซต์
• ลดความซับซ้อนในการลงชื่อสมัครใช้ รวบรวมข้อมูลอื่นๆ ของผู้ใช้ (เช่น ที่อยู่หรือรายละเอียดบัตรเครดิต) เฉพาะเมื่อผู้ใช้เห็นประโยชน์ที่ชัดเจนจากการให้ข้อมูลดังกล่าว
• ก่อนที่ผู้ใช้จะกรอกแบบฟอร์มลงทะเบียน ให้บอกให้ชัดเจนว่าคุณค่าที่นำเสนอคืออะไร ผู้ใช้ได้ประโยชน์จากการลงชื่อเข้าใช้อย่างไร ให้สิ่งจูงใจที่เป็นรูปธรรม แก่ผู้ใช้ในการลงชื่อสมัครใช้ให้เสร็จสมบูรณ์
• หากเป็นไปได้ ให้ผู้ใช้ระบุตนเองด้วยหมายเลขโทรศัพท์มือถือแทนอีเมล เนื่องจากผู้ใช้บางรายอาจไม่ได้ใช้อีเมล
• ช่วยให้ผู้ใช้รีเซ็ตรหัสผ่านได้ง่ายๆ และแสดงลิงก์ลืมรหัสผ่านให้ชัดเจน
• ลิงก์ไปยังเอกสารข้อกำหนดในการให้บริการและนโยบายความเป็นส่วนตัว: แจ้งให้ผู้ใช้ทราบอย่างชัดเจนตั้งแต่เริ่มต้นเกี่ยวกับวิธีการปกป้องข้อมูลของผู้ใช้
• ใส่โลโก้และชื่อของบริษัทหรือองค์กรไว้ในหน้าลงชื่อสมัครใช้และหน้าลงชื่อเข้าใช้ แล้วตรวจสอบว่าภาษา แบบอักษร และสไตล์ตรงกับเนื้อหาที่เหลือในเว็บไซต์ บางแบบฟอร์มอาจไม่รู้สึกว่าเป็นของเว็บไซต์เดียวกันกับเนื้อหาอื่นๆ โดยเฉพาะหากมี URL ที่แตกต่างกันอย่างมาก

เรียนรู้อยู่เสมอ

• สร้างฟอร์มที่น่าทึ่ง
• แนวทางปฏิบัติแนะนำสำหรับการออกแบบแบบฟอร์มบนอุปกรณ์เคลื่อนที่
• การควบคุมแบบฟอร์มที่มีความสามารถมากขึ้น
• การสร้างฟอร์มที่เข้าถึงได้
• การปรับปรุงขั้นตอนการลงชื่อเข้าใช้ด้วย API การจัดการข้อมูลเข้าสู่ระบบ
• ยืนยันหมายเลขโทรศัพท์ในเว็บด้วย WebOTP API

รูปภาพโดย Meghan Schiereck ใน Unsplash