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 เพื่อเพิ่มการช่วยเหลือพิเศษได้ แอตทริบิวต์เหล่านี้จะสื่อสาร บทบาท สถานะ และพร็อพเพอร์ตี้ไปยังเทคโนโลยีความช่วยเหลือโดยใช้ Accessibility API ที่พบในเบราว์เซอร์สมัยใหม่ การสื่อสารนี้เกิดขึ้นผ่านโครงสร้างการช่วยเหลือพิเศษ

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

กลุ่ม WAI

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

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

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

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 ได้สร้างวิธีดูแผนผังการช่วยเหลือพิเศษทั้งหมด เพื่อให้นักพัฒนาซอฟต์แวร์เข้าใจได้ง่ายขึ้นว่าโค้ดของตนส่งผลต่อ การช่วยเหลือพิเศษอย่างไร

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

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