ให้ AI ช่วยตรวจ Accessibility (a11y)

Accessibility หรือ a11y คือการทำให้เว็บใช้งานได้กับทุกคน รวมถึงผู้ที่ใช้ screen reader ผู้ที่ใช้คีย์บอร์ดแทนเมาส์ ผู้มีสายตาเลือนราง และผู้สูงอายุ เว็บหน่วยงานรัฐและระบบที่ประชาชนต้องใช้ยิ่งต้องใส่ใจเรื่องนี้ AI ช่วยตรวจและแก้ปัญหาพื้นฐานได้เร็ว แต่ก็สร้างปัญหาใหม่ได้เช่นกัน โดยเฉพาะการใส่ ARIA เกินจำเป็น บทความนี้จะไล่ประเด็นหลักคือ alt, label, contrast, การใช้คีย์บอร์ด และ ARIA ที่ไม่จำเป็น พร้อมตัวอย่างก่อนและหลังแก้ วิธีใช้ AI เป็นผู้ตรวจ และเหตุผลที่ยังต้องใช้เครื่องมืออัตโนมัติควบคู่กับการทดสอบจริงเสมอ

ใช้ AI ตรวจ a11y อย่างไรให้ได้ผล

วิธีที่ได้ผลดีคือให้ AI ตรวจ HTML ที่ render แล้ว (ดูจาก View Source หรือ DevTools) ไม่ใช่ไฟล์ PHP view ที่ยังมีโค้ดปน และให้กรอบการตรวจที่ชัดเจน

ตรวจ accessibility ของ HTML ต่อไปนี้ (หน้าแบบฟอร์มสมัครสมาชิก)
อ้างอิงแนวทาง WCAG ระดับ AA
ให้ตอบเป็นตาราง: ปัญหา, element ที่เกี่ยวข้อง, ผลกระทบต่อผู้ใช้กลุ่มใด, วิธีแก้
ตรวจเรื่อง: alt ของรูป, label ของฟอร์ม, ลำดับหัวข้อ, การใช้คีย์บอร์ด,
ข้อความ error, ARIA ที่ไม่จำเป็นหรือใช้ผิด
ห้ามแนะนำให้เพิ่ม ARIA ถ้าใช้ HTML element ปกติแก้ได้
ถ้าตรวจจากโค้ดอย่างเดียวไม่ได้ (เช่น contrast ของรูปพื้นหลัง) ให้บอกว่าต้องตรวจด้วยเครื่องมือ

บรรทัดสุดท้ายสำคัญ เพราะ AI มักตอบเรื่องที่มันไม่สามารถรู้ได้จากโค้ดอย่างมั่นใจ เช่น ตัดสินว่าสีผ่าน contrast ทั้งที่สีจริงมาจาก CSS ไฟล์อื่นที่ไม่ได้ส่งไป ผลตรวจจาก AI จึงเป็นรายการ "สิ่งที่ต้องไปตรวจต่อ" ไม่ใช่ใบรับรองว่าผ่าน

รูปภาพและ alt

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

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

AI ช่วยร่าง alt ได้ดีถ้าเราบอกบริบทของหน้า แต่ควรมีคนตรวจ เพราะ AI ไม่รู้ว่ารูปนั้นมีไว้เพื่ออะไรในหน้าของเรา ใน Yii2 ถ้าเรียก Html::img() โดยไม่ส่ง alt ใน options ตัว helper จะใส่ alt="" ให้ ซึ่งทำให้รูปที่มีความหมายถูกมองเป็นรูปตกแต่งและถูกข้ามไป จึงควรส่ง alt เองทุกครั้งที่รูปให้ข้อมูล

ฟอร์มและ label

ปัญหาที่พบบ่อยที่สุดคือใช้ placeholder แทน label ซึ่งหายไปเมื่อเริ่มพิมพ์ และ screen reader บางตัวอ่านไม่สม่ำเสมอ ตัวอย่างก่อนแก้ที่มักได้จากโค้ดที่ทำแบบเร่ง ๆ:

<div class="field">
  <input type="text" name="email" placeholder="อีเมล">
  <span class="error">กรุณากรอกอีเมล</span>
</div>
<div class="btn" onclick="submitForm()">สมัคร</div>

หลังแก้:

<div class="field">
  <label for="signup-email">อีเมล</label>
  <input type="email" id="signup-email" name="email"
         autocomplete="email" required
         aria-describedby="signup-email-error" aria-invalid="true">
  <p id="signup-email-error" class="error">กรุณากรอกอีเมลให้ถูกรูปแบบ เช่น name@example.com</p>
</div>
<button type="submit">สมัครสมาชิก</button>

สิ่งที่เปลี่ยน: มี label ผูกด้วย for, ใช้ type="email" และ autocomplete ให้ browser ช่วยกรอก, ผูกข้อความ error เข้ากับช่องด้วย aria-describedby และเปลี่ยน div เป็น button ซึ่งได้การโฟกัสด้วยคีย์บอร์ด การกด Enter และ Space รวมถึงบทบาท "ปุ่ม" มาฟรีทั้งหมด ข้อความ error ควรบอกวิธีแก้ ไม่ใช่แค่บอกว่าผิด

ข่าวดีสำหรับคนใช้ Yii2 คือ ActiveForm สร้าง label ที่ผูกกับ input และใส่ aria-invalid ให้อยู่แล้ว ปัญหามักเกิดเมื่อเราซ่อน label ด้วย ->label(false) เพื่อความสวยงาม ถ้าต้องการซ่อนจากสายตา ให้ใช้ class สำหรับซ่อนเฉพาะการแสดงผล เช่น visually-hidden ของ Bootstrap 5 แทน

Contrast และการใช้คีย์บอร์ด

WCAG ระดับ AA กำหนด contrast ratio ขั้นต่ำ 4.5:1 สำหรับข้อความขนาดปกติ และ 3:1 สำหรับข้อความขนาดใหญ่ ปัญหาที่เจอบ่อยคือข้อความสีเทาอ่อนบนพื้นขาว และข้อความบนรูปพื้นหลัง เรื่องนี้ตรวจด้วยเครื่องมือดีกว่าถาม AI เพราะต้องรู้สีที่ render จริง DevTools ของ browser หลักแสดงค่า contrast ได้เมื่อ inspect ข้อความ

ด้านคีย์บอร์ด ให้ลองใช้หน้าเว็บโดยไม่แตะเมาส์ เช็กลิสต์:

• กด Tab แล้วเห็นตำแหน่ง focus ชัดเจนทุกจุด ห้ามมี outline: none โดยไม่มีสไตล์ทดแทน
• ลำดับ focus เป็นไปตามลำดับการอ่าน ไม่กระโดดไปมา หลีกเลี่ยง tabindex ที่มากกว่า 0
• ทุกอย่างที่คลิกได้ ใช้คีย์บอร์ดได้ เมนู dropdown, modal และแท็บต้องเปิดปิดได้
• เปิด modal แล้ว focus ย้ายเข้า modal และกด Esc ปิดได้ เมื่อปิดแล้ว focus กลับไปที่ปุ่มเดิม
• มีลิงก์ "ข้ามไปเนื้อหาหลัก" ที่จุดเริ่มของหน้า สำหรับหน้าที่มีเมนูยาว

:focus-visible {
  outline: 3px solid #1d4ed8;
  outline-offset: 2px;
}

.skip-link {
  position: absolute;
  left: 1rem;
  top: -3rem;
}

.skip-link:focus {
  top: 1rem;
}

ARIA ที่ไม่จำเป็น: ปัญหาที่ AI ชอบสร้าง

เมื่อขอให้ "ทำให้ accessible" AI มักโรย ARIA ลงไปทุก element ซึ่งหลายครั้งทำให้แย่ลง หลักแรกของการใช้ ARIA คือ ถ้ามี HTML element ที่ทำหน้าที่นั้นได้อยู่แล้ว ให้ใช้ element นั้นแทน ARIA ไม่ได้เพิ่มพฤติกรรม มันแค่เปลี่ยนสิ่งที่ screen reader ประกาศ ถ้าประกาศอย่างหนึ่งแต่ทำงานอีกอย่าง ผู้ใช้จะสับสน

ตัวอย่างที่ควรตัดออกหรือแก้:

<!-- ซ้ำซ้อน: button มี role เป็น button อยู่แล้ว -->
<button role="button" aria-label="บันทึก">บันทึก</button>

<!-- ผิด: role บอกว่าเป็นปุ่ม แต่กดด้วยคีย์บอร์ดไม่ได้ -->
<div role="button" onclick="save()">บันทึก</div>

<!-- อันตราย: ซ่อนเนื้อหาที่โฟกัสได้จาก screen reader -->
<nav aria-hidden="true"><a href="/">หน้าแรก</a></nav>

<!-- ถูก: ปุ่มไอคอนที่ไม่มีข้อความ ต้องมีชื่อที่อ่านได้ -->
<button type="button" aria-label="ปิดหน้าต่าง">
  <svg aria-hidden="true" focusable="false" width="16" height="16"></svg>
</button>

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

เครื่องมืออัตโนมัติ และทำไมยังต้องทดสอบจริง

เครื่องมืออัตโนมัติ เช่น Lighthouse ใน DevTools, ส่วนขยาย axe หรือ WAVE ตรวจปัญหาที่วัดได้ด้วยกฎ เช่น รูปไม่มี alt, input ไม่มี label, contrast ต่ำ, ARIA ใช้ค่าที่ไม่ถูกต้อง ควรรันทุกครั้งก่อน release และถ้าเป็นไปได้ให้ใส่ใน CI

แต่เครื่องมือตรวจได้เพียงส่วนหนึ่งของปัญหา มันบอกได้ว่ามี alt แต่บอกไม่ได้ว่า alt นั้นมีความหมายไหม บอกได้ว่ามี focus แต่ไม่รู้ว่าลำดับ focus สมเหตุสมผลหรือไม่ จึงต้องทดสอบจริงอย่างน้อยดังนี้

1. ใช้งาน flow หลักของหน้า (เช่น สมัครสมาชิก ค้นหา ชำระเงิน) ด้วยคีย์บอร์ดอย่างเดียว
2. ลองฟังด้วย screen reader ที่มีในระบบปฏิบัติการ เช่น VoiceOver บน macOS หรือ NVDA บน Windows อย่างน้อยหนึ่ง flow
3. ซูม 200% และดูบนมือถือ
4. ถ้าเป็นไปได้ ให้ผู้ใช้ที่ใช้เทคโนโลยีช่วยเหลือจริงทดลองใช้ ข้อมูลจากผู้ใช้จริงมีค่ากว่าเครื่องมือทุกตัว

อ่านแนวทางเพิ่มเติมได้ที่ W3C Web Accessibility Initiative (WAI) ซึ่งรวบรวม WCAG และคำอธิบายสำหรับนักพัฒนาไว้

สรุป

• ให้ AI ตรวจ HTML ที่ render แล้ว พร้อมกรอบการตรวจที่ชัด และถือผลเป็นรายการที่ต้องตรวจต่อ
• alt เขียนตามหน้าที่ของรูป, ฟอร์มต้องมี label จริง, ข้อความ error ต้องบอกวิธีแก้
• ตรวจ contrast ด้วยเครื่องมือ และใช้งานทั้งหน้าด้วยคีย์บอร์ดให้ได้
• ใช้ HTML element ที่ถูกต้องก่อน ARIA และตัด ARIA ที่ซ้ำซ้อนหรือขัดกับพฤติกรรมจริง
• เครื่องมืออัตโนมัติจับได้บางส่วน ต้องทดสอบด้วยคีย์บอร์ดและ screen reader จริงเสมอ

ลองทำ

เลือกหน้าฟอร์มหนึ่งหน้าในระบบของคุณ รัน Lighthouse หมวด Accessibility แล้วจดปัญหาที่พบ จากนั้น copy HTML ที่ render แล้วให้ AI ตรวจด้วย prompt ในบทความ เทียบสองรายการว่าอะไรที่เครื่องมือจับได้แต่ AI ไม่เห็น และกลับกัน สุดท้ายลองกรอกฟอร์มนั้นจนส่งสำเร็จด้วยคีย์บอร์ดอย่างเดียว แล้วแก้อย่างน้อยหนึ่งปัญหาที่เจอ