วิธีตรวจสอบการช่วยเหลือพิเศษ

Rob Dodson

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

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

เริ่มด้วยแป้นพิมพ์

ผู้ใช้ที่ไม่สามารถหรือเลือกที่จะไม่ใช้เมาส์จะใช้การไปยังส่วนต่างๆ ด้วยแป้นพิมพ์เป็นวิธีหลักในการเข้าถึงทุกอย่างบนหน้าจอ กลุ่มเป้าหมายนี้รวมถึงผู้ใช้ที่มีความบกพร่องด้านการเคลื่อนไหว เช่น การบาดเจ็บจากกิจวัตรเดิมซ้ำๆ (Repetitive Stress Injury: RSI) หรืออัมพาต รวมถึงผู้ใช้โปรแกรมอ่านหน้าจอ

มุ่งเน้นที่จะมีลําดับแท็บที่สมเหตุสมผลและสไตล์โฟกัสที่แยกแยะได้อย่างชัดเจน เพื่อให้ผู้ใช้ได้รับประสบการณ์การใช้งานแป้นพิมพ์ที่ดี

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

  • การควบคุมแบบอินเทอร์แอกทีฟที่กําหนดเองควรโฟกัสได้ หากคุณใช้ JavaScript เพื่อเปลี่ยน <div> เป็นเมนูแบบเลื่อนลง ระบบจะไม่แทรก <div> ลงในลําดับแท็บโดยอัตโนมัติ หากต้องการให้ตัวควบคุมที่กำหนดเองโฟกัสได้ ให้ใส่ tabindex="0" ค่า tabindex ที่มากกว่า 0 จะเปลี่ยนลําดับการกด Tab และอาจทําให้ผู้ใช้โปรแกรมอ่านหน้าจอสับสน

  • ทำให้เฉพาะเนื้อหาแบบอินเทอร์แอกทีฟเท่านั้นที่โฟกัสได้ การเพิ่ม tabindex ลงในองค์ประกอบที่ไม่ใช่แบบอินเทอร์แอกทีฟ เช่น หัวเรื่อง จะทําให้ผู้ใช้แป้นพิมพ์ที่มองเห็นหน้าจอทํางานช้าลง และไม่ได้ช่วยให้ผู้ใช้โปรแกรมอ่านหน้าจอได้รับประโยชน์ เนื่องจากโปรแกรมอ่านหน้าจอจะรู้อยู่แล้วว่าจะประกาศองค์ประกอบดังกล่าว

  • หากคุณเพิ่มเนื้อหาใหม่ลงในหน้าเว็บ ให้นำโฟกัสของผู้ใช้ไปยังเนื้อหานั้นก่อนเพื่อให้ผู้ใช้ดำเนินการกับเนื้อหาได้ ดูตัวอย่างได้ที่หัวข้อการจัดการโฟกัสที่ระดับหน้าเว็บ

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

ทําให้การควบคุมโฟกัสใช้งานได้

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

จัดการเนื้อหาที่อยู่นอกหน้าจอ

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

ดูเคล็ดลับในการจัดการองค์ประกอบเหล่านี้ได้ที่การจัดการเนื้อหาที่อยู่นอกหน้าจอ

ทดสอบด้วยโปรแกรมอ่านหน้าจอ

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

หากคุณไม่คุ้นเคยกับวิธีที่เทคโนโลยีความช่วยเหลือพิเศษตีความมาร์กอัปเชิงความหมาย โปรดอ่านโครงสร้างเนื้อหา

  • ตรวจสอบรูปภาพทั้งหมดเพื่อดูว่าข้อความ alt ถูกต้อง ข้อยกเว้นของแนวทางปฏิบัตินี้คือเมื่อรูปภาพมีไว้เพื่อวัตถุประสงค์ในการนำเสนอเป็นหลักและไม่ใช่เนื้อหาส่วนสําคัญ หากต้องการระบุว่าโปรแกรมอ่านหน้าจอควรข้ามรูปภาพ ให้ตั้งค่าเป็นสตริงว่างเปล่า alt=""
  • ตรวจสอบการควบคุมทั้งหมดเพื่อหาป้ายกำกับ สำหรับการควบคุมที่กำหนดเอง คุณอาจต้องใช้ aria-label หรือ aria-labelledby ดูตัวอย่างได้ที่ป้ายกำกับและความสัมพันธ์ ARIA
  • ตรวจสอบตัวควบคุมที่กำหนดเองทั้งหมดว่ามี role ที่เหมาะสมและแอตทริบิวต์ ARIA ที่จำเป็นซึ่งแสดงสถานะของตัวควบคุม เช่น ช่องทําเครื่องหมายที่กําหนดเองต้องมี role="checkbox" และ aria-checked="true|false" เพื่อสื่อสถานะอย่างถูกต้อง ดูข้อมูลเบื้องต้นเกี่ยวกับ ARIA เพื่อดูภาพรวมทั่วไปเกี่ยวกับวิธีที่ ARIA ระบุความหมายที่ขาดหายไปสำหรับการควบคุมที่กำหนดเอง
  • จัดระเบียบข้อมูลในหน้าเว็บให้เข้าใจง่าย เนื่องจากโปรแกรมอ่านหน้าจอไปยังส่วนต่างๆ ของหน้าเว็บตามลําดับ DOM จึงจะอ่านออกเสียงองค์ประกอบที่คุณจัดเรียงใหม่ด้วยสายตาโดยใช้ CSS ในลําดับที่ไม่สอดคล้องกัน หากต้องการให้สิ่งใดปรากฏในหน้าเว็บก่อน ให้ย้ายรายการนั้นไปไว้ก่อนใน DOM
  • มุ่งเน้นที่การรองรับการไปยังส่วนต่างๆ ด้วยโปรแกรมอ่านหน้าจอสำหรับเนื้อหาทั้งหมดในหน้า ตรวจสอบว่าไม่มีส่วนใดของเว็บไซต์ที่ซ่อนหรือบล็อกไม่ให้โปรแกรมอ่านหน้าจอเข้าถึงอย่างถาวร
    • หากเนื้อหาควรซ่อนจากโปรแกรมอ่านหน้าจอ เช่น อยู่นอกหน้าจอหรือเป็นเพียงการแสดงผล ให้ตั้งค่าเนื้อหานั้นเป็น aria-hidden="true" ดูคำอธิบายเพิ่มเติมได้ในหัวข้อการซ่อนเนื้อหา

ทำความคุ้นเคยกับโปรแกรมอ่านหน้าจอ

แม้ว่าการเรียนรู้โปรแกรมอ่านหน้าจออาจดูน่ากลัว แต่จริงๆ แล้วโปรแกรมเหล่านี้ค่อนข้างใช้งานง่าย โดยทั่วไป นักพัฒนาแอปส่วนใหญ่จะดำเนินการได้โดยใช้คำสั่งแป้นพิมพ์ง่ายๆ เพียงไม่กี่รายการ

หากใช้ Mac โปรดดูวิดีโอเกี่ยวกับ VoiceOver ซึ่งเป็นโปรแกรมอ่านหน้าจอที่มาพร้อมกับ Mac OS หากคุณใช้ PC โปรดดูวิดีโอเกี่ยวกับ NVDA ซึ่งเป็นโปรแกรมอ่านหน้าจอแบบโอเพนซอร์สที่รับเงินบริจาคสำหรับ Windows

aria-hidden ไม่ป้องกันโฟกัสแป้นพิมพ์

สิ่งสำคัญคือต้องเข้าใจว่า ARIA จะส่งผลต่อความหมายขององค์ประกอบเท่านั้น และไม่ส่งผลต่อลักษณะการทำงานขององค์ประกอบ คุณทำให้องค์ประกอบซ่อนอยู่จากโปรแกรมอ่านหน้าจอได้โดยใช้ aria-hidden="true" แต่การดำเนินการนี้จะไม่เปลี่ยนลักษณะการทำงานของโฟกัสสำหรับองค์ประกอบนั้น สำหรับเนื้อหาแบบอินเทอร์แอกทีฟที่อยู่นอกหน้าจอ ให้ใช้แอตทริบิวต์ inert เพื่อให้แน่ใจว่าเนื้อหาดังกล่าวถูกนำออกจากโฟลว์แป้นพิมพ์แล้ว สําหรับเบราว์เซอร์เวอร์ชันเก่า ให้รวม aria-hidden="true" เข้ากับ tabindex="-1"

องค์ประกอบแบบอินเทอร์แอกทีฟควรระบุวัตถุประสงค์และสถานะ

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

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

ใช้หัวข้อและจุดสังเกต

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

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

  • ใช้ลําดับชั้น h1-h6 ให้คิดว่าส่วนหัวเป็นเครื่องมือในการสร้างเค้าโครงของหน้า อย่าใช้การจัดรูปแบบส่วนหัวที่มีอยู่แล้ว แต่ให้ถือว่าเนื้อหามีขนาดใหญ่เท่ากันทั้งหมดและใช้ระดับที่เหมาะสมตามความหมายสำหรับเนื้อหาหลัก รอง และเนื้อหาเสริม จากนั้นใช้ CSS เพื่อทําให้ส่วนหัวตรงกับการออกแบบ
  • ใช้องค์ประกอบและบทบาทจุดสังเกตเพื่อให้ผู้ใช้ข้ามเนื้อหาที่ซ้ำกันได้ เทคโนโลยีความช่วยเหลือพิเศษจํานวนมากมีแป้นพิมพ์ลัดสําหรับข้ามไปยังส่วนต่างๆ ของหน้า เช่น ส่วนที่กําหนดโดยองค์ประกอบ <main> หรือ <nav> องค์ประกอบเหล่านี้มีบทบาทจุดสังเกตโดยนัย นอกจากนี้ คุณยังใช้แอตทริบิวต์ ARIA role เพื่อกำหนดภูมิภาคในหน้าเว็บอย่างชัดเจนได้ ดังตัวอย่างใน <div role="search"> ดูตัวอย่างเพิ่มเติมได้ในความหมายและการนำทางเนื้อหา
  • หลีกเลี่ยงrole="application" เว้นแต่คุณจะมีประสบการณ์ในการใช้งาน บทบาทจุดสังเกต application จะบอกให้เทคโนโลยีความช่วยเหลือพิเศษปิดใช้แป้นพิมพ์ลัดและส่งการกดแป้นพิมพ์ทั้งหมดไปยังหน้าเว็บ ซึ่งหมายความว่าแป้นที่ผู้ใช้โปรแกรมอ่านหน้าจอมักใช้เพื่อไปยังส่วนต่างๆ ของหน้าเว็บจะไม่ทำงานอีกต่อไป และคุณจะต้องจัดการแป้นพิมพ์ทั้งหมดด้วยตนเอง

ตรวจสอบส่วนหัวและจุดสังเกตด้วยโปรแกรมอ่านหน้าจอ

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

ดูข้อมูลเพิ่มเติมได้จากวิดีโอแนะนำเหล่านี้เกี่ยวกับพื้นฐานของ VoiceOver และ NVDA

ทำให้กระบวนการเป็นแบบอัตโนมัติ

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

  • หน้าเว็บผ่านการทดสอบทั้งหมดจากส่วนขยายเบราว์เซอร์ aXe หรือ WAVE หรือไม่ ยังมีตัวเลือกอื่นๆ อยู่ แต่ส่วนขยายเหล่านี้จะมีประโยชน์เพิ่มเติมในกระบวนการทดสอบด้วยตนเอง เนื่องจากสามารถตรวจหาปัญหาเล็กๆ น้อยๆ เช่น อัตราส่วนคอนทราสต์ไม่ผ่านเกณฑ์และไม่มีแอตทริบิวต์ ARIA
    • หากต้องการใช้บรรทัดคำสั่ง axe-cli มีฟีเจอร์เดียวกับส่วนขยายเบราว์เซอร์ aXe แต่สามารถเรียกใช้จากเทอร์มินัลได้
  • เพื่อหลีกเลี่ยงการถดถอย โดยเฉพาะอย่างยิ่งในสภาพแวดล้อมการผสานรวมอย่างต่อเนื่อง ให้รวมไลบรารีอย่าง axe-core ไว้ในชุดทดสอบอัตโนมัติ axe-core เป็นเครื่องมือเดียวกับที่ขับเคลื่อนส่วนขยาย aXe ใน Chrome แต่เป็นยูทิลิตีบรรทัดคำสั่ง
  • หากคุณใช้เฟรมเวิร์กหรือไลบรารี เฟรมเวิร์กหรือไลบรารีนั้นให้เครื่องมือการช่วยเหลือพิเศษของตนเองไหม เช่น protractor-accessibility-plugin สำหรับ Angular ใช้เครื่องมือที่มีให้เมื่อเป็นไปได้

ใช้ Lighthouse เพื่อทดสอบ PWA

Lighthouse เป็นเครื่องมือที่วัดประสิทธิภาพของ Progressive Web App (PWA) และใช้ไลบรารี axe-core เพื่อขับเคลื่อนการทดสอบการช่วยเหลือพิเศษ

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

แหล่งข้อมูลเพิ่มเติม