ที่ผ่านมาในหลักสูตรนี้ คุณได้เรียนรู้เกี่ยวกับบุคคล ธุรกิจ และแง่มุมด้านกฎหมายของการเข้าถึงดิจิทัล รวมถึงข้อมูลพื้นฐานเกี่ยวกับการปฏิบัติตามข้อกำหนดการช่วยเหลือพิเศษทางดิจิทัล คุณได้อ่านหัวข้อเฉพาะเกี่ยวกับการออกแบบและการเขียนโค้ดที่ไม่แบ่งแยก รวมถึงกรณีที่ควรใช้ 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, คีออสก์ หรือผลิตภัณฑ์อื่นๆ
- ส่วนใดในวงจรการพัฒนาซอฟต์แวร์ที่คุณกำลังทดสอบผลิตภัณฑ์ของคุณ
- การตั้งค่าและการใช้เครื่องมือใช้เวลานานเท่าใด สำหรับบุคคล ทีม หรือบริษัท
- ใครเป็นผู้ทำการทดสอบ เช่น นักออกแบบ นักพัฒนาซอฟต์แวร์ QA และอื่นๆ
- คุณต้องการให้ตรวจสอบการช่วยเหลือพิเศษบ่อยแค่ไหน รายละเอียดที่ควรระบุ ในรายงานมีอะไรบ้าง ปัญหาควรเชื่อมโยงกับระบบการจำหน่ายตั๋วโดยตรง หรือไม่
- เครื่องมือใดทำงานได้ดีที่สุดในสภาพแวดล้อมของคุณ สำหรับทีมของคุณ
นอกจากนี้ยังมีปัจจัยอื่นๆ อีกหลายอย่างที่ควรพิจารณาเช่นกัน อ่านบทความของ 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 [บทบาท] ที่กำหนดให้เด็กต้องมี [บทบาท] ที่เฉพาะเจาะจงขาดองค์ประกอบย่อยที่จำเป็นดังกล่าวบางส่วนหรือทั้งหมด บทบาท 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 ตัวอย่าง
Medical Mysteries Club มีค่าสีแบบเลขฐาน 16 เป็น #01aa9d และค่าฐานสิบหกของพื้นหลังคือ #ffffff อัตราส่วนคอนทราสต์ของสีคือ 2.9:1
ดูภาพหน้าจอขนาดเต็ม
Mermaid syndrome ข้อความมีค่าฐานสิบหกเป็น #7c7c7c ในขณะที่สีแบบเลขฐาน 16 ของพื้นหลังคือ #ffffff อัตราส่วนคอนทราสต์ของสีคือ 4.2:1
ดูภาพหน้าจอขนาดเต็ม
มาแก้ไขกัน
ตรวจพบปัญหาเกี่ยวกับคอนทราสต์ของสีหลายรายการในหน้าเว็บ ตามที่คุณได้เรียนรู้ในโมดูลสีและคอนทราสต์ ข้อความขนาดปกติ (น้อยกว่า 18pt / 24px) มีข้อกำหนดคอนทราสต์ของสีเป็น 4.5:1 ในขณะที่ข้อความขนาดใหญ่ (อย่างน้อย 18pt / 24px หรือ 14pt / ตัวหนา 18.5px) และไอคอนที่จำเป็นต้องเป็นไปตามข้อกำหนด 3:1
สำหรับชื่อหน้า ข้อความสีทีลต้องตรงตามข้อกำหนดของสีที่คอนทราสต์ 3:1 เนื่องจากเป็นข้อความขนาดใหญ่ที่ 24px อย่างไรก็ตาม ปุ่มสีน้ำเงินอมเขียวถือเป็นข้อความขนาดปกติที่ตัวหนา 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 ในหน้าเว็บตามปกติ หากต้องการคงลำดับการกด Tab ไว้อย่างเป็นธรรมชาติ เราอาจเปลี่ยนดัชนีแท็บเป็น 0 หรือนำแอตทริบิวต์ออกไปเลยก็ได้
<button type="submit">Subscribe</button>
ขั้นตอนที่ 6
เมื่อคุณแก้ไขปัญหาการช่วยเหลือพิเศษอัตโนมัติทั้งหมดแล้ว ให้เปิดหน้าโหมดแก้ไขข้อบกพร่องใหม่ เรียกใช้การตรวจสอบการช่วยเหลือพิเศษของ Lighthouse อีกครั้ง คะแนนของคุณน่าจะดีกว่าการเรียกใช้งานครั้งแรกเป็นอย่างมาก
เราได้นำการอัปเดตการช่วยเหลือพิเศษอัตโนมัติทั้งหมดนี้ไปใช้กับ CodePen ใหม่
ขั้นตอนถัดไป
ทำได้ดีมาก คุณประสบความสำเร็จหลายอย่างแล้ว แต่เรายังทำไม่จบเลย ต่อไป เราจะไปต่อยังการตรวจสอบด้วยตนเอง ตามรายละเอียดในโมดูลการทดสอบการช่วยเหลือพิเศษด้วยตนเอง
ตรวจสอบความเข้าใจของคุณ
ทดสอบความรู้ของคุณเกี่ยวกับการทดสอบความสามารถเข้าถึงได้ง่ายแบบอัตโนมัติ
คุณควรทำการทดสอบประเภทใดเพื่อให้แน่ใจว่าเว็บไซต์ของคุณสามารถเข้าถึงได้
การทดสอบอัตโนมัติพบข้อผิดพลาดใดบ้าง