เช็กลิสต์ WCAG 2.2 AA สำหรับผลิตภัณฑ์ SaaS และเว็บแอป

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

ประเด็นสำคัญ

• WCAG 2.2 ได้เป็น W3C Recommendation ในเดือนตุลาคม 2023 และเพิ่มเกณฑ์ความสำเร็จ 9 ข้อ ซึ่ง 6 ข้ออยู่ในระดับ A หรือ AA (W3C (เปิดในแท็บใหม่))
• Accessible Authentication (3.3.8, AA) หมายความว่าการเข้าสู่ระบบต้องไม่ขึ้นอยู่กับการจำหรือพิมพ์รหัสผ่านตามที่เห็น เว้นแต่ผู้ใช้จะวางรหัสผ่านหรือใช้โปรแกรมจัดการรหัสผ่านได้ (W3C (เปิดในแท็บใหม่))
• เป้าหมายที่โต้ตอบได้ต้องมีขนาดอย่างน้อย 24 × 24 พิกเซล CSS หรือมีพื้นที่รอบๆ เพียงพอ (2.5.8, AA) (W3C (เปิดในแท็บใหม่))
• ข้อความอย่าง “บันทึกแล้ว” หรือ “3 ผลลัพธ์” ต้องส่งถึงโปรแกรมอ่านหน้าจอโดยไม่ย้ายโฟกัส (4.1.3, AA) (W3C (เปิดในแท็บใหม่))
• ผู้ซื้อภาคธุรกิจและภาครัฐมักขอ Accessibility Conformance Report ซึ่งมักจัดทำบนเทมเพลต VPAT ของ Information Technology Industry Council (ITI (เปิดในแท็บใหม่))

ทำไมการเข้าถึงจึงสำคัญกับ SaaS มากกว่าเว็บไซต์แนะนำบริษัท

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

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

ทำให้การสมัครใช้งานและการเข้าสู่ระบบเข้าถึงได้อย่างไร

การยืนยันตัวตนคือส่วนที่ WCAG 2.2 เพิ่มข้อกำหนดใหม่ที่สำคัญที่สุดสำหรับ SaaS

• อนุญาตให้วางข้อความและใช้โปรแกรมจัดการรหัสผ่าน (3.3.8, AA) อย่าบล็อกการวางในช่องรหัสผ่านหรือช่องรหัสยืนยัน และใช้ autocomplete="username", autocomplete="current-password" และ autocomplete="one-time-code" เพื่อให้เบราว์เซอร์และโปรแกรมจัดการรหัสผ่านกรอกให้ได้
• อย่าใช้ปริศนาเป็นทางเข้าเพียงทางเดียว CAPTCHA ที่ให้พิมพ์ตัวอักษรที่บิดเบี้ยวหรือแก้ปริศนาถือเป็นการทดสอบการทำงานของสมอง (cognitive function test) ให้มีทางเลือกอื่น และเลือกใช้การตรวจที่ไม่ต้องให้ผู้ใช้ทำอะไร (W3C (เปิดในแท็บใหม่))
• ใส่ป้ายกำกับให้ทุกช่อง (1.3.1 และ 3.3.2, A) ใช้ <label> ที่มองเห็นได้และเชื่อมกับช่องกรอก ข้อความ placeholder จะหายไปเมื่อเริ่มพิมพ์และไม่ใช่ป้ายกำกับ
• ระบุข้อผิดพลาดเป็นข้อความ (3.3.1, A) และเสนอวิธีแก้ (3.3.3, AA) ข้อความ “รหัสผ่านต้องมีอย่างน้อย 12 อักขระ” ช่วยได้ แต่ขอบสีแดงเพียงอย่างเดียวช่วยไม่ได้
• อย่าถามซ้ำ (3.3.7, A) หากการสมัครแบบหลายขั้นตอนถามชื่อบริษัทหรือที่อยู่ไปแล้ว ให้กรอกให้อัตโนมัติหรือให้ผู้ใช้เลือกแทนการพิมพ์ใหม่
• วางความช่วยเหลือไว้ที่เดิม (3.2.6, A) หากคุณมีแชต ลิงก์ความช่วยเหลือ หรือข้อมูลติดต่อ ให้วางไว้ในตำแหน่งสัมพัทธ์เดียวกันในทุกหน้าของขั้นตอนนั้น

รูปแบบฟอร์มและข้อผิดพลาดแบบใดทำให้เกิดปัญหามากที่สุด

ปัญหาส่วนใหญ่ของแอปพลิเคชันอยู่ในฟอร์ม แบบสำรวจของ WebAIM ปี 2026 กับหน้าแรก 1 ล้านหน้าพบว่า 51% ไม่มีป้ายกำกับฟอร์ม (WebAIM (เปิดในแท็บใหม่)) และแอปพลิเคชันมีฟอร์มมากกว่าหน้าแรกหลายเท่า

• ให้ช่องกรอกทุกช่องมีชื่อที่โปรแกรมอ่านได้ (programmatic name) และจัดกลุ่มตัวควบคุมที่เกี่ยวข้องกัน เช่น ปุ่มตัวเลือก ด้วย <fieldset> และ <legend>
• แจ้งข้อผิดพลาดในตำแหน่งที่ผู้ใช้จะสังเกตเห็น เช่น ย้ายโฟกัสไปที่สรุปข้อผิดพลาดด้านบนฟอร์ม หรือไปที่ช่องแรกที่ไม่ถูกต้อง และลิงก์รายการในสรุปแต่ละรายการไปยังช่องของมัน
• ระบุช่องที่จำเป็นเป็นข้อความ ไม่ใช่ใช้สีเพียงอย่างเดียว (1.4.1, A)
• อย่าส่งฟอร์มหรือเปลี่ยนบริบทเพียงเพราะผู้ใช้เลือกตัวเลือก (3.2.2, A) ให้รอการกระทำที่ชัดเจน

กล่องโต้ตอบ เมนู และป๊อปโอเวอร์ควรทำงานอย่างไร

คอมโพเนนต์ที่สร้างขึ้นเองเป็นจุดที่การรองรับคีย์บอร์ดและโปรแกรมอ่านหน้าจอเสียบ่อยที่สุด WAI-ARIA Authoring Practices Guide อธิบายพฤติกรรมที่ควรเป็นของแต่ละรูปแบบไว้ (W3C (เปิดในแท็บใหม่))

• กล่องโต้ตอบ: ย้ายโฟกัสเข้าไปในกล่องเมื่อเปิด ให้ Tab วนอยู่ภายในขณะที่เปิดอยู่ ปิดได้ด้วย Escape และคืนโฟกัสไปยังตัวควบคุมที่เปิดกล่องนั้น ใช้องค์ประกอบ <dialog> ของเบราว์เซอร์ หรือ role="dialog" พร้อม aria-modal="true" และชื่อ
• ไม่มีกับดักคีย์บอร์ด (2.1.2, A): ทุกคอมโพเนนต์ต้องออกได้ด้วยคีย์บอร์ด
• โฟกัสที่มองเห็นได้ (2.4.7, AA) และไม่ถูกบังด้วยส่วนหัวแบบติดหน้าจอ แบนเนอร์คุกกี้ หรือวิดเจ็ตแชต (2.4.11, AA ซึ่งเพิ่มใหม่ใน 2.2)
• Tooltip และป๊อปโอเวอร์ (1.4.13, AA) ที่ผู้ใช้ปิดได้ด้วย Escape ชี้เมาส์ไปบนนั้นได้โดยไม่หายไป และยังแสดงอยู่จนกว่าจะปิด
• คีย์ลัดแบบปุ่มเดียว (2.1.4, A): หากการกดปุ่มตัวอักษรทำให้เกิดการกระทำ ให้ผู้ใช้ปิดหรือกำหนดคีย์ลัดใหม่ได้ หรือให้คีย์ลัดทำงานเฉพาะเมื่อคอมโพเนนต์ที่เกี่ยวข้องได้รับโฟกัส

จัดการการนำทางในแอปแบบหน้าเดียวอย่างไร

ในแอปแบบหน้าเดียว (single-page app) URL จะเปลี่ยนโดยไม่โหลดหน้าใหม่ โปรแกรมอ่านหน้าจอจึงอาจไม่ประกาศว่ามีอะไรเกิดขึ้น

• อัปเดตชื่อเอกสาร (document title) ทุกครั้งที่เปลี่ยนเส้นทาง เพื่อให้ทุกมุมมองมีชื่อที่สื่อความหมาย (2.4.2, A)
• ย้ายโฟกัสไปที่หัวข้อหลักของมุมมองใหม่ หรือประกาศการเปลี่ยนแปลงใน live region แบบ polite เฟรมเวิร์กอย่าง Next.js มีตัวประกาศเส้นทาง (route announcer) สำหรับเรื่องนี้
• รักษาลำดับโฟกัสให้สมเหตุสมผล (2.4.3, A) หลังลบรายการใด โฟกัสควรไปยังรายการข้างเคียงที่เหมาะสม ไม่ใช่กลับไปด้านบนสุดของหน้า
• มีวิธีข้ามการนำทางที่ซ้ำกัน (2.4.1, A) เช่น ลิงก์ข้าม (skip link) หรือ landmark

ทำให้แดชบอร์ด ตารางข้อมูล และแผนภูมิเข้าถึงได้อย่างไร

• ตาราง: ใช้ markup <table> จริงพร้อม <th> และ scope สำหรับส่วนหัว และมีคำอธิบายตาราง (1.3.1, A) กริดที่สร้างจากองค์ประกอบ <div> ต้องใช้รูปแบบ ARIA grid แบบเต็ม ซึ่งทำให้ถูกต้องได้ยากกว่ามาก
• แผนภูมิ: ให้แผนภูมิแต่ละอันมีข้อความทดแทนที่บอกประเด็นหลัก และมีข้อมูลในรูปตาราง (1.1.1, A) อย่าใช้สีเพียงอย่างเดียวในการแยกชุดข้อมูล (1.4.1, A) ให้เพิ่มป้ายกำกับหรือลวดลาย
• คอนทราสต์: ข้อความต้องได้ 4.5:1 (1.4.3, AA) ส่วนเส้นในแผนภูมิ ไอคอน และเส้นขอบช่องกรอกต้องได้ 3:1 เทียบกับพื้นหลัง (1.4.11, AA) ตรวจโหมดมืดแยกต่างหาก เครื่องมือตรวจสอบคอนทราสต์สี ของเราทดสอบคู่สีได้ทุกคู่
• ข้อความสถานะ (4.1.3, AA): “บันทึกแล้ว” “อัปโหลดเสร็จแล้ว” และจำนวนผลลัพธ์ควรใช้ role="status" หรือ live region เพื่อให้โปรแกรมอ่านหน้าจอได้ยินโดยไม่เสียตำแหน่งที่อ่านอยู่

เกณฑ์ใหม่ของ WCAG 2.2 เปลี่ยนอะไรสำหรับเว็บแอป

WCAG 2.2 ยังตัด 4.1.1 Parsing ออก เพราะไม่มีผลในทางปฏิบัติต่อการเข้าถึงแล้ว (W3C (เปิดในแท็บใหม่))

แล้วเรื่องการหมดเวลา เลย์เอาต์ และการซูมล่ะ

• การหมดเวลาของเซสชัน (2.2.1, A): เตือนผู้ใช้ก่อนเซสชันหมดอายุ และให้ขยายเวลาได้ด้วยการกระทำง่ายๆ เว้นแต่การจำกัดเวลานั้นจำเป็นหรือยาวกว่า 20 ชั่วโมง การบันทึกงานที่ทำค้างไว้ช่วยป้องกันผลที่แย่ที่สุด
• การจัดเรียงใหม่ (1.4.10, AA): เนื้อหาต้องใช้งานได้ที่ความกว้าง 320 พิกเซล CSS (เทียบเท่าการซูม 400% บนหน้าจอ 1280 พิกเซล) โดยไม่ต้องเลื่อนสองทิศทาง ตารางข้อมูลและเนื้อหาลักษณะเดียวกันได้รับการยกเว้น
• ระยะห่างของข้อความ (1.4.12, AA): การเพิ่มความสูงบรรทัดและระยะห่างตัวอักษรต้องไม่ทำให้ข้อความถูกตัด ซึ่งมักเกิดกับกล่องที่กำหนดความสูงตายตัว
• การวางแนวหน้าจอ (1.3.4, AA): อย่าล็อกแอปไว้ที่แนวตั้งหรือแนวนอน เว้นแต่จำเป็น

ACR คืออะไร และคุณจำเป็นต้องมีหรือไม่

Accessibility Conformance Report (ACR) บันทึกว่าผลิตภัณฑ์ทำตามเกณฑ์การเข้าถึงแต่ละข้ออย่างไร ได้แก่ รองรับ รองรับบางส่วน หรือไม่รองรับ พร้อมหมายเหตุ ส่วนใหญ่จัดทำบนเทมเพลต VPAT ที่เผยแพร่โดย Information Technology Industry Council ซึ่งมีฉบับสำหรับ WCAG มาตรฐาน Section 508 ของสหรัฐฯ และมาตรฐานยุโรป EN 301 549 (ITI (เปิดในแท็บใหม่))

หน่วยงานรัฐบาลกลางของสหรัฐฯ ต้องซื้อเทคโนโลยีที่เข้าถึงได้ตาม Section 508 (Section508.gov (เปิดในแท็บใหม่)) และหน่วยงานภาครัฐในสหภาพยุโรปอ้างอิง EN 301 549 ผลิตภัณฑ์ B2B ที่ขายให้ลูกค้าเหล่านี้จึงมักถูกขอ ACR ในขั้นตอนจัดซื้อ ACR ที่ซื่อตรงและระบุช่องโหว่ที่ทราบไว้มีประโยชน์ต่อผู้ซื้อมากกว่า ACR ที่อ้างว่ารองรับทั้งหมด ACR ควรอ้างอิงจากการทดสอบผลิตภัณฑ์ รวมถึงการทดสอบด้วยคน การสแกนอัตโนมัติเพียงอย่างเดียวไม่สามารถกรอก ACR ได้

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

ทีม SaaS ควรทดสอบการเข้าถึงอย่างไร

1. ทำส่วนพื้นฐานให้เป็นอัตโนมัติ รัน axe-core หรือเอนจินที่คล้ายกันในการทดสอบแบบ end-to-end และบนเว็บไซต์การตลาด และให้ build ล้มเมื่อพบการละเมิดใหม่ เครื่องมือตรวจสอบการเข้าถึงฟรี ของเราใช้เอนจินเดียวกันกับหน้าสาธารณะใดก็ได้
2. ทดสอบด้วยคีย์บอร์ด ทำขั้นตอนการทำงานหลัก เช่น การสมัคร การสร้างระเบียนข้อมูล และการเปลี่ยนการตั้งค่า โดยใช้เพียง Tab, Shift+Tab, Enter, Space, Escape และปุ่มลูกศร
3. ทดสอบด้วยโปรแกรมอ่านหน้าจอ NVDA บน Windows และ VoiceOver บน macOS และ iOS ใช้ได้ฟรี ตรวจว่ามีการประกาศชื่อ บทบาท สถานะ และข้อความ
4. ซูมและปรับขนาด ตรวจการซูมข้อความ 200% และหน้าต่างกว้าง 320 พิกเซล
5. แก้ที่ระบบดีไซน์ ปัญหาส่วนใหญ่มาจากคอมโพเนนต์ที่ใช้ร่วมกัน การแก้ปุ่มหรือกล่องโต้ตอบครั้งเดียวจะแก้ได้ทุกที่

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

WCAG ใช้กับส่วนของเว็บแอปที่ต้องเข้าสู่ระบบหรือไม่

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

โอเวอร์เลย์ทำให้ผลิตภัณฑ์ SaaS เข้าถึงได้หรือไม่

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

เครื่องมืออัตโนมัติตรวจ WCAG ได้มากแค่ไหน

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

เราควรตั้งเป้า WCAG เวอร์ชันใด

WCAG 2.2 ระดับ AA เป็นเวอร์ชันปัจจุบัน กฎหมายและกฎการจัดซื้อจำนวนมากยังอ้างอิง WCAG 2.1 AA การผ่าน 2.2 AA ก็ถือว่าผ่าน 2.1 AA ด้วย ยกเว้นเกณฑ์ Parsing ที่ถูกตัดออกไป

เราต้องผ่านระดับ AAA หรือไม่

W3C ไม่แนะนำให้กำหนด AAA กับทั้งผลิตภัณฑ์ เพราะเนื้อหาบางอย่างไม่สามารถผ่านเกณฑ์ AAA ได้ทุกข้อ ระดับ AA จึงเป็นเป้าหมายทั่วไป

แหล่งที่มา

• W3C: What's new in WCAG 2.2 (เปิดในแท็บใหม่)
• W3C: Web Content Accessibility Guidelines (WCAG) 2.2 (เปิดในแท็บใหม่)
• W3C: Understanding 3.3.8 Accessible Authentication (Minimum) (เปิดในแท็บใหม่)
• W3C: Understanding 2.5.8 Target Size (Minimum) (เปิดในแท็บใหม่)
• W3C: Understanding 4.1.3 Status Messages (เปิดในแท็บใหม่)
• W3C: ARIA Authoring Practices Guide: Dialog (modal) pattern (เปิดในแท็บใหม่)
• W3C: Inaccessibility of CAPTCHA (เปิดในแท็บใหม่)
• ITI: Voluntary Product Accessibility Template (VPAT) (เปิดในแท็บใหม่)
• GSA: Section508.gov (เปิดในแท็บใหม่)
• WebAIM: The WebAIM Million (2026) (เปิดในแท็บใหม่)