เว็บที่ทุกคนใช้ได้: เริ่มต้นกับ Accessibility และมาตรฐาน WCAG

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

Accessibility คือเรื่องของลูกค้า ไม่ใช่แค่ความถูกต้อง

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

มาตรฐานสากลของเรื่องนี้คือ WCAG (Web Content Accessibility Guidelines) จัดทำโดย W3C Web Accessibility Initiative โดยเวอร์ชันปัจจุบันคือ WCAG 2.2 แบ่งระดับความสอดคล้องเป็น A, AA และ AAA ซึ่งระดับ AA คือเป้าหมายมาตรฐานที่กฎหมายและหน่วยงานหลายประเทศรวมถึงแนวทางภาครัฐไทยใช้อ้างอิง

หลักการ POUR: กรอบคิดหลักของ WCAG

WCAG จัดข้อกำหนดทั้งหมดใต้ 4 หลักการ ย่อว่า POUR ได้แก่ Perceivable (รับรู้ได้ เช่น รูปภาพต้องมีข้อความอธิบาย), Operable (ใช้งานได้ เช่น ทุกอย่างต้องทำได้ด้วยแป้นพิมพ์), Understandable (เข้าใจได้ เช่น ฟอร์มมีคำแนะนำและข้อความ error ชัดเจน) และ Robust (แข็งแรง คือทำงานได้กับเทคโนโลยีช่วยเหลืออย่าง Screen Reader)

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

5 ปัญหายอดฮิตที่แก้ได้เร็ว

ผลสำรวจหน้าเว็บยอดนิยมนับล้านหน้าโดยโครงการ WebAIM Million พบปัญหาซ้ำ ๆ เดิมทุกปี ได้แก่ (1) สีตัวอักษรกับพื้นหลังคอนทราสต์ต่ำ ซึ่ง WCAG AA กำหนดอัตราส่วนอย่างน้อย 4.5:1 สำหรับข้อความปกติ (2) รูปภาพไม่มี alt text (3) ฟอร์มไม่มี label ผูกกับช่องกรอก (4) ลิงก์เขียนแค่ "คลิกที่นี่" ที่ไม่สื่อปลายทาง และ (5) เอกสารไม่ประกาศภาษา (lang) ทำให้ Screen Reader อ่านออกเสียงผิด

ทั้งห้าข้อใช้เวลาแก้น้อยมากเมื่อเทียบกับผลที่ได้ เริ่มจากใช้เครื่องมือตรวจคอนทราสต์ตอนเลือกสีแบรนด์, ตั้งกติกาว่า input ทุกช่องต้องมี label และรูปสื่อความหมายทุกรูปต้องมี alt ที่บรรยายสาระ (ส่วนรูปตกแต่งใช้ alt ว่างเปล่า) เท่านี้ก็หนีปัญหาส่วนใหญ่ที่เว็บทั่วไปเจอแล้ว

ใช้ HTML ให้ถูกความหมาย ก่อนพึ่ง ARIA

ความลับที่นักพัฒนามักมองข้ามคือ HTML เชิงความหมาย (Semantic HTML) ให้ Accessibility ฟรีมหาศาล ปุ่มใช้ <button> ไม่ใช่ <div> ติด onclick เพราะ button ได้การโฟกัสด้วยแป้นพิมพ์ กด Enter/Space ได้ และประกาศตัวเองต่อ Screen Reader โดยอัตโนมัติ เช่นเดียวกับการใช้ heading ไล่ระดับถูกต้องและ landmark อย่าง <nav>, <main> ที่ช่วยให้ผู้ใช้ Screen Reader กระโดดไปส่วนต่าง ๆ ได้เร็ว

ATTRIBUTE กลุ่ม ARIA มีไว้เสริมเมื่อ HTML ธรรมดาไม่พอ เช่น ประกาศสถานะของคอมโพเนนต์ที่ซับซ้อน แต่กฎข้อแรกของ ARIA ที่ W3C ย้ำเองคือ "อย่าใช้ ARIA ถ้ามี HTML ที่ทำหน้าที่นั้นอยู่แล้ว" เพราะ ARIA ที่ใช้ผิดสร้างประสบการณ์ที่แย่กว่าไม่ใช้เสียอีก

ทดสอบอย่างไร และฝังเข้ากระบวนการทีมอย่างไร

เริ่มจากเครื่องมืออัตโนมัติอย่าง Lighthouse หรือ axe DevTools ซึ่งตรวจจับปัญหาได้ราว 30-40% ของทั้งหมด ที่เหลือต้องทดสอบด้วยมือ สองการทดสอบที่คุ้มค่าที่สุดคือ ลองใช้ทั้งเว็บด้วยแป้นพิมพ์อย่างเดียว (Tab ไล่ลำดับสมเหตุสมผลไหม เห็นกรอบโฟกัสไหม) และลองเปิด Screen Reader ที่มากับระบบปฏิบัติการฟังหน้าเว็บของตัวเอง

ระยะยาว ให้กำหนดเกณฑ์ WCAG 2.2 ระดับ AA ไว้ใน Definition of Done, เพิ่มการตรวจอัตโนมัติเข้า CI และตรวจงานออกแบบตั้งแต่ขั้น Mockup เช่น คอนทราสต์สีและลำดับโฟกัส เพราะการแก้ตั้งแต่ต้นถูกกว่าตามแก้ทีหลังหลายเท่า Accessibility ที่ยั่งยืนไม่ใช่โครงการกวาดล้างครั้งใหญ่ปีละหน แต่คือมาตรฐานเล็ก ๆ ที่ทำทุกสปรินต์