ข้อมูลเบื้องต้นเกี่ยวกับแผนผังการช่วยเหลือพิเศษ
ลองนึกภาพว่าคุณกำลังสร้างอินเทอร์เฟซผู้ใช้สำหรับผู้ใช้โปรแกรมอ่านหน้าจอเท่านั้น ในกรณีนี้ คุณไม่จำเป็นต้องสร้าง UI ที่มองเห็นได้เลย เพียงแค่ระบุข้อมูลที่เพียงพอสำหรับโปรแกรมอ่านหน้าจอที่จะใช้
สิ่งที่คุณจะสร้างคือ API ประเภทหนึ่งที่อธิบายโครงสร้างหน้าเว็บ คล้ายกับ DOM API แต่คุณสามารถใช้ข้อมูลและโหนดน้อยลงได้ เนื่องจากข้อมูลจำนวนมากมีประโยชน์สำหรับการนำเสนอภาพเท่านั้น ซึ่งอาจมีลักษณะดังนี้
ซึ่งโดยพื้นฐานแล้วคือสิ่งที่เบราว์เซอร์แสดงต่อโปรแกรมอ่านหน้าจอจริงๆ เบราว์เซอร์จะนำแผนผัง DOM มาแก้ไขให้อยู่ในรูปแบบที่เป็นประโยชน์ต่อเทคโนโลยีความช่วยเหลือพิเศษ เราเรียกแผนผังที่แก้ไขนี้ว่าแผนผังการช่วยเหลือพิเศษ
คุณอาจเห็นภาพต้นไม้การช่วยเหลือพิเศษที่ดูคล้ายกับหน้าเว็บเก่าๆ จากยุค 90 ซึ่งมีรูปภาพ 2-3 รูป ลิงก์จำนวนมาก และอาจมีช่องและปุ่ม
การสแกนหน้าเว็บด้วยสายตาแบบนี้จะทำให้คุณได้รับประสบการณ์ที่คล้ายกับที่ผู้ใช้โปรแกรมอ่านหน้าจอจะได้รับ อินเทอร์เฟซมีอยู่ แต่เรียบง่ายและตรงไปตรงมา คล้ายกับอินเทอร์เฟซแผนผังการช่วยเหลือพิเศษ
แผนผังการช่วยเหลือพิเศษคือสิ่งที่เทคโนโลยีความช่วยเหลือพิเศษส่วนใหญ่โต้ตอบด้วย ขั้นตอนจะเป็นประมาณนี้
- แอปพลิเคชัน (เบราว์เซอร์หรือแอปอื่นๆ) จะแสดงเวอร์ชันเชิงความหมายของ UI ต่อเทคโนโลยีความช่วยเหลือพิเศษผ่าน API
- เทคโนโลยีความช่วยเหลือพิเศษอาจใช้ข้อมูลที่อ่านผ่าน API เพื่อสร้างการนำเสนออินเทอร์เฟซผู้ใช้ทางเลือกสำหรับผู้ใช้ ตัวอย่างเช่น โปรแกรมอ่านหน้าจอจะสร้างอินเทอร์เฟซที่ผู้ใช้จะได้ยินเสียงพูดแทนการแสดงผลของแอป
- เทคโนโลยีความช่วยเหลือพิเศษยังอาจช่วยให้ผู้ใช้โต้ตอบกับแอปในรูปแบบที่แตกต่างออกไปได้ด้วย ตัวอย่างเช่น โปรแกรมอ่านหน้าจอส่วนใหญ่จะมีฮุกที่ช่วยให้ผู้ใช้จำลองการคลิกเมาส์หรือการแตะด้วยนิ้วได้ง่ายๆ
- เทคโนโลยีความช่วยเหลือพิเศษจะส่งต่อความตั้งใจของผู้ใช้ (เช่น "คลิก") กลับไปยังแอปผ่าน Accessibility API จากนั้นแอปจะมีหน้าที่ตีความการดำเนินการอย่างเหมาะสมในบริบทของ UI เดิม
สำหรับเว็บเบราว์เซอร์ จะมีขั้นตอนเพิ่มเติมในแต่ละทิศทาง เนื่องจากเบราว์เซอร์เป็นแพลตฟอร์มสำหรับเว็บแอปที่ทำงานภายในเบราว์เซอร์ ดังนั้นเบราว์เซอร์จึงต้องแปลเว็บแอปเป็นแผนผังการช่วยเหลือพิเศษ และต้องตรวจสอบว่าเหตุการณ์ที่เหมาะสมเริ่มทำงานใน JavaScript โดยอิงตามการดำเนินการของผู้ใช้ที่มาจากเทคโนโลยีความช่วยเหลือพิเศษ
แต่ทั้งหมดนี้เป็นความรับผิดชอบของเบราว์เซอร์ หน้าที่ของเราในฐานะนักพัฒนาเว็บคือการตระหนักว่าสิ่งนี้กำลังเกิดขึ้น และพัฒนาหน้าเว็บที่ใช้ประโยชน์จากกระบวนการนี้เพื่อสร้างประสบการณ์ที่เข้าถึงได้สำหรับผู้ใช้
เราทำเช่นนี้โดยตรวจสอบว่าเราแสดงความหมายของหน้าเว็บอย่างถูกต้อง กล่าวคือ ตรวจสอบว่าองค์ประกอบที่สำคัญในหน้าเว็บมีบทบาท สถานะ และพร็อพเพอร์ตี้ที่เข้าถึงได้ที่ถูกต้อง และเราระบุชื่อที่เข้าถึงได้และคำอธิบาย จากนั้นเบราว์เซอร์จะอนุญาตให้เทคโนโลยีความช่วยเหลือพิเศษเข้าถึงข้อมูลดังกล่าวเพื่อสร้างประสบการณ์การใช้งานที่ปรับแต่งเองได้
ความหมายใน HTML ของระบบ
เบราว์เซอร์สามารถเปลี่ยนแผนผัง DOM เป็นแผนผังการช่วยเหลือพิเศษได้เนื่องจาก DOM ส่วนใหญ่มีความหมายเชิงความหมายโดยนัย กล่าวคือ DOM จะใช้องค์ประกอบ HTML แบบเนทีฟที่เบราว์เซอร์รู้จักและทำงานได้อย่างคาดการณ์ได้ในแพลตฟอร์มต่างๆ ดังนั้น ระบบจะจัดการการช่วยเหลือพิเศษสำหรับองค์ประกอบ HTML แบบเนทีฟ เช่น ลิงก์หรือปุ่ม โดยอัตโนมัติ เราสามารถใช้ประโยชน์จาก Accessibility ในตัวนั้นได้โดยการเขียน HTML ที่แสดงความหมายขององค์ประกอบของหน้าเว็บ
อย่างไรก็ตาม บางครั้งเราใช้องค์ประกอบที่ดูเหมือนองค์ประกอบเนทีฟแต่ไม่ใช่ ตัวอย่างเช่น "ปุ่ม" นี้ไม่ใช่ปุ่มเลย
ซึ่งอาจสร้างขึ้นใน HTML ได้หลายวิธี โดยวิธีหนึ่งแสดงอยู่ด้านล่าง
<div class="button-ish">Give me tacos</div>
เมื่อเราไม่ได้ใช้องค์ประกอบปุ่มจริง โปรแกรมอ่านหน้าจอจะไม่มีทางรู้ว่ากำลังอยู่ที่องค์ประกอบใด นอกจากนี้ เรายังต้องทำงานเพิ่มเติมในการเพิ่ม tabindex เพื่อให้ผู้ใช้ที่ใช้แป้นพิมพ์เท่านั้นใช้งานได้ เนื่องจากโค้ดในปัจจุบันทำให้ใช้งานได้ด้วยเมาส์เท่านั้น
เราแก้ไขปัญหานี้ได้ง่ายๆ โดยใช้องค์ประกอบ button ปกติแทน div
การใช้องค์ประกอบแบบเนทีฟยังมีประโยชน์ในการดูแลการโต้ตอบกับแป้นพิมพ์ให้เราด้วย และอย่าลืมว่าคุณไม่จำเป็นต้องสูญเสียเอฟเฟกต์ภาพที่สวยงามเพียงเพราะใช้องค์ประกอบแบบเนทีฟ คุณสามารถจัดรูปแบบองค์ประกอบแบบเนทีฟให้มีลักษณะตามที่ต้องการได้ และยังคงรักษาความหมายและลักษณะการทำงานโดยนัยไว้ได้
ก่อนหน้านี้เราได้ระบุว่าโปรแกรมอ่านหน้าจอจะประกาศบทบาท ชื่อ สถานะ และค่าขององค์ประกอบ การใช้องค์ประกอบเชิงความหมายที่ถูกต้องจะครอบคลุมบทบาท สถานะ และค่า แต่เราต้องตรวจสอบด้วยว่าเราทำให้ชื่อขององค์ประกอบค้นพบได้
โดยทั่วไปแล้ว ชื่อจะมี 2 ประเภท ได้แก่
- ป้ายกำกับที่มองเห็นได้ ซึ่งผู้ใช้ทุกคนใช้เพื่อเชื่อมโยงความหมายกับองค์ประกอบ และ
- ข้อความแสดงแทน ซึ่งจะใช้เมื่อไม่จำเป็นต้องมีป้ายกำกับภาพเท่านั้น
สำหรับองค์ประกอบระดับข้อความ เราไม่จำเป็นต้องทำอะไรเลย เพราะตามคำจำกัดความแล้ว องค์ประกอบเหล่านี้จะมีเนื้อหาข้อความอยู่แล้ว อย่างไรก็ตาม สำหรับองค์ประกอบอินพุตหรือการควบคุม และเนื้อหาภาพ เช่น รูปภาพ เราต้องตรวจสอบว่าได้ระบุชื่อแล้ว อันที่จริงแล้ว การระบุข้อความสำรองสำหรับเนื้อหาที่ไม่ใช่ข้อความคือรายการแรกสุดในเช็กลิสต์ของ WebAIM
วิธีหนึ่งในการดำเนินการดังกล่าวคือทำตามคำแนะนำที่ว่า "อินพุตของแบบฟอร์มมีป้ายกำกับข้อความที่เชื่อมโยง" การเชื่อมโยงป้ายกำกับกับองค์ประกอบของแบบฟอร์ม เช่น ช่องทำเครื่องหมาย มี 2 วิธีดังนี้ ทั้ง 2 วิธีทำให้ข้อความป้ายกำกับกลายเป็นเป้าหมายการคลิกสำหรับช่องทำเครื่องหมายด้วย ซึ่งเป็นประโยชน์สำหรับผู้ใช้เมาส์หรือหน้าจอสัมผัสเช่นกัน หากต้องการเชื่อมโยงป้ายกำกับกับองค์ประกอบ ให้ทำอย่างใดอย่างหนึ่งต่อไปนี้
- วางองค์ประกอบการป้อนข้อมูลไว้ภายในองค์ประกอบป้ายกำกับ
<label>
<input type="checkbox">Receive promotional offers?
</label>หรือ
- ใช้แอตทริบิวต์
forของป้ายกำกับและอ้างอิงidขององค์ประกอบ
<input id="promo" type="checkbox">
<label for="promo">Receive promotional offers?</label>
เมื่อติดป้ายกำกับช่องทำเครื่องหมายอย่างถูกต้อง โปรแกรมอ่านหน้าจอจะรายงานได้ว่าองค์ประกอบมีบทบาทเป็นช่องทำเครื่องหมาย อยู่ในสถานะเลือกแล้ว และมีชื่อว่า "รับข้อเสนอโปรโมชันไหม"
