วิธีทำให้เว็บไซต์ของคุณเข้าถึงได้: คู่มือเริ่มต้น WCAG 2.2

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

"เข้าถึงได้" หมายความว่าอะไรในทางปฏิบัติ

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

มาตรฐานอ้างอิงคือ Web Content Accessibility Guidelines (WCAG) ของ W3C ณ เดือนกันยายน 2026 เวอร์ชันปัจจุบันคือ WCAG 2.2 (เผยแพร่ตุลาคม 2023 อัปเดตธันวาคม 2024) WCAG 3 เป็นร่างเบื้องต้น WCAG จัดระเบียบรอบสี่หลักการ — เนื้อหาต้อง รับรู้ได้ ใช้งานได้ เข้าใจได้ และทนทาน — และมีสามระดับการปฏิบัติตาม:

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

ตัวเลือก: วิธีไปถึงจุดนั้น

สำหรับเว็บขนาดเล็กส่วนใหญ่ สองแนวทางแรกเพียงพอ: บอก AI ให้สร้างอย่างเข้าถึงได้ตั้งแต่ต้น แล้วตรวจก่อนเปิดตัว

การแก้ไขที่สำคัญที่สุด

ใช้องค์ประกอบ HTML ที่ถูกต้อง

การเข้าถึงส่วนใหญ่มาฟรีกับ HTML ที่ถูกต้อง <button> รับโฟกัสได้ ทำงานกับ Enter และ Space และถูกประกาศว่าเป็นปุ่ม <div> ที่มี click handler ไม่มีสิ่งเหล่านั้นเลย โค้ดที่ AI สร้างบางครั้งใช้ div ที่ตกแต่งแล้วสำหรับทุกอย่าง ให้ขอองค์ประกอบเชิงความหมาย:

• <button> สำหรับการกระทำ <a href> สำหรับการนำทาง
• <h1> หนึ่งตัวต่อหน้า แล้ว <h2> <h3> ตามลำดับ — ผู้ใช้โปรแกรมอ่านหน้าจอกระโดดระหว่างหัวข้อ
• แลนด์มาร์ก: <header> <nav> <main> <footer>
• <label> ที่เชื่อมกับฟิลด์ฟอร์มทุกช่อง
• ภาษาของหน้าใน <html lang="th">

ใช้คุณลักษณะ ARIA เฉพาะเมื่อไม่มีองค์ประกอบพื้นฐานที่เหมาะสม เช่น ชุดแท็บหรือ combobox แบบกำหนดเอง ARIA ที่ผิดแย่กว่าไม่มีเลย

การเข้าถึงด้วยคีย์บอร์ดและโฟกัสที่มองเห็นได้

ทุกอย่างที่ทำด้วยเมาส์ได้ ต้องทำได้ด้วยคีย์บอร์ดเพียงอย่างเดียว (WCAG 2.1.1) กด Tab ผ่านหน้า: ทุกลิงก์ ปุ่ม และช่องกรอกควรเข้าถึงได้ตามลำดับที่สมเหตุสมผล และคุณควรเห็นว่าโฟกัสอยู่ตรงไหนเสมอ (2.4.7 Focus Visible) WCAG 2.2 เพิ่มว่าองค์ประกอบที่ถูกโฟกัสต้องไม่ถูกบังโดยสมบูรณ์ด้วยส่วนหัวแบบ sticky หรือแบนเนอร์คุกกี้ (2.4.11 ระดับ AA)

ความล้มเหลวที่พบบ่อย: เมนูที่เปิดเฉพาะเมื่อชี้เมาส์ โมดัลที่ไม่กักโฟกัสหรือปิดด้วย Escape ไม่ได้ และ outline: none ใน CSS โดยไม่มีอะไรมาแทน

ข้อความทางเลือกของเนื้อหา

รูปภาพที่มีความหมายทุกรูปต้องมี alt text ที่บอกว่ามันแสดงอะไรในบริบท ("เชฟจัดจานเมนูชิมรส" ไม่ใช่ "image1.jpg") รูปตกแต่งให้ใส่ alt="" ว่างเปล่า เพื่อให้โปรแกรมอ่านหน้าจอข้ามไป ปุ่มที่มีแต่ไอคอนต้องมีชื่อที่เข้าถึงได้ ("ปิด" "ค้นหา") วิดีโอต้องมีคำบรรยาย เสียงต้องมีข้อความถอดเสียง

สีและคอนทราสต์

WCAG 2.2 ระดับ AA กำหนดอัตราส่วนคอนทราสต์อย่างน้อย 4.5:1 สำหรับข้อความปกติ และ 3:1 สำหรับข้อความขนาดใหญ่ (1.4.3) และ 3:1 สำหรับส่วนประกอบของอินเทอร์เฟซ เช่น เส้นขอบช่องกรอกและไอคอนที่มีความหมาย (1.4.11) ข้อความ placeholder สีเทาอ่อนและปุ่มสีจางคือความล้มเหลวที่พบบ่อย นอกจากนี้ อย่าใช้สีเพียงอย่างเดียวเพื่อสื่อความหมาย — กรอบสีแดงของช่องที่ไม่ถูกต้องต้องมีข้อความแสดงข้อผิดพลาดด้วย

การปรับขนาดและการจัดเรียงใหม่

ข้อความต้องใช้งานได้เมื่อซูมถึง 200% (1.4.4) และเนื้อหาต้องทำงานที่ความกว้าง 320 พิกเซล CSS โดยไม่ต้องเลื่อนแนวนอน (1.4.10) เลย์เอาต์ที่ตอบสนอง ที่ดีจัดการเรื่องนี้ได้ส่วนใหญ่

เป้าหมายการแตะ ฟอร์ม และข้อผิดพลาด

• ขนาดเป้าหมาย: WCAG 2.2 ระดับ AA กำหนดให้เป้าหมายการชี้อย่างน้อย 24 x 24 พิกเซล CSS หรือมีระยะห่างรอบรายการที่เล็กกว่า (2.5.8) ใหญ่กว่าจะเป็นมิตรกับโทรศัพท์มากกว่า
• ฟอร์ม: ป้ายกำกับที่มองเห็นได้ (ไม่ใช่แค่ placeholder) คำแนะนำที่ชัดเจน และข้อความแสดงข้อผิดพลาดที่บอกว่าผิดตรงไหนและแก้อย่างไร อยู่ข้างช่องนั้น
• การล็อกอิน: อย่าให้คนต้องแก้ปริศนาหรือพิมพ์รหัสโดยไม่มีทางเลือกอื่น อนุญาตให้ใช้ตัวจัดการรหัสผ่านและการวาง (3.3.8 Accessible Authentication)

พรอมต์ที่ได้ผล

สร้างเว็บนี้ให้เป็นไปตาม WCAG 2.2 ระดับ AA: แลนด์มาร์ก HTML เชิงความหมาย h1 หนึ่งตัวต่อหน้าพร้อมหัวข้อตามลำดับ องค์ประกอบปุ่มและลิงก์จริง ป้ายกำกับทุกช่องของฟอร์ม สไตล์โฟกัสที่มองเห็นได้ คอนทราสต์ข้อความอย่างน้อย 4.5:1 alt text บนรูปที่มีความหมายและ alt="" บนรูปตกแต่ง และตั้ง html lang

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

เมนูมือถือใช้ด้วยคีย์บอร์ดไม่ได้ ทำให้เป็นปุ่มที่มี aria-expanded ย้ายโฟกัสเข้าเมนูเมื่อเปิด ปิดด้วย Escape และคืนโฟกัสไปที่ปุ่ม

ทีละขั้นตอน

1. รันการตรวจอัตโนมัติ ส่วน Accessibility ของ Lighthouse ใน Chrome DevTools หรือส่วนขยาย axe บนเบราว์เซอร์ ในแต่ละหน้าหลัก แก้ทุกอย่างที่รายงาน
2. ถอดเมาส์ออก กด Tab ผ่านแต่ละหน้าและทำงานหลักให้เสร็จทั้งหมด เช่น ลงทะเบียน ค้นหา ชำระเงิน จดสิ่งที่คุณเข้าไม่ถึง มองไม่เห็นโฟกัส หรือออกไม่ได้
3. ซูมถึง 200% และย่อหน้าต่างให้เท่าความกว้างโทรศัพท์ ไม่ควรมีอะไรถูกตัดหรือต้องเลื่อนแนวนอน
4. ลองโปรแกรมอ่านหน้าจอ สิบนาที: VoiceOver บน Mac และ iPhone, TalkBack บน Android หรือ NVDA บน Windows (ฟรี) ฟังหัวข้อ ลิงก์ และช่องฟอร์ม "ปุ่ม" ที่ไม่มีชื่อ หรือ "ลิงก์ คลิกที่นี่" หมายถึงงานที่ต้องทำ
5. ตรวจคอนทราสต์ ของข้อความ ปุ่ม และช่องกรอกด้วยเครื่องมือตรวจคอนทราสต์
6. แก้ แล้วทดสอบใหม่ งานเดิม
7. เผยแพร่คำแถลงการเข้าถึง ที่ระบุมาตรฐานที่คุณตั้งเป้าและวิธีรายงานปัญหา — และตอบรายงานเหล่านั้น

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

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

รายการตรวจการเข้าถึง

• การตรวจอัตโนมัติ (Lighthouse หรือ axe) ผ่านในหน้าหลัก
• ทุกงานทำได้ด้วยคีย์บอร์ดเพียงอย่างเดียว
• โฟกัสมองเห็นได้เสมอ และไม่ถูกซ่อนหลังองค์ประกอบ sticky
• หัวข้อ แลนด์มาร์ก ปุ่ม และลิงก์เชิงความหมาย ตั้งค่า lang แล้ว
• alt text ที่มีความหมาย รูปตกแต่งใช้ alt="" มีคำบรรยายในวิดีโอ
• คอนทราสต์ข้อความ ≥ 4.5:1 (ข้อความขนาดใหญ่ ≥ 3:1) ส่วน UI ≥ 3:1
• ใช้งานได้ที่การซูม 200% และความกว้าง 320 พิกเซล
• ทุกช่องฟอร์มมีป้ายกำกับที่มองเห็นได้และข้อความข้อผิดพลาดที่ชัดเจน
• มีคำแถลงการเข้าถึงพร้อมช่องทางรายงานปัญหา

สำหรับแนวคิดเบื้องหลัง อ่าน การเข้าถึงเว็บคืออะไร การออกแบบที่เข้าถึงได้และการออกแบบที่ดีทับซ้อนกันมาก วิธีออกแบบแอปที่สวยงามด้วย AI ครอบคลุมด้านภาพ

การเข้าถึงบน Mythex

Mythex สร้างตามมาตรฐานที่คุณขอ ดังนั้นใส่ "WCAG 2.2 AA" ในพรอมต์แรกและในการติดตามผล คุณใช้กรอบขนาดโทรศัพท์ของพรีวิวเพื่อตรวจหน้าจอเล็กได้ (Preview and Code) แต่การทดสอบคีย์บอร์ด การซูม และโปรแกรมอ่านหน้าจอทำงานได้ดีที่สุดบน URL ที่เผยแพร่แล้ว หรือพรีวิวที่เปิดในแท็บของตัวเอง ขอให้เอเจนต์ตรวจหน้าหนึ่ง แก้สิ่งที่พบ แล้วทดสอบการแก้ไขด้วยตัวเอง — การตรวจอัตโนมัติคือจุดเริ่มต้น ไม่ใช่การรับรองขั้นสุดท้าย

คำถาม