นักพัฒนาซอฟต์แวร์ส่วนใหญ่คุ้นเคยกับภาษามาร์กอัปมาตรฐานของเว็บสมัยใหม่อย่าง HyperText Markup Language (HTML) แต่คุณอาจไม่ค่อยคุ้นเคยกับ Accessible Rich Internet Applications (ARIA) (เดิมเรียกว่า WAI-ARIA) ว่าคืออะไร นำมาใช้อย่างไร และเมื่อใดและไม่ใช้
HTML และ ARIA มีบทบาทสำคัญในการทําให้ผลิตภัณฑ์ดิจิทัลเข้าถึงได้ง่าย โดยเฉพาะเมื่อพูดถึงเทคโนโลยีความช่วยเหลือพิเศษ (AT) เช่น โปรแกรมอ่านหน้าจอ เครื่องมือทั้ง 2 ประเภทใช้เพื่อแปลงเนื้อหาเป็นรูปแบบอื่น เช่น อักษรเบรลล์หรือการอ่านออกเสียงข้อความ (TTS)
มาทบทวนประวัติสั้นๆ เกี่ยวกับ ARIA เพื่อความสำคัญ รวมถึงช่วงเวลาและวิธีการใช้งานที่ดีที่สุด
ข้อมูลเบื้องต้นเกี่ยวกับ ARIA
ARIA พัฒนาขึ้นครั้งแรกในปี 2008 โดยกลุ่ม Web Accessibility Initiative (WAI) ซึ่งเป็นกลุ่มย่อยของ World Wide Web Consortium (W3C) ที่ใช้ควบคุมและกำกับดูแลอินเทอร์เน็ต
ARIA ไม่ใช่ภาษาโปรแกรมที่แท้จริง แต่เป็นชุดแอตทริบิวต์ที่คุณสามารถเพิ่มลงในองค์ประกอบ HTML เพื่อเพิ่มการช่วยเหลือพิเศษ แอตทริบิวต์เหล่านี้จะสื่อสารบทบาท สถานะ และพร็อพเพอร์ตี้กับเทคโนโลยีความช่วยเหลือพิเศษผ่าน API การช่วยเหลือพิเศษที่พบในเบราว์เซอร์รุ่นใหม่ๆ การสื่อสารนี้จะเกิดขึ้นผ่านแผนผัง การช่วยเหลือพิเศษ
"WAI-ARIA" เป็นชุดเครื่องมือ Accessible Rich Internet Application Suite ที่กำหนดวิธีทำให้ผู้พิการเข้าถึงเนื้อหาเว็บและเว็บแอปพลิเคชันต่างๆ ได้ดีขึ้น โดยเฉพาะอย่างยิ่งจะช่วยกับเนื้อหาแบบไดนามิกและการควบคุมอินเทอร์เฟซผู้ใช้ขั้นสูงที่พัฒนาด้วย HTML, JavaScript และเทคโนโลยีที่เกี่ยวข้อง"
กลุ่ม WAI
แผนผังการช่วยเหลือพิเศษ
ARIA แก้ไขโค้ดที่ไม่ถูกต้องหรือไม่สมบูรณ์เพื่อสร้างประสบการณ์ที่ดีขึ้นสำหรับผู้ใช้ที่ใช้ AT โดยการเปลี่ยนแปลง แสดง หรือเพิ่มส่วนต่างๆ ของแผนผังการช่วยเหลือพิเศษ
โครงสร้างการช่วยเหลือพิเศษนี้สร้างขึ้นโดยเบราว์เซอร์และอิงตามแผนผัง Document Object Model (DOM) มาตรฐาน แผนผังการช่วยเหลือพิเศษมีออบเจ็กต์ที่แทนองค์ประกอบมาร์กอัป แอตทริบิวต์ และโหนดข้อความทั้งหมดเช่นเดียวกับแผนผัง DOM นอกจากนี้ API การช่วยเหลือพิเศษเฉพาะแพลตฟอร์มยังใช้แผนผังการช่วยเหลือพิเศษเฉพาะแพลตฟอร์มด้วยเพื่อแสดงให้เห็นว่าเทคโนโลยีความช่วยเหลือพิเศษนั้นเข้าใจได้
![โครงสร้างการช่วยเหลือพิเศษที่ปรับปรุงใหม่ของ ARIA](https://web.dev/static/learn/accessibility/aria-html/image/the-aria-augmented-access-70b111217be0f.jpg?authuser=6&hl=th)
ARIA เพียงอย่างเดียวไม่ได้เปลี่ยนแปลงฟังก์ชันการทำงานหรือลักษณะที่ปรากฏขององค์ประกอบ ซึ่งหมายความว่าเฉพาะผู้ใช้ AT เท่านั้นที่จะสังเกตเห็นความแตกต่างระหว่างผลิตภัณฑ์ดิจิทัลที่มี ARIA และผลิตภัณฑ์ที่ไม่มี ARIA ซึ่งหมายความว่านักพัฒนาซอฟต์แวร์เท่านั้นที่มีหน้าที่รับผิดชอบในการเปลี่ยนแปลงโค้ดและการจัดรูปแบบที่เหมาะสมเพื่อให้องค์ประกอบเข้าถึงได้มากที่สุด
คุณลักษณะหลัก 3 อย่างของ ARIA คือบทบาท พร็อพเพอร์ตี้ และสถานะ/ค่า
บทบาทเป็นตัวกำหนดว่าองค์ประกอบคืออะไรหรือทำอะไรในหน้าเว็บหรือแอป
<div role="button">Self-destruct</div>
พร็อพเพอร์ตี้แสดงลักษณะหรือความสัมพันธ์ที่มีต่อออบเจ็กต์
<div role="button" aria-describedby="more-info">Self-destruct</div>
<div id="more-info">This page will self-destruct in 10 seconds.</div>
สถานะ/ค่าจะกำหนดเงื่อนไขปัจจุบันหรือค่าข้อมูลที่เชื่อมโยงกับองค์ประกอบนั้นๆ
<div role="button" aria-describedby="more-info" aria-pressed="false">
Self-destruct
</div>
<div id="more-info">
This page will self-destruct in 10 seconds.
</div>
องค์ประกอบทั้ง 3 รายการของ ARIA จะใช้ในโค้ดบรรทัดเดียวได้ แต่ก็ไม่จำเป็น แต่ให้เลเยอร์บทบาท พร็อพเพอร์ตี้ และสถานะ/ค่า ARIA จนกว่าคุณจะบรรลุเป้าหมายการช่วยเหลือพิเศษขั้นสุดท้าย การรวม ARIA เข้ากับฐานโค้ดอย่างถูกต้องช่วยให้มั่นใจว่าผู้ใช้ AT จะมีข้อมูลทั้งหมดที่จำเป็นต่อการใช้งานเว็บไซต์ แอป หรือผลิตภัณฑ์ดิจิทัลอื่นๆ ของคุณอย่างประสบความสำเร็จและเท่าเทียมกัน
เมื่อเร็วๆ นี้ Chrome DevTools ได้สร้างวิธีดูแผนผังการช่วยเหลือพิเศษแบบเต็มเพื่อให้นักพัฒนาซอฟต์แวร์เข้าใจได้ง่ายขึ้นว่าโค้ดของตนส่งผลต่อการช่วยเหลือพิเศษอย่างไร
กรณีที่ควรใช้ ARIA
W3C ได้เผยแพร่คำแนะนำ HTML5 อย่างเป็นทางการในปี 2014 การเปลี่ยนแปลงครั้งนี้ก่อให้เกิดการเปลี่ยนแปลงครั้งใหญ่ ซึ่งรวมถึงการเพิ่มองค์ประกอบจุดสังเกต เช่น <main>
, <header>
, <footer>
, <aside>
, <nav>
และแอตทริบิวต์อย่าง hidden
และrequired
ด้วยองค์ประกอบและแอตทริบิวต์ HTML5 ใหม่เหล่านี้ประกอบกับการรองรับเบราว์เซอร์ที่เพิ่มขึ้น บางส่วนของ ARIA จึงมีความสำคัญน้อยลง
เมื่อเบราว์เซอร์รองรับแท็ก HTML ที่มีบทบาทโดยนัยที่มีค่าเทียบเท่ากับ ARIA ปกติแล้วก็ไม่จำเป็นต้องเพิ่ม ARIA ลงในองค์ประกอบ อย่างไรก็ตาม ARIA ยังคงมีบทบาท สถานะ และพร็อพเพอร์ตี้มากมายที่ไม่มีใน HTML ทุกเวอร์ชัน อย่างไรก็ตาม แอตทริบิวต์เหล่านั้นยังมีประโยชน์อยู่ในขณะนี้
เราจึงมาถึงคำถามสำคัญที่ว่า คุณควรใช้ ARIA เมื่อใด โชคดีที่กลุ่ม WAI ได้พัฒนากฎ 5 ข้อของ ARIA เพื่อช่วยคุณตัดสินใจว่าจะทำให้องค์ประกอบเข้าถึงได้อย่างไร
กฎข้อ 1: ไม่ใช้ ARIA
ใช่ คุณอ่านถูกแล้ว การเพิ่ม ARIA ไปยังองค์ประกอบไม่ได้ช่วยให้เข้าถึง ARIA ได้ง่ายขึ้นตามปกติ รายงานการช่วยเหลือพิเศษประจำปีของ WebAIM Million พบว่าหน้าแรกที่มี ARIA พบข้อผิดพลาดที่ตรวจจับได้มากกว่าหน้าที่ไม่มี ARIA โดยเฉลี่ย 70% โดยหลักๆ แล้วเกิดจากการใช้งานแอตทริบิวต์ ARIA ที่ไม่เหมาะสม
กฎนี้มีข้อยกเว้น ต้องใช้ ARIA เมื่อองค์ประกอบ HTML ไม่รองรับการช่วยเหลือพิเศษ ซึ่งอาจเป็นเพราะการออกแบบไม่อนุญาตองค์ประกอบ HTML ที่เจาะจง หรือฟีเจอร์/ลักษณะการทำงานที่ต้องการไม่พร้อมใช้งานใน HTML อย่างไรก็ตาม สถานการณ์เหล่านี้น่าจะไม่เพียงพอ
<a role="button">Submit</a>
<button>Submit</button>
หากไม่แน่ใจ ให้ใช้องค์ประกอบ HTML เชิงความหมาย
กฎข้อที่ 2: อย่าเพิ่ม ARIA (ไม่จำเป็น) ลงใน HTML
ในกรณีส่วนใหญ่ องค์ประกอบ HTML จะทำงานได้ดีเมื่อเปิดใช้ในกล่อง และไม่จำเป็นต้องเพิ่ม ARIA เพิ่มเติม ที่จริงแล้วนักพัฒนาซอฟต์แวร์ที่ใช้ ARIA มักจะต้องเพิ่มโค้ดเพิ่มเติมเพื่อให้องค์ประกอบทำงานได้ในกรณีที่เป็นองค์ประกอบแบบอินเทอร์แอกทีฟ
<h2 role="tab">Heading tab</h2>
<div role="tab"><h2>Heading tab</h2></div>
ทำงานน้อยลงและมีโค้ดที่มีประสิทธิภาพดีขึ้นเมื่อใช้องค์ประกอบ HTML ตามที่ตั้งใจไว้
กฎที่ 3: รองรับการนำทางด้วยแป้นพิมพ์เสมอ
การควบคุม ARIA แบบอินเทอร์แอกทีฟทั้งหมด (ไม่ได้ปิดใช้) ต้องเข้าถึงด้วยแป้นพิมพ์ได้ คุณสามารถเพิ่ม Tabindex= "0" ลงในองค์ประกอบที่ต้องการโฟกัสซึ่งปกติแล้วจะไม่ได้รับการโฟกัสแป้นพิมพ์ หลีกเลี่ยงการใช้ดัชนีของแท็บที่มีจำนวนเต็มบวกเมื่อเป็นไปได้เพื่อป้องกันปัญหาการเรียงลำดับโฟกัสแป้นพิมพ์ที่อาจเกิดขึ้น
<span role="button" tabindex="1">Submit</span>
<span role="button" tabindex="0">Submit</span>แน่นอนว่าในกรณีนี้ ให้ใช้องค์ประกอบ
<button>
จริง
กฎที่ 4: อย่าซ่อนองค์ประกอบที่โฟกัสได้
อย่าเพิ่ม role= "presentation"
หรือ aria-hidden= "true"
ลงในองค์ประกอบที่ต้องโฟกัส ซึ่งรวมถึงองค์ประกอบที่มี tabindex= "0"
เมื่อเพิ่มบทบาท/สถานะเหล่านี้ลงในองค์ประกอบ ระบบจะส่งข้อความถึง AT ว่าองค์ประกอบเหล่านี้ไม่สำคัญและต้องข้ามไป ซึ่งอาจทำให้เกิดความสับสนหรือ
รบกวนผู้ใช้ที่พยายามโต้ตอบกับองค์ประกอบหนึ่งๆ
<div aria-hidden="true"><button>Submit</button></div>
<div><button>Submit</button></div>
กฎข้อ 5: ใช้ชื่อที่เข้าถึงได้สำหรับองค์ประกอบแบบอินเทอร์แอกทีฟ
วัตถุประสงค์ขององค์ประกอบแบบอินเทอร์แอกทีฟจำเป็นต้องถ่ายทอดให้ผู้ใช้ทราบว่าจะโต้ตอบกับองค์ประกอบนั้นอย่างไร ตรวจสอบว่าองค์ประกอบทั้งหมดมีชื่อที่เข้าถึงได้สำหรับผู้ที่ใช้อุปกรณ์ AT
ชื่อที่เข้าถึงได้อาจเป็นเนื้อหาที่ล้อมรอบด้วยองค์ประกอบ (ในกรณีของ <a>
) ข้อความสำรอง หรือป้ายกำกับ
สำหรับตัวอย่างโค้ดต่อไปนี้ ชื่อที่เข้าถึงได้คือ "รองเท้าบูทหนังสีแดง"
<!-- A plain link with text between the link tags. -->
<a href="shoes.html">Red leather boots</a>
<!-- A linked image, where the image has alt text. -->
<a href="shoes.html"><img src="shoes.png" alt="Red leather boots"></a>
<!-- A checkbox input with a label. -->
<input type="checkbox" id="shoes">
<label for="shoes">Red leather boots</label>
วิธีการตรวจสอบชื่อการช่วยเหลือพิเศษขององค์ประกอบนั้นทำได้หลายวิธี เช่น การตรวจสอบแผนผังการช่วยเหลือพิเศษโดยใช้เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome หรือการทดสอบด้วยโปรแกรมอ่านหน้าจอ
ARIA ใน HTML
แม้ว่าแนวทางปฏิบัติแนะนำจะใช้องค์ประกอบ HTML เพียงอย่างเดียว แต่คุณก็เพิ่มองค์ประกอบ ARIA ได้ในบางสถานการณ์ ตัวอย่างเช่น คุณอาจจับคู่ ARIA กับ HTML ในรูปแบบที่ต้องการการสนับสนุน AT ในระดับที่สูงกว่าเนื่องจากข้อจำกัดด้านสภาพแวดล้อม หรือเป็นวิธีสำรองสำหรับองค์ประกอบ HTML ที่ไม่ได้รับการสนับสนุนอย่างเต็มรูปแบบจากบางเบราว์เซอร์
เรามีคำแนะนำสำหรับการใช้ ARIA ใน HTML ด้วย สิ่งที่สำคัญที่สุดคือ อย่าลบล้างบทบาท HTML เริ่มต้น ลดความซ้ำซ้อน และระวังผลข้างเคียงที่ไม่ได้ตั้งใจ
เรามาดูตัวอย่างกัน
<a role="heading">Read more</a>กำหนดบทบาทที่ไม่ถูกต้อง
<a aria-label="Read more about some awesome article title">Read More</a>แก้ไขบทบาทและคำอธิบายลิงก์เพิ่มเติม
<ul role="list">...</ul>บทบาทซ้ำซ้อน
<ul>...</ul>นำความซ้ำซ้อนออกแล้ว
<details> <summary role="button">more information</summary> ... </details>ผลข้างเคียงที่อาจเกิดขึ้น
<details> <summary>more information</summary> ... </details>ไม่มีผลข้างเคียงที่ไม่พึงประสงค์
ความซับซ้อนของ ARIA
ARIA มีความซับซ้อน และคุณควรระมัดระวังเสมอเมื่อใช้ แม้ว่าตัวอย่างโค้ดในบทเรียนนี้ค่อนข้างตรงไปตรงมา แต่การสร้างรูปแบบที่กำหนดเองที่เข้าถึงได้อาจซับซ้อนอย่างรวดเร็ว
มีสิ่งต่างๆ มากมายที่ต้องให้ความสำคัญ ซึ่งรวมถึงแต่ไม่จำกัดเพียงการโต้ตอบผ่านแป้นพิมพ์, อินเทอร์เฟซการสัมผัส, การรองรับ AT/เบราว์เซอร์, ความจำเป็นในการแปล, ข้อจำกัดด้านสิ่งแวดล้อม, โค้ดเดิม และค่ากำหนดของผู้ใช้ ความรู้เรื่องการเขียนโค้ดเล็กน้อยอาจมีผลเสีย หรือน่ารำคาญเลย หากใช้อย่างไม่ถูกวิธี อย่าลืมทำให้โค้ดของคุณเรียบง่ายเข้าไว้
คำเตือนดังกล่าวยังช่วยในเรื่องของการช่วยเหลือพิเศษในรูปแบบดิจิทัลอีกหลายอย่าง แต่กลับทำให้มีพื้นที่ที่เสื่อมโทรมเช่นนี้ได้ โซลูชันการเขียนโค้ดหลายรายการอาจมองว่า "ถูกต้อง" ขึ้นอยู่กับสถานการณ์ สิ่งสำคัญคือคุณต้องเรียนรู้ ทดสอบ และพยายามทำให้โลกดิจิทัลของเราเปิดกว้างสำหรับทุกคนมากขึ้น
ตรวจสอบความเข้าใจของคุณ
ทดสอบความรู้เกี่ยวกับ ARIA และ HTML
ข้อใดต่อไปนี้คือแนวทางปฏิบัติแนะนำสำหรับการสร้างปุ่มสำหรับการช่วยเหลือพิเศษ
<div id="saveChanges" aria-role="button" aria-pressed="false" tabindex="0">Go to shop</div>
<a id="saveChanges" aria-label="Some awesome article title">Go to shop</a>
<button id="saveChanges" type="button">Go to shop</button>