ทีมผลิตภัณฑ์มักมีนิสัยที่มองว่าการเข้าถึง (accessibility) เป็นเหมือนการทาสีทับเป็นขั้นตอนสุดท้าย พวกเขาสร้างฟีเจอร์ ปรับแต่งอินเทอร์เฟซให้สวยงาม แล้วก็—เพียงสองวันก่อนเปิดตัว—ก็รันตัวสแกน ทันใดนั้น แดชบอร์ดก็ขึ้นไฟสีแดงแจ้งเตือน ป้ายกำกับฟอร์ม (form labels) หายไป ปุ่มไม่มีชื่อที่เข้าถึงได้ (accessible name) ระดับหัวข้อ (heading levels) กระโดดจาก h1 ไป h4 โดยไม่มีการแจ้งล่วงหน้า หรือคู่สีที่ทำให้ข้อความกลายเป็นส่วนหนึ่งของพื้นหลังจนอ่านไม่ออก รายการปัญหาเหล่านี้ดูน่าตกใจเพราะมันมาถึงช้าเกินไป

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

สิ่งที่เครื่องจักรทำได้ดีที่สุดจริงๆ

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

ใช้ AI สำหรับงานปริมาณมาก การคัดกรอง (triage) และการจดจำรูปแบบ ปล่อยให้มันจัดการภาระการสแกนข้อมูลดิบ เพื่อให้ทีมของคุณสามารถมุ่งเน้นไปที่การแก้ไขปัญหาได้

สัญญาณที่บ่งบอกถึงความล้มเหลวที่พบบ่อย

ความล้มเหลวในการเข้าถึงส่วนใหญ่มักส่งสัญญาณที่ชัดเจนและตรวจจับได้ ตัวสแกนสามารถตรวจพบรูปภาพที่ขาดแอตทริบิวต์ alt สามารถหาปุ่มที่มีอยู่ใน DOM แต่ไม่มีข้อความหรือ aria-label ซึ่งทำให้ผู้ใช้ที่ใช้เครื่องอ่านหน้าจอ (screen reader) ไม่รู้ว่าปุ่มนั้นทำหน้าที่อะไร สามารถระบุลิงก์ที่เขียนว่า "คลิกที่นี่" หรือ "อ่านเพิ่มเติม" ซึ่งทำให้ผู้ใช้ที่ใช้การกด Tab ผ่านหน้าเว็บไม่ทราบบริบทของจุดหมายปลายทาง นอกจากนี้ยังตรวจจับคู่สีที่ไม่ผ่านเกณฑ์คอนทราสต์ และระบุลำดับชั้นของหัวข้อที่ข้ามระดับ ซึ่งจะขัดขวางการนำทางสำหรับผู้ที่ต้องพึ่งพาหัวข้อในการทำความเข้าใจโครงสร้างหน้าเว็บ

สิ่งเหล่านี้คือปัญหาที่อิงตามรูปแบบ (pattern-based) ซึ่งปรากฏเป็นเครื่องหมายในโค้ดที่คาดเดาได้ นั่นหมายความว่ามันคือประเภทของงานที่ระบบอัตโนมัติมีความเชี่ยวชาญในการค้นหาอย่างยิ่ง

การสร้าง Pipeline ที่ตรวจจับปัญหาที่แท้จริง

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

เลเยอร์ที่สองคือ Browser Automation การวิเคราะห์โค้ดแบบ Static ไม่สามารถตรวจจับสิ่งที่เกิดขึ้นหลังจาก Modal เปิดขึ้น, ดรอปดาวน์ขยายออก หรือข้อผิดพลาดจากการตรวจสอบฟอร์ม (form validation) ปรากฏขึ้น เบราว์เซอร์อัตโนมัติจำเป็นต้องจำลองเส้นทางการใช้งานจริงของผู้ใช้ เช่น ขั้นตอนการสมัครสมาชิก, กระบวนการชำระเงิน, หรือแดชบอร์ดบัญชี ซึ่งเนื้อหาจะเปลี่ยนแปลงแบบไดนามิกตามการกระทำของผู้ใช้ หากข้อกำหนดรหัสผ่านของคุณปรากฏขึ้นหลังจากที่โฟกัสออกจากช่องกรอกข้อมูลเท่านั้น ลำพังแค่ตัวสแกนโค้ดอาจไม่มีวันเห็นความล้มเหลวในการประกาศแจ้งเตือนนั้น

เลเยอร์ที่สามคือจุดที่ AI เข้ามาตีความสิ่งที่พบและรวมรายการที่ซ้ำกัน หากปุ่มไอคอนที่ไม่มีป้ายกำกับเหมือนกันปรากฏอยู่ในคอมโพเนนต์ Header ที่ใช้ในแปดสิบหน้า ระบบควรรายงานสิ่งนี้เพียงครั้งเดียวในฐานะข้อบกพร่องระดับคอมโพเนนต์ (component-level defect) ไม่ใช่บั๊กระดับหน้าเว็บแปดสิบรายการแยกกัน วิธีนี้จะช่วยป้องกันไม่ให้ทีมต้องจมกองข้อมูลที่ไร้ประโยชน์

เลเยอร์ที่สี่คือการตรวจสอบโดยมนุษย์ เครื่องจักรควรตรวจสอบอย่างต่อเนื่อง แต่คนควรเป็นผู้ตรวจสอบกรณีที่ซับซ้อน (edge cases) ก่อนการปล่อยใช้งานจริง ไม่มี Pipeline อัตโนมัติใดควรเป็นผู้ตัดสินชี้ขาดเพียงลำพัง

เปลี่ยนศัพท์เทคนิคให้เป็นการลงมือทำ

ผลลัพธ์ดิบจากตัวสแกนมักจะค้างอยู่ใน Backlog เพราะมันอ่านเหมือนข้อกำหนดสำหรับผู้ตรวจสอบ (auditors) ไม่ใช่สำหรับนักพัฒนา รายงานที่บอกว่า "insufficient color contrast ratio" มักถูกละเลยเพราะฟังดูเป็นนามธรรมและมีความสำคัญต่ำ แต่การบอกว่า "ข้อความช่วยเหลือสีเทาอ่านยากบนพื้นหลังสีขาว" จะบอกนักพัฒนาได้อย่างชัดเจนว่าต้องแก้ไขอะไร ตรงไหน และทำไมมันถึงสำคัญต่อผู้ใช้จริง AI สามารถช่วยลดช่องว่างนี้ได้โดยการแปลความล้มเหลวทางเทคนิคตามมาตรฐาน WCAG ให้เป็นภาษาที่เข้าใจง่าย ซึ่งทีมผลิตภัณฑ์สามารถอ่านและนำไปปฏิบัติได้จริง

คุณยังจำเป็นต้องกำหนดระดับความเชื่อมั่น (confidence levels) ให้กับสิ่งที่คุณตรวจพบ แทนที่จะปฏิบัติกับทุกการแจ้งเตือนเหมือนกันหมด ปัญหาที่มีความเชื่อมั่นสูง เช่น ช่องกรอกข้อมูล (form inputs) ที่ไม่มีป้ายกำกับ สามารถสร้างตั๋ว (tickets) ได้โดยอัตโนมัติ เพราะการแก้ไขมักเป็นสิ่งที่จำเป็นตามมาตรฐาน WCAG และมีวิธีการแก้ไขที่ตรงไปตรงมา สิ่งที่ตรวจพบที่มีความเชื่อมั่นระดับกลาง เช่น alt text ที่น่าสงสัยว่าอาจเป็นการยัดคำสำคัญ (keyword-stuffed) มากกว่าการอธิบายเนื้อหา จำเป็นต้องใช้มนุษย์ในการตรวจสอบเพื่อตัดสินว่าคำอธิบายนั้นมีประโยชน์หรือไม่ ส่วนรายการที่มีความเชื่อมั่นต่ำควรคงไว้ในรายงานเพื่อการทดสอบด้วยตนเอง เครื่องมือสแกนอาจตรวจพบว่าขาดแอตทริบิวต์ alt แต่เครื่องมือไม่รู้ว่ารูปภาพนั้นเป็นเพียงรูปภาพเพื่อการตกแต่งหรือเป็นส่วนสำคัญในการทำความเข้าใจเนื้อหา บริบทดังกล่าวยังคงต้องใช้มนุษย์ในการพิจารณา

แก้ไขครั้งเดียว แก้ไขได้ทุกที่

AI ช่วยให้ทีมค้นพบจุดที่ปัญหาเกาะกลุ่มกัน หากคอมโพเนนต์ปุ่มที่สร้างมาไม่ดีถูกนำไปใช้ในหน้าจอถึงห้าสิบหน้า การแก้ไขคอมโพเนนต์เพียงครั้งเดียวจะช่วยลดจำนวนปัญหาลงได้ทันที สิ่งนี้จะเปลี่ยนจากการไล่แก้ปัญหาทีละหน้าแบบไล่ตีตัวตุ่น (whack-a-mole) ไปเป็นการบำรุงรักษาไลบรารีคอมโพเนนต์อย่างเป็นระบบ การจดจำรูปแบบ (Pattern recognition) คือจุดที่ AI ให้ผลตอบแทนที่คุ้มค่า มันช่วยเชื่อมโยงจุดต่างๆ จากหน้าเว็บหลายร้อยหน้า เพื่อให้ทีมไม่ต้องเสียเวลาแก้ไขบั๊กเดิมซ้ำๆ ในตั๋ว Jira ถึงสี่สิบใบ

การเชื่อมต่อเครื่องมือสแกนเข้ากับ pull requests จะช่วยให้การตอบสนองนี้รวดเร็วและแม่นยำ เมื่อนักพัฒนาได้รับการแจ้งเตือนว่า markup ใหม่ของพวกเขาทำให้เกิดการข้ามระดับหัวข้อ (heading level) ก่อนที่จะทำการ merge การแก้ไขจะใช้เวลาเพียงไม่กี่นาที แต่หากปัญหานั้นถูกส่งไปยัง production และถูกตรวจพบสองวันก่อนการเปิดตัว การแก้ไขจะต้องใช้ทั้ง hotfix, การทดสอบ regression และการสื่อสารกับผู้มีส่วนได้ส่วนเสีย การสร้างวงจรการทำงานที่กระชับขึ้นจะช่วยประหยัดเวลาและลดหนี้ด้านการเข้าถึง (accessibility debt)

การแบ่งหน้าที่การทำงาน

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

ใช้ AI สำหรับงานปริมาณมาก การคัดกรอง (triage) และการจดจำรูปแบบ ปล่อยให้เครื่องจักรจัดการกับการสแกนที่ซ้ำซากในทุกหน้าเว็บทุกคืน และปล่อยให้มนุษย์จัดการกับการตัดสินใจ การแบ่งหน้าที่การทำงานเช่นนี้คือวิธีที่การทำให้เข้าถึงได้ (accessibility) จะเปลี่ยนจากการตื่นตระหนกก่อนการเปิดตัว ไปสู่การเป็นนิสัยปกติในงานวิศวกรรม

ที่มา: https://dev.to/henryv/automating-wcag-compliance-with-ai-4ogp

เข้าร่วมการสนทนา: https://t.me/GyaanSetuAi