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

เมื่อองค์กรการเงินหรือประกันเข้าประมูลสัญญากับหน่วยงานภาครัฐ หรือขายผลิตภัณฑ์ดิจิทัลให้ลูกค้าองค์กรขนาดใหญ่ คำถามเรื่อง WCAG 2.2 มักไม่ได้มาจากทีม Engineering แต่มาจากฝ่ายจัดซื้อของคู่สัญญาที่ขอเอกสารยืนยันความสอดคล้องด้านการเข้าถึง (accessibility conformance) ก่อนเซ็นสัญญา หากองค์กรไม่มีเอกสารพร้อมตอบคำถามนี้ อาจเสียโอกาสทางธุรกิจไปทั้งที่ผลิตภัณฑ์อาจไม่ได้มีปัญหาด้านเทคนิคร้ายแรงเลย เพียงแค่ไม่เคยมีใครประเมินและบันทึกไว้เป็นทางการ

บทความนี้จึงเน้นมุมของฝ่ายกฎหมาย Privacy, Security และ Compliance โดยตรง อธิบายว่าทำไมสัญญาจัดซื้อจัดจ้างและลูกค้าองค์กรถึงอ้างอิง WCAG 2.2 การจัดทำเอกสาร VPAT ให้พร้อมตอบคำถามคู่สัญญา ความเสี่ยงด้านการฟ้องร้องและชื่อเสียงหากผลิตภัณฑ์เข้าถึงไม่ได้ และวิธีเตรียมรายงานสรุปให้คณะกรรมการตรวจสอบภายในเข้าใจสถานะความเสี่ยงได้ชัดเจน

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

ทำไมสัญญาจัดซื้อจัดจ้างและลูกค้าองค์กรถึงอ้างอิง WCAG 2.2

หน่วยงานภาครัฐจำนวนมากกำหนดให้ผลิตภัณฑ์ดิจิทัลที่จัดซื้อต้องผ่านเกณฑ์การเข้าถึงระดับหนึ่ง มักอ้างอิง WCAG 2.2 ระดับ AA เป็นเกณฑ์ขั้นต่ำใน TOR (Terms of Reference) หรือ RFP (Request for Proposal) เช่นเดียวกับลูกค้าองค์กรขนาดใหญ่ในภาคการเงินที่มีนโยบายความรับผิดชอบต่อสังคมด้าน accessibility ของตนเอง และต้องการให้คู่ค้าปฏิบัติตามมาตรฐานเดียวกัน สำหรับองค์กรที่ขายผลิตภัณฑ์ B2B หรือเข้าประมูลสัญญาภาครัฐเป็นประจำ การไม่มีหลักฐานความสอดคล้องกับ WCAG 2.2 พร้อมใช้งาน อาจทำให้ตกรอบการพิจารณาตั้งแต่ขั้นตอนเอกสาร ก่อนที่จะได้แข่งขันด้านราคาหรือฟีเจอร์เลยด้วยซ้ำ

ฝ่ายกฎหมายและ Compliance จึงควรทำงานร่วมกับฝ่ายขายและฝ่ายพัฒนาผลิตภัณฑ์ตั้งแต่ช่วงวางแผน ไม่ใช่รอให้ฝ่ายขายส่งคำขอเอกสาร VPAT มาแบบเร่งด่วนก่อนปิดดีลภายในไม่กี่วัน เพราะการประเมินความสอดคล้องกับ WCAG 2.2 อย่างละเอียดต้องใช้เวลาตรวจสอบจริง ไม่ใช่งานที่ทำเสร็จได้ในชั่วข้ามคืน

การจัดทำเอกสาร VPAT ให้พร้อมตอบคู่สัญญา

VPAT (Voluntary Product Accessibility Template) คือเอกสารมาตรฐานที่สรุปว่าผลิตภัณฑ์สอดคล้องกับเกณฑ์การเข้าถึงแต่ละข้อของ WCAG มากน้อยเพียงใด แบ่งสถานะเป็นระดับ เช่น สอดคล้องครบถ้วน (Supports) สอดคล้องบางส่วน (Partially Supports) หรือไม่สอดคล้อง (Does Not Support) พร้อมคำอธิบายประกอบแต่ละข้อ เอกสารนี้เมื่อจัดทำเสร็จจะเรียกว่า Accessibility Conformance Report (ACR) ซึ่งเป็นเอกสารที่ฝ่ายจัดซื้อของลูกค้าองค์กรและหน่วยงานภาครัฐมักขอดูก่อนตัดสินใจ

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

เปรียบเทียบความเสี่ยงเชิงสัญญาและกฎหมายตามเกณฑ์ใหม่ของ WCAG 2.2

ขั้นตอนเตรียมรายงานความเสี่ยงด้านการเข้าถึงให้คณะกรรมการตรวจสอบ

คำถามที่ว่าควรรายงานความเสี่ยงด้าน WCAG ต่อคณะกรรมการตรวจสอบอย่างไร มีคำตอบที่เป็นขั้นตอนชัดเจนดังนี้

1. รวบรวมผลการตรวจสอบ WCAG 2.2 ล่าสุดของผลิตภัณฑ์หลักทุกตัวที่ขายให้ลูกค้าองค์กรหรือใช้ในสัญญาภาครัฐ
2. จัดหมวดข้อบกพร่องตามระดับความเสี่ยง เช่น กระทบสัญญาที่มีอยู่ กระทบโอกาสทางธุรกิจใหม่ หรือกระทบชื่อเสียงองค์กร
3. เตรียมแผนแก้ไขพร้อมกรอบเวลาและงบประมาณสำหรับข้อบกพร่องที่มีความเสี่ยงสูงสุดก่อน
4. จัดทำสรุปสถานะ VPAT ของผลิตภัณฑ์แต่ละตัวว่าเป็นปัจจุบันหรือต้องปรับปรุง
5. นำเสนอรายงานต่อคณะกรรมการตรวจสอบภายในพร้อมข้อเสนอแนะเชิงนโยบาย เช่น การกำหนดเกณฑ์ WCAG ขั้นต่ำในกระบวนการพัฒนาผลิตภัณฑ์ใหม่

กรณีตัวอย่าง: ลูกค้าองค์กรขอ VPAT ก่อนต่อสัญญาแล้วพบข้อบกพร่องสำคัญ

บริษัทประกันแห่งหนึ่งขายซอฟต์แวร์บริหารกรมธรรม์ให้ลูกค้าองค์กรขนาดใหญ่มาหลายปี เมื่อถึงรอบต่อสัญญา ฝ่ายจัดซื้อของลูกค้าเปลี่ยนนโยบายและขอเอกสาร VPAT ฉบับล่าสุดเป็นครั้งแรก บริษัทไม่เคยจัดทำเอกสารนี้มาก่อนจึงต้องเริ่มตรวจสอบผลิตภัณฑ์ทั้งหมดอย่างเร่งด่วน และพบว่าขั้นตอนยืนยันตัวตนของระบบไม่มีทางเลือกอื่นนอกจาก captcha แบบตีความรูปภาพล้วน ซึ่งขัดกับเกณฑ์ Accessible Authentication ของ WCAG 2.2 โดยตรง ทำให้ต้องเจรจาขอเวลาเพิ่มเติมกับลูกค้าเพื่อแก้ไขก่อนต่อสัญญาได้สำเร็จ

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

VPAT คืออะไรและใครควรเป็นผู้จัดทำ

คำถามที่ฝ่ายกฎหมายมักได้รับจากผู้บริหารคือ VPAT คืออะไรและใครควรเป็นผู้จัดทำ ในทางปฏิบัติ VPAT ไม่ใช่เอกสารที่เขียนขึ้นจากความเข้าใจทั่วไปได้ แต่ต้องอ้างอิงผลการตรวจสอบจริงของแต่ละเกณฑ์ในผลิตภัณฑ์ กระบวนการที่แนะนำคือให้ทีมที่มีความรู้ด้าน accessibility ไล่ตรวจสอบทุกเกณฑ์ของ WCAG 2.2 ทีละข้อ บันทึกสถานะและหลักฐานประกอบ แล้วให้ฝ่ายกฎหมายหรือ Compliance ทบทวนภาษาที่ใช้ในเอกสารให้เหมาะสมกับบริบทของสัญญาก่อนส่งให้ลูกค้าหรือหน่วยงานที่ร้องขอ ไม่ควรให้ฝ่ายขายเขียนเองเพียงเพราะต้องการปิดดีลให้ทันเวลา เพราะความคลาดเคลื่อนระหว่างสิ่งที่ระบุในเอกสารกับความเป็นจริงของผลิตภัณฑ์ อาจกลายเป็นประเด็นที่ร้ายแรงกว่าการไม่มีเอกสารเลยเสียอีก หากถูกตรวจพบภายหลังจากที่สัญญาเซ็นไปแล้ว

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

ควรทบทวน VPAT บ่อยแค่ไหน

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

ดูภาพรวมเพิ่มเติมได้ที่ คู่มือ WCAG 2.2 สำหรับ SaaS หรือดูภาพรวมหมวดหมู่ทั้งหมดได้ที่ accessibility-trust

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

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

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

ไม่มีเอกสาร VPAT พร้อมใช้งานจนกว่าลูกค้าองค์กรหรือหน่วยงานภาครัฐจะร้องขอแบบเร่งด่วน

ให้ฝ่ายขายกรอกสถานะความสอดคล้องใน VPAT เองโดยไม่ผ่านการตรวจสอบจริงจากทีมที่ประเมิน WCAG

ปล่อยให้ VPAT ล้าสมัยไม่ตรงกับฟีเจอร์ปัจจุบันของผลิตภัณฑ์ เสี่ยงต่อความน่าเชื่อถือหากลูกค้าตรวจสอบภายหลัง

ไม่รายงานความเสี่ยงด้านการเข้าถึงต่อคณะกรรมการตรวจสอบภายในเป็นประจำ ทำให้ผู้บริหารไม่ทราบความเสี่ยงที่แท้จริง

รอให้เกิดปัญหาระหว่างเจรจาต่อสัญญาก่อนถึงจะเริ่มตรวจสอบ WCAG 2.2 แทนที่จะตรวจสอบเป็นส่วนหนึ่งของกระบวนการปกติ

ความเสี่ยงด้านการฟ้องร้องและชื่อเสียงในตลาดที่ยังไม่มีกฎหมายบังคับโดยตรง

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

ฝ่ายกฎหมายและ Compliance จึงควรประสานกับฝ่าย Investor Relations หรือฝ่ายที่ดูแลรายงาน ESG ขององค์กร เพื่อให้แน่ใจว่าข้อมูลด้านความสอดคล้องกับ WCAG 2.2 ที่รายงานออกไปสอดคล้องกับสถานะจริงของผลิตภัณฑ์ ไม่ใช่รายงานแยกกันคนละชุดโดยไม่มีการตรวจสอบไขว้กัน ซึ่งอาจนำไปสู่ความไม่สอดคล้องที่ตรวจพบได้ง่ายหากมีการตรวจสอบจากภายนอกในภายหลัง

สรุป

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

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

• W3C Web Content Accessibility Guidelines (WCAG) 2.2