รูปแบบ คอมโพเนนต์ และระบบการออกแบบ

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

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

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

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

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

คิดอย่างมีวิจารณญาณ

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

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

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

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

แหล่งข้อมูลที่เป็นที่ยอมรับ

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

แหล่งข้อมูลที่ยอดเยี่ยมสำหรับรูปแบบ คอมโพเนนต์ และระบบการออกแบบที่เข้าถึงได้มีดังนี้

สำหรับเฟรมเวิร์ก JavaScript แหล่งข้อมูลต่อไปนี้ค่อนข้างเข้าถึงได้ง่ายเมื่อนำมาใช้ใหม่หรือปรับแต่งค่าการช่วยเหลือพิเศษได้ง่าย

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

คุณควรมองว่าทรัพยากรทั้งหมดเป็นจุดเริ่มต้น อย่าลืมทดสอบทุกอย่าง

การรองรับเบราว์เซอร์และเทคโนโลยีความช่วยเหลือพิเศษ (AT)

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

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

โปรแกรมอ่านหน้าจอ ระบบปฏิบัติการ ความเข้ากันได้กับเบราว์เซอร์ ค่าใช้จ่าย
การเข้าถึงงานด้วยเสียงพูด (JAWS) Windows Chrome, Firefox, Edge ต้องมีใบอนุญาต (มีเวอร์ชันฟรี 40 นาที)
การเข้าถึงเดสก์ท็อปที่ไม่ใช่ภาพ (NVDA) Windows Chrome และ Firefox ฟรี (ต้องดาวน์โหลด)
Narrator Windows Edge ฟรี (ติดตั้งมาในเครื่อง Windows)
VoiceOver macOS Safari ฟรี (ติดตั้งมาในเครื่อง macOS)
วาฬเพชฌฆาต Linux Firefox ฟรี (รวมอยู่ในระบบดิสทริบิวชัน Gnome)
TalkBack Android Chrome และ Firefox ฟรี (มีอยู่แล้วในระบบปฏิบัติการ Android บางเวอร์ชัน)
VoiceOver iOS Safari ฟรี (ติดตั้งมาในอุปกรณ์ iOS)

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

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

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

ข้อควรพิจารณาอื่นๆ

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

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

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

มีข้อควรพิจารณาเพิ่มเติมที่ต้องชั่งน้ำหนักเมื่อเลือกลาย คอมโพเนนต์ หรือระบบการออกแบบ อย่างเช่น

  • การแสดง
  • ความปลอดภัย
  • บริการปรับแต่งเว็บไซต์ให้ติดอันดับบนเครื่องมือการค้นหา
  • การรองรับการแปลภาษา
  • การผสานรวมกับบุคคลที่สาม

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

ตรวจสอบความเข้าใจของคุณ

ทดสอบความรู้เกี่ยวกับรูปแบบ

ผู้ใช้ยังคงเข้าถึงคอมโพเนนต์ที่ช่วยเหลือพิเศษได้เสมอหรือไม่

ไม่ได้ คุณต้องทดสอบคอมโพเนนต์ก่อน
ได้ คุณสามารถใช้คอมโพเนนต์เหล่านี้โดยไม่ต้องดำเนินการเพิ่มเติม