Web Accessibility คืออะไร? อธิบาย WCAG และการออกแบบเพื่อทุกคน

Web accessibility หมายถึงการสร้างเว็บไซต์และแอปให้คนที่มีความพิการใช้งานได้ ไม่ว่าจะตาบอดและใช้โปรแกรมอ่านหน้าจอ ใช้เมาส์ไม่ได้ มีสายตาเลือนรางหรือตาบอดสี หูหนวก หรือมีความพิการทางการรับรู้หรือการเรียนรู้ ในทางปฏิบัติมันหมายถึงสิ่งต่างๆ เช่น ข้อความอธิบายแทนรูปภาพ ความคมชัดของสีที่เพียงพอ ฟอร์มที่มีป้ายกำกับถูกต้อง และทุกอย่างทำงานได้ด้วยคีย์บอร์ดเพียงอย่างเดียว มาตรฐานสากลของเรื่องนี้คือ WCAG (Web Content Accessibility Guidelines) จาก W3C

คำว่า accessibility มักย่อเป็น a11y คือ "a" ตามด้วยตัวอักษรอีก 11 ตัวแล้วจบด้วย "y"

ทำไม accessibility จึงสำคัญเมื่อสร้างด้วย AI

AI builder เก่งในการสร้างแอปที่ ดูถูกต้อง แต่ accessibility ส่วนใหญ่เป็นสิ่งที่มองไม่เห็นในภาพหน้าจอ เช่น ปุ่มที่เป็นปุ่มจริงหรือไม่ ช่องกรอกมีป้ายกำกับที่โปรแกรมอ่านหน้าจอประกาศได้หรือไม่ และเปิดเมนูได้ด้วยปุ่ม Tab หรือไม่

นี่คือเหตุผลที่ควรถาม:

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

ตัวอย่างเปรียบเทียบในชีวิตประจำวัน

ลองนึกถึงทางเข้าอาคาร

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

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

WCAG โดยสังเขป

WCAG เผยแพร่โดย Web Accessibility Initiative ของ W3C เวอร์ชันปัจจุบันคือ WCAG 2.2 ที่เผยแพร่ครั้งแรกในเดือนตุลาคม 2023 มันเข้ากันได้ย้อนหลัง คือเนื้อหาที่เป็นไปตาม WCAG 2.2 ก็เป็นไปตาม 2.1 และ 2.0 ด้วย และ W3C แนะนำให้ใช้เวอร์ชันล่าสุด WCAG 2.2 ยังได้รับการรับรองเป็นมาตรฐานสากล ISO/IEC 40500:2025 ส่วน WCAG 3 ที่แตกต่างกันมากกำลังพัฒนาเป็นร่างเบื้องต้น ยังไม่ใช่มาตรฐานที่สมบูรณ์

WCAG จัดระเบียบภายใต้หลักการสี่ข้อ ซึ่งมักจำได้ว่า POUR:

เกณฑ์แต่ละข้อมีเกณฑ์ความสำเร็จที่ทดสอบได้ใน 3 ระดับ:

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

WCAG 2.2 เพิ่มเกณฑ์ความสำเร็จเก้าข้อจาก 2.1 รวมถึง Target Size (Minimum) ในระดับ AA ซึ่งกำหนดว่าเป้าหมายที่คลิกได้ควรมีขนาดอย่างน้อย 24 x 24 พิกเซล CSS โดยมีข้อยกเว้น และ Accessible Authentication (Minimum) ซึ่งจำกัดขั้นตอนการล็อกอินที่ต้องพึ่งความจำหรือปริศนา เช่น ต้องพิมพ์รหัสผ่านซ้ำโดยไม่อนุญาตให้วาง นอกจากนี้ยังลบเกณฑ์ "Parsing" เดิมออกเพราะล้าสมัยแล้ว

ตัวอย่างจริง: แบบฟอร์มสมัครสมาชิก

นี่คือแบบฟอร์มสมัครสมาชิกที่ AI อาจสร้าง และสิ่งที่การตรวจ accessibility พบ:

การแก้ไขเหล่านี้แทบไม่เปลี่ยนรูปลักษณ์ของฟอร์ม แต่ทั้งหมดเปลี่ยนว่าบางคนใช้งานฟอร์มนี้ได้หรือไม่เลย

คำศัพท์ที่ควรรู้

ข้อผิดพลาดที่พบบ่อยและความเข้าใจผิด

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

สิ่งที่ควรขอจาก AI builder

• "สร้างสิ่งนี้ให้เป็นไปตาม WCAG 2.2 ระดับ AA"
• "ใช้ HTML เชิงความหมาย: ปุ่มและลิงก์จริง หัวข้อเรียงลำดับ และป้ายกำกับสำหรับทุกช่องกรอกในฟอร์ม"
• "ทำให้องค์ประกอบโต้ตอบทุกอันทำงานด้วยคีย์บอร์ดเพียงอย่างเดียว และมีสไตล์โฟกัสที่มองเห็นได้"
• "ตรวจความคมชัดของสีตัวอักษรและไอคอนทั้งหมด: 4.5:1 สำหรับตัวอักษรปกติ และ 3:1 สำหรับตัวอักษรขนาดใหญ่และไอคอน"
• "เพิ่ม alt text ที่มีความหมายให้รูปภาพที่ให้ข้อมูล และ alt ว่างให้รูปตกแต่ง"
• "แสดงข้อผิดพลาดของฟอร์มเป็นข้อความ เชื่อมกับช่องกรอก ไม่ใช่แค่ด้วยสี"
• "เคารพการตั้งค่าลดการเคลื่อนไหว (reduced motion) ของผู้ใช้สำหรับแอนิเมชัน"
• "รันการตรวจ accessibility อัตโนมัติและบอกรายการที่มันตรวจไม่ได้ เพื่อให้ฉันตรวจด้วยตนเอง"

จากนั้นทดสอบด้วยตัวคุณเอง: วางเมาส์ไว้ก่อน แล้วลองทำขั้นตอนหลักให้สำเร็จด้วย Tab, Shift+Tab, Enter และ Space เท่านั้น ลองใช้โปรแกรมอ่านหน้าจอที่มาในโทรศัพท์ของคุณกับหน้าหลัก ซูมเบราว์เซอร์เป็น 200% และดูว่ามีอะไรพังหรือไม่

Accessibility ใน Mythex

Mythex ไม่มีเครื่องมือตรวจ accessibility โดยเฉพาะ ดังนั้นให้ถือว่า accessibility เป็นส่วนหนึ่งของพรอมต์และการทดสอบของคุณ ขอ WCAG 2.2 AA ตั้งแต่พรอมต์แรก ตรวจผลลัพธ์ใน Preview ด้วยคีย์บอร์ด และใช้ /test เพื่อให้ agent คลิกผ่านขั้นตอนหลักก่อนเผยแพร่ ดู App Testing สูตร SEO ยังขอหัวข้อเชิงความหมายและ alt text ที่มีความหมาย ซึ่งรับใช้เป้าหมายทั้งสองด้วยกัน

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

คำถาม