การช่วยเหลือพิเศษสำหรับทีม

วิธีนำการช่วยเหลือพิเศษมาใช้ในกระบวนการของทีม

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

อย่าลืมว่าการช่วยเหลือพิเศษคือการทำงานเป็นทีม ทุกคนต่างมีบทบาท บทความนี้จะสรุปเกณฑ์สำหรับสาขาหลักๆ แต่ละสาขา (ผู้จัดการโครงการ นักออกแบบ UX และนักพัฒนาซอฟต์แวร์) เพื่อให้พวกเขานำแนวทางปฏิบัติแนะนำของการช่วยเหลือพิเศษมาใช้ในกระบวนการของตนได้

ผู้จัดการโครงการ

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

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

การฝึกอบรมการช่วยเหลือพิเศษ

มีแหล่งข้อมูลดีๆ มากมายสำหรับการเรียนรู้เกี่ยวกับการช่วยเหลือพิเศษในเว็บ การแบ่งเวลาให้ทีมศึกษาหัวข้อจะช่วยให้การช่วยเหลือพิเศษในช่วงแรกง่ายขึ้น

แหล่งข้อมูลบางส่วนที่ Google มีให้ ได้แก่

Web Accessibility โดย Google — หลักสูตรการฝึกอบรมแบบอินเทอร์แอกทีฟที่ใช้ระยะเวลาหลายสัปดาห์

หลักพื้นฐานในการช่วยเหลือพิเศษ — คู่มือเกี่ยวกับการช่วยเหลือพิเศษที่เขียนแล้วและแนวทางปฏิบัติแนะนำ

หลักเกณฑ์ด้านเนื้อหา: การช่วยเหลือพิเศษ — ชุดแนวทางปฏิบัติแนะนำเกี่ยวกับ UX สำหรับการออกแบบที่ไม่แบ่งแยก

ระบุเส้นทางที่สำคัญของผู้ใช้

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

เส้นทางหลักของผู้ใช้: ผู้ใช้สามารถเพิ่มสินค้าลงในรถเข็นช็อปปิ้ง

การดำเนินการบางอย่างอาจมีความสำคัญรองลงมา และบางครั้งอาจดำเนินการเป็นครั้งคราว เช่น การเปลี่ยนรูปโปรไฟล์เป็นฟีเจอร์ที่ดี แต่อาจไม่ได้สำคัญต่อประสบการณ์ทั้งหมด

การระบุการดำเนินการหลักและรองในแอปพลิเคชันจะช่วยให้คุณจัดลำดับความสำคัญของการช่วยเหลือพิเศษในอนาคต หลังจากนั้น คุณสามารถรวมการดำเนินการเหล่านี้เข้ากับรายการตรวจสอบการช่วยเหลือพิเศษเพื่อติดตามความคืบหน้าและหลีกเลี่ยงการถดถอย

รวมรายการตรวจสอบการช่วยเหลือพิเศษ

หัวข้อการช่วยเหลือพิเศษค่อนข้างกว้าง ดังนั้นการมีเช็กลิสต์ส่วนสำคัญที่ต้องพิจารณาจะช่วยให้ครอบคลุมทุกสถานการณ์

มีรายการตรวจสอบการช่วยเหลือพิเศษจำนวนหนึ่ง ตัวอย่างอุตสาหกรรมบางส่วน ได้แก่

เช็กลิสต์สำหรับ WCAG ของ WebAIM หลักเกณฑ์การช่วยเหลือพิเศษของ Vox

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

ตารางที่มีกรณีการใช้งานหลักเป็นแถวและรายการตรวจสอบเป็นคอลัมน์

การประเมินด้วยการศึกษาผู้ใช้

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

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

นักออกแบบ UX

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

  • เนื้อหามีคอนทราสต์ของสีที่เพียงพอ
  • มีการกำหนดลำดับแท็บ
  • ตัวควบคุมมีป้ายกำกับที่เข้าถึงได้
  • ซึ่งโต้ตอบกับ UI ได้หลายวิธี

เนื้อหามีคอนทราสต์ของสีที่ดี

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

คอนทราสต์วัดจากการเปรียบเทียบความสว่างของสีพื้นหน้าและสีพื้นหลัง สำหรับข้อความขนาดเล็ก (ตัวหนาที่ต่ำกว่า 18pt หรือ 14pt) ขอแนะนำให้ใช้อัตราส่วน 4.5:1 เป็นอย่างน้อย สำหรับข้อความขนาดใหญ่ อัตราส่วนนี้ปรับเป็น 3:1 ได้

ในรูปภาพด้านล่าง ข้อความทางด้านซ้ายมือตรงกับค่าต่ำสุดคอนทราสต์เหล่านี้ ขณะที่ข้อความด้านขวามือมีคอนทราสต์ต่ำ

ตัวอย่างข้อความแบบแสดงคู่กัน ระดับแรกคือคอนทราสต์ที่เพียงพอ อีกเกณฑ์คือคอนทราสต์ต่ำ

มีเครื่องมือมากมายสำหรับการวัดคอนทราสต์ของสี เช่น เครื่องมือสีแบบ Material ของ Google, แอปอัตราคอนทราสต์ของ Lea Verou's Constant Ratio และ aXe ของ Deque

กำหนดลำดับแท็บแล้ว

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

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

องค์ประกอบการออกแบบพร้อมการควบคุมแบบอินเทอร์แอกทีฟที่มีหมายเลขกำกับ

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

ตัวควบคุมมีป้ายกำกับที่เข้าถึงได้

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

ต่อไปนี้คือคำแนะนำง่ายๆ ที่คุณปฏิบัติตามเมื่อออกแบบป้ายกำกับสำหรับการช่วยเหลือพิเศษ:

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

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

โต้ตอบและทำความเข้าใจ UI ได้หลายวิธี

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

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

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

นักพัฒนาแอป

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

  • ลำดับของแท็บเป็นไปตามตรรกะ
  • โฟกัสได้รับการจัดการและมองเห็นได้อย่างเหมาะสม
  • องค์ประกอบแบบอินเทอร์แอกทีฟรองรับแป้นพิมพ์
  • ระบบนำบทบาทและแอตทริบิวต์ ARIA ไปใช้ตามความจำเป็น
  • องค์ประกอบมีป้ายกำกับอย่างถูกต้อง
  • การทดสอบจะเป็นแบบอัตโนมัติ

ลำดับแท็บที่สมเหตุสมผล

องค์ประกอบเนทีฟ เช่น input, button และ select จะเลือกใช้การเรียงแท็บได้ฟรีและจะโฟกัสได้โดยอัตโนมัติด้วยแป้นพิมพ์ แต่องค์ประกอบบางอย่าง ไม่ได้มีลักษณะการทำงานเดียวกันนี้ โดยเฉพาะองค์ประกอบทั่วไป เช่น div และ span จะไม่เลือกใช้ลำดับแท็บ ซึ่งหมายความว่า หากใช้ div เพื่อสร้างการควบคุมแบบอินเทอร์แอกทีฟ คุณจะต้องดำเนินการเพิ่มเติมเพื่อทำให้เข้าถึงด้วยแป้นพิมพ์ได้

โดยมี 2 ตัวเลือกดังนี้

  • ให้การควบคุมแก่ tabindex="0" อย่างน้อยก็จะช่วยให้โฟกัสได้ แต่คุณอาจต้องทำงานเพิ่มเติมเพื่อเพิ่มการรองรับการกดแป้นพิมพ์
  • หากเป็นไปได้ ให้พิจารณาใช้ button แทน div หรือ span สำหรับการควบคุมที่คล้ายปุ่ม องค์ประกอบดั้งเดิม button นั้นจัดรูปแบบได้ง่ายมากและ ยังรองรับแป้นพิมพ์ฟรีด้วย

การจัดการโฟกัส

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

การรองรับแป้นพิมพ์สำหรับองค์ประกอบแบบอินเทอร์แอกทีฟ

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

ข้อความที่ตัดตอนมาจากคู่มือ ARIA Authoring Practices ที่อธิบายวิธีสร้างกลุ่มวิทยุ

หากต้องการดูข้อมูลเพิ่มเติมเกี่ยวกับการเพิ่มการรองรับแป้นพิมพ์ลงในองค์ประกอบ ให้ดูที่ส่วน Tabindex ในเอกสารพื้นฐานการช่วยเหลือพิเศษของ Google

มีการนำบทบาทและแอตทริบิวต์ ARIA ไปใช้ตามที่จำเป็น

การควบคุมที่กำหนดเองไม่เพียงแต่ต้องมีการรองรับแป้นพิมพ์ที่เหมาะสมเท่านั้น แต่ยังต้องใช้ความหมายที่เหมาะสมด้วย ที่จริงแล้ว div ในทางความหมายคือคอนเทนเนอร์การจัดกลุ่มทั่วไป หากใช้ div เป็นฐานสำหรับเมนูแบบเลื่อนลง คุณจะต้องใช้ ARIA เพื่อแบ่งชั้นเชิงอรรถศาสตร์เพิ่มเติมเพื่อให้ถ่ายทอดประเภทการควบคุมไปยังเทคโนโลยีความช่วยเหลือได้ คู่มือแนวทางปฏิบัติในการสร้าง ARIA ช่วยคุณระบุบทบาท รัฐ และพร็อพเพอร์ตี้ที่คุณควรใช้อีกครั้ง คำอธิบายจำนวนมากในคู่มือ ARIA มาพร้อมกับโค้ดตัวอย่างเพื่อเป็นโบนัสเสริม

องค์ประกอบการติดป้ายกำกับ

สำหรับการติดป้ายกำกับอินพุตเนทีฟ คุณสามารถใช้องค์ประกอบ <label> ในตัวตามที่อธิบายไว้ใน MDN วิธีนี้ไม่เพียงช่วยให้คุณสร้างพื้นที่การมองเห็นบนหน้าจอ แต่ยังทำให้อินพุตมีชื่อที่เข้าถึงได้ในแผนผังการช่วยเหลือพิเศษด้วย เทคโนโลยีความช่วยเหลือพิเศษ (เช่น โปรแกรมอ่านหน้าจอ) จะเลือกชื่อนี้และประกาศให้ผู้ใช้ทราบ

ขออภัยที่ <label> ไม่รองรับการตั้งชื่อที่เข้าถึงได้ให้กับการควบคุมที่กำหนดเอง (เช่น องค์ประกอบที่สร้างโดยใช้องค์ประกอบที่กำหนดเอง หรือจาก div และระยะเวลาแบบง่าย) คุณจะต้องใช้แอตทริบิวต์ aria-label และ aria-labelledby สำหรับการควบคุมประเภทนี้

การทดสอบอัตโนมัติ

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

aXe ที่สร้างโดยระบบ Deque จะพร้อมใช้งานเป็นส่วนขยาย Chrome และโมดูลโหนด (เหมาะสำหรับสภาพแวดล้อมการผสานรวมอย่างต่อเนื่อง) A11ycast สั้นๆ นี้จะอธิบายวิธีต่างๆ ในการนำ AXe มาใช้ในขั้นตอนการพัฒนา

Lighthouse เป็นโครงการโอเพนซอร์สของ Google สำหรับตรวจสอบประสิทธิภาพของ Progressive Web App นอกจากการตรวจสอบว่า PWA รองรับสิ่งต่างๆ อย่างเช่น Service Worker และไฟล์ Manifest ของเว็บแอปแล้ว Lighthouse จะทำการทดสอบแนวทางปฏิบัติแนะนำหลายรายการ ซึ่งรวมถึงการทดสอบปัญหาด้านการช่วยเหลือพิเศษด้วย

บทสรุป

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

หากต้องการดูข้อมูลเพิ่มเติมเกี่ยวกับการช่วยเหลือพิเศษ โปรดดูหลักสูตร Udacity แบบไม่เสียค่าใช้จ่ายของเรา และเรียกดูเอกสารเกี่ยวกับการช่วยเหลือพิเศษที่มีให้ที่ web.dev