Design System แก้ปัญหา Accessibility ได้จริง แต่ต้องไร้ทางลัด

การแก้ไขปัญหาเรื่องการเข้าถึงหรือ Accessibility ในงานพัฒนาซอฟต์แวร์มักนำไปสู่ข้อสรุปเดิมๆ นั่นคือ การหยุดแก้ปัญหาทีละจุดแล้วหันมาแก้ไขที่ต้นตอของปัญหาแทน การแก้ไขที่ต้นทางนี้มีเป้าหมายสูงสุดอยู่ที่การใช้ Design System ซึ่งช่วยให้การแก้ไขคอมโพเนนต์หลักเพียงครั้งเดียว ส่งผลให้ทุกส่วนที่เรียกใช้งานในผลิตภัณฑ์ได้รับการแก้ไขตามไปด้วยทันที

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

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

• ปุ่มหรือลิงก์ที่ถูกเขียนขึ้นเองแบบเฉพาะกิจนอกเหนือจากคอมโพเนนต์กลาง
• การคัดลอกโค้ดเดิมไปใช้งานก่อนที่ Design System จะถูกพัฒนาขึ้น
• การใช้แท็ก HTML ทั่วไปพร้อมใส่ Event Listener แทนการใช้คอมโพเนนต์ที่รองรับ Accessibility

ผลลัพธ์ที่ตามมาคือ การตรวจสอบการเข้าถึงรอบใหม่จะผ่านในหน้าเว็บที่สร้างจาก Design System แต่จะล้มเหลวในหน้าเว็บที่นักพัฒนาสร้างขึ้นมาใหม่ด้วยวิธีของตนเอง ปัญหานี้สร้างความสับสนเพราะใช้การแก้ไขแบบเดียวกัน ผลิตภัณฑ์ตัวเดียวกัน แต่กลับให้ผลลัพธ์ที่แตกต่างกัน โดยที่ไม่มีความผิดปกติใดๆ ปรากฏในคอมโพเนนต์ดิฟฟ์ (Component diff) เลยแม้แต่น้อย