วิธี Audit Website Accessibility Audit ขององค์กรการเงิน ประกัน และธุรกิจที่มีความเสี่ยงสูง พร้อม Evidence ที่ควรเก็บ

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

ทำไมเว็บไซต์การเงินมีความเสี่ยงจากผู้ให้บริการภายนอกมากกว่าธุรกิจทั่วไป

ธุรกิจการเงินและประกันมักใช้บริการภายนอกจำนวนมากเพื่อตอบโจทย์ข้อกำหนดด้านความปลอดภัยและกฎระเบียบ เช่น ระบบยืนยันตัวตนที่ต้องผ่านมาตรฐานเฉพาะ หรือระบบ e-Signing ที่ต้องมีผลทางกฎหมาย บริการเหล่านี้ฝังโค้ดของตัวเองเข้ามาในหน้าเว็บ และมักอยู่นอกเหนือการควบคุมโดยตรงของทีมพัฒนาภายใน การตรวจ Accessibility เฉพาะโค้ดที่ทีมภายในเขียนเองจึงไม่เพียงพอ เพราะจุดที่ลูกค้าใช้งานบ่อยที่สุด เช่น การยืนยันตัวตนหรือการเซ็นเอกสาร มักเป็นส่วนที่มาจากผู้ให้บริการภายนอกทั้งหมด

ทำ Inventory รายชื่อผู้ให้บริการภายนอกที่ฝังอยู่ในเว็บไซต์

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

ตรวจ Widget แชทและระบบยืนยันตัวตนจากผู้ให้บริการภายนอก

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

ตรวจระบบชำระเงินและ e-Signing จากผู้ให้บริการภายนอก

ระบบชำระเงินที่ฝังมาจากผู้ให้บริการภายนอกมักมีฟอร์มกรอกข้อมูลบัตรหรือบัญชีธนาคารในกรอบ iframe แยกต่างหาก ทีมควรตรวจว่าช่องกรอกข้อมูลเหล่านี้มี Label ที่ Screen Reader อ่านได้ และสามารถกดยืนยันการชำระเงินได้ด้วยคีย์บอร์ดล้วน ส่วนระบบ e-Signing ที่ใช้เซ็นเอกสารสำคัญ เช่น สัญญากรมธรรม์หรือสัญญาสินเชื่อ ควรตรวจว่าขั้นตอนลงลายมือชื่ออิเล็กทรอนิกส์ทำได้ครบถ้วนโดยไม่ต้องพึ่งการลากเมาส์วาดลายเซ็นเพียงอย่างเดียว เพราะผู้ใช้บางกลุ่มไม่สามารถควบคุมเมาส์ได้แม่นยำพอสำหรับการวาดลายเซ็น

ตรวจ Banner ยินยอมคุกกี้และเครื่องมือวิเคราะห์ข้อมูล

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

วิธีขอ Accessibility Conformance Report จากผู้ให้บริการภายนอก (VPAT)

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

เก็บ Evidence อะไรบ้างระหว่างการ Audit ผู้ให้บริการภายนอก

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

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

รายงานผล Audit ให้ฝ่ายกฎหมายและผู้บริหารรับทราบ

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

หลังจากส่งรายงานแล้ว ควรนัดประชุมร่วมกับฝ่ายกฎหมาย ฝ่ายจัดซื้อ และทีมพัฒนา เพื่อตัดสินใจร่วมกันว่าจะรอผู้ให้บริการแก้ไขตามกำหนดเวลาที่ตกลงไว้ หรือควรเริ่มหาผู้ให้บริการรายอื่นควบคู่ไปด้วย การตัดสินใจนี้ควรพิจารณาจากทั้งความรุนแรงของปัญหาและต้นทุนในการเปลี่ยนผู้ให้บริการ ไม่ใช่ทีมเทคนิคตัดสินใจฝ่ายเดียว นอกจากนี้ควรกำหนดรอบทบทวนซ้ำให้ผูกกับวันครบกำหนดสัญญาของผู้ให้บริการแต่ละราย เพื่อให้การตรวจสอบ Accessibility เป็นส่วนหนึ่งของกระบวนการต่อสัญญาตามปกติ ไม่ใช่งานพิเศษที่ต้องรื้อฟื้นขึ้นมาทำใหม่ทุกครั้ง

เมื่อผู้ให้บริการภายนอกไม่ยอมแก้ไข ควรทำอย่างไร

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

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

ต้องตรวจผู้ให้บริการภายนอกทุกรายพร้อมกันในการ Audit ครั้งเดียวหรือไม่

ไม่จำเป็นต้องตรวจพร้อมกันทั้งหมด ให้เริ่มจากบริการที่อยู่ในเส้นทางธุรกรรมหลัก เช่น ระบบยืนยันตัวตนและระบบชำระเงินก่อน แล้วขยายไปยัง Chat Widget และ Banner คุกกี้ในรอบถัดไปตามความเสี่ยงที่ประเมินได้

ถ้าผู้ให้บริการภายนอกมี VPAT อยู่แล้ว ยังต้องทดสอบซ้ำด้วยตัวเองหรือไม่

ควรทดสอบซ้ำอย่างน้อยในเส้นทางที่ลูกค้าใช้งานจริงบนเว็บไซต์ของธุรกิจตัวเอง เพราะ VPAT มักอ้างอิงจากการทดสอบผลิตภัณฑ์ในสภาพแวดล้อมมาตรฐาน ซึ่งอาจแตกต่างจากวิธีที่ธุรกิจนำไปติดตั้งใช้งานจริงบนเว็บไซต์ของตัวเอง

ทีมจัดซื้อควรเริ่มขอเอกสาร Accessibility จากผู้ให้บริการตั้งแต่ขั้นตอนใด

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

การ Audit ผู้ให้บริการภายนอกครอบคลุมทำให้มั่นใจได้แน่นอนว่าไม่มีปัญหาเหลืออยู่เลยหรือไม่

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

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

• ทำ Inventory รายชื่อผู้ให้บริการภายนอกทั้งหมดที่ฝังอยู่ในเว็บไซต์พร้อมหน้าที่และตำแหน่งที่ใช้งาน
• ทดสอบระบบยืนยันตัวตนและระบบชำระเงินจากผู้ให้บริการภายนอกด้วยคีย์บอร์ดล้วนและ Screen Reader
• ตรวจ Chat Widget ว่าเปิดปิดด้วยคีย์บอร์ดได้และไม่ดักโฟกัสผู้ใช้ไว้
• ตรวจ Banner ยินยอมคุกกี้ว่ากดยอมรับหรือปฏิเสธด้วยคีย์บอร์ดได้และไม่บล็อกทางเข้าเนื้อหาหลัก
• ขอเอกสาร VPAT หรือ Accessibility Conformance Report จากผู้ให้บริการภายนอกทุกรายที่เกี่ยวข้องกับธุรกรรมสำคัญ
• เตรียมแผนทางเลือกสำรองสำหรับบริการที่ผู้ให้บริการภายนอกไม่ยอมแก้ไขปัญหา
• บันทึกผลตรวจแยกตามผู้ให้บริการแต่ละรายพร้อมวันที่และช่องทางติดต่อสำหรับติดตามความคืบหน้า

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

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

สรุป

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

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

• W3C Web Content Accessibility Guidelines (WCAG) 2.2
• คู่มือ Website Accessibility Audit สำหรับองค์กรการเงินและประกัน
• เช็กลิสต์ Website Accessibility Audit สำหรับองค์กรการเงินและประกัน
• Accessibility & Trust UX