ARIA Accessibility Checker: ตรวจ label ตกหล่นและ ARIA เสียก่อนส่งงานจริง

บั๊กด้าน accessibility เป็นบั๊กที่เงียบที่สุด — input ที่ไม่มี label, aria-labelledby ที่พิมพ์ผิด, หรือ landmark ที่ไม่มีชื่อ ทั้งหมดนี้ไม่ทำให้หน้าเว็บพังในสายตาคนทั่วไป แต่ทำให้หน้าเว็บพังสำหรับผู้ใช้ screen reader ทั้งหมด ARIA Accessibility Checker คือเครื่องมือ scan ฟรีที่ทำงานใน browser ช่วยหาปัญหาพวกนี้ได้ในไม่กี่วินาที

วิธีใช้ง่ายมาก: วาง (paste) HTML ลงไป เครื่องมือจะรัน 14 audit rules ทันที ครอบคลุมตั้งแต่ accessible name, ARIA attributes, roles ไปจนถึง landmarks ผลลัพธ์อัปเดตสด (live) ขณะที่คุณพิมพ์ ทุก issue ระบุ line:column แบบเป๊ะ พร้อม snippet ของ element ที่มีปัญหา และ copy รายงานเต็มเป็น plain text ได้ในคลิกเดียว

ที่สำคัญ — ทุกอย่างประมวลผล 100% ฝั่ง client ใน browser ของคุณ markup ไม่ถูกส่งออกไปไหนเลย ซึ่งสำคัญมากถ้าคุณกำลัง audit dashboard ภายใน, template ของลูกค้า หรือโค้ดที่ policy บอกว่า "ห้ามเอาไปแปะที่ service ภายนอก"

ทำไมต้องใช้ ARIA Accessibility Checker

• Feedback ทันที — ไม่มีปุ่ม "Run scan" ให้ตามหา พอ paste หรือแก้ markup ปุ๊บ รายการ findings รีเฟรชทันที แก้เสร็จ issue หายจากลิสต์ก่อนที่คุณจะพิมพ์บรรทัดถัดไปเสร็จ
• ระบุตำแหน่งเป๊ะ ไม่ใช่ warning ลอย ๆ — แต่ละ finding บอก line:column พร้อม element snippet ทำให้กระโดดไปแก้จุดนั้นได้เลย ไม่ต้องไล่อ่าน template ทั้งไฟล์ใหม่
• 14 rules ที่โดนใจ screen reader จริง ๆ — checks ถูกออกแบบจากปัญหาที่ทำให้ผู้ใช้ assistive technology ลำบากจริง: form control ที่ไม่มี accessible name, ID reference ขาด, role ไม่ valid, element ที่ focus ได้แต่ถูกซ่อนด้วย aria-hidden และอีกมาก
• แยก severity ให้ triage ได้ — findings แบ่งเป็น error (อุปสรรคจริง), warning (ความเสี่ยง/code smell) และ pass ทำให้รู้ว่าอะไรต้องแก้เดี๋ยวนี้ อะไรควรแก้
• Zero friction — ไม่ต้องสมัคร account ไม่ต้อง upload ไม่ต้องติดตั้งอะไร มี sample document ให้ลองเล่น ทำให้เครื่องมือเป็นทั้งตัว audit และตัวช่วยเรียนรู้
• Privacy by design — scanner เป็น client-side JavaScript ล้วน ๆ เหมาะกับ HTML ที่ policy ห้ามเอาไปวางที่ third-party service

ฟีเจอร์หลัก

มีรายละเอียดที่น่ารู้เพิ่ม: การตรวจ attribute อิงจาก ARIA 1.2 attribute set แบบเต็ม attribute ที่ดูสมเหตุสมผลแต่ไม่มีอยู่จริงอย่าง aria-name จะโดนตั้ง flag เป็น error ทันที ส่วนการตรวจ role ครอบคลุม WAI-ARIA roles มาตรฐานราว 70 ตัว — พิมพ์ผิดอย่าง role="buton" หรือ role ที่ถูก retire ไปแล้วจะโผล่ทันที

จุดที่เครื่องมือนี้ช่วยประหยัดเวลาได้เยอะที่สุดคือ reference checks: aria-labelledby, aria-describedby, aria-controls และ aria-owns จะถูกเทียบกับ IDs ที่มีอยู่จริงใน markup ของคุณ — reference ที่ขาดหายไปหลัง refactor (หนึ่งใน ARIA regression ที่พบบ่อยที่สุด) จะถูกจับได้ก่อนถึงมือผู้ใช้ screen reader

วิธีใช้งาน

1. เปิด ARIA Accessibility Checker
2. Paste HTML ของคุณลง input panel — เป็น document เต็ม, component เดี่ยว หรือ fragment ก็ได้ (หรือกดโหลด sample ที่มีบั๊กให้ดูก่อน)
3. อ่าน findings list — error (แดง) คืออุปสรรคจริง, warning (เหลือง) คือความเสี่ยงที่ควรรีวิว แต่ละรายการบอก rule, line:column และ element snippet
4. แก้ปัญหาที่ source จริง (หรือแก้ใน tool ไปเรื่อย ๆ) แล้วดู findings หายทยอยออกจากลิสต์ขณะพิมพ์
5. พอ scan สะอาดแล้ว กด Copy report เพื่อเก็บ plain-text accessibility report ไว้แนบ PR description, ticket หรือโน้ต compliance

เข้าใจ ARIA Roles และ Landmarks

Accessible name คือกระดูกสันหลังของ accessibility — ทุก interactive control (button, link, input, select) ต้องมีชื่อที่ assistive technology อ่านออก ชื่ออาจมาจาก inner text (<button>บันทึก</button>), <label for> ที่เชื่อมกัน, aria-label หรือ aria-labelledby ที่ชี้ไปที่ข้อความที่อ่านได้ checker จะไล่ตรวจทุก form control แล้ว flag ตัวที่สุดท้ายแล้วไม่มีชื่อ กรณีคลาสสิกคือปุ่มที่ render เป็นไอคอนเปล่า ๆ:

<!-- เสีย: ไม่มี accessible name -->
<button class="icon-btn">
  <svg>...</svg>
</button>

<!-- แก้แล้ว -->
<button class="icon-btn" aria-label="ปิดหน้าต่าง">
  <svg>...</svg>
</button>

Reference attributes คือสัญญา — aria-labelledby="user-name" คือคำมั่นว่าจะมี element ที่ id="user-name" อยู่จริง เมื่อ ID ถูก rename หรือ component ถูก copy-paste โดยไม่เอา label ตามไปด้วย สัญญานั้นก็ขาด และ element เสียชื่อตอน runtime แบบเงียบ ๆ checker จะ resolve ทุก reference เทียบกับ IDs ที่มีใน markup และเตือนตัวที่ห้อยอยู่ลอย ๆ รวมถึง duplicate IDs ที่ทำให้ reference กำกวม

Role ต้อง valid — และต้องมีพฤติกรรมรองรับ — checker ตรวจค่า role เทียบกับชุด role มาตรฐาน แต่ยังจับกับดักที่ซับกว่านั้น: role="button" บน <div> ที่ไม่มี tabindex จะรับ keyboard focus ไม่ได้ ผู้ใช้ keyboard จึงไปถึง element นั้นไม่ได้เลย — case นี้จะได้ warning คู่ที่คล้ายกันคือ aria-hidden="true" บน element ที่ focus ได้ ซึ่งเป็น error เพราะคุณบอกให้ screen reader มองไม่เห็นอะไรบางอย่างที่ keyboard ยัดเข้าไปได้ — แย่กว่าไม่ทำอะไรเลยด้วยซ้ำ

Landmark คือสารบัญของหน้าเว็บ — ผู้ใช้ screen reader นำทางด้วย regions: main, navigation, banner, contentinfo, form, search checker กำหนดให้ต้องมี main เพียงหนึ่งเดียว, เตือนเมื่อ landmark ซ้ำ (เช่น nav สองอัน) ไม่มีชื่อให้แยกแยะ และเตือนให้ใส่ lang ที่ <html> เพื่อให้ speech synthesizer เลือกภาษาออกเสียงถูกต้อง

Use cases จริง

เช็คก่อนส่ง PR

ก่อนเปิด pull request ให้ paste markup ของ component ที่ render แล้วเข้า checker สามสิบวินาทีถัดมาคุณจะรู้ว่า feature ใหม่ส่งมาพร้อมชื่อบน controls และ ARIA ที่ valid หรือเปล่า — accessibility review กลายเป็นนิสัยประจำวัน ไม่ใช่ audit รายไตรมาส

Audit component library

เอา markup ของแต่ละ component ผ่านเครื่องมือแล้วจด findings ไว้ทีละตัว เพราะ report ที่ copy ได้มี severity counts คุณจะได้ a11y scorecard แบบเบา ๆ ที่ตามผลได้เรื่อย ๆ และยกมาอ้างใน documentation ได้

ตรวจ template และ email HTML

Newsletter, CMS theme และ legacy page template แทบไม่เคยได้รับความสนใจด้าน accessibility ลอง paste เข้าไป มักจะเจอ alt หาย, landmark ซ้ำไม่มีชื่อ และ input ไม่มี name — เป็น fix list ที่จัดลำดับความสำคัญให้แล้ว ดีกว่าไล่อ่าน markup ที่ไม่มีใครอยากอ่านทีละบรรทัด

ใช้สอนและเรียน a11y

โหลด built-in sample แล้วทำลายมันด้วยตัวเอง — ลบ aria-label, พิมพ์ role ผิด, ตัด label for ขาด การเห็น finding ที่สอดคล้องโผล่มา (พร้อม line number) สร้าง mental model ได้เร็วกว่า checklist ใด ๆ และทำให้เครื่องมือนี้เป็นของคู่ใจตอน live-demo ใน workshop

Best Practices

• ใช้ native element ก่อน ARIA เสมอ — <button> จริง ๆ ให้ focus, keyboard activation และ name มาฟรี; role="button" บน <div> แปลว่าคุณต้องรับผิดชอบทั้งสามอย่างเอง
• อย่าลบชื่อเดียวที่มีออก — กำลัง refactor inner text เป็นไอคอน? ใส่ aria-label ใน commit เดียวกัน — findings แบบ live ของ checker ทำให้นี่เป็นนิสัยที่ใช้เวลาแค่สองวินาที
• มอง warning เป็น error ในอนาคต — tabindex บวกหรือ role="button" div "ยังใช้ได้" วันนี้ แต่ทั้งคู่คือ regression ที่รอเวลาเจอผู้ใช้ keyboard-only
• ตั้งชื่อ landmark ที่ซ้ำกัน — <nav> สองอันควรเป็น aria-label="เมนูหลัก" และ aria-label="ท้ายเว็บ" เพื่อให้ผู้ใช้แยกทางกันได้ใน landmarks list
• แก้ duplicate IDs ก่อนแก้ reference — labelledby ที่ชี้ไป ID เดียวกันสองตัวคือ undefined behavior ให้ dedupe ก่อนแล้วค่อย scan ใหม่
• อย่าลืม lang บน <html> — เป็น attribute เดียว แต่คุมการออกเสียงของ screen reader ทั้งหน้า

เริ่ม Scan HTML ของคุณวันนี้

ความล้มเหลวด้าน ARIA มองไม่เห็นในหน้าต่าง browser แต่ชัดเจนมากใน screen reader ARIA Accessibility Checker ปิดช่องว่างนี้ให้: paste markup, เห็น line และ column แบบเป๊ะของทุก name ที่หาย, attribute ที่ invalid, และ reference ที่ขาด, แก้ แล้ว scan ใหม่แบบ real-time ไม่ต้องมี account ไม่ต้อง upload ไม่ต้องติดตั้ง — ได้ HTML ที่สะอาดกว่าและ inclusive กว่าก่อนส่งขึ้น production

เครื่องมือที่เกี่ยวข้อง:

• HTML Alt Text Checker — สแกนรูปภาพที่ alt หาย ว่าง หรือ path เสีย
• Heading Structure Checker — ตรวจโครง H1–H6 ให้นำทางด้วย screen reader ได้ถูกต้อง
• Accessible Name Calculator — ดูเป๊ะ ๆ ว่า assistive technology จะคำนวณชื่ออะไรให้ element นั้น

ขอให้เขียน HTML ที่ accessible ทุกครั้งนะ!