วิธี Audit WCAG 2.2 ของร้านค้าออนไลน์และ E-commerce พร้อม Evidence ที่ควรเก็บ

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

นิยาม Audit WCAG 2.2 ต่างจาก Automated Scan อย่างไร

Automated Scan คือเครื่องมือที่ไล่ตรวจโค้ด HTML เทียบกับกฎที่ตั้งไว้ล่วงหน้า เช่น รูปที่ไม่มี Alt Text หรือคอนทราสต์สีที่ต่ำกว่าเกณฑ์ เครื่องมือประเภทนี้ตรวจได้เร็วและครอบคลุมหลายหน้าพร้อมกัน แต่ไม่สามารถประเมินได้ว่าข้อความ Alt ที่มีอยู่สื่อความหมายจริงหรือไม่ หรือผู้ใช้คีย์บอร์ดจะติดอยู่ตรงจุดใดของหน้า

Audit คือกระบวนการที่มีคนเข้าไปตรวจจริง ผสมทั้งผลจาก Automated Scan และการทดสอบด้วยคีย์บอร์ด โปรแกรมอ่านหน้าจอ และการเดินตามเส้นทางผู้ใช้จริง (User Flow) แล้วสรุปเป็น Finding พร้อมหลักฐาน Audit จึงให้ภาพที่ใกล้เคียงประสบการณ์จริงของผู้ใช้มากกว่าการอ่านคะแนนสแกนเพียงอย่างเดียว

ขั้นตอน Audit WCAG 2.2 ทีละขั้น

ขั้นที่ 1 — กำหนดขอบเขตและระดับเป้าหมาย

ก่อนเริ่ม ต้องตกลงกันก่อนว่าจะตรวจกี่หน้า ครอบคลุมเทมเพลตแบบใดบ้าง และอ้างอิงระดับใดของ WCAG 2.2 ส่วนใหญ่ธุรกิจใช้ระดับ AA เป็นเป้าหมายเชิงปฏิบัติ ควรระบุให้ชัดว่า Audit รอบนี้ครอบคลุมเฉพาะหน้าที่เข้าถึงได้แบบสาธารณะ ไม่รวมส่วนหลังบ้านหรือหน้าที่ต้องล็อกอินก่อน เว้นแต่จะรวมไว้ในขอบเขตตั้งแต่ต้น

ขั้นที่ 2 — รัน Automated Scan เป็นจุดเริ่มต้น

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

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

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

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

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

ขั้นที่ 5 — สรุปเป็น Finding พร้อมหลักฐาน

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

Evidence ที่ควรเก็บระหว่าง Audit

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

• ภาพหน้าจอของจุดที่มีปัญหา พร้อมวงกลมหรือลูกศรชี้ตำแหน่งชัดเจน
• โค้ด HTML เฉพาะส่วนที่เกี่ยวข้อง เช่น แท็ก img ที่ไม่มี alt หรือ input ที่ไม่มี label
• ชุดเบราว์เซอร์และโปรแกรมอ่านหน้าจอที่ใช้ทดสอบ พร้อมเวอร์ชัน
• วันที่และเวลาที่ทดสอบ เพราะเว็บไซต์อาจเปลี่ยนแปลงหลังอัปเดตธีมหรือปลั๊กอิน
• ลิงก์หรือ URL ของหน้าที่พบปัญหา ระบุให้ตรงเทมเพลตหรือหน้าเฉพาะ

กรณีเฉพาะของ E-commerce ที่ Audit ต้องให้น้ำหนักเป็นพิเศษ

ร้านค้าออนไลน์มีองค์ประกอบที่ธุรกิจประเภทอื่นไม่ค่อยมี ซึ่งควรอยู่ในขอบเขตของทุก Audit

ฟอร์ม Checkout และการชำระเงิน

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

ตัวกรองและการเรียงลำดับสินค้า

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

แชทสดและป๊อปอัปโปรโมชัน

ตรวจว่าหน้าต่างแชทสดหรือป๊อปอัปส่วนลดไม่บล็อกโฟกัสของคีย์บอร์ดไม่ให้กลับไปหน้าหลัก และมีปุ่มปิดที่กดถึงง่ายด้วยคีย์บอร์ด

รีวิวสินค้าและเนื้อหาที่ผู้ใช้สร้างเอง

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

บทบาทและเครื่องมือที่เกี่ยวข้องกับการ Audit

การ Audit ที่ได้ผลจริงมักไม่ใช่งานของคนคนเดียว ทีมที่เกี่ยวข้องโดยทั่วไปมีดังนี้

ผู้ตรวจสอบ Accessibility

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

ทีมพัฒนา (Developer)

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

เจ้าของร้านค้าหรือผู้จัดการโครงการ

ตัดสินใจจัดลำดับงบประมาณและเวลา โดยเฉพาะเมื่อ Finding มีจำนวนมากและต้องเลือกว่าจะแก้ส่วนใดก่อนตามความเสี่ยงต่อธุรกิจ

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

ระดับความรุนแรงของ Finding และความถี่ในการ Audit ซ้ำ

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

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

การจัดลำดับความสำคัญของ Finding

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

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

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

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

Audit WCAG 2.2 กับ Automated Scan ต่างกันอย่างไร

Automated Scan คือการรันเครื่องมือตรวจโค้ดอัตโนมัติที่จับปัญหาโครงสร้างบางประเภทได้เร็ว ส่วน Audit คือกระบวนการที่มีคนทดสอบด้วยคีย์บอร์ดและโปรแกรมอ่านหน้าจอเพิ่มเติม เพื่อดูปัญหาเชิงพฤติกรรมที่เครื่องมือมองไม่เห็น

ควรเก็บ Evidence อะไรบ้างระหว่าง Audit

ควรเก็บภาพหน้าจอของจุดที่มีปัญหา โค้ด HTML ส่วนที่เกี่ยวข้อง ชุดเบราว์เซอร์และโปรแกรมอ่านหน้าจอที่ใช้ทดสอบ วันที่ทดสอบ และ URL ของหน้าที่พบปัญหา

Audit ควรครอบคลุมหน้าไหนบ้างในร้านค้าออนไลน์

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

จัดลำดับ Finding จาก Audit อย่างไรให้เหมาะสม

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

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

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

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

• ใช้ผลจาก Automated Scan เพียงอย่างเดียวแล้วเรียกว่าเป็นการ Audit เต็มรูปแบบ
• เขียน Finding แบบกว้าง ๆ เช่น "ปัญหาด้าน Accessibility" โดยไม่มีหลักฐานหรือตำแหน่งที่ชัดเจน
• ไม่บันทึกวันที่ Audit ทำให้ตรวจไม่ได้ว่าปัญหาที่พบยังอยู่หลังอัปเดตธีมหรือไม่
• จัดลำดับ Finding ตามความง่ายในการแก้ แทนที่จะดูผลกระทบต่อผู้ใช้จริง
• ตรวจเฉพาะหน้า Desktop โดยไม่ทดสอบเวอร์ชันมือถือที่ลูกค้าส่วนใหญ่ใช้จริง

สรุป

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

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

• W3C — Web Content Accessibility Guidelines (WCAG) 2.2