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