วิธีที่เราทำให้ Accessibility VPATs เป็นระบบอัตโนมัติใน CI วิธีที่เราทำให้ Accessibility VPATs เป็นระบบอัตโนมัติใน CI
การตรวจสอบการเข้าถึง (Accessibility audits) ล้าสมัยได้อย่างรวดเร็ว เพียงแค่การรวมโค้ด (code merge) ครั้งเดียวก็เปลี่ยนทุกอย่างได้แล้ว
เราแก้ปัญหานี้ด้วยการเปลี่ยนรายงานการเข้าถึงของเราให้กลายเป็น build artifact แบบต่อเนื่อง
Pipeline ของเราใช้สามเลเยอร์ในการค้นหาข้อผิดพลาด:
- การตรวจสอบแบบ Static: เราใช้ axe-core สำหรับการทดสอบพื้นฐานใน Storybook
- การทดสอบแบบ Interactive: เราใช้ Vitest helpers ที่ปรับแต่งเองเพื่อทดสอบกฎการใช้งานผ่านคีย์บอร์ด
- การตรวจสอบด้วยตนเอง (Manual audits): เราจัดเก็บผลลัพธ์จาก screen reader ในรูปแบบไฟล์ JSON
CI pipeline ของเราจะรวมผลลัพธ์เหล่านี้เข้าด้วยกัน
หากการทดสอบล้มเหลว PR ก็จะล้มเหลวด้วย แต่ถ้าการทดสอบทั้งหมดผ่าน ระบบจะสร้าง PDF ฉบับใหม่ขึ้นมา ซึ่ง PDF นี้จะถูกส่งไปพร้อมกับ release ของคุณ
เราเคยลองทำสิ่งหนึ่งแต่ไม่สำเร็จ
เราลองใช้ LLM มาแทนที่การตรวจสอบด้วยตนเอง แต่เราก็หยุดใช้มันทันที เพราะผลลัพธ์จาก AI มีความผันผวนมากเกินไป และคุณต้องการผลลัพธ์ที่เสถียรสำหรับการเป็น CI gate
อ่านรายละเอียดทางเทคนิคฉบับเต็มได้ที่นี่:
แหล่งที่มา: https://dev.to/yassine_lakhdar_d0226709a/how-we-automated-our-accessibility-vpats-in-ci-46jk
ARTICLE: ทีมพัฒนาได้ทำให้การสร้าง accessibility VPATs (Voluntary Product Accessibility Templates) เป็นระบบอัตโนมัติโดยตรงใน CI pipeline ของตนเอง โดยเปลี่ยนจากรายงานที่ต้องทำด้วยตนเองเป็นระยะๆ ให้กลายเป็น build artifact ที่ส่งไปพร้อมกับทุกการ release เวิร์กโฟลว์ใหม่นี้จะสั่งให้ pull request ล้มเหลวหากมีการนำ accessibility regressions เข้ามา และจะสร้างเอกสารการปฏิบัติตามมาตรฐาน (compliance document) ในรูปแบบ PDF โดยอัตโนมัติเมื่อการ build สำเร็จ เพื่อให้มั่นใจว่าทุกการเปลี่ยนแปลงของโค้ดยังคงอยู่ในมาตรฐานการเข้าถึง
Why automation matters
การตรวจสอบการเข้าถึงจะล้าสมัยทันทีที่มีโค้ดใหม่เข้ามา การ merge เพียงครั้งเดียวอาจทำให้เกิดปัญหา เช่น การขาด alt text, ลำดับการ focus ที่ไม่เหมาะสม หรือปัญหาด้าน screen reader ซึ่งทำให้ VPAT ที่เคยออกไปก่อนหน้านี้ใช้งานไม่ได้ การรักษามาตรฐานการปฏิบัติตาม (compliance) ด้วยตนเองหมายถึงการต้องรันการตรวจสอบใหม่ทุกครั้งหลังการเปลี่ยนแปลง ซึ่งเป็นกระบวนการที่สิ้นเปลืองและเสี่ยงต่อความผิดพลาด และมักจะตามไม่ทันความเร็วในการพัฒนา การฝังการตรวจสอบไว้ใน CI ช่วยให้ทีมได้รับผลตอบรับทันที รักษามาตรฐานให้เป็นปัจจุบันเสมอ และหลีกเลี่ยงความเสี่ยงทางกฎหมายและชื่อเสียงจากการปล่อยซอฟต์แวร์ที่เข้าถึงไม่ได้
The three-layer testing approach
Static checks – Pipeline จะรัน axe-core ซึ่งเป็นไลบรารี open-source ที่สแกนคอมโพเนนต์ที่แสดงผลใน Storybook เพื่อหาข้อผิดพลาดที่ทราบกันดี เช่น การขาด landmarks หรือความต่างของสี (color contrast) ที่ไม่เพียงพอ การทดสอบเหล่านี้จะตรวจพบปัญหาตั้งแต่ก่อนที่จะมีการโต้ตอบใดๆ เกิดขึ้น
Interactive checks – Vitest helpers ที่ปรับแต่งเองจะทดสอบกฎการนำทางด้วยคีย์บอร์ด เพื่อตรวจสอบว่าการ focus เคลื่อนที่อย่างสมเหตุสมผล และองค์ประกอบที่โต้ตอบได้สามารถตอบสนองต่อเหตุการณ์คีย์บอร์ดมาตรฐานได้ ชั้นการทดสอบนี้ไปไกลกว่าการวิเคราะห์แบบ static เพื่อให้มั่นใจในความสามารถในการใช้งานจริง
Manual audit artifacts – ผลลัพธ์จากการทดสอบด้วย screen reader จะถูกบันทึกเป็นไฟล์ JSON นักพัฒนาจะบันทึกสิ่งที่สังเกตเห็นระหว่างการทำ exploratory testing และ commit ไฟล์ JSON ไปพร้อมกับโค้ด งานใน CI จะรวม artifacts เหล่านี้เข้ากับผลลัพธ์อัตโนมัติ เพื่อสร้างแหล่งข้อมูลความจริงหนึ่งเดียว (single source of truth) สำหรับ VPAT
เมื่อการทดสอบใดๆ ในสองชั้นแรกล้มเหลว pull request จะถูกระงับ เพื่อป้องกันไม่ให้การเปลี่ยนแปลงนั้นไปถึง production หากการทดสอบทั้งหมดผ่าน pipeline จะรวบรวมข้อมูลทั้งหมดเข้าด้วยกันเป็น PDF ที่แนบไปกับ release ซึ่งช่วยให้ได้ VPAT ที่เป็นปัจจุบันโดยไม่ต้องใช้ความพยายามเพิ่มเติม
What didn’t work
ทีมได้ทดลองใช้ large language model (LLM) เพื่อสร้างส่วนของการตรวจสอบด้วยตนเองโดยอัตโนมัติ แต่ผลลัพธ์ที่ AI สร้างขึ้นมีความผันผวนมากเกินไป ทำให้ CI gate ไม่น่าเชื่อถือ ความสม่ำเสมอเป็นสิ่งสำคัญสำหรับการตรวจสอบแบบ pass/fail ดังนั้นการทดลองนี้จึงถูกยกเลิกและเปลี่ยนมาใช้ manual artifacts ที่อิงตาม JSON แทน
What to watch next
สำหรับตอนนี้ โมเดล CI แบบสามชั้นนี้เป็นแนวทางที่ใช้งานได้จริงในการทำให้ VPAT เป็นปัจจุบัน ลดภาระงานที่ต้องทำด้วยตนเอง และทำให้เรื่องการเข้าถึง (accessibility) เป็นหัวใจสำคัญในทุกการเปลี่ยนแปลงของโค้ด