วิธีวางระบบ WCAG 2.2 สำหรับองค์กรการเงิน ประกัน และธุรกิจที่มีความเสี่ยงสูงแบบเป็นขั้นตอน

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

สถานการณ์แบบนี้พบได้ทั่วไปในองค์กรการเงิน ประกันภัย และธุรกิจที่มีความเสี่ยงสูง เพราะ Digital Channel มักถูกดูแลแยกกันหลายทีม และ WCAG 2.2 มักถูกมองเป็นโปรเจกต์ที่ทำครั้งเดียวแล้วจบ บทความนี้วางขั้นตอนที่ทำให้ WCAG 2.2 กลายเป็นระบบต่อเนื่องที่รายงานต่อผู้บริหารได้จริง

ทำไมต้องวางเป็นระบบ ไม่ใช่โปรเจกต์ครั้งเดียว

องค์กรการเงินมี Digital Channel จำนวนมากที่เปลี่ยนแปลงตลอดเวลา ทั้ง Internet Banking, แอปมือถือ, พอร์ทัลเคลมประกัน, ระบบยื่นขอสินเชื่อออนไลน์ และเอกสาร PDF อย่างใบแจ้งยอดหรือกรมธรรม์ การตรวจครั้งเดียวจับภาพได้เฉพาะสถานะ ณ วันที่ตรวจ แต่ไม่ครอบคลุมการเปลี่ยนแปลงหลังจากนั้น องค์กรที่มีความเสี่ยงสูงจึงต้องมีระบบที่ตรวจซ้ำและรายงานต่อเนื่อง ไม่ใช่รอให้มีการร้องเรียนก่อนถึงจะเริ่มดู นอกจากนี้องค์กรการเงินและประกันภัยมักอยู่ภายใต้การกำกับดูแลหลายชั้น ทั้งหน่วยงานกำกับสถาบันการเงิน หน่วยงานคุ้มครองผู้บริโภค และข้อกำหนดภายในของกลุ่มบริษัท การมีระบบ Accessibility ที่ตรวจสอบย้อนกลับได้จึงช่วยให้ตอบคำถามจากผู้ตรวจสอบภายในและภายนอกได้เร็วขึ้นเมื่อถูกร้องขอ

ขั้นที่ 1 ตั้ง Governance และผู้รับผิดชอบ

ก่อนเริ่มตรวจ ต้องมีคนรับผิดชอบชัดเจนระดับองค์กร ไม่ใช่กระจายให้แต่ละทีมดูแลกันเอง หลายองค์กรตั้งคณะทำงานร่วมระหว่างฝ่ายกฎหมาย ฝ่าย Compliance ฝ่ายไอที และฝ่าย Digital Product โดยมีเจ้าของงานหลักหนึ่งคนที่รายงานตรงต่อผู้บริหารระดับสูง คณะทำงานนี้ทำหน้าที่อนุมัติมาตรฐานที่ใช้ จัดสรรงบประมาณ และติดตามความคืบหน้าของแต่ละ Channel

ขั้นที่ 2 จัดกลุ่มความเสี่ยงของแต่ละ Digital Channel

ไม่ใช่ทุก Channel มีความเสี่ยงเท่ากัน ควรจัดลำดับตามผลกระทบต่อลูกค้าและปริมาณผู้ใช้งาน เช่น Internet Banking และแอปมือถือที่ใช้ทำธุรกรรมทุกวันควรอยู่ในกลุ่มความเสี่ยงสูงสุด รองลงมาคือพอร์ทัลเคลมประกันและระบบยื่นขอสินเชื่อที่ใช้ในช่วงเวลาวิกฤตของลูกค้า ส่วนเอกสารข้อมูลทั่วไปหรือหน้าการตลาดอาจจัดเป็นความเสี่ยงต่ำกว่า การจัดกลุ่มแบบนี้ช่วยให้จัดสรรงบและเวลาตรวจได้ตรงจุดกว่าการไล่ตรวจทุก Channel พร้อมกัน ควรทำตารางสรุปสั้นๆ ที่ระบุชื่อ Channel เจ้าของทีม ระดับความเสี่ยง และจำนวนผู้ใช้งานต่อเดือนโดยประมาณ เพื่อให้คณะทำงาน Governance ใช้ตัดสินใจจัดลำดับได้โดยไม่ต้องถกเถียงกันใหม่ทุกครั้งที่ประชุม

ขั้นที่ 3 กำหนด Baseline ด้วย Automated Scan และการทดสอบเบื้องต้น

เริ่มจากรัน Automated Scan ในทุก Channel เพื่อให้เห็นภาพรวมปัญหาพื้นฐาน เช่น Alt Text ที่หายไป Label ของฟอร์มที่ไม่เชื่อมกับ Input หรือ Contrast ที่ต่ำกว่ามาตรฐานในบางจุด ผลจากขั้นนี้ใช้เป็น Baseline ตั้งต้นเท่านั้น ต้องตามด้วยการทดสอบคีย์บอร์ดและโปรแกรมอ่านหน้าจอใน Flow ที่มีความเสี่ยงสูงตามที่จัดกลุ่มไว้ในขั้นที่ 2 โดยเฉพาะ Flow การยืนยันตัวตนและการทำธุรกรรมทางการเงิน

ขั้นที่ 4 วาง Remediation Roadmap ตามระดับความเสี่ยง

หลังได้ผล Baseline ให้จัดลำดับการแก้ไขตามความเสี่ยงที่จัดกลุ่มไว้ ไม่ใช่ตามความง่ายของการแก้ Channel ที่อยู่ในกลุ่มความเสี่ยงสูงสุดควรได้รับงบและเวลาก่อน แม้ปัญหาจะแก้ยากกว่า Roadmap ควรระบุกรอบเวลาชัดเจนในแต่ละ Channel พร้อมเจ้าของงาน และมีจุด Checkpoint ให้คณะทำงาน Governance ติดตามความคืบหน้าได้เป็นระยะ

ขั้นที่ 5 จัดหาผู้เชี่ยวชาญภายนอกสำหรับ Manual Audit เชิงลึก

Channel ที่มีความเสี่ยงสูงและมีข้อมูลอ่อนไหว เช่น ข้อมูลสุขภาพในกรมธรรม์ประกัน ควรมีผู้เชี่ยวชาญ Accessibility ภายนอกเข้ามาทดสอบเชิงลึกเพิ่มจากทีมภายใน เมื่อออก RFP ควรระบุขอบเขตให้ชัดว่าต้องการ Manual Test ด้วยผู้ใช้จริงที่ใช้เทคโนโลยีช่วยเหลือ ไม่ใช่แค่รายงานผลจาก Automated Scan และควรขอให้ผู้ให้บริการระบุวิธีทดสอบ เครื่องมือที่ใช้ และขอบเขตที่ไม่ครอบคลุมไว้ในรายงานอย่างชัดเจน

ขั้นที่ 6 ฝึกอบรมทีม Design, Dev และ Content ให้ทำงานต่อเนื่องตามมาตรฐาน

การแก้ปัญหาที่พบเป็นเพียงจุดเริ่มต้น สิ่งที่ทำให้ระบบยั่งยืนคือทีมที่ออกแบบและพัฒนาฟีเจอร์ใหม่เข้าใจเกณฑ์ WCAG 2.2 ตั้งแต่ขั้นออกแบบ ไม่ใช่มาตรวจพบปัญหาหลังปล่อยใช้งานแล้ว ควรมีการอบรมประจำปีสำหรับทีม Design และ Development รวมถึงทีม Content ที่เขียนข้อความแจ้งเตือนหรือ Error Message ให้เข้าใจหลักการเขียนที่ผู้ใช้ทุกกลุ่มเข้าใจได้

จัดการ Third-Party Vendor ที่พัฒนา Digital Channel แทนองค์กร

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

สิ่งที่ควรระบุในสัญญาจ้าง Vendor ใหม่

สัญญาจ้างพัฒนาหรือดูแล Digital Channel ควรระบุว่าต้องอ้างอิงมาตรฐาน WCAG 2.2 เป็นข้อกำหนดด้านคุณภาพงานส่งมอบ พร้อมกำหนดว่า Vendor ต้องส่งรายงานผลทดสอบ Accessibility ก่อนส่งมอบงานแต่ละเฟส และต้องรับผิดชอบแก้ไขปัญหาที่พบภายในกรอบเวลาที่ตกลงกันโดยไม่คิดค่าใช้จ่ายเพิ่มเติม หากปัญหานั้นเป็นการไม่ปฏิบัติตามข้อกำหนดที่ระบุไว้ในสัญญาตั้งแต่แรก

เมื่อ Vendor เดิมไม่มีข้อกำหนดนี้อยู่แล้ว

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

การรายงานต่อผู้บริหารและคณะกรรมการกำกับความเสี่ยง

รายงานที่ส่งต่อผู้บริหารควรแสดงสถานะของแต่ละ Channel ตามระดับความเสี่ยง จำนวนปัญหาที่พบและแก้แล้วในแต่ละ Blocker Major Minor พร้อมกรอบเวลาที่เหลือของ Roadmap ไม่ควรใช้คะแนนรวมตัวเดียวแทนความเสี่ยงที่แท้จริง เพราะ Blocker หนึ่งจุดในหน้าธุรกรรมสำคัญมีน้ำหนักมากกว่าปัญหา Minor หลายสิบจุดในหน้าที่ใช้งานน้อย

องค์กรที่เริ่มต้นวางระบบนี้ควรอ่านคู่มือ WCAG 2.2 สำหรับองค์กรการเงิน ประกัน และธุรกิจที่มีความเสี่ยงสูงเพื่อดูภาพรวมทั้งหมด และดูรายการตรวจก่อนเปิดใช้งานเพิ่มเติมได้ที่เช็กลิสต์ WCAG 2.2 สำหรับองค์กรการเงิน ประกัน และธุรกิจที่มีความเสี่ยงสูง รวมถึงดูหัวข้ออื่นด้าน Accessibility และ Trust UX ที่ภาพรวม Accessibility และ Trust UX

ข้อควรระวังเมื่อทดสอบกับข้อมูลอ่อนไหว

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

คำถามที่พบบ่อย

ต้องเริ่มจาก Channel ใดก่อนถ้ามีงบจำกัด ควรเริ่มจาก Channel ที่จัดอยู่ในกลุ่มความเสี่ยงสูงสุดตามผลกระทบต่อลูกค้าและปริมาณผู้ใช้งาน เช่น Internet Banking หรือแอปมือถือหลัก ไม่ใช่ Channel ที่แก้ง่ายที่สุด

ใครควรเป็นเจ้าของงานหลักของระบบนี้ ควรเป็นบทบาทที่รายงานตรงต่อผู้บริหารระดับสูงและมีอำนาจประสานงานข้ามฝ่าย เช่น หัวหน้าฝ่าย Digital Compliance ไม่ใช่ตำแหน่งที่อยู่ลึกในทีมไอทีเพียงทีมเดียว

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

เช็กลิสต์ปฏิบัติ

• ตั้งคณะทำงาน Governance ร่วมระหว่างฝ่ายกฎหมาย Compliance ไอที และ Digital Product
• จัดกลุ่มความเสี่ยงของทุก Digital Channel ตามผลกระทบต่อลูกค้า
• รัน Automated Scan ทุก Channel เพื่อกำหนด Baseline
• ทดสอบคีย์บอร์ดและโปรแกรมอ่านหน้าจอใน Flow ความเสี่ยงสูงโดยเฉพาะ
• วาง Remediation Roadmap พร้อมกรอบเวลาและเจ้าของงานต่อ Channel
• ออก RFP ผู้เชี่ยวชาญภายนอกสำหรับ Channel ความเสี่ยงสูงและข้อมูลอ่อนไหว
• อบรมทีม Design, Dev และ Content ประจำปี
• รายงานสถานะต่อผู้บริหารเป็นรอบพร้อมจำนวน Blocker ที่แก้แล้ว

ข้อผิดพลาดที่พบบ่อย

• ปล่อยให้แต่ละทีมดูแล Channel ของตัวเองโดยไม่มีคณะทำงานกลาง
• ใช้ผล Audit ครั้งเดียวเมื่อหลายปีก่อนเป็นข้อมูลอ้างอิงถาวร
• แก้ปัญหา Minor ในหน้าที่ใช้งานน้อยก่อน Blocker ในหน้าธุรกรรมสำคัญ
• ใช้ข้อมูลลูกค้าจริงในการทดสอบแทนข้อมูลจำลอง
• รายงานผู้บริหารด้วยคะแนนรวมตัวเดียวโดยไม่แยกระดับความรุนแรง

สรุป

การวางระบบ WCAG 2.2 สำหรับองค์กรการเงินและประกันภัยต้องเริ่มจาก Governance ที่ชัดเจน จัดกลุ่มความเสี่ยงของแต่ละ Channel แล้ววาง Roadmap ที่รายงานต่อผู้บริหารได้อย่างต่อเนื่อง ไม่ใช่การตรวจครั้งเดียวแล้วปิดโปรเจกต์

แหล่งข้อมูลอ้างอิง

• W3C — Web Content Accessibility Guidelines (WCAG) 2.2
• W3C WAI — Understanding WCAG 2.2