วิธีออกแบบฟอร์มที่ทุกคนเข้าถึงได้: label ข้อความแจ้งข้อผิดพลาด autocomplete และ CAPTCHA

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

การแก้ส่วนใหญ่ เป็นแค่ HTML ธรรมดาที่ใช้อย่างถูกวิธี บวกกับการเลือกคำอย่างรอบคอบ และแต่ละข้อก็ตรงกับเกณฑ์ข้อหนึ่งใน WCAG 2.2 (มาตรฐานการเข้าถึงเว็บสากล) ถ้าอยากรู้ว่าควรถามข้อมูลอะไรบ้าง อ่าน การออกแบบฟอร์มบนเว็บ ส่วนการเข้าถึงในเรื่องอื่นนอกจากฟอร์ม เริ่มจาก คู่มือการเข้าถึงเว็บไซต์ฉบับใช้งานจริง ของเรา

สรุปสั้นๆ ฟอร์มที่เข้าถึงได้

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

1. ทุกช่องมี label ที่มองเห็นได้ และเชื่อมกับช่อง ไม่ใช่มีแค่ placeholder (ข้อความจางๆ ในช่อง)
2. จัดกลุ่มตัวเลือกที่เกี่ยวข้องกัน ด้วย fieldset และ legend
3. บอกเป็นข้อความ ว่าช่องไหนต้องกรอก และต้องกรอกแบบไหน ไว้ก่อนถึงช่อง
4. ใส่แอตทริบิวต์ autocomplete ในช่องข้อมูลของผู้เข้าชมเอง
5. ข้อความแจ้งข้อผิดพลาดที่บอกวิธีแก้ อยู่ติดกับช่อง และถูกอ่านออกเสียง
6. ข้อความแจ้งความสำเร็จและสถานะ ที่โปรแกรมอ่านหน้าจออ่านออกมา
7. ไม่ต้องกรอกซ้ำ ไม่มีเวลาจำกัดแบบไม่ทันตั้งตัว และไม่มีด่านที่ผ่านได้ ด้วยการแก้ปริศนาเท่านั้น

label และโครงสร้างฟอร์ม

ทุกช่องต้องมี label ที่เห็นได้และเชื่อมกับช่อง

ทุกช่องต้องมี label ที่มองเห็นได้ และเชื่อมกันในโค้ด คือ <label> ที่ค่า for ตรงกับ id ของช่อง (WCAG 1.3.1, 3.3.2 และ 4.1.2) โปรแกรมอ่านหน้าจอจะอ่าน label เมื่อโฟกัสมาที่ช่อง และการคลิก label ก็จะโฟกัสไปที่ช่องด้วย ทุกคนจึงได้พื้นที่กดที่ใหญ่ขึ้น แต่ถึงอย่างนั้น การไม่มี label ก็ติดหนึ่งในหกปัญหาที่พบบ่อยที่สุดใน WebAIM Million เป็นประจำ ซึ่งเป็นการสแกนหน้าแรกของเว็บไซต์ยอดนิยมหนึ่งล้านอันดับแรกที่ทำทุกปี

• placeholder ไม่ใช่ label เพราะจะหายไปทันทีที่เริ่มพิมพ์ และมักจางเกินกว่าจะผ่านค่าคอนทราสต์ 4.5:1 ที่ WCAG กำหนด สำหรับตัวอักษรขนาดปกติ
• ให้คำที่มองเห็น อยู่ในชื่อที่เข้าถึงได้ (accessible name) ด้วย ผู้ใช้ที่สั่งงานด้วยเสียงจะพูดตามสิ่งที่เห็น เช่น “คลิก ที่อยู่อีเมล” ถ้า aria-label เขียนไว้เป็นคำอื่น คำสั่งนั้นจะใช้ไม่ได้ (2.5.3 Label in Name)

จัดกลุ่มคำถามด้วย fieldset และ legend

ครอบปุ่มตัวเลือก (radio button) หรือช่องทำเครื่องหมาย (checkbox) แต่ละชุดด้วย <fieldset> และใส่คำถามสั้นๆ ไว้ใน <legend> เช่น “ให้เราติดต่อกลับทางไหนดี?” ผู้ใช้โปรแกรมอ่านหน้าจอ จะได้รู้ว่าตัวเลือกเหล่านั้นตอบคำถามอะไร และทำแบบเดียวกันกับวันที่ ที่แยกเป็นช่องวัน เดือน และปี

บอกช่องบังคับและคำแนะนำไว้ก่อนช่อง

ใส่ “(จำเป็น)” หรือ “(ไม่บังคับ)” ไว้ใน label เลย และใส่กฎเรื่องรูปแบบ (“ใส่รหัสประเทศด้วย”) เป็นคำแนะนำไว้เหนือช่อง แล้วเชื่อมด้วย aria-describedby คำแนะนำที่อยู่ใน tooltip หรืออยู่หลังช่องกรอก มองข้ามได้ง่าย โดยเฉพาะตอนซูมหน้าจอ อย่าบอกว่าช่องไหนบังคับด้วยสีอย่างเดียว (1.4.1 Use of Color) หรือด้วยดอกจันที่ไม่มีคำอธิบาย และใส่ required หรือ aria-required="true" เพื่อให้โปรแกรมอ่านหน้าจออ่านออกมา

ใช้ตัวควบคุมมาตรฐานที่เห็นชัดและกดง่าย

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

มีอีกสามข้อในระดับ AA ที่ต้องเช็ก และสองข้อในนั้นเป็นของใหม่ใน WCAG 2.2 ได้แก่ สิ่งที่บอกตำแหน่งของช่อง ซึ่งปกติคือเส้นขอบ ต้องมีคอนทราสต์ 3:1 กับพื้นหลัง (1.4.11) ช่องติ๊กและเป้าหมายการกดอื่นๆ ต้องมีขนาดอย่างน้อย 24×24 CSS พิกเซล หรือเว้นระยะห่างให้พอ (2.5.8) และช่องที่กำลังโฟกัส ต้องไม่ถูกบังมิดทั้งช่อง ด้วยแถบหัวเว็บที่ติดค้างอยู่ แบนเนอร์คุกกี้ หรือหน้าต่างแชต (2.4.11) เรื่องสไตล์ของโฟกัส ดู เมนูนำทางที่เข้าถึงได้ และโฟกัสที่มองเห็นชัด

autocomplete: ให้เบราว์เซอร์พิมพ์แทน

WCAG 1.3.5 Identify Input Purpose (ระดับ AA) กำหนดให้ช่อง ที่เก็บข้อมูลส่วนตัวของผู้ใช้ ระบุจุดประสงค์ของช่องไว้ในโค้ด ซึ่งใน HTML ก็คือแอตทริบิวต์ autocomplete เบราว์เซอร์และโปรแกรมจัดการรหัสผ่าน จะได้กรอกข้อมูลที่บันทึกไว้ให้ ช่วยทั้งคนที่มีข้อจำกัด ด้านการเคลื่อนไหวหรือความจำ และทุกคนที่กรอกบนมือถือ ค่าที่ใช้ (token) มาจากรายการตายตัวในมาตรฐาน HTML และข้อผิดพลาดที่เจอก็มักซ้ำเดิม

ใช้ token เหล่านี้กับข้อมูลของผู้เข้าชมเองเท่านั้น (ช่อง “อีเมลของเพื่อนร่วมงาน” ไม่ควรเสนออีเมลของคนกรอก) ตั้งคำถามกับ autocomplete="off" ทุกจุดในฟอร์มติดต่อหรือฟอร์มจอง และตรวจ HTML ที่แสดงผลจริง ผ่านเครื่องมือตรวจสอบ (inspector) ของเบราว์เซอร์ ไม่ใช่ดูแค่หน้าตั้งค่าของตัวสร้างฟอร์ม

แจ้งข้อผิดพลาดให้รู้วิธีแก้

บอกว่าผิดอะไรและแก้อย่างไร

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

วางข้อความไว้ตรงที่คนจะเห็น

วางข้อความไว้ระหว่าง label กับช่องกรอก เพื่อให้เห็นและถูกอ่าน ก่อนถึงตัวช่อง เชื่อมด้วย aria-describedby ใส่ aria-invalid="true" ที่ช่อง ใช้สีแดงคู่กับไอคอนและคำอธิบายเสมอ และอย่าล้างสิ่งที่ผู้เข้าชมพิมพ์ไว้

<label for="email">Email address</label>
<p id="email-hint">We’ll only use this to reply to you.</p>
<p id="email-error">Enter an email address like name@example.com</p>
<input id="email" name="email" type="email" autocomplete="email"
  required aria-invalid="true" aria-describedby="email-hint email-error">

เพิ่มสรุปข้อผิดพลาดในฟอร์มยาว

ในฟอร์มที่ยาว ให้แสดงสรุปไว้ด้านบนเมื่อคนกดส่ง โดยมีหัวข้อ เช่น “พบปัญหา” แล้วตามด้วยข้อผิดพลาดแต่ละข้อ เป็นลิงก์ไปยังช่องนั้น ย้ายโฟกัสคีย์บอร์ดไปที่สรุปนี้ และถ้าหน้าโหลดใหม่ ให้ขึ้นต้นชื่อหน้า (page title) ด้วย “ข้อผิดพลาด:” แบบที่ GOV.UK ทำไว้ใน Design System ของตัวเอง

GOV.UK ยังปิดป๊อปอัปแจ้งข้อผิดพลาด ของเบราว์เซอร์ด้วย novalidate และเลือกทำเครื่องหมายที่ช่องที่ไม่บังคับ แทนการใช้ required ถ้าคุณใช้ required ให้ใส่ novalidate ด้วย เพราะป๊อปอัปเหล่านั้นปรับหน้าตาไม่ได้ หายไปตามจังหวะของเบราว์เซอร์ และมักแสดงเป็นภาษาของเบราว์เซอร์ ไม่ใช่ภาษาของหน้าเว็บ

แจ้งผลสำเร็จและสถานะให้ทุกคนรับรู้

เมื่อฟอร์มส่งโดยไม่โหลดหน้าใหม่ ผู้เข้าชมที่มองเห็นจะเห็นข้อความ “ขอบคุณ เราได้รับคำถามของคุณแล้ว” แต่ผู้ใช้โปรแกรมอ่านหน้าจอ จะไม่ได้ยินอะไรเลย ถ้าข้อความนั้นไม่ได้ทำมาให้อ่านออกเสียง ตามที่ WCAG 4.1.3 Status Messages (ระดับ AA) กำหนด มีสามรูปแบบที่ใช้ได้ผล

• หน้ายืนยัน ที่มีชื่อหน้าและหัวข้อของตัวเอง ซึ่งจะถูกอ่านออกเสียงเมื่อเปิดขึ้นมา
• live region: กล่อง role="status" ที่อยู่บนหน้าอยู่แล้ว ก่อนข้อความจะมา ถ้าใส่กล่องและข้อความเข้าไปพร้อมกัน มักจะไม่ถูกอ่านออกเสียง
• ย้ายโฟกัสไปที่หัวข้อยืนยัน ซึ่งเหมาะกับฟอร์มที่มีหลายขั้นตอน

ข้อความอัปเดตอย่าง “มีช่วงเวลาว่าง 3 ช่วง” ก็ต้องใส่ใจแบบเดียวกัน ข้อความแจ้งเตือนเล็กๆ (toast) ที่ค่อยๆ จางไป อาจหายไปก่อน ที่ผู้ใช้โปรแกรมขยายหน้าจอจะหาเจอ

ฟอร์มที่ก่อให้เกิดภาระผูกพัน ทางการเงินหรือทางกฎหมาย เช่น การจองแบบชำระเงิน ยังอยู่ภายใต้ข้อ 3.3.4 Error Prevention (กฎหมาย การเงิน ข้อมูล) ด้วย คือการส่งต้องย้อนกลับได้ ถูกตรวจหาข้อผิดพลาด หรือได้รับการยืนยันหลังขั้นตอนตรวจทาน เหมือนใน ขั้นตอนชำระเงินที่ออกแบบมาดี

ฟอร์มหลายขั้นตอน: กรอกซ้ำ เวลาจำกัด และการล็อกอิน

เกณฑ์สองในสามข้อนี้เป็นของใหม่ใน WCAG 2.2 ส่วนที่เหลือของการอัปเดตนี้ อ่านได้ใน บทอธิบาย WCAG 2.2 ของเรา

อย่าถามเรื่องเดิมซ้ำ

ตามข้อ 3.3.7 Redundant Entry ข้อมูลที่ให้ไปแล้ว ในขั้นตอนเดียวกัน ต้องถูกกรอกไว้ให้ หรือเสนอให้เลือก เช่น ช่องติ๊ก “ใช้ที่อยู่เดียวกับสถานที่จัดงาน” สำหรับที่อยู่ออกบิล หรือนำอีเมลจากขั้นแรก ไปแสดงต่อในหน้าตรวจทาน ข้อยกเว้นมีน้อยมาก ได้แก่ กรณีที่จำเป็นต้องกรอกซ้ำจริงๆ เหตุผลด้านความปลอดภัย หรือคำตอบก่อนหน้าใช้ไม่ได้แล้ว

เวลาจำกัด ต้องปรับได้

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

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

ล็อกอินโดยไม่ต้องแก้โจทย์

ถ้าลูกค้าต้องล็อกอิน เพื่อจองหรือดาวน์โหลดใบเสนอราคา ข้อ 3.3.8 Accessible Authentication (Minimum) ไม่อนุญาตขั้นตอน ที่ต้องอาศัยการทดสอบ ความสามารถทางความคิด (cognitive function test) เช่น การจำรหัสผ่าน หรือการพิมพ์ตามตัวอักษรที่บิดเบี้ยว เว้นแต่จะมีทางเลือกอื่น หรือมีกลไกที่ช่วยได้ ในทางปฏิบัติ

• อนุญาตให้วาง (paste) ในช่องรหัสผ่านและช่องรหัสยืนยัน และใช้ autocomplete="current-password" เพื่อให้โปรแกรมจัดการรหัสผ่านทำงานได้
• ถ้ารหัสใช้ครั้งเดียวถูกแบ่งเป็นช่องย่อยๆ ให้แน่ใจว่าการวาง และการกรอกอัตโนมัติ ยังเติมได้ครบทุกช่อง
• มีทางเลือกที่ไม่ต้องจำรหัสผ่าน เช่น ลิงก์ที่ส่งทางอีเมล หรือ passkey

แบบทดสอบให้จำแนกวัตถุ (“เลือกทุกภาพที่มีจักรยาน”) ผ่านในระดับ AA แต่ไม่ผ่านในเวอร์ชัน AAA คือข้อ 3.3.9 อย่างดีที่สุดก็ควรเป็นทางเลือกสุดท้าย

ทางเลือกแทน CAPTCHA ในฟอร์มติดต่อ

ปริศนาแบบภาพและแบบเสียง เป็นอุปสรรคที่มีหลักฐานชัดเจน สำหรับคนที่มีความบกพร่องทางการมองเห็น การได้ยิน หรือการรับรู้ ตามที่เอกสารของ W3C เรื่อง Inaccessibility of CAPTCHA อธิบายไว้ ทางเลือกแบบเสียง ก็ตัดคนที่ทั้งหูหนวกและตาบอดออกไป และยังใช้ยากมาก เมื่ออยู่ในที่เสียงดัง หรือเมื่อฟังในภาษาที่ไม่ใช่ภาษาแม่

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

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

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

ฟอร์มหลายภาษา: เข้าถึงได้ทุกภาษา

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

• ตั้งค่าแอตทริบิวต์ lang (3.1.1 Language of Page) เพื่อให้โปรแกรมอ่านหน้าจอออกเสียง label และข้อความแจ้งข้อผิดพลาดได้ถูกต้อง
• แปลทุกข้อความ รวมถึงคำแนะนำ ข้อผิดพลาด ข้อความสถานะ และอีเมลยืนยัน ข้อความตั้งต้นของปลั๊กอินตกหล่นได้ง่าย ถ้าไม่มี ขั้นตอนการแปลที่ชัดเจน
• รองรับรูปแบบสากล: ช่อง “ชื่อ-นามสกุล” ช่องเดียว เบอร์โทรที่มีเครื่องหมายบวก ที่อยู่ที่ไม่มีรหัสไปรษณีย์ และวันที่ที่ไม่กำกวม (03/04 หมายถึงคนละวัน ในแต่ละประเทศ)
• ให้ label ที่แปลแล้วยาวขึ้น ตัดขึ้นบรรทัดใหม่ได้ และตั้งค่า dir ให้ถูกต้อง สำหรับภาษาที่เขียนจากขวาไปซ้าย

ทดสอบด้วยคีย์บอร์ดและโปรแกรมอ่านหน้าจอ

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

ใช้คีย์บอร์ดอย่างเดียว

1. วางเมาส์ไว้ก่อน แล้วกด Tab ไล่ไปทั่วฟอร์ม โฟกัสควรไล่ตามลำดับที่สมเหตุสมผล และมองเห็นได้ตลอด
2. ใช้ปุ่มลูกศรในกลุ่มปุ่มตัวเลือก กด Space เพื่อติ๊กช่อง และกด Enter เพื่อส่ง
3. ส่งฟอร์มโดยเว้นช่องบังคับไว้หนึ่งช่อง และกรอกอีกช่องผิด ข้อผิดพลาดควรขึ้นเป็นคำอธิบายข้างแต่ละช่อง และสิ่งที่คุณพิมพ์ไว้ต้องไม่หายไป

ใช้โปรแกรมอ่านหน้าจอ

ใช้ VoiceOver (มีในเครื่อง Mac และ iPhone) NVDA (ใช้ฟรีบน Windows) หรือ TalkBack (Android)

1. กด Tab ไล่อีกรอบ ทุกช่องควรอ่านออกมาทั้ง label ประเภทของช่อง ว่าเป็นช่องบังคับหรือไม่ และคำแนะนำถ้ามี
2. ทำให้เกิดข้อผิดพลาด แล้วแก้ไข ข้อผิดพลาดควรถูกอ่านออกมา แล้วหยุดแจ้งเมื่อแก้แล้ว
3. ส่งฟอร์ม ข้อความยืนยันควรถูกอ่านออกมา

ใช้การซูม กรอกอัตโนมัติ และเสียง

1. ซูมหน้าต่างเบราว์เซอร์บนเดสก์ท็อป ที่กว้างประมาณ 1,280 พิกเซล ไปที่ 400% label คำแนะนำ และข้อผิดพลาดควรอยู่ติดกับช่องของมัน โดยไม่ต้องเลื่อนไปด้านข้าง (1.4.10 Reflow)
2. บนมือถือ ลองกรอกข้อมูลของคุณด้วยการกรอกอัตโนมัติ ทุกค่าควรลงในช่องที่ถูกต้อง
3. ใช้การสั่งงานด้วยเสียง พูดว่า “คลิก” (หรือ “แตะ” บน iPhone) ตามด้วยชื่อ label ช่องที่ถูกต้องควรตอบสนอง

ขั้นตอนต่อไป

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

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