การตรวจการเข้าถึง เครื่องมือตรวจอัตโนมัติ และ overlay: แต่ละแบบบอกอะไรได้

ถ้าถามว่า “เว็บไซต์ของเราเข้าถึงได้สำหรับทุกคนไหม?” คุณจะได้คำตอบ 3 แบบที่ต่างกันมาก ได้แก่ เครื่องมือตรวจฟรีที่ให้คะแนนภายในไม่กี่วินาที การตรวจการเข้าถึงเว็บไซต์ (accessibility audit) ที่มีคนทดสอบหน้าเว็บของคุณตาม WCAG ด้วยมือ และวิดเจ็ตที่สัญญาว่าจะทำให้ผ่านมาตรฐานได้ด้วยโค้ดบรรทัดเดียว

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

คำตอบสั้น ๆ

• เครื่องมือตรวจอัตโนมัติ อย่าง axe, WAVE และ Lighthouse ใช้ฟรีและเร็ว จับข้อผิดพลาดที่เครื่องทดสอบได้ เช่น ไม่มี alt attribute หรือคอนทราสต์ต่ำ แต่ WCAG หลายข้อต้องใช้วิจารณญาณของคน ผลสแกนที่ไม่พบปัญหาจึงไม่ได้แปลว่าเว็บไซต์เข้าถึงได้
• การตรวจด้วยมือ ทดสอบหน้าและเส้นทางสำคัญ ตาม WCAG 2.2 ระดับ AA ด้วยคีย์บอร์ด โปรแกรมอ่านหน้าจอ และการซูม เป็นวิธีเดียวในสามแบบที่บอกได้ว่าเว็บไซต์ผ่านมาตรฐานหรือไม่
• วิดเจ็ต overlay เพิ่มแถบเครื่องมือไว้บนหน้าเว็บ ไม่ได้ซ่อมโค้ด อาจขัดกับเทคโนโลยีช่วยเหลือที่ผู้เข้าชมใช้อยู่เอง และคำกล่าวอ้างเรื่องการผ่านมาตรฐานที่ทำให้เข้าใจผิด ก็เคยถูกหน่วยงานกำกับดูแลเอาผิดมาแล้ว

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

เครื่องมือตรวจอัตโนมัติ: เร็ว ฟรี แต่ไม่ครบ

เครื่องมือตรวจการเข้าถึงที่รู้จักกันดีเริ่มใช้ได้ฟรี axe DevTools คือส่วนขยายเบราว์เซอร์ของ Deque ที่สร้างบนเอนจินโอเพนซอร์ส axe-core WAVE จาก WebAIM วางไอคอนของแต่ละปัญหาไว้บนหน้าเว็บโดยตรง Lighthouse ในเครื่องมือนักพัฒนาของ Chrome และใน PageSpeed Insights ใช้ axe-core ในการตรวจการเข้าถึง

สิ่งที่เครื่องมือจับได้แน่นอน

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

สิ่งที่เครื่องมือตัดสินไม่ได้

เครื่องมือตรวจยืนยันได้ว่ามี alt text อยู่ แต่ยืนยันไม่ได้ว่า alt text นั้นอธิบายภาพได้จริง และยังบอกไม่ได้ว่า:

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

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

อ่านผลลัพธ์เป็นรายการสิ่งที่ต้องทำ

ให้ถือว่า error คือสิ่งที่ต้องแก้ และคะแนนคือตัววัดความคืบหน้า ไม่ใช่คำตัดสิน จากนั้นไล่ทำสิ่งที่เครื่องมือทิ้งไว้ให้คนตัดสิน ได้แก่ alert ของ WAVE รายการ “needs review” ของ axe และรายการตรวจด้วยมือที่ Lighthouse แสดงไว้ใต้คะแนน

การตรวจการเข้าถึงด้วยมือครอบคลุมอะไร

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

ขอบเขต และกลุ่มตัวอย่าง

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

คีย์บอร์ด

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

ทดสอบด้วยโปรแกรมอ่านหน้าจอ

ผู้ทดสอบใช้คู่ที่พบบ่อย ได้แก่ NVDA หรือ JAWS บน Windows, VoiceOver กับ Safari บน Mac หรือ iPhone และ TalkBack บน Android แล้วฟังว่าโครงหัวข้อสมเหตุสมผลไหม มี landmark ไหม ข้อความลิงก์เข้าใจได้แม้อยู่นอกบริบทไหม ช่องกรอกมีป้ายกำกับไหม ข้อผิดพลาดถูกอ่านออกเสียงไหม และปุ่มบอกสถานะของตัวเองไหม เช่น “expanded” (ขยายอยู่)

ซูม การจัดเรียงใหม่ และระยะห่าง

ที่ขนาดตัวอักษร 200% ต้องไม่มีอะไรถูกตัด ที่การซูม 400% ในหน้าต่างกว้าง 1,280 พิกเซล (เท่ากับ viewport กว้าง 320 พิกเซล CSS) เนื้อหาควรจัดเรียงใหม่เป็นคอลัมน์เดียว โดยไม่ต้องเลื่อนไปด้านข้าง และการเพิ่มระยะห่างระหว่างบรรทัด ตัวอักษร และคำ ต้องไม่ทำให้เลย์เอาต์พัง

เนื้อหา สื่อ และฟอร์ม

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

การตรวจนี้ทดสอบการผ่านมาตรฐาน ไม่ใช่ความง่ายในการใช้งาน การทดสอบการใช้งาน (usability testing) หรือ การตรวจ UX ของเว็บไซต์ ตอบคำถามที่เกี่ยวข้องนั้น

Overlay: ทำไมวิดเจ็ตจึงแก้เว็บไซต์ไม่ได้

Overlay คือสคริปต์ภายนอก มักเป็นไอคอนลอยที่เปิดแถบเครื่องมือสำหรับขยายตัวอักษร โหมดคอนทราสต์ หรือแถบช่วยอ่าน หลายตัวยังพยายามซ่อมอัตโนมัติระหว่างที่หน้าโหลด เช่น เดาป้ายกำกับของช่องกรอก หรือสร้าง alt text

ทำไม overlay จึงไม่พอ

• โค้ดข้างใต้ไม่ได้เปลี่ยน การแปะแก้ตอนหน้าโหลดแก้ได้แค่สิ่งที่สคริปต์เดาถูก ฟอร์มที่กรอกด้วยคีย์บอร์ดไม่ได้ก็ยังพังอยู่
• ผู้เข้าชมมีเครื่องมือของตัวเอง คนที่ต้องการตัวอักษรใหญ่ คอนทราสต์สูง หรือเสียงอ่าน มักตั้งค่าไว้บนอุปกรณ์ของตัวเองแล้ว แถบเครื่องมือของเว็บไซต์จึงซ้ำกับการตั้งค่าเหล่านั้น หรือไม่ก็ขัดกัน
• Overlay อาจเพิ่มอุปสรรค แผงของ overlay เองก็ต้องเข้าถึงได้ด้วย มันเพิ่มจุดแวะในลำดับการกด Tab และสิ่งที่ overlay เปลี่ยนอาจทับสิ่งที่โปรแกรมอ่านหน้าจอจะอ่านออกเสียงตามปกติ
• เป็นสคริปต์อีกตัวในทุกหน้า เหมือน สคริปต์ภายนอก อื่น ๆ overlay เพิ่มเวลาโหลด และเพิ่มสิ่งที่ต้องพึ่งพา ซึ่งคุณควบคุมไม่ได้
• คำกล่าวอ้างไม่เป็นจริง ในปี 2025 คณะกรรมาธิการการค้าแห่งสหพันธรัฐของสหรัฐฯ (FTC) สั่งให้ผู้ให้บริการ overlay รายหนึ่งจ่ายเงิน 1 ล้านดอลลาร์สหรัฐ จากการกล่าวอ้างว่าเครื่องมือ AI ของตนทำให้เว็บไซต์ใดก็ได้ผ่าน WCAG และการติดตั้ง overlay ก็ไม่ได้ช่วยให้ธุรกิจรอดจากการถูกฟ้องเรื่องเว็บไซต์ที่เข้าถึงไม่ได้

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

วิธีทดสอบการเข้าถึงเว็บไซต์ใน 30 นาที

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

1. รันเครื่องมือตรวจ (5 นาที)

รัน WAVE หรือ axe DevTools ในแต่ละหน้า แล้วจด error ไว้ error ที่ปรากฏในทุกหน้ามักอยู่ในส่วนหัว ส่วนท้าย หรือธีม แก้ครั้งเดียวก็หายทุกหน้า

2. เก็บเมาส์ (10 นาที)

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

3. ซูมเข้า (5 นาที)

• ที่การซูม 200% ไม่มีข้อความถูกตัดหรือซ่อน
• ที่การซูม 400% โดยหน้าต่างกว้างประมาณ 1,280 พิกเซล ข้อความจัดเรียงใหม่ โดยไม่ต้องเลื่อนไปด้านข้าง

4. ฟัง (7 นาที)

บน Mac เปิด VoiceOver (Command + F5) แล้วใช้ Safari บน Windows ติดตั้ง NVDA ซึ่งเป็นโปรแกรมอ่านหน้าจอฟรี

• หัวข้อเรียงเป็นโครงที่สมเหตุสมผล (VoiceOver: กด Control + Option + U เพื่อเปิด rotor แล้วกดลูกศรไปที่ Headings ส่วน NVDA: กด H เพื่อกระโดดระหว่างหัวข้อ)
• ปุ่มและลิงก์มีชื่อที่มีความหมาย ไม่ใช่แค่ “ปุ่ม” หรือ “ลิงก์”
• ช่องกรอกในฟอร์มถูกอ่านออกเสียงพร้อมป้ายกำกับ และข้อผิดพลาดถูกอ่านออกมาด้วย

5. อ่านแบบผู้เข้าชม (3 นาที)

• ภาพที่มีความหมาย มี alt text ที่บอกว่าภาพแสดงอะไร
• ข้อความลิงก์บอกว่าลิงก์ไปที่ไหน ไม่ใช่แค่ “อ่านต่อ”
• วิดีโอมีคำบรรยายที่ถูกต้อง และข้อความบนภาพถ่ายอ่านง่าย

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

รายงานการตรวจที่มีประโยชน์ ต้องมีอะไร

รายงานที่ดี ทำให้นักพัฒนาแก้แต่ละปัญหาได้ โดยไม่ต้องโทรถามเพิ่ม ทุกสิ่งที่พบต้องมี:

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

จัดลำดับ แก้ที่ต้นเหตุ แล้วทดสอบซ้ำ

จัดลำดับตามผลกระทบ

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

แก้ปัญหาที่ต้นเหตุ

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

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

ทดสอบซ้ำ และตรวจต่อเนื่อง

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

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

คำถามที่พบบ่อย

คะแนน accessibility 100 ใน Lighthouse เพียงพอไหม?

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

ควรทดสอบการเข้าถึงเว็บไซต์บ่อยแค่ไหน?

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

ต้องทดสอบกับผู้ใช้ที่มีความพิการด้วยไหม?

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

ตรวจเว็บไซต์ของเราเองได้ไหม?

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

ขั้นตอนถัดไป

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

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