การช่วยเหลือพิเศษสำหรับนักพัฒนาเว็บ

การปรับปรุงการช่วยเหลือพิเศษทำให้เว็บไซต์มีประโยชน์มากขึ้นสำหรับทุกคน

Addy Osmani

การสร้างเว็บไซต์ที่เปิดกว้างและเข้าถึงได้สำหรับทุกคนจึงเป็นสิ่งสำคัญ ความพิการที่สำคัญซึ่งคุณเพิ่มประสิทธิภาพได้มีอย่างน้อย 6 ข้อ ดังนี้ visual, การได้ยิน, อุปกรณ์เคลื่อนที่, การรับรู้, เสียงพูด และระบบประสาท เครื่องมือและแหล่งข้อมูลมากมาย ช่วยคุณได้ที่นี่ แม้จะเป็นมือใหม่ก็ตาม

ผู้คนกว่า 1 พันล้านคน อยู่กับความพิการแบบใดแบบหนึ่ง

เว็บไซต์ต้องทำงานในอุปกรณ์หลายเครื่องเพื่อให้เข้าถึงได้ ที่มีขนาดหน้าจอและอินพุตประเภทต่างๆ เช่น โปรแกรมอ่านหน้าจอ ยิ่งไปกว่านั้น เว็บไซต์ควรจะใช้งานได้สำหรับกลุ่มผู้ใช้ที่หลากหลายที่สุด ซึ่งรวมถึงผู้พิการด้วย

ความพิการบางอย่างที่ผู้ใช้อาจมีมีดังนี้

ปัญหาด้านภาพมีตั้งแต่ความบกพร่องทางการมองเห็นไปจนถึงการมองไม่เห็นสีเลย

• ตรวจสอบว่าเนื้อหาข้อความเป็นไปตามเกณฑ์ขั้นต่ำ เกณฑ์อัตราส่วนคอนทราสต์
• หลีกเลี่ยงการสื่อสารข้อมูล การใช้สีเพียงอย่างเดียว และตรวจสอบว่าข้อความทั้งหมด ที่ปรับขนาดได้
• ตรวจสอบว่าคอมโพเนนต์อินเทอร์เฟซผู้ใช้ทั้งหมดใช้กับเทคโนโลยีความช่วยเหลือพิเศษได้ เช่น โปรแกรมอ่านหน้าจอ แว่นขยาย และจอแสดงผลอักษรเบรลล์ ซึ่งจะต้องมีการมาร์กอัปคอมโพเนนต์ 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 จะแสดงข้อมูลการช่วยเหลือพิเศษในแท็บElementsของแผงElements

ต่อไปนี้คือรายการคำถามที่คุณสามารถถามตัวเองเมื่อต้องการทำให้คอมโพเนนต์ 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% ของหน้าเว็บเท่านั้นที่ติดป้ายกำกับสำหรับอินพุตทั้งหมดของฟอร์ม

เราสามารถทำอะไรได้มากมายเพื่อสร้างประสบการณ์ ที่เข้าถึงได้ง่ายมากขึ้นสำหรับ ทุกคน