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

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

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

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

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

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

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

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

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

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

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

ทรัพยากรที่จัดตั้งขึ้น

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

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

• คอมโพเนนต์ที่เข้าถึงได้
• ไลบรารี ARIA ของ Deque University
• Gov.UK Design System
• คอมโพเนนต์ที่ครอบคลุม
• MagentaA11y
• ระบบการออกแบบเว็บไซต์ของสหรัฐอเมริกา (USWDS) ซึ่งสร้างขึ้นสำหรับรัฐบาลกลางของสหรัฐอเมริกา
• รายการรูปแบบที่เข้าถึงได้จาก Smashing Magazine

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

• เมื่อ CSS ไม่เพียงพอ: ข้อกำหนด JavaScript สำหรับคอมโพเนนต์ที่เข้าถึงได้
• แสดงความรู้สึก
  • ReachUI
  • Reakit
  • Chakra
• Angular: ไลบรารี Material
• Vue: Vuetensils

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ทดสอบความเข้าใจ

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