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

ในหลักสูตรนี้ คุณได้เรียนรู้เกี่ยวกับแง่มุมต่างๆ ของการช่วยเหลือพิเศษทางดิจิทัล ทั้งในแง่ของบุคคล ธุรกิจ และกฎหมาย รวมถึงพื้นฐานของการปฏิบัติตามข้อกำหนดด้านการช่วยเหลือพิเศษทางดิจิทัล นอกจากนี้ คุณยังได้สำรวจหัวข้อเฉพาะที่เกี่ยวข้องกับการออกแบบและการเขียนโค้ดแบบครอบคลุม ซึ่งรวมถึงเวลาที่ควรใช้ 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 หรือบุคคลอื่น
• คุณต้องการให้ตรวจสอบการช่วยเหลือพิเศษบ่อยแค่ไหน ควรมีรายละเอียดใดบ้างในรายงาน ควรลิงก์ปัญหาไปยังระบบออกตั๋วโดยตรงหรือไม่
• เครื่องมือใดทำงานได้ดีที่สุดในสภาพแวดล้อมของคุณ สำหรับทีมของคุณ

นอกจากนี้ยังมีปัจจัยอื่นๆ อีกมากมายที่ต้องพิจารณา โปรดดูบทความ "Selecting Web Accessibility Evaluation Tools" ของ 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

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

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

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

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

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