จนถึงตอนนี้ คุณได้เรียนรู้เกี่ยวกับ บุคคลทั่วไป ธุรกิจ และ แง่มุมทางกฎหมายเกี่ยวกับการช่วยเหลือพิเศษในโลกดิจิทัล และข้อมูลเบื้องต้นเกี่ยวกับการช่วยเหลือพิเศษทางดิจิทัล ความสอดคล้อง คุณได้สำรวจหัวข้อเฉพาะที่เกี่ยวข้องกับการออกแบบที่ไม่แบ่งแยกและ การเขียนโค้ด ซึ่งรวมถึงเวลาที่ควรใช้ 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 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] หนึ่งที่ขาดรายการย่อยที่จำเป็นบางส่วนหรือทั้งหมด บทบาท 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" กำลังเพิ่ม
แอตทริบิวต์นี้จะซ่อนองค์ประกอบ (และทุกอย่างที่ซ้อนอยู่ใต้องค์ประกอบนี้) จาก
ของ Google
<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 มีค่าสีฐานสิบหกเป็น #01aa9d และค่าฐานสิบหกพื้นหลังคือ #ffffff อัตราส่วนคอนทราสต์ของสีคือ 2.9:1
ดูภาพหน้าจอขนาดเต็ม
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 ถึง
คงลำดับแท็บตามปกติ เราอาจเปลี่ยน Tabindex เป็น 0 หรือ
นำแอตทริบิวต์ทั้งหมดออก
<button type="submit">Subscribe</button>
ขั้นตอนที่ 6
เมื่อคุณแก้ไขปัญหาการเข้าถึงแบบอัตโนมัติทั้งหมดแล้ว ให้เปิด หน้าโหมดแก้ไขข้อบกพร่อง เรียกใช้การตรวจสอบการช่วยเหลือพิเศษของ Lighthouse อีกครั้ง คะแนนของคุณ น่าจะดีกว่าการเรียกใช้ครั้งแรกอย่างมาก
เราได้นำการอัปเดตการเข้าถึงแบบอัตโนมัติทั้งหมดเหล่านี้ไปใช้กับ CodePen
ขั้นตอนถัดไป
เก่งมากๆ คุณประสบความสำเร็จมากมายแล้ว แต่เรายังไม่จบ! ถัดไป เราจะไปต่อกันที่การตรวจสอบด้วยตนเอง ตามที่ระบุไว้ใน การทดสอบการช่วยเหลือพิเศษด้วยตนเอง
ตรวจสอบความเข้าใจ
ทดสอบความรู้ของคุณเกี่ยวกับการทดสอบการช่วยเหลือพิเศษโดยอัตโนมัติ
การทดสอบประเภทใดที่คุณควรทำเพื่อให้แน่ใจว่าเว็บไซต์ของคุณสามารถเข้าถึงได้
การทดสอบอัตโนมัติพบข้อผิดพลาดใดบ้าง