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

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

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

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