โมดูลนี้มุ่งเน้นที่การใช้เทคโนโลยีความช่วยเหลือพิเศษ (AT) สำหรับการทดสอบการช่วยเหลือพิเศษ ผู้พิการสามารถใช้ AT เพื่อช่วยเพิ่ม รักษา หรือปรับปรุงความสามารถในการทำงาน
ในโลกดิจิทัล AT สามารถทำสิ่งต่อไปนี้ได้
- ไม่สำคัญ/เทคโนโลยีต่ำ: อุปกรณ์ยึดติดศีรษะ/ปาก แว่นขยายแบบมือถือ อุปกรณ์ที่มีปุ่มขนาดใหญ่
- เทคโนโลยีขั้นสูง: อุปกรณ์ที่สั่งงานด้วยเสียง อุปกรณ์ติดตามสายตา แป้นพิมพ์/เมาส์แบบปรับอัตโนมัติ
- ฮาร์ดแวร์: ปุ่มเปลี่ยน แป้นพิมพ์แบบสรีระ อุปกรณ์อักษรเบรลล์ที่รีเฟรชอัตโนมัติ
- ซอฟต์แวร์: โปรแกรมอ่านออกเสียงข้อความ คำบรรยายสด โปรแกรมอ่านหน้าจอ
เราขอแนะนําให้ใช้ AT หลายประเภทในเวิร์กโฟลว์การทดสอบโดยรวม
ข้อมูลเบื้องต้นเกี่ยวกับการทดสอบโปรแกรมอ่านหน้าจอ
ในโมดูลนี้ เราจะมุ่งเน้นไปที่โปรแกรมอ่านหน้าจอ AT ดิจิทัลยอดนิยมโปรแกรมหนึ่ง โปรแกรมอ่านหน้าจอคือชิ้นส่วนของซอฟต์แวร์ที่อ่านโค้ดที่สำคัญของเว็บไซต์หรือแอป จากนั้นจะแปลงข้อมูลดังกล่าวเป็นเสียงพูดหรือเอาต์พุตอักษรเบรลล์สำหรับผู้ใช้
โปรแกรมอ่านหน้าจอจำเป็นสำหรับผู้ที่ตาบอดและหูหนวก แต่ก็ยังเป็นประโยชน์ต่อผู้ที่มีสายตาเลือนราง มีความผิดปกติด้านการอ่าน หรือความบกพร่องทางสติปัญญาด้วย
ความเข้ากันได้กับเบราว์เซอร์
โปรแกรมอ่านหน้าจอมีตัวเลือกอยู่หลายรายการ โปรแกรมอ่านหน้าจอที่ได้รับความนิยมมากที่สุดในปัจจุบันคือ JAWS, NVDA และ VoiceOver สำหรับคอมพิวเตอร์เดสก์ท็อป รวมทั้ง VoiceOver และ Talkback สำหรับอุปกรณ์เคลื่อนที่
โปรแกรมอ่านหน้าจอหนึ่งอาจโดดเด่นกว่าตัวเลือกที่ดีที่สุด ทั้งนี้ขึ้นอยู่กับระบบปฏิบัติการ (OS) เบราว์เซอร์โปรด และอุปกรณ์ที่ใช้ โปรแกรมอ่านหน้าจอส่วนใหญ่สร้างขึ้นโดยคำนึงถึงฮาร์ดแวร์และเว็บเบราว์เซอร์ที่เฉพาะเจาะจง เมื่อใช้โปรแกรมอ่านหน้าจอกับเบราว์เซอร์ที่ไม่มีการปรับเทียบ คุณอาจพบ "ข้อบกพร่อง" เพิ่มเติม หรือการทำงานที่ไม่คาดคิด โปรแกรมอ่านหน้าจอทำงานได้ดีที่สุดเมื่อใช้คู่กันต่อไปนี้
คำสั่งของโปรแกรมอ่านหน้าจอ
เมื่อตั้งค่าซอฟต์แวร์โปรแกรมอ่านหน้าจออย่างเหมาะสมสำหรับเดสก์ท็อปหรืออุปกรณ์เคลื่อนที่แล้ว คุณควรดูเอกสารประกอบของโปรแกรมอ่านหน้าจอ (ตามลิงก์ในตารางก่อนหน้านี้) และศึกษาคำสั่งของโปรแกรมอ่านหน้าจอที่จำเป็นเพื่อทำความคุ้นเคยกับเทคโนโลยีดังกล่าว หากเคยใช้โปรแกรมอ่านหน้าจอมาก่อน เราขอแนะนำให้ลองใช้โปรแกรมใหม่
เมื่อใช้โปรแกรมอ่านหน้าจอเพื่อทดสอบการช่วยเหลือพิเศษ เป้าหมายคือการตรวจหาปัญหาในโค้ดที่รบกวนการใช้งานเว็บไซต์หรือแอป ไม่ใช่เพื่อจำลองประสบการณ์ของผู้ใช้โปรแกรมอ่านหน้าจอ ดังนั้น คุณจึงมีสิ่งต่างๆ มากมายที่คุณสามารถทำได้หากมีความรู้พื้นฐาน คำสั่งของโปรแกรมอ่านหน้าจอ 2-3 อย่าง และฝึกฝนเพิ่มอีกเล็กน้อยหรือหลายอย่างก็ได้
หากต้องการทำความเข้าใจประสบการณ์ของผู้ใช้จากผู้ที่ใช้โปรแกรมอ่านหน้าจอและ AT อื่นๆ เพิ่มเติม คุณก็สามารถมีส่วนร่วมกับองค์กรและบุคคลจำนวนมากเพื่อรับข้อมูลเชิงลึกที่มีค่านี้ได้ โปรดจำไว้ว่าการใช้ AT เพื่อทดสอบโค้ดกับชุดกฎต่างๆ และการถามเกี่ยวกับประสบการณ์ของผู้ใช้มักจะให้ผลลัพธ์ที่แตกต่างกัน ทั้ง 2 ปัจจัยเป็นสิ่งสำคัญในการสร้างผลิตภัณฑ์ที่ครอบคลุมอย่างเต็มรูปแบบ
คำสั่งแป้นพิมพ์สำหรับโปรแกรมอ่านหน้าจอเดสก์ท็อป
คำสั่งแป้นพิมพ์สำหรับโปรแกรมอ่านหน้าจอบนอุปกรณ์เคลื่อนที่
การสาธิตการทดสอบโปรแกรมอ่านหน้าจอ
ในการทดสอบการสาธิต เราใช้ Safari บนแล็ปท็อปที่ใช้ MacOS และบันทึกเสียง คุณทำตามขั้นตอนเหล่านี้โดยใช้โปรแกรมอ่านหน้าจอใดก็ได้ แต่วิธีที่พบข้อผิดพลาดบางอย่างอาจต่างจากวิธีที่อธิบายไว้ในโมดูลนี้
ขั้นตอนที่ 1
ไปที่ CodePen ที่อัปเดตแล้วซึ่ง มีการใช้การอัปเดตการช่วยเหลือพิเศษทั้งแบบอัตโนมัติและด้วยตนเองแล้ว
โปรดดูในโหมดแก้ไขข้อบกพร่องเพื่อดำเนินการ
การทดสอบถัดไป นี่เป็นสิ่งสำคัญ เพราะจะนำ <iframe> ที่อยู่รอบๆ ออก
หน้าเว็บสาธิต ซึ่งอาจรบกวนเครื่องมือทดสอบบางอย่าง ดูข้อมูลเพิ่มเติมเกี่ยวกับ
โหมดแก้ไขข้อบกพร่องของ CodePen
ขั้นตอนที่ 2
เปิดใช้งานโปรแกรมอ่านหน้าจอที่ต้องการและไปที่หน้าสาธิต คุณอาจลองเลื่อนดูทั้งหน้าจากบนลงล่างก่อนที่จะโฟกัสที่ปัญหาเฉพาะจุด
เราได้บันทึกโปรแกรมอ่านหน้าจอสำหรับแต่ละปัญหาทั้งก่อนและหลังจากการแก้ไขที่นำไปใช้ในการสาธิต เราขอแนะนำให้คุณดูตัวอย่างดังกล่าวด้วยโปรแกรมอ่านหน้าจอของคุณเอง
ประเด็นที่ 1: โครงสร้างเนื้อหา
ส่วนหัวและจุดสังเกตเป็นวิธีหลักวิธีหนึ่งที่ผู้ใช้ไปยังส่วนต่างๆ โดยใช้โปรแกรมอ่านหน้าจอ ในกรณีที่ไม่มีหน้าเหล่านี้ ผู้ใช้โปรแกรมอ่านหน้าจอจะต้องอ่านทั้งหน้าเพื่อทำความเข้าใจบริบท ซึ่งอาจใช้เวลานานและทำให้รู้สึกหงุดหงิด ถ้าคุณพยายามไปยังส่วนต่างๆ ตามองค์ประกอบใดองค์ประกอบหนึ่งในการสาธิต คุณจะค้นพบได้อย่างรวดเร็วว่าองค์ประกอบเหล่านั้นไม่มีอยู่จริง
- ตัวอย่างจุดสังเกต ได้แก่
<div class="main">...</div> - ตัวอย่างหัวข้อ:
<p class="h1">Join the Club</p>
หากอัปเดตทุกอย่างอย่างถูกต้องแล้ว ก็จะไม่น่าจะมีการเปลี่ยนแปลงภาพ แต่ประสบการณ์การใช้โปรแกรมอ่านหน้าจอของคุณจะดีขึ้นอย่างมาก
มาแก้ไขกันเลย
องค์ประกอบบางอย่างที่ไม่สามารถเข้าถึงได้ไม่อาจสังเกตได้ด้วยการดูเว็บไซต์ คุณอาจจำความสำคัญของระดับส่วนหัวและ HTML เชิงความหมายได้จากโมดูลโครงสร้างเนื้อหา เนื้อหาชิ้นหนึ่งอาจดูเหมือนส่วนหัว แต่จริงๆ แล้วเนื้อหารวมอยู่ใน <div> ที่ทำสไตไลซ์
ในการแก้ไขปัญหาเกี่ยวกับส่วนหัวและจุดสังเกต ก่อนอื่นคุณต้องระบุแต่ละองค์ประกอบที่ควรมาร์กอัปและอัปเดต HTML ที่เกี่ยวข้อง โปรดอัปเดต CSS ที่เกี่ยวข้องด้วย
ตัวอย่างจุดสังเกต ได้แก่ <main>...</main>
ตัวอย่างหัวข้อ: <h1>Join the Club</h1>
หากอัปเดตทุกอย่างอย่างถูกต้องแล้ว ก็จะไม่น่าจะมีการเปลี่ยนแปลงภาพ แต่ประสบการณ์การใช้โปรแกรมอ่านหน้าจอของคุณจะดีขึ้นอย่างมาก
ปัญหา 2: บริบทของลิงก์
คุณควรให้เนื้อหาแก่ผู้ใช้โปรแกรมอ่านหน้าจอเกี่ยวกับวัตถุประสงค์ของลิงก์และตรวจสอบว่าลิงก์เปลี่ยนเส้นทางผู้ใช้ไปยังตำแหน่งใหม่นอกเว็บไซต์หรือแอปหรือไม่
ในการสาธิตนี้ เราแก้ไขลิงก์ส่วนใหญ่เมื่อเราอัปเดตข้อความทางเลือกของรูปภาพที่ใช้งานอยู่ แต่มีลิงก์เพิ่มเติมอีกเล็กน้อยเกี่ยวกับโรคที่พบไม่บ่อยนัก ซึ่งอาจได้รับประโยชน์จากการให้บริบทเพิ่มเติม โดยเฉพาะเมื่อเปลี่ยนเส้นทางไปยังตำแหน่งใหม่
<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease">
Maple syrup urine disease (MSUD)
</a>
ในการแก้ปัญหานี้สำหรับผู้ใช้โปรแกรมอ่านหน้าจอ เราอัปเดตโค้ดเพื่อเพิ่มข้อมูลเพิ่มเติมโดยไม่ส่งผลกระทบต่อองค์ประกอบภาพ หรือเราอาจเลือกใส่ข้อความพร้อมภาพอื่นแทน เพื่อช่วยผู้คนจำนวนมากขึ้น เช่น ผู้ที่มีความผิดปกติเกี่ยวกับการอ่านและการรับรู้
มีรูปแบบที่แตกต่างกันมากมายที่เราอาจพิจารณาเพื่อเพิ่มข้อมูลลิงก์เพิ่มเติม ป้ายกำกับ ARIA เป็นตัวเลือกที่ไม่ซับซ้อนในสถานการณ์นี้เนื่องด้วยสภาพแวดล้อมที่เรียบง่ายของเราที่รองรับเพียงภาษาเดียว คุณอาจสังเกตเห็นว่าป้ายกำกับ ARIA จะแทนที่ข้อความลิงก์ต้นฉบับ ดังนั้นอย่าลืมใส่ข้อมูลนั้นไว้ในการอัปเดต
<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease"
aria-label="Learn more about Maple syrup urine disease on the Rare Diseases website.">
Maple syrup urine disease (MSUD)
</a>
ปัญหา 3: รูปภาพตกแต่ง
ในโมดูลการทดสอบอัตโนมัติของเรา Lighthouse ไม่สามารถเลือกใช้ SVG แทรกในบรรทัดซึ่งทำหน้าที่เป็นรูปภาพแนะนำหลักในหน้าสาธิต แต่โปรแกรมอ่านหน้าจอพบและประกาศว่าเป็น "รูปภาพ" โดยไม่มีข้อมูลเพิ่มเติม และจะเป็นเช่นนี้เสมอ แม้จะไม่ได้เพิ่มแอตทริบิวต์ role="img" ลงใน SVG อย่างชัดแจ้งก็ตาม
<div class="section-right">
<svg>...</svg>
</div>
ในการแก้ไขปัญหานี้ เราต้องพิจารณาก่อนว่ารูปภาพนั้นมีข้อมูลหรือการตกแต่ง เราต้องเพิ่มข้อความสำรองของรูปภาพที่เหมาะสม (รูปภาพให้ข้อมูล) หรือซ่อนรูปภาพไม่ให้ผู้ใช้โปรแกรมอ่านหน้าจอ (ตกแต่ง) ออก ขึ้นอยู่กับการตัดสินใจดังกล่าว
เราได้ชั่งน้ำหนักระหว่างข้อดีและข้อเสียของวิธีการจัดหมวดหมู่รูปภาพที่ดีที่สุด และตัดสินใจว่ารูปภาพนั้นมีการตกแต่ง ซึ่งหมายความว่าเราต้องการเพิ่มหรือแก้ไขโค้ดเพื่อซ่อนรูปภาพ วิธีที่รวดเร็วคือการเพิ่ม role="presentation" ลงในรูปภาพ SVG โดยตรง การดำเนินการนี้จะส่งสัญญาณไปยังโปรแกรมอ่านหน้าจอให้ข้ามรูปภาพนี้และไม่ต้องแสดงรูปภาพดังกล่าวในกลุ่มรูปภาพ
<div class="section-right">
<svg role="presentation">...</svg>
</div>
ปัญหา 4: การตกแต่งหัวข้อย่อย
คุณอาจสังเกตเห็นว่าโปรแกรมอ่านหน้าจออ่านภาพสัญลักษณ์หัวข้อย่อย CSS ที่อยู่ใต้ เกี่ยวกับโรคที่พบไม่บ่อย ถึงแม้เราจะไม่ใช่รูปภาพ รูปแบบดั้งเดิมที่เรา ตามที่ได้กล่าวไว้ในโมดูลรูปภาพ ยังคงต้องแก้ไขรูปภาพเมื่อรบกวน การไหลเวียนของเนื้อหา และอาจหันเหความสนใจหรือทำให้ผู้ใช้โปรแกรมอ่านหน้าจอสับสน
<p class="bullet">...</p>
เช่นเดียวกับตัวอย่างรูปภาพตกแต่งที่พูดถึงไปก่อนหน้า คุณจะเพิ่ม role="presentation" ลงใน HTML ด้วยคลาสหัวข้อย่อยเพื่อซ่อนไว้จากโปรแกรมอ่านหน้าจอได้ ในทำนองเดียวกัน role="none" ก็ใช้ได้ เพียงตรวจสอบให้แน่ใจว่าคุณไม่ได้ใช้ aria-hidden: true มิเช่นนั้นระบบจะซ่อนข้อมูลย่อหน้าทั้งหมดไม่ให้ผู้ใช้เห็น
<p class="bullet" role="none">...</p>
ปัญหาที่ 5: ช่องในแบบฟอร์ม
ในโมดูลฟอร์ม เราได้เรียนรู้ว่าแบบฟอร์มทั้งหมด ต้องมีป้ายกำกับที่เป็นภาพและแบบเป็นโปรแกรมด้วย ป้ายกำกับนี้ต้องยังคงอยู่ มองเห็นได้ตลอดเวลา
ในการสาธิต เราไม่มีป้ายกำกับทั้งแบบภาพและแบบเป็นโปรแกรมในช่องอีเมลการสมัครรับจดหมายข่าว มีองค์ประกอบตัวยึดตำแหน่งข้อความแต่ไม่ได้แทนที่ป้ายกำกับเนื่องจากไม่ได้แสดงภาพต่อเนื่องและใช้งานร่วมกับโปรแกรมอ่านหน้าจอทั้งหมดไม่ได้โดยสมบูรณ์
<form>
<div class="form-group">
<input type="email" placeholder="Enter your e-mail address" required>
<button type="submit">Subscribe</button>
</div>
</form>
ในการแก้ไขปัญหานี้ ให้แทนที่ตัวยึดตำแหน่งข้อความด้วยองค์ประกอบป้ายกำกับที่คล้ายคลึง เอลิเมนต์ป้ายกำกับดังกล่าวจะเชื่อมต่อแบบเป็นโปรแกรมกับช่องของแบบฟอร์ม และมีการเพิ่มการเคลื่อนไหวด้วย JavaScript เพื่อให้ป้ายกำกับมองเห็นได้ แม้จะมีการเพิ่มเนื้อหาลงในช่องก็ตาม
<form>
<div class="form-group">
<input type="email" required id="youremail" name="youremail" type="text">
<label for="youremail">Enter your e-mail address</label>
<button type="submit" aria-label="Subscribe to our newsletter">Subscribe</button>
</div>
</form>
สรุป
ยินดีด้วย คุณทดสอบการสาธิตนี้เสร็จสมบูรณ์แล้ว คุณสามารถดูการเปลี่ยนแปลงทั้งหมดเหล่านี้ได้ในโค้ดที่อัปเดตสําหรับการสาธิตนี้
ตอนนี้คุณก็ใช้สิ่งที่ได้เรียนรู้ในการตรวจสอบการช่วยเหลือพิเศษของตัวเองได้แล้ว เว็บไซต์และแอปเหล่านี้
เป้าหมายของการทดสอบความสามารถเข้าถึงได้ง่ายทั้งหมดนี้คือ เพื่อแก้ปัญหาให้ได้มากที่สุด ที่ผู้ใช้อาจพบเจอ แต่ไม่ได้หมายความว่าเว็บไซต์หรือแอปของคุณ จะเข้าใช้งานได้ทันทีเมื่อคุณดำเนินการเสร็จ คุณจะพบความสำเร็จสูงสุดโดย ออกแบบเว็บไซต์หรือแอปให้เข้าถึงได้ง่ายตลอดกระบวนการ และ ใช้การทดสอบเหล่านี้กับการทดสอบอื่นๆ ก่อนการเปิดตัว
ตรวจสอบความเข้าใจ
ทดสอบความรู้ของคุณเกี่ยวกับการทดสอบการช่วยเหลือพิเศษโดยอัตโนมัติ
โปรแกรมอ่านหน้าจอใดที่ดีที่สุดในการทดสอบการช่วยเหลือพิเศษ
การทดสอบด้วยเทคโนโลยีความช่วยเหลือพิเศษมีไว้เพื่ออะไร