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