World Usability Day 2026: ทดสอบเว็บไทยใน 15 นาทีด้วย Tab + NVDA

บทนำ: 15 นาทีที่จะเปลี่ยนวิธีมองเว็บของตัวเอง

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

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

World Usability Day 2026 ตรงกับวันพฤหัสบดีที่ 12 พฤศจิกายน 2026 ซึ่งเป็นวันพฤหัสบดีที่สองของเดือนพฤศจิกายน หัวข้อในปีนี้คือ Designing a Sustainable Future with Ethical AI หรือการออกแบบอนาคตที่ยั่งยืนด้วย AI ที่มีจริยธรรม บทความนี้จึงไม่ได้ชวนให้กลัว AI แต่ชวนให้ทดสอบด้วยมือของเราเองก่อนว่า AI ที่เราใส่เพิ่มเข้าไป ช่วยให้คนใช้งานได้ง่ายขึ้นจริง หรือกำลังสร้างกำแพงใหม่โดยไม่รู้ตัว

ทำไมต้องทดสอบด้วย Tab และ NVDA

คีย์บอร์ดคือเส้นชีวิต ไม่ใช่ทางเลือกเสริม

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

แนวทาง WCAG 2.2 กำหนดหลักการพื้นฐานไว้ชัดเจน ข้อ 2.1.1 Keyboard ระดับ A กำหนดว่าฟังก์ชันทั้งหมดต้องใช้งานผ่านคีย์บอร์ดได้ ส่วนข้อ 2.4.7 Focus Visible ระดับ AA กำหนดว่าต้องเห็นได้ว่าตอนนี้โฟกัสอยู่ที่องค์ประกอบใด และ WCAG 2.2 ยังมีข้อ 2.4.11 Focus Not Obscured ที่กำหนดว่าเมื่อองค์ประกอบได้รับโฟกัสแล้ว ต้องไม่ถูกบังจนมองไม่เห็น เช่น ถูกแถบด้านบนแบบติดค้างหรือแบนเนอร์คุกกี้บังจนหมด

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

NVDA คืออะไร และ Web Rotor ในบทความนี้หมายถึงอะไร

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

ต้องทำความเข้าใจคำศัพท์ให้ตรงกันก่อน คำว่า Rotor เป็นชื่อฟีเจอร์ของ VoiceOver บนอุปกรณ์ของ Apple ส่วน NVDA ไม่มีฟีเจอร์ชื่อ Rotor โดยตรง แต่มีฟีเจอร์ที่ทำหน้าที่คล้ายกันคือ Elements List หรือรายการองค์ประกอบ เปิดด้วยปุ่ม NVDA + F7 ในบทความนี้ เมื่อพูดว่า Web Rotor จึงหมายถึงวิธีคิดแบบเดียวกัน คือ แทนที่จะอ่านเว็บจากบนลงล่างทีละบรรทัด ให้กระโดดดูโครงสร้างของเว็บเป็นกลุ่ม ๆ เช่น ดูเฉพาะหัวข้อ ดูเฉพาะลิงก์ ดูเฉพาะปุ่ม หรือดูเฉพาะแลนด์มาร์ก

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

เตรียมตัวก่อนเริ่ม: 5 นาทีที่ห้ามข้าม

เลือกเว็บและงานที่สมจริงที่สุด

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

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

ตั้งค่า NVDA แบบพื้นฐาน

ดาวน์โหลด NVDA จากเว็บไซต์ทางการของ NV Access แล้วติดตั้งหรือเลือกใช้งานแบบชั่วคราวโดยไม่ต้องติดตั้งถาวรก็ได้ตามตัวเลือกที่โปรแกรมมีให้ ปุ่ม NVDA โดยทั่วไปคือปุ่ม Insert หรือ Caps Lock ขึ้นอยู่กับการตั้งค่า ถ้าใช้โน้ตบุ๊กแล้วปุ่ม Insert ใช้งานลำบาก ให้ตรวจสอบการตั้งค่าแป้นพิมพ์ของ NVDA ก่อนเริ่ม

ฝึกปุ่มพื้นฐานไม่กี่ปุ่มก็พอ ไม่ต้องจำทุกคำสั่ง ปุ่มที่จำเป็นที่สุดคือ Tab เพื่อเลื่อนไปข้างหน้า Shift + Tab เพื่อย้อนกลับ Enter หรือ Space เพื่อเปิดใช้งานปุ่มและลิงก์ Esc เพื่อปิดกล่องโต้ตอบหรือเมนู และ NVDA + F7 เพื่อเปิด Elements List ส่วนในโหมดอ่านเว็บหรือ Browse Mode ปุ่มตัวอักษรอย่าง H สำหรับหัวข้อถัดไป K สำหรับลิงก์ถัดไป B สำหรับปุ่มถัดไป และ D สำหรับแลนด์มาร์กถัดไป จะช่วยให้กระโดดดูโครงสร้างได้เร็วขึ้น

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

โปรโตคอล 15 นาที: ทดสอบเว็บไทยทีละขั้น

นาทีที่ 0-3: ทดสอบด้วย Tab อย่างเดียว

วางเมาส์ลง แล้วกด Tab จากด้านบนสุดของหน้าเว็บ สังเกตสิ่งต่อไปนี้

• มีลิงก์ข้ามไปยังเนื้อหาหลักหรือ Skip to main content ตั้งแต่ต้นหรือไม่ ถ้าไม่มี ผู้ใช้คีย์บอร์ดจะต้องกด Tab ผ่านเมนูทั้งหมดทุกครั้งที่เปลี่ยนหน้า
• ลำดับโฟกัสสมเหตุสมผลหรือไม่ โฟกัสควรไหลตามลำดับที่ตาเห็น ไม่ใช่กระโดดจากเมนูบนไปท้ายเว็บแล้วค่อยกลับมาที่เนื้อหากลางหน้า
• เห็นกรอบโฟกัสชัดเจนหรือไม่ ถ้ากรอบโฟกัสจางจนมองไม่เห็น หรือถูกแถบด้านบนบังจนหมด ถือว่าเป็นปัญหา
• ปุ่ม เมนู ช่องค้นหา และกล่องเลือกต่าง ๆ เข้าถึงด้วย Tab ได้ครบหรือไม่ ถ้ามีส่วนที่คลิกด้วยเมาส์ได้แต่ Tab ไปไม่ถึง ให้จดไว้เป็นปัญหาระดับวิกฤต
• มีกับดักคีย์บอร์ดหรือไม่ เช่น กด Tab เข้าไปในปฏิทิน เมนู หรือวิดีโอแล้วออกมาไม่ได้ ถ้าออกไม่ได้ ให้ถือว่าเป็นปัญหาที่ต้องแก้ทันที

เมื่อเจอจุดที่สงสัย ให้ลองกด Enter และ Space ทั้งสองแบบ เพราะปุ่มบางประเภทตอบสนองต่อปุ่มใดปุ่มหนึ่งเท่านั้นในทางปฏิบัติ และลองกด Esc เพื่อดูว่ากล่องโต้ตอบหรือเมนูปิดได้หรือไม่ แล้วโฟกัสกลับไปอยู่ตรงจุดเดิมอย่างสมเหตุสมผลหรือเปล่า

นาทีที่ 3-8: เปิด NVDA แล้วฟังโครงสร้างเว็บ

เปิด NVDA แล้วกลับไปที่ด้านบนของหน้าเว็บอีกครั้ง อย่าเพิ่งฟังทุกคำ ให้ใช้วิธีสแกนโครงสร้างก่อน

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

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

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

นาทีที่ 8-12: ใช้ Elements List ตรวจภาพรวมทั้งหน้า

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

วิธีนี้เหมาะมากสำหรับเว็บไทย เพราะจะเห็นปัญหาที่ซ่อนอยู่ทันที เช่น

สิ่งที่เห็นใน Elements List	แปลว่าอะไร	ควรทำอย่างไร
หัวข้อซ้ำกันจำนวนมาก	โครงสร้างหน้าไม่ชัด ผู้ใช้สแกนไม่เจอจุดสำคัญ	ตรวจลำดับหัวข้อและข้อความหัวข้อให้สื่อความหมาย
ลิงก์ชื่อ อ่านเพิ่มเติม ซ้ำกันหลายอัน	ผู้ใช้ไม่รู้ว่าแต่ละลิงก์พาไปไหน	ใส่ชื่อลิงก์ให้เฉพาะเจาะจงตามปลายทาง
ปุ่มชื่อว่า ปุ่ม หรือไม่มีชื่อ	โปรแกรมอ่านหน้าจอประกาศชื่อไม่ได้	ใส่ชื่อปุ่มที่บอกหน้าที่ของปุ่มให้ชัดเจน
ช่องกรอกไม่มีป้ายกำกับ	ผู้ใช้ไม่รู้ว่าต้องกรอกอะไร	ผูกป้ายกำกับกับช่องกรอกทุกช่อง
แลนด์มาร์กไม่มีหรือมีแต่ main ซ้ำกัน	ผู้ใช้กระโดดไปส่วนต่าง ๆ ไม่ได้	กำหนด nav main search และ footer ให้ถูกต้อง

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

นาทีที่ 12-15: ทดสอบงานจริงจนจบหนึ่งงาน

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

จดบันทึกแบบสั้นแต่ใช้งานได้จริง ใช้รูปแบบนี้ทุกครั้ง

• งานที่ทดสอบคืออะไร
• ติดที่ขั้นตอนไหน
• เกิดอะไรขึ้นเมื่อใช้ Tab หรือ NVDA
• คาดหวังว่าจะเกิดอะไรขึ้น
• ระดับความรุนแรงคือ วิกฤต ใช้งานได้แต่ลำบาก หรือควรปรับปรุง

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

ปัญหาที่เจอบ่อยในเว็บไทย และวิธีแก้แบบไม่ต้องรื้อเว็บใหม่

เมนูและกล่องโต้ตอบที่ขังผู้ใช้ไว้

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

ฟอร์มภาษาไทยที่อ่านไม่รู้เรื่อง

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

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

ลิงก์และปุ่มที่ชื่อไม่สื่อความหมาย

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

ภาพ แบนเนอร์ และวิดีโอที่ไม่มีคำอธิบาย

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

ก่อนใส่ AI เพิ่ม: ถาม 5 ข้อให้จบก่อนเขียนโค้ด

หัวข้อ World Usability Day 2026 พูดถึง AI ที่มีจริยธรรมและความยั่งยืน ในทางปฏิบัติ คำถามที่สำคัญที่สุดไม่ใช่ AI ฉลาดแค่ไหน แต่คือ AI ช่วยให้คนใช้งานได้จริงหรือไม่ ลองตอบคำถาม 5 ข้อนี้ก่อนเพิ่มฟีเจอร์ AI ทุกครั้ง

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

หลักคิดง่าย ๆ คือ AI ควรเป็นทางลัด ไม่ใช่ประตูบานใหม่ที่ทุกคนต้องผ่านให้ได้ก่อนถึงจะใช้งานเว็บได้ ถ้าผู้ใช้ไม่ต้องการ AI ก็ควรใช้งานเว็บเดิมได้ครบเหมือนเดิม

ข้อควรระวัง: การทดสอบ 15 นาทีบอกอะไร และบอกอะไรไม่ได้

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

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

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

เช็กลิสต์ส่งต่อให้ทีมภายในหนึ่งหน้า

ถ้าต้องส่งต่อให้ทีมพัฒนา ทีมออกแบบ หรือทีมคอนเทนต์ ให้ใช้เช็กลิสต์นี้เป็นภาษาเดียวกัน

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

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

สรุป: เริ่มจากมือของผู้ใช้ ไม่ใช่เริ่มจากฟีเจอร์ใหม่

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

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

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

แหล่งข้อมูลอ้างอิง

• World Usability Day — UXPA International
• NVDA — Download NVDA จาก NV Access
• W3C — Web Content Accessibility Guidelines (WCAG) 2.2