ARIA และ HTML

นักพัฒนาซอฟต์แวร์ส่วนใหญ่คุ้นเคยกับภาษามาร์กอัปมาตรฐานของเว็บสมัยใหม่อย่าง 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 เพียงอย่างเดียวไม่ได้เปลี่ยนแปลงฟังก์ชันการทำงานหรือลักษณะที่ปรากฏขององค์ประกอบ ซึ่งหมายความว่าเฉพาะผู้ใช้ 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>

กฎที่ 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