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

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

การประเมินด้วยการศึกษาผู้ใช้
ไม่มีอะไรดีไปกว่าการนั่งคุยกับผู้ใช้จริงและสังเกตดูขณะที่ผู้ใช้พยายามใช้แอปของคุณ หากคุณกำลังปรับแต่งการช่วยเหลือพิเศษให้เข้ากับประสบการณ์การใช้งานที่มีอยู่ กระบวนการนี้จะช่วยให้คุณระบุจุดที่ต้องปรับปรุงได้อย่างรวดเร็ว และหากคุณกำลังเริ่มโปรเจ็กต์ใหม่ การศึกษาวิจัยผู้ใช้ตั้งแต่เนิ่นๆ จะช่วยให้คุณหลีกเลี่ยงการใช้เวลามากเกินไปในการพัฒนาฟีเจอร์ที่ใช้งานยาก
พยายามรวบรวมความคิดเห็นจากผู้ใช้ที่หลากหลายมากที่สุด พิจารณาผู้ใช้ที่ไปยังส่วนต่างๆ ด้วยแป้นพิมพ์เป็นหลัก หรือใช้เทคโนโลยีความช่วยเหลือพิเศษ เช่น โปรแกรมอ่านหน้าจอหรือโปรแกรมขยายหน้าจอ
นักออกแบบ UX
เนื่องจากผู้คนมีแนวโน้มที่จะออกแบบโดยใช้อคติของตนเอง หากคุณไม่มีความพิการและเพื่อนร่วมงานไม่มีความพิการ คุณอาจออกแบบโดยไม่ได้ตั้งใจให้ผู้ใช้เพียงบางส่วนเท่านั้น ขณะทํางาน ให้ถามตัวคุณเองว่า "ผู้ใช้ประเภทใดบ้างที่อาจใช้การออกแบบนี้" ต่อไปนี้คือเทคนิคบางอย่างที่คุณลองใช้เพื่อทำให้กระบวนการมีความครอบคลุมมากขึ้น
- เนื้อหามีคอนทราสต์ของสีเพียงพอ
- กำหนดลําดับแท็บแล้ว
- การควบคุมมีป้ายกำกับที่เข้าถึงได้
- การโต้ตอบกับ UI มีหลายวิธี
เนื้อหามีคอนทราสต์สีที่ดี
เป้าหมายหลักของเว็บไซต์ส่วนใหญ่คือการสื่อข้อมูลบางอย่างไปยังผู้ใช้ ไม่ว่าจะเป็นข้อความหรือรูปภาพ อย่างไรก็ตาม หากเนื้อหานี้มีคอนทราสต์ต่ำ ผู้ใช้บางราย (โดยเฉพาะผู้ที่มีปัญหาด้านการมองเห็น) อาจอ่านได้ยาก ซึ่งอาจส่งผลเสียต่อประสบการณ์ของผู้ใช้ หากต้องการแก้ไขปัญหานี้ ให้พยายามทำให้ข้อความและรูปภาพทั้งหมดมีคอนทราสต์ของสีที่เพียงพอ
ระบบจะวัดคอนทราสต์โดยการเปรียบเทียบความสว่างของสีพื้นหน้าและพื้นหลัง สำหรับข้อความขนาดเล็ก (ต่ำกว่า 18pt หรือ 14pt ตัวหนา) เราขอแนะนำให้ใช้อัตราส่วนขั้นต่ำ 4.5:1 สำหรับข้อความขนาดใหญ่ อัตราส่วนนี้สามารถปรับเป็น 3:1 ได้
ในรูปภาพด้านล่าง ข้อความทางด้านซ้ายเป็นไปตามเกณฑ์คอนทราสต์ขั้นต่ำเหล่านี้ ขณะที่ข้อความทางด้านขวามีคอนทราสต์ต่ำ

มีเครื่องมือหลายอย่างสําหรับวัดคอนทราสต์ของสี เช่น Material Color Tool ของ Google, แอปอัตราส่วนคอนทราสต์ของ Lea Verou และ aXe ของ Deque
กำหนดลำดับแท็บแล้ว
ลําดับการกด Tab คือลําดับที่องค์ประกอบต่างๆ ได้รับโฟกัสเมื่อผู้ใช้กดแป้น Tab สําหรับผู้ใช้ที่ไปยังส่วนต่างๆ ด้วยแป้นพิมพ์เป็นหลัก ปุ่ม Tab เป็นช่องทางหลักในการเข้าถึงทุกอย่างบนหน้าจอ โปรดทราบว่าฟีเจอร์นี้เหมือนกับเคอร์เซอร์เมาส์
ตามหลักการแล้ว ลำดับแท็บควรเป็นไปตามลำดับการอ่านและไหลจากด้านบนของหน้าเว็บลงล่าง โดยรายการที่สําคัญกว่าควรปรากฏในลำดับที่สูงขึ้น วิธีนี้จะช่วยให้ทุกคนที่ใช้แป้นพิมพ์เข้าถึงรายการเหล่านี้ได้อย่างรวดเร็วและมีประสิทธิภาพมากขึ้น

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

คุณอาจพิจารณาสร้างการจําลองที่มีป้ายกำกับการควบคุมทั้งหมด คุณสามารถแชร์ข้อมูลนี้กับทีมพัฒนาและทีม QA เพื่อใช้งานและทดสอบ
วิธีต่างๆ ในการโต้ตอบและทำความเข้าใจ UI
เราอาจคิดว่าผู้ใช้ทุกคนโต้ตอบกับหน้าเว็บโดยใช้เมาส์เป็นหลัก เมื่อออกแบบ ให้พิจารณาว่าผู้ใช้จะโต้ตอบกับตัวควบคุมโดยใช้แป้นพิมพ์อย่างไรแทน
วางแผนสถานะโฟกัส ซึ่งหมายความว่าต้องกำหนดลักษณะที่ตัวควบคุมจะมีเมื่อผู้ใช้โฟกัสด้วย Tab หรือกดแป้นลูกศร คุณควรวางแผนสถานะเหล่านี้ตั้งแต่เนิ่นๆ แทนที่จะพยายามยัดเยียดสถานะเหล่านี้ลงในการออกแบบในภายหลัง
สุดท้าย คุณต้องตรวจสอบว่าผู้ใช้มีวิธีทำความเข้าใจเนื้อหาได้หลายวิธีในจุดที่โต้ตอบ พยายามอย่าใช้สีเพียงอย่างเดียวเพื่อสื่อข้อมูล เนื่องจากผู้ใช้ที่มีความบกพร่องทางการมองเห็นสีอาจมองไม่เห็นสัญญาณเล็กๆ น้อยๆ เหล่านี้ ตัวอย่างคลาสสิกคือช่องข้อความที่ไม่ถูกต้อง พิจารณาเพิ่มข้อความช่วยเหลือแทนการขีดเส้นใต้สีแดงเพื่อบ่งบอกปัญหา วิธีนี้จะช่วยให้คุณครอบคลุมฐานข้อมูลได้มากขึ้นและเพิ่มโอกาสที่ผู้ใช้จะสังเกตเห็นปัญหา
นักพัฒนาซอฟต์แวร์
บทบาทของนักพัฒนาแอปคือการนำการจัดการโฟกัสและความหมายมารวมกันเพื่อสร้างประสบการณ์ของผู้ใช้ที่มีประสิทธิภาพ ด้านล่างนี้คือสิ่งที่นักพัฒนาซอฟต์แวร์ควรคำนึงถึงขณะทํางานกับเว็บไซต์หรือแอปพลิเคชัน
- ลําดับแท็บมีความเป็นตรรกะ
- โฟกัสได้รับการจัดการและแสดงอย่างถูกต้อง
- องค์ประกอบแบบอินเทอร์แอกทีฟรองรับแป้นพิมพ์
- ใช้บทบาทและแอตทริบิวต์ ARIA ตามที่จำเป็น
- ติดป้ายกำกับองค์ประกอบอย่างถูกต้อง
- การทดสอบเป็นแบบอัตโนมัติ
ลําดับแท็บตามตรรกะ
องค์ประกอบแบบเนทีฟ เช่น input
, button
และ select
จะเลือกใช้ลําดับแท็บได้ฟรีและสามารถโฟกัสด้วยแป้นพิมพ์โดยอัตโนมัติ แต่องค์ประกอบบางอย่างอาจไม่มีลักษณะการทำงานแบบเดียวกันนี้ โดยเฉพาะอย่างยิ่ง องค์ประกอบทั่วไป เช่น div
และ span
จะไม่เลือกใช้ลําดับแท็บ ซึ่งหมายความว่าหากคุณใช้ div
เพื่อสร้างการควบคุมแบบอินเทอร์แอกทีฟ คุณจะต้องดำเนินการเพิ่มเติมเพื่อให้เข้าถึงด้วยแป้นพิมพ์ได้
2 ตัวเลือก ได้แก่
- ตั้งชื่อตัวควบคุมเป็น
tabindex="0"
วิธีนี้จะทำให้โฟกัสได้อย่างน้อย แม้ว่าคุณอาจต้องดำเนินการเพิ่มเติมเพื่อเพิ่มการรองรับการกดแป้นพิมพ์ - หากเป็นไปได้ ให้พิจารณาใช้
button
แทนdiv
หรือspan
สำหรับการควบคุมที่มีลักษณะคล้ายปุ่ม องค์ประกอบbutton
เนทีฟมีการปรับแต่งได้ง่ายมากและรองรับแป้นพิมพ์โดยไม่มีค่าใช้จ่าย
การจัดการโฟกัส
เมื่อคุณเปลี่ยนเนื้อหาของหน้า สิ่งสำคัญคือการดึงดูดความสนใจของผู้ใช้โดยย้ายโฟกัส ตัวอย่างคลาสสิกของกรณีที่เทคนิคนี้มีประโยชน์คือการเปิดกล่องโต้ตอบแบบโมดอล หากผู้ใช้ที่อาศัยแป้นพิมพ์กดปุ่มเพื่อเปิดกล่องโต้ตอบและโฟกัสไม่ย้ายไปยังองค์ประกอบกล่องโต้ตอบ การดำเนินการเดียวที่ทำได้คือกด Tab ไปยังส่วนต่างๆ ของเว็บไซต์จนกว่าจะพบตัวควบคุมใหม่ การย้ายโฟกัสไปยังเนื้อหาใหม่ทันทีที่ปรากฏจะช่วยให้ประสบการณ์ของผู้ใช้เหล่านี้มีประสิทธิภาพมากขึ้น
การรองรับแป้นพิมพ์สําหรับองค์ประกอบแบบอินเทอร์แอกทีฟ
หากกำลังสร้างการควบคุมที่กําหนดเอง เช่น ภาพสไลด์หรือเมนูแบบเลื่อนลง คุณจะต้องทํางานเพิ่มเติมเพื่อเพิ่มการรองรับแป้นพิมพ์ คำแนะนำแนวทางปฏิบัติด้านการเขียน ARIA เป็นแหล่งข้อมูลที่มีประโยชน์ซึ่งระบุรูปแบบ UI ต่างๆ และประเภทของการดำเนินการด้วยแป้นพิมพ์ที่ควรรองรับ

ดูข้อมูลเพิ่มเติมเกี่ยวกับการเพิ่มการรองรับแป้นพิมพ์ให้กับองค์ประกอบได้ที่ส่วน roving tabindex ในเอกสารพื้นฐานเกี่ยวกับการช่วยเหลือพิเศษของ Google
ใช้บทบาทและแอตทริบิวต์ ARIA ตามที่จำเป็น
การควบคุมที่กำหนดเองไม่เพียงต้องได้รับการรองรับแป้นพิมพ์อย่างเหมาะสมเท่านั้น แต่ยังต้องมีความหมายที่เหมาะสมด้วย ท้ายที่สุดแล้ว div
ในแง่ความหมายก็คือคอนเทนเนอร์การจัดกลุ่มทั่วไป หากใช้ div
เป็นพื้นฐานของเมนูแบบเลื่อนลง คุณจะต้องอาศัย ARIA เพื่อเพิ่มความหมายเพิ่มเติมเพื่อให้เทคโนโลยีความช่วยเหลือพิเศษส่งต่อประเภทการควบคุมได้ ในกรณีนี้ คำแนะนำแนวทางปฏิบัติด้านการเขียน ARIA จะช่วยระบุบทบาท สถานะ และพร็อพเพอร์ตี้ที่คุณควรใช้
นอกจากนี้ คำอธิบายจำนวนมากในคู่มือ ARIA ยังมีโค้ดตัวอย่างให้ด้วย
องค์ประกอบการติดป้ายกำกับ
สำหรับการติดป้ายกำกับอินพุตเนทีฟ คุณสามารถใช้องค์ประกอบ <label>
ในตัวตามที่อธิบายไว้ใน MDN ซึ่งไม่เพียงช่วยให้คุณสร้างการสื่อความหมายด้วยภาพบนหน้าจอเท่านั้น แต่ยังตั้งชื่อที่เข้าถึงได้ให้กับอินพุตในต้นไม้การช่วยเหลือพิเศษด้วย จากนั้นเทคโนโลยีความช่วยเหลือพิเศษ (เช่น โปรแกรมอ่านหน้าจอ) จะรับชื่อนี้ไปอ่านออกเสียงให้ผู้ใช้ฟัง
ขออภัย <label>
ไม่รองรับการตั้งชื่อที่เข้าถึงได้ให้กับการควบคุมที่กำหนดเอง (เช่น การควบคุมที่สร้างโดยใช้องค์ประกอบที่กำหนดเองหรือจาก div และ span ธรรมดา) สำหรับการควบคุมประเภทเหล่านี้ คุณจะต้องใช้แอตทริบิวต์ aria-label
และ aria-labelledby
การทดสอบอัตโนมัติ
การขี้เกียจอาจเป็นเรื่องที่ดี โดยเฉพาะเมื่อพูดถึงการทดสอบ พยายามทำให้การทดสอบการช่วยเหลือพิเศษเป็นแบบอัตโนมัติทุกครั้งที่ทำได้ เพื่อที่คุณจะได้ไม่ต้องทำทุกอย่างด้วยตนเอง ปัจจุบันมีเครื่องมือทดสอบที่ยอดเยี่ยมมากมายในอุตสาหกรรมที่จะช่วยให้คุณตรวจสอบปัญหาการช่วยเหลือพิเศษที่พบได้ทั่วไปได้อย่างรวดเร็วและง่ายดาย ดังนี้
aXe ที่พัฒนาโดย Deque Systems มีให้บริการเป็นส่วนขยาย Chrome และโมดูล Node (เหมาะสำหรับสภาพแวดล้อมการผสานรวมแบบต่อเนื่อง) A11ycast สั้นๆ นี้อธิบายวิธีต่างๆ ในการใช้ aXe กับกระบวนการพัฒนา
Lighthouse เป็นโปรเจ็กต์โอเพนซอร์สของ Google สำหรับการตรวจสอบประสิทธิภาพของ Progressive Web App นอกจากการตรวจสอบว่า PWA รองรับสิ่งต่างๆ เช่น Service Worker และ Web App Manifest หรือไม่แล้ว Lighthouse จะทำการทดสอบแนวทางปฏิบัติแนะนำต่างๆ รวมถึงการทดสอบปัญหาการช่วยเหลือพิเศษด้วย
บทสรุป
การช่วยเหลือพิเศษเป็นงานที่ต้องทำกันเป็นทีม ทุกคนต่างก็มีบทบาทสำคัญ คู่มือนี้ระบุหัวข้อสำคัญ 2-3 ข้อที่สมาชิกแต่ละคนของทีมสามารถใช้เพื่อทบทวนข้อมูลเกี่ยวกับเรื่องนี้อย่างรวดเร็ว และหวังว่าจะช่วยปรับปรุงประสบการณ์การใช้งานโดยรวมของแอป
หากต้องการดูข้อมูลเพิ่มเติมเกี่ยวกับการช่วยเหลือพิเศษ โปรดดูหลักสูตร Udacity ฟรีและเรียกดูเอกสารการช่วยเหลือพิเศษที่มีอยู่ใน web.dev