การทดสอบการเข้าถึงอัตโนมัติ

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

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

การทดสอบแต่ละประเภท ไม่ว่าจะเป็นแบบอัตโนมัติ ดำเนินการด้วยตนเอง และเทคโนโลยีความช่วยเหลือ ล้วนมีความสำคัญต่อการสร้างผลิตภัณฑ์ที่เข้าถึงได้ง่ายที่สุด การทดสอบของเราใช้หลักเกณฑ์การพัฒนาเนื้อหาเว็บที่ทุกคนสามารถเข้าถึงได้ง่าย (WCAG) 2.1 ระดับการปฏิบัติตามข้อกำหนด A และ AA เป็นมาตรฐาน

โปรดทราบว่าอุตสาหกรรม ประเภทผลิตภัณฑ์ กฎหมายและนโยบายท้องถิ่นและระดับประเทศ หรือเป้าหมายการช่วยเหลือพิเศษโดยรวมเป็นตัวกำหนดหลักเกณฑ์ที่ควรปฏิบัติตามและระดับที่ควรบรรลุ หากคุณไม่ต้องการมาตรฐานที่เฉพาะเจาะจงสำหรับโปรเจ็กต์ เราขอแนะนำให้ปฏิบัติตาม WCAG เวอร์ชันล่าสุด โปรดดู "การช่วยเหลือพิเศษทางดิจิทัลวัดอย่างไร" เพื่อดูข้อมูลทั่วไปเกี่ยวกับการตรวจสอบการช่วยเหลือพิเศษ, ประเภท/ระดับความสอดคล้อง, WCAG และ POUR

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

ข้อมูลเบื้องต้นเกี่ยวกับการทดสอบอัตโนมัติ

การทดสอบการช่วยเหลือพิเศษอัตโนมัติใช้ซอฟต์แวร์เพื่อสแกนผลิตภัณฑ์ดิจิทัลเพื่อหาปัญหาการช่วยเหลือพิเศษเทียบกับมาตรฐานการปฏิบัติตามข้อกำหนดการช่วยเหลือพิเศษที่กำหนดไว้ล่วงหน้า

ข้อดีของการทดสอบการช่วยเหลือพิเศษอัตโนมัติมีดังนี้

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

ข้อเสียของการทดสอบการช่วยเหลือพิเศษอัตโนมัติ

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

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

ประเภทของเครื่องมืออัตโนมัติ

หนึ่งในเครื่องมือทดสอบการช่วยเหลือพิเศษอัตโนมัติทางออนไลน์เครื่องแรกที่พัฒนาขึ้นในปี 1996 โดย Center for Applied Special Technology (CAST) ในชื่อ "The Bobby Report" ปัจจุบันมีเครื่องมือทดสอบอัตโนมัติกว่า 100 รายการให้เลือก

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

เครื่องมืออัตโนมัติประเภทใดที่คุณจะเลือกใช้ขึ้นอยู่กับหลายปัจจัย ดังนี้

  • คุณกำลังทดสอบมาตรฐานและเกณฑ์ความสอดคล้องใด ซึ่งอาจรวมถึง WCAG 2.1, WCAG 2.0, มาตรา 508 ของสหรัฐอเมริกา หรือรายการกฎการช่วยเหลือพิเศษที่มีการแก้ไข
  • คุณกำลังทดสอบผลิตภัณฑ์ดิจิทัลประเภทใด ซึ่งอาจเป็นเว็บไซต์ เว็บแอป แอปบนอุปกรณ์เคลื่อนที่แบบเนทีฟ, PDF, คีออสก์ หรือผลิตภัณฑ์อื่นๆ
  • คุณกำลังทดสอบผลิตภัณฑ์ในช่วงใดของวงจรการพัฒนาซอฟต์แวร์
  • การตั้งค่าและใช้เครื่องมือนี้ใช้เวลานานเท่าใด สำหรับบุคคล ทีม หรือบริษัท
  • ใครเป็นผู้ทำการทดสอบ นักออกแบบ นักพัฒนาซอฟต์แวร์ เจ้าหน้าที่ควบคุมคุณภาพ หรือบุคคลอื่น
  • คุณต้องการให้มีการตรวจสอบการช่วยเหลือพิเศษบ่อยแค่ไหน รายละเอียดใดบ้างที่ควรรวมไว้ในรายงาน ปัญหาควรลิงก์กับระบบการออกตั๋วโดยตรงไหม
  • เครื่องมือใดที่เหมาะกับสภาพแวดล้อมของคุณมากที่สุด สำหรับทีมของคุณ

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

การสาธิต: การทดสอบอัตโนมัติ

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

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

ขั้นตอนที่ 1

ติดตั้งส่วนขยาย Lighthouse บนเบราว์เซอร์ Chrome

มีหลายวิธีในการผสานรวม Lighthouse กับเวิร์กโฟลว์การทดสอบ เราจะใช้ส่วนขยาย Chrome ในการสาธิตนี้

ขั้นตอนที่ 2

เว็บไซต์ Medical Mystery Club

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

ดูข้อมูลเพิ่มเติมเกี่ยวกับโหมดแก้ไขข้อบกพร่องของ CodePen

ขั้นตอนที่ 3

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

เว็บไซต์ Medical Mystery Club ที่มีแผงเครื่องมือสำหรับนักพัฒนาเว็บของรายงาน Lighthouse เปิดอยู่

ขั้นตอนที่ 4

คลิกวิเคราะห์การโหลดหน้าเว็บและให้เวลา Lighthouse ทำการทดสอบ

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

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

เว็บไซต์ Medical Mysteries Club ได้รับคะแนน Lighthouse 62 ในการทดสอบเดือนธันวาคม 2022

ขั้นตอนที่ 5

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

ปัญหา 1: บทบาท ARIA

ปัญหาแรกระบุว่า "องค์ประกอบที่มี ARIA [role] ที่กำหนดให้องค์ประกอบย่อยต้องมี [role] ที่เฉพาะเจาะจงขาดองค์ประกอบย่อยที่จำเป็นดังกล่าวบางส่วนหรือทั้งหมด บทบาท ARIA ระดับบนสุดบางบทบาทต้องมีบทบาทย่อยที่เจาะจงเพื่อใช้ฟังก์ชันการช่วยเหลือพิเศษตามวัตถุประสงค์" ดูข้อมูลเพิ่มเติมเกี่ยวกับกฎบทบาท ARIA

ในการสาธิตของเรา ปุ่มสมัครรับจดหมายข่าวล้มเหลว:

<button role="list" type="submit" tabindex="1">Subscribe</button>
มาแก้ปัญหากัน

ปุ่ม "ติดตาม" ข้างช่องป้อนข้อมูลมีบทบาท ARIA ที่ไม่ถูกต้อง ในกรณีนี้ คุณจะนําบทบาทออกได้ทั้งหมด

<button type="submit" tabindex="1">Subscribe</button>

ปัญหาที่ 2: ARIA ซ่อนอยู่

เอลิเมนต์ "[aria-hidden="true"] มีเอลิเมนต์ที่โฟกัสได้ลำดับต่อลงมา เอลิเมนต์ที่โฟกัสได้ลำดับต่อลงมาในเอลิเมนต์ [aria-hidden="true"] ป้องกันไม่ให้ผู้ใช้เทคโนโลยีความช่วยเหลือพิเศษ (เช่น โปรแกรมอ่านหน้าจอ) ใช้เอลิเมนต์การโต้ตอบเหล่านั้นได้ ดูข้อมูลเพิ่มเติมเกี่ยวกับกฎ aria-hidden

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>
มาแก้ไขกันเลย

ช่องป้อนข้อมูลมีการใช้แอตทริบิวต์ aria-hidden="true" การเพิ่มแอตทริบิวต์นี้จะซ่อนองค์ประกอบ (และทุกอย่างที่ฝังอยู่ภายใน) จากเทคโนโลยีความช่วยเหลือพิเศษ

<input type="email" placeholder="Enter your e-mail address" tabindex="-1" required>

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

ปัญหา 3: ชื่อปุ่ม

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

ดูข้อมูลเพิ่มเติมเกี่ยวกับกฎการตั้งชื่อปุ่ม

<button role="list" type="submit" tabindex="1">Subscribe</button>
มาแก้ปัญหากัน

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

<button type="submit" tabindex="1">Subscribe</button>

ปัญหาที่ 4: แอตทริบิวต์ Alt ของรูปภาพ

องค์ประกอบรูปภาพไม่มีแอตทริบิวต์ [alt] องค์ประกอบเพื่อการให้ข้อมูลควรมีข้อความสำรองที่สั้นกระชับและสื่อความหมาย การใช้แอตทริบิวต์ Alt ที่ว่างเปล่าจะเป็นการเพิกเฉยต่อองค์ประกอบเพื่อการตกแต่ง ดูข้อมูลเพิ่มเติมเกี่ยวกับกฎของข้อความแสดงแทนของรูปภาพ

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png">
</a>
มาแก้ไขกันเลย

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

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png"
    alt="Go to the home page.">
</a>

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

<a href="#!"><svg><path>...</path></svg></a>
มาแก้ไขกันเลย

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

สําหรับไอคอนโซเชียลมีเดียที่ใช้แท็ก <svg> คุณสามารถใช้รูปแบบคําอธิบายสำรองรูปแบบอื่นที่กําหนดเป้าหมาย SVG, เพิ่มข้อมูลระหว่างแท็ก <a> กับ <svg> แล้วซ่อนจากผู้ใช้ เพิ่ม ARIA ที่รองรับ หรือตัวเลือกอื่นๆ วิธีหนึ่งอาจดีกว่าอีกวิธี ทั้งนี้ขึ้นอยู่กับสภาพแวดล้อมและข้อจำกัดโค้ดของคุณ

ใช้ตัวเลือกรูปแบบที่ง่ายที่สุดซึ่งครอบคลุมเทคโนโลยีความช่วยเหลือมากที่สุด ซึ่งก็คือการเพิ่ม role="img" ลงในแท็ก <svg> และใส่องค์ประกอบ <title>

<a href="#!">
  <svg role="img">
    <title>Connect on our Twitter page.</title>
    <path>...</path>
  </svg>
</a>

ปัญหาที่ 6: คอนทราสต์ของสี

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

มีการรายงานตัวอย่าง 2 รายการ

Medical Mysteries Club มีค่า HEX ของสีเป็น #01aa9d และค่า HEX ของพื้นหลังเป็น #ffffff อัตราส่วนคอนทราสต์ของสีคือ 2.9:1
คะแนนของ Lighthouse สำหรับข้อความของกลุ่มอาการเงือกน้อย (Mermaid syndrome)
กลุ่มอาการนางเงือกมีค่าฐานสิบหกของข้อความเป็น #7c7c7c ส่วนสีฐานสิบหกของพื้นหลังคือ #ffffff อัตราส่วนคอนทราสต์ของสีคือ 4.2:1
มาแก้ปัญหากัน

ตรวจพบปัญหาคอนทราสต์ของสีในหน้าเว็บเป็นจำนวนมาก ดังที่ได้ทราบในข้อบังคับสีและความคมชัด ข้อความขนาดปกติ (น้อยกว่า 18pt / 24px) ต้องมีสีที่มีความคมชัด 4.5:1 ส่วนข้อความขนาดใหญ่ (อย่างน้อย 18pt / 24px หรือ 14pt / 18.5px ตัวหนา) และไอคอนที่จำเป็นต้องเป็นไปตามข้อกำหนด 3:1

สำหรับชื่อหน้า ข้อความสีน้ำเงินเทอร์ควอยซ์ต้องเป็นไปตามข้อกำหนดความคมชัดของสี 3:1 เนื่องจากเป็นข้อความขนาดใหญ่ขนาด 24 พิกเซล อย่างไรก็ตาม ปุ่มสีเขียวเทอร์ควอยต์ถือเป็นข้อความขนาดปกติขนาด 16 พิกเซลตัวหนา จึงต้องเป็นไปตามข้อกำหนดความคมชัดของสี 4.5:1

ในกรณีนี้ เราอาจหาสีเทอร์ควอยซ์ที่เข้มพอเพื่อให้ได้ 4.5:1 หรืออาจเพิ่มขนาดข้อความปุ่มเป็น 18.5 พิกเซลเป็นตัวหนาและเปลี่ยนค่าสีเทอร์ควอยซ์เล็กน้อย ไม่ว่าจะเป็นวิธีการใดยังคงสอดคล้องกับ ความสวยงามของการออกแบบ

ข้อความสีเทาทั้งหมดบนพื้นหลังสีขาวไม่ผ่านเกณฑ์คอนทราสต์สีเช่นกัน ยกเว้นส่วนหัว 2 รายการที่ใหญ่ที่สุดในหน้า ข้อความนี้ต้องปรับให้มืดลง เพื่อให้เป็นไปตามข้อกำหนดคอนทราสต์ของสี 4.5:1

สีน้ำเงินอมเขียวคงที่และไม่ล้มเหลวอีกต่อไป
ชื่อชมรม Medical Mysteries Club ได้รับค่าสีเป็น #008576 และพื้นหลังยังคงเป็น #ffffff อัตราส่วนคอนทราสต์ของสีที่อัปเดตแล้วคือ 4.5:1 คลิกรูปภาพเพื่อดูขนาดเต็ม
สีเทาได้รับการแก้ไขแล้ว
ตอนนี้ Mermaid syndrome มีค่าสีเป็น #767676 และพื้นหลังยังคงเป็น #ffffff อัตราส่วนคอนทราสต์ของสีคือ 4.5:1

ปัญหาที่ 7: โครงสร้างรายการ

รายการย่อย (<li>) ไม่ได้อยู่ภายในองค์ประกอบระดับบนสุด <ul> หรือ <ol> โปรแกรมอ่านหน้าจอกำหนดให้รายการย่อย (<li>) อยู่ใน <ul> หรือ <ol> ระดับบนสุดเพื่อให้อ่านได้อย่างถูกต้อง

ดูข้อมูลเพิ่มเติมเกี่ยวกับกฎรายการ

<div class="ul">
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</div>
มาแก้ปัญหากัน

เราใช้คลาส CSS ในการสาธิตนี้เพื่อจำลองรายการแบบไม่เรียงลำดับแทนการใช้แท็ก <ul> เมื่อเราเขียนโค้ดนี้อย่างไม่ถูกต้อง เราได้นำฟีเจอร์ HTML เชิงความหมายที่มีอยู่ในแท็กนี้ออก เราได้แก้ไขปัญหาการช่วยเหลือพิเศษนี้ด้วยการแทนที่คลาสด้วยแท็ก <ul> จริงและแก้ไข CSS ที่เกี่ยวข้อง

<ul>
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</ul>

ปัญหาที่ 8: tabindex

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

<button type="submit" tabindex="1">Subscribe</button>
มาแก้ปัญหากัน

คุณไม่จำเป็นต้องใช้จำนวนเต็มบวกในแอตทริบิวต์ tabindex เว้นแต่จะมีเหตุผลที่เจาะจงในการขัดจังหวะลําดับการกด Tab ตามปกติในหน้าเว็บ เราจะเปลี่ยน Tabindex เป็น 0 หรือนำแอตทริบิวต์ออกเพื่อให้ตามลำดับแท็บตามปกติ

<button type="submit">Subscribe</button>

ขั้นตอนที่ 6

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

สำเร็จแล้ว
ตอนนี้คะแนน Lighthouse เป็น 100 ซึ่งหมายความว่าคุณแก้ไขปัญหา Lighthouse ทั้งหมดแล้ว

เราได้นำการอัปเดตการช่วยเหลือพิเศษอัตโนมัติเหล่านี้ไปใช้กับ CodePen ใหม่

ขั้นตอนถัดไป

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

ทดสอบความเข้าใจ

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

คุณควรทำการทดสอบประเภทใดเพื่อให้แน่ใจว่าเว็บไซต์เข้าถึงได้

การทดสอบด้วยตนเอง
การทดสอบโดยผู้ใช้
การทดสอบเทคโนโลยีความช่วยเหลือพิเศษ
การทดสอบอัตโนมัติ

การทดสอบอัตโนมัติพบข้อผิดพลาดใดบ้าง

ไม่มีข้อความแสดงแทน
ภาษาที่ไม่แบ่งแยก
ข้อผิดพลาด ARIA
ป้ายกำกับฟอร์มที่สื่อความหมาย
ปัญหาเกี่ยวกับคอนทราสต์ของสี