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

ในหลักสูตรนี้ คุณได้เรียนรู้เกี่ยวกับแง่มุมส่วนบุคคล ธุรกิจ และ กฎหมายของการช่วยเหลือพิเศษดิจิทัล รวมถึงพื้นฐานของการปฏิบัติตาม การช่วยเหลือพิเศษดิจิทัล คุณได้สำรวจหัวข้อที่เฉพาะเจาะจงซึ่งเกี่ยวข้องกับการออกแบบและการเขียนโค้ดที่ครอบคลุม รวมถึงเมื่อใดที่ควรใช้ 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.2, WCAG 2.1, มาตรา 508 ของสหรัฐอเมริกา หรือรายการกฎการช่วยเหลือพิเศษที่แก้ไขแล้ว
• คุณกำลังทดสอบผลิตภัณฑ์ดิจิทัลประเภทใด ซึ่งอาจเป็นเว็บไซต์ เว็บแอป แอปบนอุปกรณ์เคลื่อนที่แบบเนทีฟ PDF คีออสก์ หรือผลิตภัณฑ์อื่นๆ
• คุณทดสอบผลิตภัณฑ์ในส่วนใดของวงจรการพัฒนาซอฟต์แวร์
• การตั้งค่าและใช้เครื่องมือนี้ใช้เวลานานเท่าใด สำหรับบุคคล ทีม หรือบริษัท
• ใครเป็นผู้ทำการทดสอบ นักออกแบบ นักพัฒนาซอฟต์แวร์ QA หรือบุคคลอื่น
• คุณต้องการให้ตรวจสอบการช่วยเหลือพิเศษบ่อยเพียงใด รายงานควรมีรายละเอียดใดบ้าง Should issues be directly linked to a ticketing system?
• เครื่องมือใดทำงานได้ดีที่สุดในสภาพแวดล้อมของคุณ สำหรับทีมของคุณ

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

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

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

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

ขั้นตอนที่ 1

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

การผสานรวม 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 hidden

เอลิเมนต์ "[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 พิกเซล อย่างไรก็ตาม ปุ่มสีเขียวอมฟ้าถือเป็นข้อความขนาดปกติที่ 16px แบบตัวหนา ดังนั้นปุ่มจึงต้องเป็นไปตามข้อกำหนดด้านคอนทราสต์สีที่ 4.5:1

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

ข้อความสีเทาทั้งหมดบนพื้นหลังสีขาวก็ไม่ผ่านการตรวจสอบคอนทราสต์สีเช่นกัน ยกเว้น ส่วนหัวที่ใหญ่ที่สุด 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>

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

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

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

ขั้นตอนที่ 6

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

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

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

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