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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ขั้นตอนที่ 1

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

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

ขั้นตอนที่ 2

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

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

ขั้นตอนที่ 3

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

ขั้นตอนที่ 4

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

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

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

ขั้นตอนที่ 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>

ปัญหา 5: ข้อความลิงก์

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

<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 รายการ

มาแก้ปัญหากัน

ตรวจพบปัญหาด้านคอนทราสต์ของสีหลายรายการในหน้าเว็บ ตามที่คุณได้เรียนรู้มาใน โมดูลสีและคอนทราสต์ ข้อความขนาดปกติ (น้อยกว่า 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

ปัญหาที่ 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 ถึง คงลำดับแท็บตามปกติ เราอาจเปลี่ยน Tabindex เป็น 0 หรือ นำแอตทริบิวต์ทั้งหมดออก

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

ขั้นตอนที่ 6

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

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

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

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

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

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