เจาะประเด็น
Accessibility
ผ่านบอตตรวจ alt text ไม่ได้แปลว่าคนตาบอดอ่านแล้วเข้าใจจริง
GitHub สร้างปลั๊กอินใหม่ที่ทดสอบ alt text ในแบบที่เครื่องมือตรวจสอบอัตโนมัติทั่วไปทำไม่ได้
ทีมข่าว เอไอไทย.com
⏱ อ่าน 4 นาที
เครื่องมืออัตโนมัติตรวจได้แค่ "มี alt text หรือไม่" แต่ไม่มีทางรู้ว่า alt text นั้น "ดีพอหรือไม่" — แล้วเราจะแก้ช่องโหว่นี้ยังไง?
เราคุ้นเคยกันดีกับคำว่า alt text หรือข้อความทดแทนสำหรับรูปภาพ — เวลาที่เมาส์ไปชี้ที่รูปแล้วมีกล่องข้อความโผล่ขึ้นมา หรือเวลาที่รูปโหลดไม่ขึ้นแล้วเห็นข้อความแทนที่ นั่นแหละ alt text แต่หน้าที่จริงๆ ของมันคือการบอกให้คนที่ใช้โปรแกรมอ่านหน้าจอ (screen reader) รู้ว่ารูปนั้นคืออะไร ถ้าไม่มีมัน คนตาบอดก็จะได้ยินแค่คำว่า "image" เฉยๆ แล้วก็ไม่รู้เรื่องอะไรเลย
ปัญหาคือเครื่องมือตรวจสอบความเข้าถึงได้ (accessibility checker) ส่วนใหญ่ในตลาด — รวมถึงที่ GitHub ใช้อยู่ — มันตรวจแค่ว่ามี alt text หรือเปล่า ถ้ามีก็ผ่าน แล้วก็จบ แต่ไม่มีตัวไหนเลยที่ตรวจว่า alt text ที่เขียนไปนั้น "ใช้ได้จริง" หรือไม่ ความหมายคือ รูปภาพหนึ่งรูปคุณเขียน alt text ว่า "image" หรือ "รูป" ผ่านการตรวจทั้งหมด แต่คนตาบอดที่ฟังผ่าน screen reader จะได้ประโยชน์อะไรจากคำว่า "รูป" กัน?
ทีมงาน GitHub เลยลงมือทำอะไรบางอย่างที่จริงจังกว่าการโวยวายในบอร์ด พวกเขาสร้างปลั๊กอินสำหรับ GitHub Accessibility Scanner ที่ชื่อว่า alt-text accessibility plugin โดยหลักการทำงานไม่ได้ซับซ้อนเกินไป — มันจะอ่าน alt text ในโค้ดของคุณแล้วเทียบกับเกณฑ์ที่ว่ามัน "มีความหมาย" หรือไม่ ตัวอย่างเช่น ถ้าคุณเขียน alt text ที่ซ้ำกับชื่อไฟล์รูป หรือเป็นคำพูดกำกวมแบบ "ภาพถ่าย" หรือ "กราฟิก" ปลั๊กอินตัวนี้จะฟ้องว่ามันไม่ผ่าน
นี่คือการยกระดับมาตรฐานครั้งสำคัญ เพราะที่ผ่านมา เรามัวแต่ภูมิใจว่า "เว็บเราผ่าน automated check ครบ 100%" แต่ลืมคิดไปว่า automated check ที่ว่านั้นมันตื้นเขินแค่ไหน มันเหมือนกับตรวจการบ้านนักเรียนแค่ว่า "ส่งครบทุกข้อไหม" โดยไม่ดูเนื้อหาว่าถูกหรือผิด — ผ่านก็ผ่านไป แต่ใครได้ประโยชน์จริง?
เกณฑ์ที่ปลั๊กอินตัวนี้ใช้ตรวจ มีอะไรบ้าง? จากตัวอย่างในบล็อกของ GitHub เอง มันจะจับ alt text ที่มีความยาวเกินจำเป็น (เช่นลอกบทความทั้งย่อหน้าลงไป) จับคำซ้ำซากไร้ค่า จับการเขียนที่หลอกระบบ เช่น ใส่ alt text ที่เป็นคำสุ่มหรือเป็นชื่อไฟล์รูปตรงๆ ตรงนี้แหละที่น่าสนใจ — เพราะชื่อไฟล์รูปอย่าง "IMG_4521.JPG" หรือ "screenshot-2024-01-15-at-3.45pm.png" มันผ่าน automated check มาได้เสมอ แต่สำหรับคนที่ฟังผ่าน screen reader มันคือขยะชัดๆ
ตัวอย่าง alt text ที่ควรโดนจับ
ชื่อไฟล์รูป (เช่น "DSC00123.jpg") — ผ่าน automated check แต่ไร้ความหมายโดยสิ้นเชิง
คำกำกวมไม่บอกข้อมูล
"รูปภาพ" "ภาพประกอบ" — คนฟังแล้วไม่รู้ว่าภาพนั้นคืออะไร ภาพอะไร
ข้อความยาวเกินจำเป็น
ลอกเนื้อหาทั้งหน้าลงใน alt text — screen reader จะอ่านยาวมากจนคนฟังหลงประเด็น
ผมมองว่าการทำแบบนี้ของ GitHub คือการตั้งคำถามกับมาตรฐานเดิมที่เรายึดถือกันมานาน เราเคยชินกับการ "ทำตาม checklist" เพื่อให้ผ่านการตรวจ แล้วก็คิดว่างานเสร็จแล้ว แต่ความจริงคือ ผู้ใช้ที่ต้องการความช่วยเหลือจริงๆ ยังไม่ได้อะไรที่ดีขึ้นเลย การมีปลั๊กอินแบบนี้ช่วยยกระดับความคาดหวัง ว่าแค่ "มี" ยังไม่พอ ต้อง "ดี" ด้วย
แน่นอนว่าเครื่องมือนี้ยังไม่สมบูรณ์แบบ — มันยังเป็นแค่ตัวกรองหยาบๆ ที่จับได้เฉพาะรูปแบบที่ชัดเจนเท่านั้น ความหมายเชิงบริบทของภาพ เช่น รูปคนยิ้มในงานศพ หรือรูปมือชูนิ้วกลางในบริบทประชด ยังเป็นอะไรที่ AI หรือกฎเกณฑ์คงประเมินได้ยาก แต่การเริ่มต้นที่ "จับขยะที่เห็นได้ชัด" ก่อน ก็ดีกว่าไม่ทำอะไรเลย และนี่คือจุดเริ่มต้นที่ทำให้วงการ dev ต้องหันกลับมาคิดว่า accessibility ไม่ใช่แค่ checkbox ที่ต้องติ๊กว่าผ่าน
บทเรียนจาก GitHub ครั้งนี้คือ "ระบบอัตโนมัติเป็นแค่กับดักความสบายใจ" ถ้าเรายังเขียน alt text แบบผ่านๆ ไปวันๆ โดยไม่คิดถึงคนอ่านจริง เราก็แค่หลอกตัวเองว่าทำดีแล้ว ปลั๊กอินนี้คือสะกิดให้รู้ตัว — และถึงมันจะไม่สมบูรณ์แบบ แต่อย่างน้อยก็ดีกว่าเครื่องมือตรวจที่ทำได้แค่ถามว่า "มีหรือเปล่า" มากโข
ที่มา: GitHub Blog — อ่านต้นฉบับ
ความคิดเห็น 6
กำลังโหลดความคิดเห็น...