วิธี Audit WCAG 2.2 ของคลินิก โรงพยาบาล และธุรกิจสุขภาพ พร้อม Evidence ที่ควรเก็บ

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

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

ขั้นตอนที่ 1 — กำหนดขอบเขตหน้าที่มีความเสี่ยงสูงสุดก่อน

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

บันทึกขอบเขตนี้เป็นเอกสารต้นทาง เพื่อให้รอบตรวจถัดไปเทียบกับรอบก่อนหน้าได้ และเพื่อให้ผู้บริหารเห็นว่าอะไรอยู่ในและนอกขอบเขตของรอบนี้

ขั้นตอนที่ 2 — สแกนอัตโนมัติเพื่อจับปัญหาเชิงโครงสร้าง

เครื่องมือสแกนอัตโนมัติตรวจจับปัญหาบางประเภทได้ดี เช่น รูปภาพที่ไม่มี alt text, contrast สีที่ต่ำกว่าเกณฑ์บางจุด, label ฟอร์มที่ขาดหาย, โครงสร้าง Heading ที่กระโดดข้ามระดับ และภาษาที่ไม่ได้ระบุใน HTML ผลลัพธ์เหล่านี้เป็นจุดเริ่มต้นที่ดีสำหรับให้ทีมพัฒนาไล่แก้ไขก่อน

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

ขั้นตอนที่ 3 — ทดสอบด้วยคีย์บอร์ดอย่างเดียวทั้งกระบวนการ

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

ขั้นตอนที่ 4 — ทดสอบด้วยโปรแกรมอ่านหน้าจอจริง

เลือกโปรแกรมอ่านหน้าจออย่างน้อยหนึ่งตัว เช่น NVDA บน Windows หรือ VoiceOver บน macOS/iOS แล้วไล่ฟังทุกขั้นตอนของฟอร์มนัดหมายและการล็อกอินพอร์ทัลผู้ป่วย บันทึกว่าชื่อฟิลด์ถูกอ่านออกมาถูกต้องหรือไม่ ข้อความ error ถูกประกาศทันทีหรือต้องเลื่อนหาเอง และปุ่มที่สร้างขึ้นเองมีชื่อที่สื่อความหมายหรือถูกอ่านว่าเป็นเพียง "ปุ่ม" เฉยๆ

ขั้นตอนนี้มักเผยปัญหาที่การสแกนอัตโนมัติมองไม่เห็น เช่น ปุ่มยืนยันการจองที่เป็น div ไม่มี role ตามตัวอย่างต้นเรื่อง ซึ่งสแกนอัตโนมัติอาจไม่ฟ้องเป็น error เลยเพราะโครงสร้าง HTML ยังผ่านการตรวจสอบทางเทคนิคพื้นฐาน

ขั้นตอนที่ 5 — เก็บ Evidence ให้ตรวจซ้ำได้

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

เครื่องมือที่ใช้บ่อยและข้อจำกัดของแต่ละแบบ

ทีมเว็บไซต์สุขภาพมักใช้เครื่องมือ Audit สามกลุ่มร่วมกัน กลุ่มแรกคือส่วนขยายเบราว์เซอร์ที่สแกนหน้าเดียวได้เร็ว เหมาะกับการตรวจระหว่างพัฒนา แต่ไม่เห็นพฤติกรรมข้ามหลายหน้าอย่างขั้นตอนจองคิวที่มีหลายขั้น กลุ่มที่สองคือเครื่องมือสแกนแบบไล่ทั้งเว็บไซต์ (Crawler) ที่ช่วยเห็นภาพรวมปัญหาเชิงโครงสร้างในสเกลใหญ่ แต่ยังตรวจปฏิสัมพันธ์ที่ต้องคลิกหลายขั้นตอนไม่ได้ กลุ่มที่สามคือการทดสอบด้วยคนจริง ทั้งคีย์บอร์ดและโปรแกรมอ่านหน้าจอ ซึ่งเป็นกลุ่มเดียวที่จับปัญหาเชิงพฤติกรรมและลำดับการใช้งานจริงได้

ตารางด้านล่างสรุปความแตกต่างระหว่างสิ่งที่การสแกนอัตโนมัติกับการทดสอบด้วยคนมักพบ เพื่อให้ทีมวางแผนว่าควรใช้เวลากับขั้นตอนไหนมากกว่ากัน

สถานการณ์เฉพาะของเว็บไซต์สุขภาพที่ควร Audit เพิ่มจากเว็บไซต์ทั่วไป

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

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

ขั้นตอนที่ 6 — จัดลำดับความสำคัญและ Retest

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

ดูรายการเกณฑ์ที่ควรตรวจแบบละเอียดเพิ่มเติมได้ที่ เช็กลิสต์ WCAG 2.2 สำหรับ Healthcare และภาพรวมของกลุ่มบทความ Accessibility ทั้งหมดที่ Accessibility & Trust UX

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

Audit WCAG 2.2 ด้วยตัวเองใช้เวลานานเท่าไรสำหรับเว็บไซต์โรงพยาบาล

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

ต้องใช้เครื่องมือสแกนอัตโนมัติกี่ตัวถึงจะเพียงพอ

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

ถ้าไม่มีทีม Accessibility ภายใน ควรเริ่มจากตรงไหนก่อน

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

Evidence ที่เก็บระหว่าง Audit ต้องส่งให้ใครดูบ้าง

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

Retest ต้องทำซ้ำทุกข้อหรือเฉพาะจุดที่แก้ไข

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

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

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

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

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

สรุป

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

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

• W3C — Web Content Accessibility Guidelines (WCAG) 2.2
• W3C Web Accessibility Initiative — Evaluating Web Accessibility