ARIA และ HTML

นักพัฒนาซอฟต์แวร์ส่วนใหญ่คุ้นเคยกับภาษามาร์กอัปมาตรฐานของ เว็บ HyperText Markup Language (HTML) อย่างไรก็ตาม คุณอาจไม่ค่อยคุ้นเคยกับ Accessible Rich Internet Applications (ARIA) (เดิมเรียกว่า WAI-ARIA): คืออะไร ใช้งานอย่างไร และเมื่อใดและไม่ควรใช้

HTML และ ARIA มีบทบาทสำคัญในการทำให้ผลิตภัณฑ์ดิจิทัลเข้าถึงได้ง่าย โดยเฉพาะเมื่อเป็นเรื่องของเทคโนโลยีความช่วยเหลือพิเศษ (AT) เช่น โปรแกรมอ่านหน้าจอ ทั้ง 2 อย่างใช้เพื่อแปลงเนื้อหาเป็นรูปแบบอื่น เช่น อักษรเบรลล์ หรือ การอ่านออกเสียงข้อความ (TTS)

ลองมาทบทวนประวัติสั้นๆ ของ ARIA ความสำคัญของ ARIA รวมถึงช่วงเวลาและลักษณะที่ ควรใช้ได้ดีที่สุด

ข้อมูลเบื้องต้นเกี่ยวกับ ARIA

ARIA พัฒนาขึ้นครั้งแรกในปี 2008 โดย กลุ่ม Web Accessibility Initiative (WAI) - ของ World Wide Web Consortium (W3C) ที่ครอบคลุม ซึ่งควบคุมและ ทำหน้าที่ควบคุมอินเทอร์เน็ต

ARIA ไม่ใช่ภาษาโปรแกรมที่แท้จริง แต่เป็นชุดแอตทริบิวต์ที่คุณสามารถเพิ่มลงใน องค์ประกอบ HTML เพื่อเพิ่มความสามารถในการเข้าถึง แอตทริบิวต์เหล่านี้สื่อสาร บทบาท สถานะ และพร็อพเพอร์ตี้ให้แก่เทคโนโลยีความช่วยเหลือพิเศษผ่าน API การช่วยเหลือพิเศษ ที่พบในเบราว์เซอร์สมัยใหม่ การสื่อสารนี้เกิดขึ้นผ่านการช่วยเหลือพิเศษ ต้นไม้

"WAI-ARIA, Accessible Rich Internet Applications Suite คือตัวกำหนดวิธีทำให้เว็บ และเนื้อหาและเว็บแอปพลิเคชันที่คนพิการสามารถเข้าถึง ได้มากขึ้น ทั้งนี้ โดยเฉพาะการสนับสนุนด้านเนื้อหาแบบไดนามิก และการควบคุมอินเทอร์เฟซผู้ใช้ขั้นสูง พัฒนาด้วย HTML, JavaScript และเทคโนโลยีที่เกี่ยวข้อง"

กลุ่ม WAI

แผนผังการช่วยเหลือพิเศษ

ARIA จะแก้ไขโค้ดที่ไม่ถูกต้องหรือไม่สมบูรณ์เพื่อสร้างประสบการณ์ที่ดีขึ้นสำหรับ โดยใช้ AT ด้วยการเปลี่ยนแปลง เปิดเผย และปรับปรุงส่วนต่างๆ ของการช่วยเหลือพิเศษ ต้นไม้

โครงสร้างการช่วยเหลือพิเศษนี้สร้างขึ้นโดยเบราว์เซอร์และอิงตามมาตรฐาน แผนผัง Document Object Model (DOM) เช่นเดียวกับแผนผัง DOM แผนผังการช่วยเหลือพิเศษ มีออบเจ็กต์ที่แสดงถึงองค์ประกอบมาร์กอัป แอตทริบิวต์ และข้อความทั้งหมด แผนผังการช่วยเหลือพิเศษยังใช้โดยการช่วยเหลือพิเศษเฉพาะแพลตฟอร์มด้วย API เพื่อนำเสนอสิ่งที่เทคโนโลยีความช่วยเหลือพิเศษเข้าใจได้

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

กรณีที่ควรใช้ ARIA

ในปี 2014 W3C ได้เผยแพร่คำแนะนำ HTML5 อย่างเป็นทางการ มาพร้อมกับ การเปลี่ยนแปลงที่สำคัญบางอย่าง ซึ่งรวมถึงการเพิ่มองค์ประกอบจุดสังเกต เช่น <main> <header>, <footer>, <aside>, <nav> และแอตทริบิวต์ เช่น hidden และ required องค์ประกอบและแอตทริบิวต์ HTML5 ใหม่เหล่านี้รวมกับ มีการรองรับเบราว์เซอร์ที่เพิ่มมากขึ้น ขณะนี้ ARIA บางส่วนมีความสำคัญน้อยลง

เมื่อเบราว์เซอร์รองรับแท็ก HTML ที่มีบทบาทโดยนัยกับ ARIA เทียบเท่า โดยปกติไม่จำเป็นต้องเพิ่ม ARIA ลงในองค์ประกอบ อย่างไรก็ตาม ARIA ยังมีบทบาท สถานะ และพร็อพเพอร์ตี้หลายรายการที่ไม่มีอยู่ใน เวอร์ชัน HTML แอตทริบิวต์เหล่านั้นยังคงมีประโยชน์ในปัจจุบัน

เรามาถึงคำถามข้อสุดท้ายว่า คุณควรใช้ ARIA เมื่อใด โชคดี กลุ่ม WAI ได้พัฒนา กฎ 5 ข้อของ ARIA เพื่อช่วยคุณเลือกวิธี เพื่อช่วยให้เข้าถึงองค์ประกอบได้

กฎข้อ 1: อย่าใช้ ARIA

ใช่ คุณอ่านถูก การเพิ่ม ARIA ไปยังองค์ประกอบไม่ได้เป็น เข้าถึงได้ง่ายขึ้น รายงานการเข้าถึงประจำปีของ WebAIM ล้าน พบว่าหน้าแรกที่มี 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 DevTools หรือการทดสอบด้วยโปรแกรมอ่านหน้าจอ

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 มีความซับซ้อน และคุณควรใช้ความระมัดระวังเมื่อใช้ ARIA เสมอ ในขณะที่ ตัวอย่างโค้ดในบทเรียนนี้ค่อนข้างตรงไปตรงมา รูปแบบที่กำหนดเองอาจซับซ้อนได้อย่างรวดเร็ว

มีสิ่งต่างๆ มากมายที่ต้องให้ความสนใจ ซึ่งรวมถึงแต่ไม่จำกัดเพียงปัจจัยต่อไปนี้ การโต้ตอบกับแป้นพิมพ์, อินเทอร์เฟซแบบสัมผัส, การสนับสนุน AT/เบราว์เซอร์, ความต้องการในการแปล ข้อจำกัดด้านสภาพแวดล้อม โค้ดเดิม และค่ากำหนดของผู้ใช้ เล็กน้อย ความรู้ในการเขียนโค้ดอาจเสียหายหรือแค่น่ารำคาญ ไม่ถูกต้อง อย่าลืมทำให้โค้ดเรียบง่าย

นอกจากนี้ คำเตือนดังกล่าวบอกว่าการช่วยเหลือพิเศษผ่านสื่อดิจิทัลไม่ใช่ปัญหา แต่เป็นสถานการณ์ที่ให้บางพื้นที่กลายเป็นสีเทา โซลูชันการเขียนโค้ดหลายโซลูชันอาจถูกมองว่า "ถูกต้อง" โดยขึ้นอยู่กับสถานการณ์ สิ่งสำคัญคือคุณต้องเรียนรู้ ทดสอบ และพยายามทำให้ ที่เปิดกว้างมากขึ้นสำหรับทุกคน

ตรวจสอบความเข้าใจ

ทดสอบความรู้ของคุณเกี่ยวกับ ARIA และ HTML