เว็บไซต์แบรนด์ของตัวเองกับ WCAG: เช็กลิสต์ปรับคอนทราสต์ การนำทางด้วยคีย์บอร์ด และโปรแกรมอ่านหน้าจอ
หนึ่ง ทำไมเว็บไซต์ B2B ถึงต้องทำ accessibility
หลายคนคิดว่า accessibility เป็นโครงการการกุศลเพื่อผู้พิการ ไม่เกี่ยวกับเว็บ B2B ที่ขายอุปกรณ์และหาลีด ข้อสรุปนี้ถูกแค่ครึ่งเดียว แรงผลักดันจริงมีสามข้อ: ในแบบสอบถามซัพพลายเออร์ของลูกค้ารายใหญ่ฝั่งยุโรปและอเมริกา “เว็บไซต์ผ่าน WCAG หรือไม่” กลายเป็นคำถามประจำแล้ว บางรัฐในสหรัฐฯ และการจัดซื้อของสหภาพยุโรปมีข้อกำหนดด้านการเข้าถึงสำหรับสัญญาภาครัฐและจัดซื้อสาธารณะ และที่จริงจังกว่านั้นคือ HTML ที่เป็น semantic ยังเป็นมิตรกับเสิร์ชเอนจินและ AI crawler เหมือนกัน
การตัดสินที่ขัดกับสัญชาตญาณอยู่ตรงนี้:การปรับ accessibility ไม่ใช่ต้นทุนเพิ่มเติม มันเป็นโค้ดชุดเดียวกับ SEO โครงสร้างข้อมูล และการอ้างอิงโดย AI ที่คุณอยากทำอยู่แล้ว เปลี่ยนปุ่ม div เป็น button จริง ใส่ alt ให้รูป จัดลำดับขนาดตัวอักษรให้เป็นระเบียบ สิ่งเหล่านี้จำเป็นสำหรับโปรแกรมอ่านหน้าจอ และยังเป็นแต้มบวกให้ Google กับโมเดลภาษาขนาดใหญ่เข้าใจโครงสร้างหน้าเว็บเช่นกัน ดูขอบเขตที่เกี่ยวข้องได้ที่การเข้าถึงเว็บไซต์ (WCAG) ว่าอะไรต้องทำ อะไรเลื่อนได้ก่อน
| หมวดการปรับ | เกณฑ์บังคับ WCAG 2.2 AA | ข้อผิดพลาดที่พบบ่อย | ต้นทุนการแก้ |
|---|---|---|---|
| คอนทราสต์ข้อความ | เนื้อหา ≥ 4.5:1 ตัวใหญ่ ≥ 3:1 | ตัวอักษรเทาอ่อนบนพื้นขาว ประมาณ 2.5:1 | ครึ่งวัน |
| โฟกัสคีย์บอร์ด | องค์ประกอบที่โต้ตอบได้ทุกตัวกด Tab ถึงและเห็นโฟกัส | outline:none ลบวงโฟกัสออก | หนึ่งวัน |
| alt ของรูปภาพ | รูปข้อมูลมี alt บรรยาย รูปตกแต่งเว้นว่าง | alt เป็น “image” ทั้งหมดหรือเว้นว่าง | สองวัน |
| ลำดับชั้นของหัวข้อ | h1→h2→h3 ไม่ข้ามระดับ | ข้ามจาก h2 ไป h4 เลย | ครึ่งวัน |
| ป้ายกำกับฟอร์ม | ช่องกรอกทุกช่องมี label ที่มองเห็น | ใช้แค่ placeholder เป็นป้ายกำกับ | หนึ่งวัน |
สอง เรื่องแรก: ปรับคอนทราสต์ให้ถึง 4.5:1
คอนทราสต์เป็นข้อที่วัดเป็นตัวเลขได้ง่ายที่สุด และทดสอบเองได้ง่ายที่สุดด้วย กฎไม่ซับซ้อน: ตัวอักษรขนาด 18 พอยต์ (ประมาณ 24 พิกเซล) ขึ้นไป หรือตัวหนาขนาด 14 พอยต์ (ประมาณ 18.66 พิกเซล) ต้องได้ 3:1 ส่วนข้อความเนื้อหา ตัวอักษรเล็ก และข้อความบนปุ่ม ต้องได้ 4.5:1 ตัวอักษรสีเทาตัวเล็กบนพื้นสีอ่อนคือจุดที่เว็บไซต์แบรนด์ตัวเองพลาดกันบ่อยที่สุด นักออกแบบอยากได้ความพรีเมียมเลยปรับข้อความเนื้อหาเป็น #888 วางบน #f5f5f5 ซึ่งคอนทราสต์จริงได้แค่ 2 กว่าเท่านั้น
ทดสอบเองไม่ต้องซื้อเครื่องมือ แค่ติดตั้งปลั๊กอิน axe หรือ WAVE ในเบราว์เซอร์ สแกนคลิกเดียวก็จะไฮไลต์ทุกองค์ประกอบที่คอนทราสต์ไม่ผ่าน เวลาแก้ไม่ต้องรื้อดีไซน์ทั้งหมด แค่ทำให้สีของจุดที่ไม่ผ่านเข้มขึ้น: ข้อความเนื้อหาจาก #888 เป็น #555 ก็มักผ่าน 4.5:1 แล้ว แทบไม่มีต้นทุนอะไรเลย วิธีคิดแบบนี้เหมือนกับการจับผลตอบแทนง่าย ๆ ก่อนในงานปรับประสิทธิภาพ ดูที่Core Web Vitals ในหัวข้อการจัดลำดับตามผลตอบแทน
| ประเภทองค์ประกอบ | ข้อกำหนดคอนทราสต์ระดับ AA | วิธีตรวจสอบ | วิธีแก้ที่พบบ่อย |
|---|---|---|---|
| ข้อความเนื้อหาตัวเล็ก | ≥ 4.5:1 | axe/WAVE ไฮไลต์อัตโนมัติ | เพิ่มความเข้มของสีตัวอักษรหนึ่งระดับ |
| หัวข้อตัวใหญ่ | ≥ 3:1 | เหมือนข้างต้น | มักผ่านอยู่แล้ว |
| ข้อความบนปุ่ม | ≥ 4.5:1 | ทดสอบพร้อมสีพื้น | เพิ่มความเข้มของตัวอักษรหรือสีพื้นปุ่ม |
| เส้นขอบ/ไอคอน UI | ≥ 3:1 | เทียบกับพื้นข้างเคียง | เพิ่มความเข้มของสีเส้นขอบ |
| ข้อความสถานะปิดใช้งาน | ยกเว้นได้ | ยืนยันว่าปิดใช้งานจริง | ไม่จำเป็นต้องแก้ |
สาม เรื่องที่สอง: วางเมาส์ แล้วเดินทั้งเว็บด้วยคีย์บอร์ด
วิธีตรวจสอบการนำทางด้วยคีย์บอร์ดมีอยู่ทางเดียว: ถอดเมาส์ออก แล้วใช้ Tab, Shift+Tab, Enter, Esc เดินตั้งแต่ต้นจนจบทั้งสี่หน้า ได้แก่ หน้าแรก หน้ารายการสินค้า หน้ารายละเอียดสินค้า และหน้าฟอร์มติดต่อ คุณจะเจอปัญหาสามประเภททันที: วงโฟกัสถูก CSS ลบด้วย outline: none จนมองไม่เห็นว่าตัวเองอยู่ตรงไหน เมนูแบบดรอปดาวน์เขียนด้วย JS ล้วน คีย์บอร์ดเข้าไปไม่ได้ และเมื่อเปิดป๊อปอัปแล้วโฟกัสติดอยู่ในนั้นออกไม่ได้ เรียกว่ากับดักโฟกัส
กรณีที่หนึ่ง: “ปุ่มปลอม” ที่เขียนด้วย div นักออกแบบอยากประหยัดเวลาจึงใช้ div แล้วผูกเหตุการณ์คลิก ผู้ใช้คีย์บอร์ดกด Tab ไม่ถึงและกด Enter ก็ไม่ทำงาน วิธีแก้ไม่ใช่เติม JS แต่เปลี่ยนเป็น button แท้ ๆ ซึ่งรองรับคีย์บอร์ดโดยธรรมชาติและมีชื่อสำหรับการเข้าถึงในตัว กรณีที่สอง: มองไม่เห็นวงโฟกัส สไตล์โกลบอลหลายที่เขียน *:focus { outline: none } ลบเส้นโฟกัสเริ่มต้นของเบราว์เซอร์ทิ้ง วิธีที่ถูกคือเก็บสไตล์โฟกัสที่ชัดเจนไว้ เช่นเส้นขอบนอกสีน้ำเงินหนา 2px ไม่ใช่ลบทิ้งทั้งหมด ส่วน semantic และ structured data ทำงานร่วมกันอย่างไร ดูที่Structured data Schema。
| รายการตรวจด้วยคีย์บอร์ด | เกณฑ์ผ่าน | อาการที่ไม่ผ่าน | วิธีแก้ไข |
|---|---|---|---|
| ลำดับ Tab | ตรงกับลำดับการอ่านที่มองเห็น | กระโดดมั่ว กดไปไม่ถึงปุ่ม | ปรับลำดับ DOM หรือ tabindex |
| มองเห็นโฟกัส | องค์ประกอบที่โฟกัสอยู่มีเส้นขอบชัดเจน | outline ถูกลบ มองไม่เห็น | เพิ่มสไตล์ :focus-visible |
| ดรอปดาวน์ | กดลูกศรเพื่อกางและเลือกได้ | คลิกได้ด้วยเมาส์เท่านั้น | เปลี่ยนไปใช้ select แท้หรือเพิ่มการรองรับคีย์บอร์ด |
| ป๊อปอัป | โฟกัสเข้าไปในป๊อปอัป กด Esc ปิดได้ | โฟกัสติดอยู่ในนั้นออกไม่ได้ | ทำกับดักโฟกัสและการปล่อยโฟกัส |
| ลิงก์ข้ามไปเนื้อหา | หน้ายาวมี “ข้ามไปยังเนื้อหาหลัก” | ทุกครั้งที่ต้องไล่กดแท็บนำทางหลายสิบครั้ง | เพิ่มลิงก์ skip to content |
สี่ เรื่องที่สาม: ทำให้โปรแกรมอ่านหน้าจอเข้าใจ
ผู้ใช้โปรแกรมอ่านหน้าจอได้ยิน “โครงสร้างความหมาย” ของ HTML ไม่ใช่ดีไซน์ที่คุณเห็น สามอย่างตัดสินว่าโครงสร้างดีหรือไม่: ข้อความ alt, ลำดับชั้นหัวข้อ และป้าย ARIA alt ไม่ใช่ “ตั้งชื่อไฟล์ให้รูป” แต่คือการอธิบายด้วยประโยคเดียวว่ารูปนี้สื่อสารอะไร ส่วนรูปคั่นตกแต่งให้ใส่ alt=”” เพื่อให้โปรแกรมอ่านหน้าจอข้ามไปเลย ไม่ต้องอ่านคำว่า “ปุ่ม” ออกมา
ลำดับชั้นหัวข้อก็เป็นอีกจุดที่พลาดกันหนัก หลายหน้าเว็บอยากให้หัวข้อใดแสดงตัวใหญ่ ก็ใช้แท็ก h4 หรือแม้แต่ p ครอบ CSS ผลคือโปรแกรมอ่านหน้าจอได้ยินจาก h2 ข้ามไป h4 เลย ผู้ใช้จับโครงสร้างเอกสารไม่ถูก กฎตายตัว: หนึ่งหน้าใช้ h1 เดียว ระดับถัดไปใช้ h2 เท่ากันหมด หัวข้อย่อยใช้ h3 ห้ามข้ามระดับ ปุ่มไอคอน (เช่น แว่นขยาย เมนูแฮมเบอร์เกอร์) ไม่มีข้อความ ต้องใส่ aria-label ไม่งั้นโปรแกรมอ่านหน้าจออ่านแค่คำว่า “ปุ่ม” ผู้ใช้ไม่รู้ว่ากดแล้วได้อะไร ส่วนระดับคำพูดแบบไหนที่เป็นมิตรกับผู้ซื้อต่างชาติ ดูได้ที่คู่มือโทนเสียงสำหรับเขียนคอนเทนต์เว็บไซต์。
| รายการตรวจสอบ | วิธีที่ถูกต้อง | ข้อผิดพลาดที่พบบ่อย | ตรวจสอบด้วยเครื่องมือ |
|---|---|---|---|
| alt ของอินโฟกราฟิก | อธิบายข้อสรุปสำคัญในภาพ | alt=”รูปสินค้า” ไม่มีข้อมูล | สิ่งที่โปรแกรมอ่านหน้าจอได้ยินจริง |
| alt ของรูปตกแต่ง | alt=”” เว้นว่าง | อ่านชื่อไฟล์ที่ไม่มีความหมาย | ฟังว่าถูกข้ามไหม |
| ลำดับชั้นของหัวข้อ | h1>h2>h3 ไล่ระดับ | h2 ข้ามไป h4 | axe ฟ้องว่าข้ามระดับ |
| ปุ่มไอคอน | ใส่ aria-label=”ค้นหา” | อ่านแค่ “ปุ่ม” | NVDA/VoiceOver |
| ตาราง | ทำเครื่องหมายหัวตารางด้วย th | ใช้ td ประกอบทั้งหมด | อ่านแถวแล้วได้ยินหัวตารางไหม |
ห้า การตรวจรับ: สแกนอัตโนมัติแล้ว ตามด้วยมือ
ความเข้าใจผิดข้อสุดท้ายคือ “ปลั๊กอิน axe สแกนขึ้นเขียวแปลว่าผ่านข้อกำหนด” เครื่องมืออัตโนมัติครอบคลุมปัญหาด้านการเข้าถึงได้แค่ราว 30% ถึง 40% เท่านั้น ข้อผิดพลาดเชิงกลไกอย่างคอนทราสต์ alt ที่หายไป หัวข้อข้ามระดับ มันจับได้ แต่กับดักคีย์บอร์ด ลำดับโฟกัส ประสบการณ์จริงกับโปรแกรมอ่านหน้าจอ มันทดสอบไม่ได้เลย การตรวจรับที่สมบูรณ์ต้องมีสามอย่าง: สแกนอัตโนมัติด้วย axe หนึ่งรอบ เดินคีย์บอร์ดด้วยมือล้วนในสี่หน้าสำคัญ และฟังหน้าแรกด้วย NVDA (Windows) หรือ VoiceOver (Mac) หนึ่งรอบ
ด้านลำดับความสำคัญ ให้ทำรายการที่ “ไม่กระทบดีไซน์ แก้แค่โค้ด” ก่อน: คอนทราสต์ ลำดับชั้นหัวข้อ alt วงแหวนโฟกัส สิ่งเหล่านี้ไม่ต้องให้ดีไซเนอร์เข้ามาเกี่ยวข้อง นักพัฒนาปรับเองได้ในสองวัน ส่วนรายการที่ต้องเขียนปฏิสัมพันธ์ใหม่ (ดรอปดาวน์แบบกำหนดเอง การจัดการโฟกัสในป๊อปอัป) ไว้ชุดที่สอง งานหนักแต่มีจำนวนน้อย ตั้งเป้าที่ WCAG 2.2 AA อย่าไปไล่ AAA เพราะ AAA กำหนดคอนทราสต์เนื้อหาหลัก 7:1 ซึ่งในดีไซน์จริงมักต้องแลกกับความสวยงาม ผลตอบแทนไม่คุ้ม
| วิธีตรวจรับ | ปัญหาที่จับได้ | สัดส่วนที่ครอบคลุม | ความถี่ |
|---|---|---|---|
| axe/WAVE สแกนอัตโนมัติ | คอนทราสต์ alt ที่หายไป หัวข้อข้ามระดับ | ประมาณ 30% ถึง 40% | ก่อนขึ้นระบบทุกครั้ง |
| เดินตรวจด้วยคีย์บอร์ด | ลำดับโฟกัส กับดักคีย์บอร์ด | ระบบอัตโนมัติทดสอบไม่ได้ | เดือนละครั้ง |
| ลองฟังด้วย NVDA/VoiceOver | ประสบการณ์กับโปรแกรมอ่านหน้าจอ การตั้งชื่อ aria | ระบบอัตโนมัติทดสอบไม่ได้ | ไตรมาสละครั้ง |
| ฟีดแบ็กจากผู้ใช้จริง | จุดติดขัดในการใช้งานจริง | แม่นที่สุดแต่ช้าที่สุด | เก็บข้อมูลต่อเนื่อง |
FAQ คำถามที่พบบ่อย
WCAG 2.1, 2.2, AA, AAA ควรเลือกอันไหน?
เว็บของเราไม่ได้ใหญ่ การปรับปรุงเพื่อการเข้าถึงต้องใช้เวลากี่วัน?
สแกนด้วยปลั๊กอิน axe แล้วเขียวหมด แสดงว่าผ่านมาตรฐานแล้วใช่ไหม?
alt ของรูปควรเขียนยาวแค่ไหน เขียนอะไร?
เราใช้ธีมสำเร็จรูป จำเป็นต้องแก้การเข้าถึงเองไหม?
การเข้าถึงขัดกับ SEO ไหม จะต้องให้ฉันทิ้งงานออกแบบหรือเปล่า?
ทิ้งท้าย
งานปรับปรุงการเข้าถึงมักถูกทำเป็นโปรเจกต์หน้าฉาก “ทำเพื่อให้ผ่านมาตรฐาน” แค่สแกนปลั๊กอิน ถ่ายภาพไม่กี่รูปใส่เอกสารส่งมอบก็จบ วิธีที่ได้ผลจริงคือแตกมันออกเป็นเช็กลิสต์ P0 ที่ทำเสร็จได้ในสามวัน: จัดคอนทราสต์และลำดับหัวข้อให้เข้าที่ก่อน จากนั้นไล่ดูโฟกัสด้วยคีย์บอร์ดให้ครบ สุดท้ายเติม alt กับ aria ให้ครบ เมื่อทำครบชุดนี้แล้ว เว็บของคุณใช้กับโปรแกรมอ่านหน้าจอได้ และยังเข้าใจง่ายขึ้นสำหรับเสิร์ชเอนจินและ AI crawler ด้วย
ลงมือสามขั้น: หนึ่ง ติดตั้ง axe แล้วสแกนทั้งเว็บ ทำตารางสรุปคอนทราสต์ รูปที่ขาด alt และหัวข้อที่ข้ามระดับ สอง ถอดเมาส์ออกแล้วกด Tab ไล่หน้าแรก หน้าสินค้า และหน้าแบบฟอร์ม บันทึกทุกจุดที่โฟกัสติด สาม ตั้งสแกนอัตโนมัติก่อนเผยแพร่ทุกเดือน และใช้โปรแกรมอ่านหน้าจอฟังหน้าแรกให้ครบทุกไตรมาส เว็บหลายภาษาต้องระวังความครบถ้วนของการแปล alt และหัวข้อด้วย ดูเพิ่มเติมที่การจัดการแผนภูมิของเว็บหลายภาษา。
ประโยคเดียวที่จำได้: การเข้าถึงไม่ใช่แพตช์สำหรับคนกลุ่มพิเศษ แต่คือการเขียนเว็บให้เป็นภาษาคน โปรแกรมอ่านหน้าจอเข้าใจได้ เสิร์ชเอนจินถึงจะอ่านออก และ AI ถึงจะอ้างอิงถึงคุณ