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

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

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

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

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

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

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

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

  • ทำให้เฉพาะเนื้อหาแบบอินเทอร์แอกทีฟโฟกัสได้ กำลังเพิ่ม 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 หากใช้พีซี ลองดู วิดีโอเกี่ยวกับ NVDA โปรแกรมอ่านหน้าจอแบบโอเพนซอร์สสำหรับ Windows ที่รองรับการบริจาค

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

คุณควรเข้าใจว่า ARIA สามารถส่งผลต่อความหมายของ element; ก็ไม่มีผลต่อลักษณะการทำงานขององค์ประกอบ คุณสามารถ องค์ประกอบที่ซ่อนจากโปรแกรมอ่านหน้าจอด้วย 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 เป็นกลไกเดียวกับที่ขับเคลื่อน ส่วนขยาย Chrome แต่อยู่ในยูทิลิตีบรรทัดคำสั่ง
  • หากใช้เฟรมเวิร์กหรือไลบรารี เฟรมเวิร์กหรือไลบรารีดังกล่าวมีการช่วยเหลือพิเศษของตัวเองไหม เครื่องมือ ตัวอย่างเช่น พารามิเตอร์ protractor-accessibility-plugin ของ Angular ใช้ประโยชน์จากเครื่องมือที่มีเมื่อทำได้

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

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

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

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