การปรับปรุงการช่วยเหลือพิเศษทำให้เว็บไซต์มีประโยชน์มากขึ้นสำหรับทุกคน
การสร้างเว็บไซต์ที่เปิดกว้างและเข้าถึงได้สำหรับทุกคนจึงเป็นสิ่งสำคัญ ความพิการที่สำคัญซึ่งคุณเพิ่มประสิทธิภาพได้มีอย่างน้อย 6 ข้อ ดังนี้ visual, การได้ยิน, อุปกรณ์เคลื่อนที่, การรับรู้, เสียงพูด และระบบประสาท เครื่องมือและแหล่งข้อมูลมากมาย ช่วยคุณได้ที่นี่ แม้จะเป็นมือใหม่ก็ตาม
ผู้คนกว่า 1 พันล้านคน อยู่กับความพิการแบบใดแบบหนึ่ง
เว็บไซต์ต้องทำงานในอุปกรณ์หลายเครื่องเพื่อให้เข้าถึงได้ ที่มีขนาดหน้าจอและอินพุตประเภทต่างๆ เช่น โปรแกรมอ่านหน้าจอ ยิ่งไปกว่านั้น เว็บไซต์ควรจะใช้งานได้สำหรับกลุ่มผู้ใช้ที่หลากหลายที่สุด ซึ่งรวมถึงผู้พิการด้วย
ความพิการบางอย่างที่ผู้ใช้อาจมีมีดังนี้
| การมองเห็น | การได้ยิน | การเคลื่อนไหว |
|---|---|---|
|
|
|
| การรับรู้ | คำพูด | ระบบประสาทเทียม |
|
|
|
ปัญหาด้านภาพมีตั้งแต่ความบกพร่องทางการมองเห็นไปจนถึงการมองไม่เห็นสีเลย
- ตรวจสอบว่าเนื้อหาข้อความเป็นไปตามเกณฑ์ขั้นต่ำ เกณฑ์อัตราส่วนคอนทราสต์
- หลีกเลี่ยงการสื่อสารข้อมูล การใช้สีเพียงอย่างเดียว และตรวจสอบว่าข้อความทั้งหมด resizable
- ตรวจสอบว่าคอมโพเนนต์อินเทอร์เฟซผู้ใช้ทั้งหมดใช้กับเทคโนโลยีความช่วยเหลือพิเศษได้ เช่น โปรแกรมอ่านหน้าจอ แว่นขยาย และจอแสดงผลอักษรเบรลล์ ซึ่งจะต้องมีการมาร์กอัปคอมโพเนนต์ UI API การช่วยเหลือพิเศษจะสามารถระบุแบบเป็นโปรแกรม role, state, value และ title ขององค์ประกอบใดก็ได้
โดยส่วนตัวแล้วผมมีสายตาเลือนราง และมักพบว่าตัวเองซูมเข้าไปดูเว็บไซต์ เครื่องมือสำหรับนักพัฒนาเว็บและเทอร์มินัล ในขณะที่การสนับสนุนการซูมนั้นแทบจะไม่ได้ขึ้นมาอยู่ในอันดับต้นๆ ของนักพัฒนาซอฟต์แวร์ รายการสิ่งที่ต้องทำ สิ่งนี้สร้างความแตกต่าง ให้กับผู้ใช้อย่างผมได้
ปัญหาในการได้ยินหมายความว่าผู้ใช้อาจมีปัญหาเกี่ยวกับการได้ยินที่ปล่อยออกจากหน้าเว็บ
- โปรดระบุ ข้อความที่ใช้แทน สำหรับเนื้อหาทั้งหมดที่ไม่ใช่ข้อความ
- ทดสอบว่าคอมโพเนนต์ UI ยังคงใช้งานได้ ที่ไม่มีเสียง
ปัญหาด้านการเคลื่อนย้ายอาจรวมถึงความไม่ทำงานของเมาส์ แป้นพิมพ์ หรือ หน้าจอสัมผัส
- สร้างเนื้อหาของคอมโพเนนต์ UI เข้าถึงการทำงานได้ด้วยแป้นพิมพ์ สำหรับการทำงานที่ต้องใช้เมาส์
- ตรวจสอบว่าหน้าเว็บมีมาร์กอัปที่ถูกต้องเกี่ยวกับเทคโนโลยีความช่วยเหลือพิเศษ ซึ่งรวมถึง โปรแกรมอ่านหน้าจอ ซอฟต์แวร์ควบคุมด้วยเสียง และการควบคุมสวิตช์จริง ซึ่ง มีแนวโน้มที่จะใช้ API เดียวกัน
ปัญหาด้านการรับรู้หมายความว่าผู้ใช้อาจต้องการเทคโนโลยีความช่วยเหลือพิเศษ เพื่อช่วยในการอ่านข้อความ ดังนั้นสิ่งสำคัญคือต้องมีข้อความสำรองอยู่ด้วย
โปรดระมัดระวังเมื่อใช้ภาพเคลื่อนไหว หลีกเลี่ยงวิดีโอและภาพเคลื่อนไหวที่ ทำซ้ำ หรือแฟลช ซึ่งอาจทำให้เกิดปัญหา สำหรับผู้ใช้บางราย
prefers-reduced-motionคิวรี่สื่อ CSS ช่วยให้คุณจำกัดภาพเคลื่อนไหว และเล่นอัตโนมัติสำหรับผู้ใช้ที่ต้องการลดการเคลื่อนไหว/* 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 ที่เรียกว่า ตาบอดสี (ลองใช้การจำลองภาวะตาบอดสีทั้ง 4 รูปแบบที่มีให้) คุณอาจสนใจ ดัลโตนิซ เป็นส่วนขยาย ซึ่งก็มีประโยชน์คล้ายๆ กัน
คอมโพเนนต์ UI ใช้งานกับเปิดใช้โหมดคอนทราสต์สูงได้ไหม
ระบบปฏิบัติการสมัยใหม่ทั้งหมดรองรับโหมดคอนทราสต์สูง คอนทราสต์สูง เป็นส่วนขยาย Chrome ที่ช่วยในเรื่องนี้ได้
การควบคุมที่เป็นมาตรฐาน (เช่น <button> และ <select>) มีการช่วยเหลือพิเศษ
มีอยู่ในเบราว์เซอร์ โดยจะโฟกัสได้โดยใช้คีย์ Tab
ตอบสนองต่อเหตุการณ์บนแป้นพิมพ์ (เช่น ปุ่ม Enter, Space และลูกศร)
โดยมีบทบาททางความหมาย สถานะ และพร็อพเพอร์ตี้ที่เครื่องมือช่วยเหลือพิเศษใช้
การจัดรูปแบบเริ่มต้นควรเป็นไปตามข้อกำหนดการช่วยเหลือพิเศษที่ระบุไว้ด้วย
คอมโพเนนต์ UI ที่กำหนดเอง (ยกเว้นคอมโพเนนต์ที่ขยายมาตรฐาน
องค์ประกอบ เช่น <button>) ไม่มีความสามารถในตัว รวมถึง
ความสามารถเข้าถึงได้ง่าย เป็นที่ที่ดีในการเริ่มต้น
การนำการช่วยเหลือพิเศษไปใช้คือการเปรียบเทียบคอมโพเนนต์ของคุณกับมาตรฐานที่คล้ายกัน
(หรือชุดค่าผสมขององค์ประกอบมาตรฐานหลายรายการ ขึ้นอยู่กับว่ามีความซับซ้อนมากน้อยเพียงใด
คอมโพเนนต์ของคุณอยู่)
เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์เบราว์เซอร์ส่วนใหญ่รองรับการตรวจสอบโครงสร้างการช่วยเหลือพิเศษของหน้าเว็บ ในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ตัวเลือกนี้มีอยู่ในแท็บการช่วยเหลือพิเศษในแผงองค์ประกอบ
Firefox ยังมีแผงการเข้าถึงอีกด้วย
Safari จะแสดงข้อมูลการช่วยเหลือพิเศษในแท็บโหนดของแผงองค์ประกอบ
ต่อไปนี้คือรายการคำถามที่คุณสามารถถามตัวเองเมื่อต้องการทำให้คอมโพเนนต์ UI เข้าถึงได้ง่ายขึ้น
ปรับปรุงโฟกัสของแป้นพิมพ์
โดยหลักการแล้ว ให้ตรวจสอบว่าทุกคนเข้าถึงฟังก์ชันการทำงานทั้งหมดในคอมโพเนนต์ UI ได้ ด้วยแป้นพิมพ์ เมื่อออกแบบประสบการณ์ของผู้ใช้ ลองคิดดูว่าคุณจะใช้องค์ประกอบ ของคุณด้วยแป้นพิมพ์เพียงอย่างเดียว และค้นหาชุดการโต้ตอบกับแป้นพิมพ์ที่สอดคล้องกัน
ก่อนอื่นให้ตรวจสอบว่าคุณมีเป้าหมายการโฟกัสที่สมเหตุสมผลสำหรับแต่ละองค์ประกอบ ตัวอย่างเช่น คอมโพเนนต์ที่ซับซ้อนอย่างเมนูอาจเป็นเป้าหมายโฟกัสหนึ่งใน แต่ควรจัดการโฟกัสภายในตัวเอง เพื่อให้รายการเมนูที่มีการใช้งาน มีสมาธิเสมอ
ใช้ Tabindex
คุณเพิ่มโฟกัสแป้นพิมพ์สำหรับองค์ประกอบและคอมโพเนนต์ UI ได้ด้วย tabindex
ผู้ใช้เทคโนโลยีความช่วยเหลือพิเศษและแป้นพิมพ์เท่านั้นต้องวางตำแหน่งได้
แป้นพิมพ์จะโฟกัสที่องค์ประกอบต่างๆ เพื่อโต้ตอบ
องค์ประกอบแบบอินเทอร์แอกทีฟในตัว (เช่น <button>) จะโฟกัสได้โดยนัย ดังนั้น
โดยไม่จำเป็นต้องมี tabindex แอตทริบิวต์ เว้นแต่คุณจะจำเป็นต้องเปลี่ยนตำแหน่ง
ตามลำดับแท็บ
ค่า tabindex มี 3 ประเภทดังนี้
tabindex="0"คือระบบที่พบบ่อยที่สุดและจัดวางองค์ประกอบไว้ในแท็บธรรมชาติ ลำดับ (กำหนดโดยลำดับ DOM)- ค่า
tabindexเท่ากับ -1 จะทำให้องค์ประกอบแบบเป็นโปรแกรม โฟกัสได้ แต่ไม่อยู่ในลำดับแท็บ - ค่า
tabindexที่มากกว่า 0 จะวางองค์ประกอบไว้ในลำดับแท็บที่กำหนดเอง ระบบจะเข้าชมองค์ประกอบทั้งหมดในหน้าเว็บที่มีค่าtabindexเป็นบวกใน ลำดับตัวเลขก่อนองค์ประกอบในลำดับแท็บตามปกติ
ค้นหากรณีการใช้งาน tabindex ในบทความ
การใช้ Tabindex
ตรวจสอบว่าโฟกัสจะปรากฏให้เห็นตลอดเวลา ไม่ว่าจะใช้วงแหวนโฟกัสเริ่มต้นก็ตาม หรือโดยการใช้รูปแบบโฟกัสที่กำหนดเองที่เห็นได้ชัด อย่าวางกับดัก ผู้ใช้แป้นพิมพ์ พวกเขาควรจะสามารถย้ายโฟกัสออกจากองค์ประกอบหนึ่งได้ โดยใช้เฉพาะแป้นพิมพ์
ใช้การโฟกัสอัตโนมัติ
แอตทริบิวต์ระบบโฟกัสอัตโนมัติ HTML ช่วยให้ผู้เขียนสามารถระบุ
องค์ประกอบควรโฟกัสโดยอัตโนมัติ
เมื่อหน้าโหลดขึ้นมา
รองรับ autofocus แล้วใน
ตัวควบคุมเว็บฟอร์มทั้งหมด
รวมถึงปุ่มต่างๆ
ในการโฟกัสองค์ประกอบอัตโนมัติในคอมโพเนนต์ UI ที่คุณกำหนดเอง
เรียกเมธอด focus()
ใช้ได้กับองค์ประกอบ HTML ทั้งหมดที่โฟกัสได้
(เช่น document.querySelector('myButton').focus())
เพิ่มการโต้ตอบกับแป้นพิมพ์
เมื่อโฟกัสคอมโพเนนต์ UI ได้แล้ว ให้ใส่เรื่องราวการโต้ตอบทางแป้นพิมพ์ที่ดี
เมื่อคอมโพเนนต์ถูกโฟกัสโดยการจัดการเหตุการณ์บนแป้นพิมพ์ที่เหมาะสม
เช่น อนุญาตให้ผู้ใช้ใช้ปุ่มลูกศรเพื่อเลือกตัวเลือกเมนู
และ Space หรือ Enter เพื่อเปิดใช้งานปุ่ม
คู่มือรูปแบบการออกแบบของ ARIA
จะมีคำแนะนำบางส่วนที่นี่
สุดท้าย ตรวจสอบว่าแป้นพิมพ์ลัดสามารถค้นพบได้ แนวทางปฏิบัติทั่วไปคือการมีคำอธิบายแป้นพิมพ์ลัด (ข้อความบนหน้าจอ) เพื่อแจ้งให้ผู้ใช้ทราบว่ามีทางลัดอยู่ ตัวอย่างเช่น "กด ? สำหรับแป้นพิมพ์ ทางลัด" หรือจะใช้คำแนะนำเคล็ดลับเครื่องมือดังกล่าวเพื่อแจ้งผู้ใช้ก็ได้ เกี่ยวกับทางลัด
ไม่ได้กล่าวถึงความสำคัญของการจัดการการมุ่งเน้นมากเกินไป ตัวอย่างที่สำคัญคือ ลิ้นชักการนำทาง หากคุณเพิ่มคอมโพเนนต์ UI ลงในหน้า คุณต้องมุ่งเน้นไปยังองค์ประกอบภายใน ไม่เช่นนั้น ผู้ใช้อาจต้องกด Tab ทั้งหน้าเพื่อไปถึงที่นั่น ซึ่งเป็นประสบการณ์ที่น่าหงุดหงิด ดังนั้น อย่าลืมทดสอบโฟกัสสำหรับคอมโพเนนต์ที่ไปยังส่วนต่างๆ ของแป้นพิมพ์ทั้งหมดในหน้าเว็บ
// 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> แสดงเฉพาะไอคอนรูปเฟือง
เพื่อระบุว่าเป็นเมนูการตั้งค่า
ต้องมีข้อความที่เข้าถึงได้ เช่น "การตั้งค่า"
ที่ให้ข้อมูลเดียวกัน
ขึ้นอยู่กับบริบท
คุณระบุข้อความทางเลือกได้โดยใช้แอตทริบิวต์ 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 มีการช่วยเหลือพิเศษแบบอัตโนมัติ สำหรับเฟรมเวิร์กหรือเบราว์เซอร์ที่คุณเลือก คนเชิดหุ่นขวาน ใช้ในการเขียนการทดสอบการช่วยเหลือพิเศษอัตโนมัติได้
การช่วยเหลือพิเศษของ 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 ใน Windows NVDA เป็นหน้าจอโอเพนซอร์สที่ใช้งานฟรี ผู้อ่าน แต่ก็มีความยุ่งยากในการเรียนรู้สูงสำหรับผู้ใช้ที่มองเห็น
ChromeOS มี โปรแกรมอ่านหน้าจอในตัว
เราสามารถพัฒนาการช่วยเหลือพิเศษบนเว็บได้อย่างมาก ตามหนังสือสรุปเว็บ
- เว็บไซต์ 4 แห่งจากทั้งหมด 5 แห่งมีข้อความกลืนไปกับพื้นหลัง ทำให้อ่านไม่ได้
- 49.91% ของหน้าเว็บยังคงไม่ระบุแอตทริบิวต์
altสำหรับรูปภาพบางรูป - มีเพียง 24% ของหน้าเว็บที่ใช้ปุ่มหรือลิงก์เท่านั้นที่มีป้ายกำกับ
- มีเพียง 22.33% ของหน้าเว็บเท่านั้นที่ติดป้ายกำกับสำหรับอินพุตทั้งหมดของฟอร์ม
เราสามารถทำอะไรได้มากมายเพื่อสร้างประสบการณ์ ที่เข้าถึงได้ง่ายมากขึ้นสำหรับ ทุกคน