การปรับปรุงการช่วยเหลือพิเศษจะทำให้เว็บไซต์ใช้งานได้ง่ายขึ้นสำหรับทุกคน
คุณควรสร้างเว็บไซต์ที่ไม่แบ่งแยกและเข้าถึงได้สำหรับทุกคน ความพิการที่คุณเพิ่มประสิทธิภาพได้มีอย่างน้อย 6 ด้าน ได้แก่ ภาพ การได้ยิน การเคลื่อนไหว การรับรู้ เสียงพูด และระบบประสาท เครื่องมือและแหล่งข้อมูลหลายๆ อย่างช่วยในส่วนนี้ได้ แม้ว่าคุณจะยังไม่คุ้นเคยกับการเข้าถึงเว็บ
ผู้คนกว่า 1 พันล้านคน ใช้ชีวิตพร้อมกับความพิการบางอย่าง
เพื่อให้เข้าถึงได้ง่าย เว็บไซต์ต้องทำงานในอุปกรณ์ที่หลากหลาย ซึ่งมีขนาดหน้าจอและการป้อนข้อมูลประเภทต่างๆ เช่น โปรแกรมอ่านหน้าจอ ยิ่งไปกว่านั้น ผู้ใช้กลุ่มใหญ่ที่สุดรวมถึงผู้พิการควรใช้เว็บไซต์ได้
ความพิการบางส่วนที่ผู้ใช้อาจมีมีดังนี้
การมองเห็น | การได้ยิน | การเคลื่อนไหว |
---|---|---|
|
|
|
การรับรู้ | เสียงพูด | ระบบประสาทเทียม |
|
|
|
ปัญหาด้านการมองเห็นมีตั้งแต่ไม่สามารถแยกความแตกต่างของสีไปจนถึงการมองไม่เห็นเลย
- ตรวจสอบว่าเนื้อหาข้อความตรงตามเกณฑ์อัตราส่วนคอนทราสต์ขั้นต่ำ
- หลีกเลี่ยงการสื่อสารข้อมูลโดยใช้สีเพียงอย่างเดียว และตรวจสอบว่าข้อความทั้งหมดresizable
- ตรวจสอบว่าสามารถใช้งานคอมโพเนนต์อินเทอร์เฟซผู้ใช้ทั้งหมดกับเทคโนโลยีความช่วยเหลือพิเศษได้ เช่น โปรแกรมอ่านหน้าจอ แว่นขยาย และจอแสดงผลอักษรเบรลล์ ซึ่งช่วยให้มั่นใจได้ว่ามีการมาร์กอัปคอมโพเนนต์ UI เพื่อให้ API การช่วยเหลือพิเศษกำหนดบทบาท สถานะ ค่า และชื่อขององค์ประกอบแบบเป็นโปรแกรมได้
โดยส่วนตัวแล้วผมมีสายตาเลือนรางและมักหาว่าตัวเองดูเว็บไซต์ เครื่องมือสำหรับนักพัฒนาเว็บ และเทอร์มินัล แม้ว่าการรองรับ Zoom แทบจะไม่ได้อยู่ด้านบนสุดของรายการสิ่งที่ต้องทำของนักพัฒนาซอฟต์แวร์เลย แต่ก็ช่วยสร้างความแตกต่างได้ให้แก่ผู้ใช้อย่างผม
ปัญหาในการได้ยินหมายความว่าผู้ใช้อาจมีปัญหาในการได้ยินเสียงที่ออกมาจากหน้าเว็บ
- ระบุข้อความทางเลือกสำหรับเนื้อหาทั้งหมดที่ไม่ได้มีข้อความเพียงอย่างเดียว
- ทดสอบว่าคอมโพเนนต์ UI ยังใช้งานได้โดยไม่มีเสียง
ปัญหาด้านการเคลื่อนไหวอาจรวมถึงการใช้เมาส์ แป้นพิมพ์ หรือหน้าจอสัมผัสไม่ได้
- ทำให้เนื้อหาของคอมโพเนนต์ UI เข้าถึงได้จากแป้นพิมพ์สำหรับการดำเนินการใดก็ตามที่ผู้ใช้อาจใช้เมาส์
- ตรวจสอบว่าได้มาร์กอัปหน้าสำหรับเทคโนโลยีความช่วยเหลือพิเศษ (เช่น โปรแกรมอ่านหน้าจอ ซอฟต์แวร์การควบคุมด้วยเสียง และการควบคุมสวิตช์จริง) อย่างถูกต้อง ซึ่งมีแนวโน้มที่จะใช้ API เดียวกัน
ปัญหาด้านการรับรู้หมายความว่าผู้ใช้อาจต้องการเทคโนโลยีความช่วยเหลือพิเศษเพื่อช่วยในการอ่านข้อความ จึงจำเป็นต้องมีทางเลือกข้อความแทน
ระมัดระวังเวลาใช้ภาพเคลื่อนไหว หลีกเลี่ยงการใช้วิดีโอและภาพเคลื่อนไหวที่ทำซ้ำหรือกะพริบ ซึ่งอาจทำให้เกิดปัญหาสำหรับผู้ใช้บางราย
คำค้นหาสื่อ CSS ของ
prefers-reduced-motion
ช่วยให้คุณจำกัดภาพเคลื่อนไหวและการเล่นวิดีโออัตโนมัติสำหรับผู้ใช้ที่ต้องการลดการเคลื่อนไหวได้ โดยทำดังนี้/* If the user expresses a preference for reduced motion, don't use animations on buttons. */ @media (prefers-reduced-motion: reduce) { button { animation: none; } }
หลีกเลี่ยงการโต้ตอบที่อิงตามเวลา
นี่อาจดูเหมือนว่ามีพื้นฐานหลายอย่างที่ต้องครอบคลุม แต่เราจะพูดถึงขั้นตอนการประเมินและปรับปรุงการช่วยเหลือพิเศษของคอมโพเนนต์ UI กัน
เพื่อให้ความช่วยเหลือด้านภาพเพิ่มเติม ทีมการช่วยเหลือพิเศษของ GOV.UK ได้สร้างชุดโปสเตอร์ดิจิทัลเกี่ยวกับสิ่งที่ควรและไม่ควรทำซึ่งคุณจะใช้เพื่อแชร์แนวทางปฏิบัติแนะนำกับทีมได้
วัดการเข้าถึงคอมโพเนนต์ UI
เมื่อตรวจสอบคอมโพเนนต์ UI ของหน้าเว็บสำหรับการเข้าถึง ให้ถามตัวเองว่า
คุณใช้คอมโพเนนต์ UI กับแป้นพิมพ์อย่างเดียวได้ไหม
คอมโพเนนต์นี้จัดการการโฟกัสและหลีกเลี่ยงกับดักการโฟกัสไหม อุปกรณ์สามารถตอบสนองต่อเหตุการณ์บนแป้นพิมพ์ที่เหมาะสมได้ไหม
คุณใช้คอมโพเนนต์ UI กับโปรแกรมอ่านหน้าจอได้ไหม
คุณได้ใส่ข้อความทางเลือกสำหรับข้อมูลใดๆ ที่แสดงเป็นภาพไหม คุณได้เพิ่มข้อมูลเชิงความหมายโดยใช้ ARIA แล้วหรือไม่
คอมโพเนนต์ UI ทำงานโดยไม่มีเสียงได้ไหม
ปิดลำโพงและพิจารณากรณีการใช้งาน
คอมโพเนนต์ UI ทำงานโดยไม่มีสีได้ไหม
ตรวจสอบว่าผู้ที่ไม่เห็นสีใช้คอมโพเนนต์ UI ของคุณได้ เครื่องมือที่มีประโยชน์สำหรับการจำลองตาบอดสีคือส่วนขยาย Chrome ที่ชื่อ Colorblindly (ลองใช้การจำลองตาบอดสีทั้ง 4 รูปแบบที่มีให้บริการ) นอกจากนี้ คุณยังอาจสนใจส่วนขยาย Daltonize ซึ่งมีประโยชน์ในทำนองเดียวกันด้วย
คอมโพเนนต์ UI ทำงานร่วมกับโหมดคอนทราสต์สูงได้ไหม
ระบบปฏิบัติการสมัยใหม่ทั้งหมดรองรับโหมดคอนทราสต์สูง คอนทราสต์สูง คือส่วนขยายของ Chrome ที่ช่วยได้ในส่วนนี้
ตัวควบคุมมาตรฐาน (เช่น <button>
และ <select>
) มีการช่วยเหลือพิเศษอยู่ในเบราว์เซอร์ โดยจะโฟกัสได้โดยใช้แป้น Tab
ซึ่งจะตอบสนองต่อเหตุการณ์บนแป้นพิมพ์ (เช่น Enter
, Space
และปุ่มลูกศร) รวมถึงมีบทบาทความหมาย สถานะ และพร็อพเพอร์ตี้ที่เครื่องมือช่วยเหลือพิเศษใช้
การจัดรูปแบบเริ่มต้นควรเป็นไปตามข้อกำหนดการช่วยเหลือพิเศษที่ระบุไว้ด้วย
คอมโพเนนต์ UI ที่กำหนดเอง (ยกเว้นคอมโพเนนต์ที่ขยายองค์ประกอบมาตรฐาน เช่น <button>
) จะไม่มีความสามารถในตัวซึ่งรวมถึงการช่วยเหลือพิเศษ คุณจึงต้องระบุให้คอมโพเนนต์ดังกล่าว จุดเริ่มต้นที่ดีในการใช้การช่วยเหลือพิเศษคือการเปรียบเทียบคอมโพเนนต์กับองค์ประกอบมาตรฐานที่คล้ายกัน (หรือชุดค่าผสมขององค์ประกอบมาตรฐานหลายรายการ ขึ้นอยู่กับความซับซ้อนของคอมโพเนนต์)
เครื่องมือสำหรับนักพัฒนาเบราว์เซอร์ส่วนใหญ่รองรับการตรวจสอบโครงสร้างการช่วยเหลือพิเศษของหน้าเว็บ ในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ตัวเลือกนี้อยู่ในแท็บการช่วยเหลือพิเศษในแผงองค์ประกอบ
นอกจากนี้ Firefox ยังมีแผงการช่วยเหลือพิเศษอีกด้วย
Safari จะแสดงข้อมูลการช่วยเหลือพิเศษในแท็บโหนดของแผงองค์ประกอบ
ต่อไปนี้เป็นรายการคำถามที่คุณสามารถถามตัวเองเมื่อพยายามทำให้เข้าถึงคอมโพเนนต์ UI ได้มากขึ้น
ปรับปรุงโฟกัสของแป้นพิมพ์
โดยหลักการแล้ว ให้ตรวจสอบว่าฟังก์ชันการทำงานทั้งหมดในคอมโพเนนต์ UI สามารถเข้าถึงได้ด้วยแป้นพิมพ์ เมื่อออกแบบประสบการณ์ของผู้ใช้ ให้คิดว่าคุณจะใช้องค์ประกอบด้วยแป้นพิมพ์เพียงอย่างเดียวอย่างไร และค้นหาการโต้ตอบบนแป้นพิมพ์ที่สอดคล้องกัน
ก่อนอื่นให้ตรวจสอบว่าคุณมีเป้าหมายการโฟกัสที่เหมาะสมสำหรับแต่ละคอมโพเนนต์ เช่น คอมโพเนนต์ที่ซับซ้อนอย่างเมนูอาจเป็นเป้าหมายโฟกัส 1 เป้าหมายภายในหน้าเว็บ แต่จากนั้นควรจัดการโฟกัสภายในตัวเองเพื่อให้รายการในเมนูที่ใช้งานอยู่มีโฟกัสเสมอ
ใช้ Tabindex
คุณเพิ่มโฟกัสแป้นพิมพ์สำหรับองค์ประกอบและคอมโพเนนต์ UI ได้ด้วยแอตทริบิวต์ tabindex
ผู้ใช้เทคโนโลยีความช่วยเหลือพิเศษเฉพาะแป้นพิมพ์ต้องสามารถวางโฟกัสแป้นพิมพ์ที่องค์ประกอบเพื่อโต้ตอบกับองค์ประกอบเหล่านั้น
องค์ประกอบแบบอินเทอร์แอกทีฟในตัว (เช่น <button>
) สามารถโฟกัสได้โดยปริยาย ดังนั้นจึงไม่ต้องใช้แอตทริบิวต์ tabindex
เว้นแต่จำเป็นต้องเปลี่ยนตำแหน่งในลำดับแท็บ
ค่า tabindex
มี 3 ประเภทดังนี้
tabindex="0"
คือองค์ประกอบที่พบมากที่สุดและจัดวางองค์ประกอบไว้ในลำดับแท็บตามปกติ (ระบุโดยลำดับ DOM)- ค่า
tabindex
ที่มากกว่า 0 จะวางองค์ประกอบไว้ในลำดับแท็บที่กำหนดเอง องค์ประกอบทั้งหมดในหน้าที่มีค่าtabindex
เป็นบวกจะเข้าถึงตามลำดับตัวเลขก่อนองค์ประกอบในลำดับแท็บปกติ - ค่า
tabindex
ที่เท่ากับ -1 จะทำให้องค์ประกอบโฟกัสองค์ประกอบแบบเป็นโปรแกรมได้ แต่ไม่อยู่ในลำดับแท็บ
สำหรับคอมโพเนนต์ UI ที่กำหนดเอง ให้ใช้ค่า tabindex
ที่เป็น 0 หรือ -1 เสมอ เนื่องจากคุณจะไม่สามารถกำหนดลำดับขององค์ประกอบในหน้าหนึ่งๆ ล่วงหน้าได้ ค่า -1 ของ tabindex
มีประโยชน์อย่างยิ่งสำหรับการจัดการโฟกัสภายในคอมโพเนนต์ที่ซับซ้อน
ตรวจสอบว่าโฟกัสมองเห็นได้ตลอด ไม่ว่าจะใช้รูปแบบวงแหวนโฟกัสเริ่มต้นหรือใช้รูปแบบโฟกัสที่กำหนดเองซึ่งมองเห็นได้ชัดเจน โปรดอย่าดักจับผู้ใช้แป้นพิมพ์ เพราะผู้ใช้ควรสามารถย้ายโฟกัสออกจากองค์ประกอบได้โดยใช้แป้นพิมพ์เท่านั้น
ใช้การโฟกัสอัตโนมัติ
แอตทริบิวต์โฟกัสอัตโนมัติของ HTML ช่วยให้ผู้เขียนสามารถระบุว่าองค์ประกอบหนึ่งๆ ควรโฟกัสโดยอัตโนมัติเมื่อหน้าเว็บโหลด
autofocus
ได้รับการรองรับอยู่แล้วในการควบคุมเว็บฟอร์มทั้งหมด ซึ่งรวมถึงปุ่มต่างๆ
หากต้องการโฟกัสองค์ประกอบในคอมโพเนนต์ UI ที่กำหนดเอง ให้เรียกใช้เมธอด focus()
ซึ่งรองรับในองค์ประกอบ HTML ทั้งหมดที่โฟกัสได้ (เช่น document.querySelector('myButton').focus()
)
เพิ่มการโต้ตอบทางแป้นพิมพ์
เมื่อโฟกัสคอมโพเนนต์ UI ได้ ให้ระบุเรื่องราวการโต้ตอบกับแป้นพิมพ์ที่ดีเมื่อคอมโพเนนต์โฟกัสโดยการจัดการเหตุการณ์แป้นพิมพ์ที่เหมาะสม
ตัวอย่างเช่น อนุญาตให้ผู้ใช้ใช้ปุ่มลูกศรเพื่อเลือกตัวเลือกเมนูและ Space
หรือ Enter
เพื่อเปิดใช้งานปุ่ม
คู่มือรูปแบบการออกแบบของ ARIA มีคําแนะนําบางประการที่นี่
สุดท้าย ตรวจสอบว่าคุณค้นพบแป้นพิมพ์ลัดได้ แนวทางปฏิบัติทั่วไปคือการมีคำอธิบายแป้นพิมพ์ลัด (ข้อความบนหน้าจอ) เพื่อแจ้งให้ผู้ใช้ทราบว่ามีแป้นพิมพ์ลัดอยู่ ตัวอย่างเช่น "กด ? สำหรับแป้นพิมพ์ลัด" หรือคำแนะนำที่ว่านั้นสามารถใช้เคล็ดลับเครื่องมือในการแจ้งผู้ใช้เกี่ยวกับทางลัดได้
ความสำคัญของการจัดการสิ่งที่มุ่งเน้นจะไม่สามารถพูดเกินจริง ตัวอย่างที่สำคัญคือ ลิ้นชักการนำทาง ถ้าคุณเพิ่มคอมโพเนนต์ UI ลงในหน้า คุณต้องโฟกัสไปยังองค์ประกอบที่อยู่ภายในโดยตรง ไม่เช่นนั้นผู้ใช้อาจต้องแท็บทั้งหน้าเพื่อไปที่นั่น ปัญหานี้อาจเป็นประสบการณ์ที่น่าหงุดหงิด ดังนั้นให้ทดสอบโฟกัสสำหรับคอมโพเนนต์ที่ไปยังส่วนต่างๆ ด้วยแป้นพิมพ์ได้ทั้งหมดในหน้าเว็บของคุณ
// Example for expanding and collapsing a category with the Space key
const category = await page.$(`.category`);
// verify tabIndex, role and focus
expect(await page.evaluate(elem => elem.getAttribute(`role`), category)).toEqual(`button`);
expect(await page.evaluate(elem => elem.getAttribute(`tabindex`), category)).toEqual(`0`);
expect(await page.evaluate(elem => window.document.activeElement === elem, category)).toEqual(true);
// verify aria-expanded = false
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`false`);
// toggle category by pressing Space
await page.keyboard.press('Space');
// verify aria-expanded = true
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`true`);
ดูแลให้โปรแกรมอ่านหน้าจอประสบความสำเร็จ
ผู้คนประมาณ 1% ถึง 2% ใช้โปรแกรมอ่านหน้าจอ คุณทำความเข้าใจข้อมูลสำคัญทั้งหมด และโต้ตอบกับคอมโพเนนต์โดยใช้โปรแกรมอ่านหน้าจอกับแป้นพิมพ์อย่างเดียวได้ไหม
คำถามต่อไปนี้จะช่วยแก้ไขปัญหาเกี่ยวกับการช่วยเหลือพิเศษด้วยโปรแกรมอ่านหน้าจอ
องค์ประกอบและรูปภาพทั้งหมดมีตัวเลือกข้อความที่มีความหมายไหม
เมื่อใดก็ตามที่ข้อมูลเกี่ยวกับชื่อหรือวัตถุประสงค์ของคอมโพเนนต์แบบอินเทอร์แอกทีฟถ่ายทอดออกมาเป็นภาพ ให้เสนอทางเลือกข้อความที่เข้าถึงได้ง่าย
ตัวอย่างเช่น หากคอมโพเนนต์ UI ของ <fancy-menu>
แสดงเฉพาะไอคอนรูปเฟืองเพื่อระบุว่าเป็นเมนูการตั้งค่า คอมโพเนนต์ UI ต้องใช้ข้อความที่เข้าถึงได้ เช่น "การตั้งค่า" ซึ่งแสดงข้อมูลเดียวกัน
คุณระบุทางเลือกข้อความได้โดยใช้แอตทริบิวต์ alt
, แอตทริบิวต์ aria-label
, แอตทริบิวต์ aria-labelledby
หรือข้อความธรรมดาใน Shadow DOM ทั้งนี้ขึ้นอยู่กับบริบท
คุณสามารถดูเคล็ดลับทางเทคนิคทั่วไปได้ใน ข้อมูลอ้างอิงด่วนของ WebAIM
คอมโพเนนต์ UI ที่แสดงรูปภาพควรมีกลไกในการระบุข้อความสำรองสำหรับรูปภาพนั้น ซึ่งคล้ายกับแอตทริบิวต์ alt
คอมโพเนนต์ของคุณให้ข้อมูลเชิงความหมายหรือไม่
เทคโนโลยีความช่วยเหลือพิเศษจะถ่ายทอดข้อมูลเชิงความหมายที่แสดงต่อผู้ใช้ด้วยภาพ เช่น การจัดรูปแบบ รูปแบบของเคอร์เซอร์ หรือตำแหน่ง องค์ประกอบมาตรฐานจะมีข้อมูลเชิงความหมายอยู่ในเบราว์เซอร์ แต่สำหรับคอมโพเนนต์ที่กำหนดเอง คุณต้องใช้ ARIA เพื่อเพิ่มข้อมูล
โดยทั่วไป คอมโพเนนต์ที่ฟังเหตุการณ์การคลิกเมาส์หรือเหตุการณ์การวางเมาส์เหนือควรมี Listener เหตุการณ์บนแป้นพิมพ์และบทบาท ARIA ซึ่งอาจมีสถานะและแอตทริบิวต์ ARIA ด้วย
ตัวอย่างเช่น คอมโพเนนต์ UI ของ <fancy-slider>
ที่กำหนดเองอาจมีบทบาท ARIA ของแถบเลื่อน ซึ่งมีแอตทริบิวต์ ARIA ที่เกี่ยวข้องบางอย่าง ได้แก่ aria-valuenow
, aria-valuemin
และ aria-valuemax
การเชื่อมโยงแอตทริบิวต์เหล่านี้กับพร็อพเพอร์ตี้ที่เกี่ยวข้องในคอมโพเนนต์ที่กำหนดเองช่วยให้คุณอนุญาตให้ผู้ใช้เทคโนโลยีความช่วยเหลือพิเศษโต้ตอบกับองค์ประกอบ เปลี่ยนแปลงค่า หรือแม้แต่ทำให้การนำเสนอด้วยภาพขององค์ประกอบเปลี่ยนแปลงตามไปด้วยได้
<fancy-slider role="slider" aria-valuemin="1" aria-valuemax="5" aria-valuenow="2.5">
</fancy-slider>
ผู้ใช้จะเข้าใจทุกอย่างโดยไม่ต้องพึ่งสีได้ไหม
คุณไม่ควรใช้สีเป็นวิธีเดียวในการนำเสนอข้อมูล เช่น การระบุสถานะ การกระตุ้นให้ผู้ใช้ตอบกลับ หรือการแสดงภาพข้อมูล เช่น หากคุณมีแผนภูมิวงกลม ให้ใส่ป้ายกำกับและค่าสำหรับแต่ละสไลซ์ เพื่อให้ผู้ใช้ที่มีความบกพร่องทางสายตาเข้าใจข้อมูลได้ แม้ว่าจะมองไม่เห็นจุดเริ่มต้นและจุดสิ้นสุดของชิ้นส่วนก็ตาม
มีคอนทราสต์เพียงพอไหม
เนื้อหาข้อความที่แสดงในคอมโพเนนต์ควรเป็นไปตามเกณฑ์คอนทราสต์ขั้นต่ำระดับ WCAG AA ลองใส่ธีมคอนทราสต์สูงที่ตรงตามเกณฑ์ AAA ที่สูงขึ้น และตรวจสอบว่าสามารถใช้สไตล์ชีตของ User Agent ได้หากผู้ใช้ต้องการคอนทราสต์ที่กำหนดเองหรือสีอื่น คุณสามารถใช้เครื่องมือตรวจสอบคอนทราสต์สีนี้เป็นตัวช่วยในการออกแบบคอมโพเนนต์ได้
เนื้อหาที่มีการเคลื่อนไหวหรือกะพริบหยุดได้และปลอดภัยหรือไม่
ผู้ใช้ควรหยุดชั่วคราว หยุด หรือซ่อนเนื้อหาที่เคลื่อนไหว เลื่อน หรือกะพริบได้นานกว่า 5 วินาที โดยทั่วไปแล้ว ควรหลีกเลี่ยงการใช้เนื้อหากะพริบ
หากบางอย่างต้องกะพริบ ให้ตรวจสอบว่าได้กะพริบไม่เกิน 3 ครั้งต่อวินาที
เครื่องมือและการทดสอบการช่วยเหลือพิเศษ
มีเครื่องมือกว่า 100 แบบที่พร้อมประเมินความสามารถเข้าถึงได้ง่ายของเว็บไซต์และองค์ประกอบต่างๆ ของเว็บไซต์ เครื่องมือบางอย่างทำงานอัตโนมัติในขณะที่เครื่องมืออื่นๆ กำหนดให้ต้องทดสอบด้วยตนเอง
ตัวอย่างให้คุณพิจารณามีดังนี้
- Axe จะให้การทดสอบการช่วยเหลือพิเศษแบบอัตโนมัติสำหรับเฟรมเวิร์กหรือเบราว์เซอร์ที่คุณเลือก Axe Puppeteer ใช้ในการเขียนการทดสอบการช่วยเหลือพิเศษอัตโนมัติได้
การตรวจสอบการช่วยเหลือพิเศษของ Lighthouse ให้ข้อมูลเชิงลึกที่เป็นประโยชน์สำหรับการสำรวจปัญหาด้านการช่วยเหลือพิเศษที่พบได้ทั่วไป คะแนนความสามารถเข้าถึงได้ง่ายเป็นค่าเฉลี่ยการถ่วงน้ำหนักของการตรวจสอบการช่วยเหลือพิเศษทั้งหมดโดยอิงจากการประเมินผลกระทบของผู้ใช้ Axe หากต้องการตรวจสอบการช่วยเหลือพิเศษที่มีการผสานรวมอย่างต่อเนื่อง โปรดดู Lighthouse CI
Tenon.io มีประโยชน์สำหรับการทดสอบปัญหาความสามารถเข้าถึงได้ง่ายที่พบบ่อย Tenon มีการสนับสนุนการผสานรวมที่แข็งแกร่ง ไม่ว่าจะเป็นเครื่องมือสร้าง เบราว์เซอร์ (ผ่านส่วนขยาย) ไปจนถึงโปรแกรมแก้ไขข้อความ
มีเครื่องมือเฉพาะไลบรารีและเฟรมเวิร์กจำนวนมากสำหรับไฮไลต์ ปัญหาการช่วยเหลือพิเศษของคอมโพเนนต์ ตัวอย่างเช่น ใช้ eslint-plugin-jsx-a11y เพื่อไฮไลต์ปัญหาการช่วยเหลือพิเศษสำหรับคอมโพเนนต์ React ในเครื่องมือแก้ไข
หากคุณใช้ Angular codelyzer จะมีการตรวจสอบการเข้าถึงในเครื่องมือแก้ไขดังนี้
ทำงานกับเทคโนโลยีความช่วยเหลือพิเศษ
- คุณตรวจสอบลักษณะที่เทคโนโลยีความช่วยเหลือพิเศษเห็นเนื้อหาเว็บได้โดยใช้
เครื่องมือตรวจสอบความสามารถเข้าถึงได้ง่าย (Mac)
หรือเครื่องมือทดสอบ Windows Automation API
และ AccProbe (Windows)
คุณยังดูแผนผังการช่วยเหลือพิเศษเต็มรูปแบบที่ Chrome สร้างได้โดยไปที่
about://accessibility
ด้วย - วิธีที่ดีที่สุดในการทดสอบการรองรับโปรแกรมอ่านหน้าจอใน Mac คือการใช้ยูทิลิตี VoiceOver ใช้
⌘F5
เพื่อเปิดหรือปิดใช้ รวมถึงใช้Ctrl+Option ←→
เพื่อเลื่อนผ่านหน้า และใช้Ctrl+Shift+Option + ↑↓
เพื่อเลื่อนโครงสร้างการช่วยเหลือพิเศษขึ้นและลง ดูวิธีการโดยละเอียดเพิ่มเติมได้ที่รายการคำสั่ง VoiceOver ทั้งหมดและรายการคำสั่ง VoiceOver Web ใน Windows NVDA จะเป็นโปรแกรมอ่านหน้าจอแบบโอเพนซอร์สที่ใช้งานได้ฟรี อย่างไรก็ตาม เส้นทางการเรียนรู้สำหรับผู้ใช้ที่มีความจำเป็นต้องใช้งานสูงเป็นพิเศษ
ChromeOS มีโปรแกรมอ่านหน้าจอในตัว
เรามีอีกหนทางยาวที่จะปรับปรุงการเข้าถึงบนเว็บ ตามสถิติเว็บระบุว่า
- เว็บไซต์ 4 ใน 5 เว็บไซต์มีข้อความกลืนไปกับพื้นหลังซึ่งทำให้อ่านไม่ออก
- 49.91% ของหน้าเว็บยังคงไม่ระบุแอตทริบิวต์
alt
สำหรับรูปภาพบางรูป - มีเพียง 24% ของหน้าเว็บที่ใช้ปุ่มหรือลิงก์มีป้ายกำกับ
- มีเพียง 22.33% ของหน้าเว็บที่มีป้ายกำกับสำหรับอินพุตทั้งหมดของแบบฟอร์ม
เราทำอะไรได้หลายอย่างเพื่อสร้างประสบการณ์ที่ทุกคนเข้าถึงได้มากขึ้น