ดี ดีกว่า ดีที่สุด: ไขโลกที่ซับซ้อนของรูปแบบที่เข้าถึงได้

Marc Benioff กล่าวไว้อย่างน่าจดจำว่าสิ่งเดียวที่คงที่ในอุตสาหกรรมเทคโนโลยีคือการเปลี่ยนแปลง หลังจากทำงานด้านเทคโนโลยีมากว่า 15 ปี ฉันสามารถยืนยันได้ เพื่อนไดโนเสาร์เทคโนโลยีสามารถยืนยันได้ว่าวิธีการทำงานของเว็บในยุคแรก ๆ นั้นแตกต่างอย่างมากจากที่พวกเราหลายคนจะจินตนาการได้

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

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

สิ่งที่เป็นเว็บที่พันกันเราสาน

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

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

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

ฉันจะรู้เรื่องนี้ได้อย่างไร ฉันใช้เวลาห้าปีที่ผ่านมาในการค้นคว้า สร้าง และทดสอบรูปแบบต่างๆ ที่เข้าถึงได้ในขณะที่ทำงานกับ A11y Style Guide, ARIA Pattern Library ของ Deque และประเมินรูปแบบ SVG ยอดนิยม แต่ฉันยังได้ตรวจสอบรูปแบบไคลเอนต์และไลบรารีมากมายในทุกเฟรมเวิร์ก/แพลตฟอร์มเท่าที่จะจินตนาการได้ ณ เวลานี้ ฉันสามารถพูดได้อย่างไม่มีข้อกังขาว่ามีลำดับชั้นโดยกำเนิดสำหรับการเข้าถึงรูปแบบที่เริ่มพัฒนาเมื่อคุณดูนานพอ และถึงแม้ว่าจะมีรูปแบบบางครั้งที่ต้องหลีกเลี่ยง แต่ก็ไม่ได้มีความชัดเจนเสมอไป เมื่อพูดถึงการช่วยสำหรับการเข้าถึง ฉันจะเถียงว่ารูปแบบส่วนใหญ่อยู่ในการไล่ระดับสีที่ดี ดีกว่า ดีที่สุด ส่วนที่ยากคือการรู้ว่ารูปแบบใดอยู่ในประเภทใด

การคิดอย่างมีวิจารณญาณเกี่ยวกับรูปแบบ

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

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

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

มีรูปแบบที่สามารถเข้าถึงได้อยู่แล้วหรือไม่?

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

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

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

หมายเหตุ : แหล่งข้อมูลที่มีชื่อเสียงที่ยอดเยี่ยมบางแห่ง ได้แก่ Inclusive Components, Accessible Components และระบบการออกแบบ Gov.UK นอกเหนือจากรายการรูปแบบที่สามารถเข้าถึงได้ Smashing Magazine ที่เผยแพร่เมื่อเร็วๆ นี้ (รวมถึงรายการรูปแบบและไลบรารีโดยละเอียดเพิ่มเติมที่ส่วนท้ายของบทความ) .

เบราว์เซอร์และอุปกรณ์เทคโนโลยีอำนวยความสะดวก (AT) ใดที่เราสนับสนุน

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

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

มีข้อ จำกัด ด้านกรอบงานหรือการรวม / ปัจจัยอื่น ๆ ที่ต้องพิจารณาหรือไม่?

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

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

การประเมินรูปแบบการช่วยสำหรับการเข้าถึง

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

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

รูปแบบปุ่มที่เข้าถึงได้

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

ดี: role="button"

 <a role="button" href="[link]">Sign up</a>

ดีกว่า: <button>

 <button type="button">Sign up</button>

ดีที่สุด: <button> + visually hidden + aria-describedby

 <button type="button">Sign up</button> <span class="visually-hidden"> for our monthly newsletter</span>

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

แล้วทำไมรูปแบบ ARIA ถึงไม่อยู่ในหมวด "ดีกว่า" ARIA ไม่ได้ทำให้สามารถเข้าถึงได้มากขึ้นหรือ ไม่. ในกรณีเช่นนี้ ผู้เชี่ยวชาญด้านการช่วยการเข้าถึงมักจะท่องกฎข้อแรกของ ARIA — อย่าใช้ ARIA นี่เป็นวิธีพูดง่ายๆ ในการใช้องค์ประกอบ HTML ทุกครั้งที่ทำได้ ARIA นั้นทรงพลังจริง ๆ แต่ในมือคนผิด มันทำอันตรายได้มากกว่าผลดี อันที่จริง รายงาน WebAIM Million ระบุว่า “หน้าเว็บที่มี ARIA มีข้อผิดพลาดโดยเฉลี่ยมากกว่าหน้าที่ไม่มี ARIA 60%” ดังนั้น คุณต้องรู้ว่าคุณกำลังทำอะไรอยู่เมื่อใช้ ARIA

การประท้วงต่อต้านการใช้ ARIA ในสถานการณ์เช่นนี้อีกประการหนึ่งก็คือ ฟังก์ชันการทำงานของปุ่มที่เราต้องการจะต้องสร้างขึ้นสำหรับรูปแบบ role="button" ในขณะที่ฟังก์ชันนั้นได้รับการอบล่วงหน้าในองค์ประกอบ <button> เมื่อพิจารณาว่าองค์ประกอบ <button> ยังรองรับเบราว์เซอร์ได้ 100% และเป็นรูปแบบที่ใช้งานง่าย โดยจะล้ำหน้ากว่าเล็กน้อยในลำดับชั้นเมื่อประเมินสองรูปแบบแรก หวังว่าการเปรียบเทียบนี้จะช่วยให้ความเชื่อผิด ๆ ที่ว่าการเพิ่ม ARIA ทำให้รูปแบบสามารถเข้าถึงได้มากขึ้น — บ่อยครั้งสิ่งที่ตรงกันข้ามก็เป็นความจริง

รูปแบบปุ่มที่สามแสดงองค์ประกอบ <button> HTML ควบคู่ไปกับ aria-describedby ที่เชื่อมโยงกับองค์ประกอบ ID ที่ถูกซ่อนไว้ด้วย CSS แม้ว่ารูปแบบนี้จะซับซ้อนกว่าเล็กน้อย แต่ก็เพิ่มบริบทเข้าไปอีกมากโดยการสร้างความสัมพันธ์ระหว่างปุ่มและวัตถุประสงค์ เมื่อมีข้อสงสัย เมื่อใดก็ตามที่เราสามารถเพิ่มบริบทให้กับสถานการณ์ได้ยิ่งดี ดังนั้นเราสามารถสรุปได้ว่าหากเข้ารหัสอย่างถูกต้อง มันเป็นรูปแบบที่ดีที่สุดเมื่อเปรียบเทียบเฉพาะรูปแบบปุ่มเฉพาะเหล่านี้

รูปแบบลิงก์ตามบริบทที่เข้าถึงได้

รูปแบบกลุ่มที่สองที่เราจะตรวจสอบคือลิงก์ตามบริบท รูปแบบเหล่านี้ช่วยให้ข้อมูลแก่ผู้ใช้ AT มากกว่าที่ปรากฏบนหน้าจอ รูปแบบลิงก์แรกใช้ CSS เพื่อซ่อนข้อมูลบริบทเพิ่มเติมด้วยสายตา ในขณะที่รูปแบบลิงก์ที่สองและสามเพิ่มแอตทริบิวต์ ARIA ลงในการผสมผสาน: aria-labelledby และ aria-label ตามลำดับ

ดี: visually-hidden

 <p>“My mother always used to say: The older you get, the better you get, unless you're a banana.” — Rose (Betty White)<a href="[link]">Read More<span class="visually-hidden"> Golden Girl quotes</span></a></p>

ดีกว่า: visually-hidden + aria-labelledby

 <p>“I'm either going to get ice cream or commit a felony...I'll decide in the car.” — Blanche (Rue McClanahan)<a href="[link]" aria-labelledby="quote">Read More</a><span class="visually-hidden">Read more Golden Girl quotes</span></p>

ดีที่สุด: aria-label

 <p>“People waste their time pondering whether a glass is half empty or half full. Me, I just drink whatever's in the glass.” — Sophia (Estelle Getty)<a href="[link]" aria-label="Read more Golden Girls quotes">Read More</a></p>

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

รูปแบบลิงก์สองรูปแบบถัดไปจะประเมินได้ยากกว่าเล็กน้อย ตามข้อกำหนดของ ARIA จาก W3C “จุดประสงค์ของ aria-label นั้นเหมือนกับของ aria-labelledby มันให้ชื่อผู้ใช้ที่รู้จักของวัตถุแก่ผู้ใช้” ดังนั้น ตามทฤษฎีแล้ว คุณลักษณะทั้งสองควรมีฟังก์ชันพื้นฐานเหมือนกัน

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

ดีไม่เร็วนัก ข้อกำหนดเดียวกันของ ARIA กล่าวต่อไปว่า “หากอินเทอร์เฟซนั้นไม่สามารถมีป้ายกำกับที่มองเห็นได้บนหน้าจอ (หรือหากฉลากที่มองเห็นได้ไม่ใช่ประสบการณ์ของผู้ใช้ที่ต้องการ) ผู้เขียน ควร ใช้ aria-label และ ไม่ควร ใช้ aria-labelledby ” พูดถึงเรื่องสับสน — แล้วเราควรเลือกรูปแบบไหน?

หากเราต้องการการแปลในวงกว้าง เราอาจตัดสินใจเปลี่ยนมุมมองและเขียนลิงก์โดยแสดงบริบททั้งหมด (เช่น “ อ่านเพิ่มเติมเกี่ยวกับสิ่งที่ ยอดเยี่ยมนี้”) หรือตัดสินใจใช้ aria-labelledby อย่างไรก็ตาม สมมติว่าเราไม่มีความต้องการการแปลขนาดใหญ่หรือสามารถตอบสนองความต้องการเหล่านั้นได้อย่างสมเหตุสมผล/เข้าถึงได้ และเราไม่ต้องการเปลี่ยนภาพ — แล้วอะไรล่ะ

ตามคำแนะนำ ARIA 1.1 ปัจจุบัน (พร้อมคำแปลของ aria-label ใน ARIA 1.2) บวกกับข้อเท็จจริงที่ว่า aria-label นั้นง่ายกว่าเล็กน้อยสำหรับ devs ที่จะนำไปใช้เมื่อเทียบกับ aria-labelledby เราสามารถตัดสินใจเพิ่มน้ำหนัก aria-label ได้ aria-labelledby ในการประเมินรูปแบบของเรา นี่เป็นตัวอย่างที่ชัดเจนเมื่อบริบทมีน้ำหนักมากในตัวเลือกรูปแบบที่เข้าถึงได้ของเรา

รูปแบบ <svg> เข้าถึงได้

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

สมมติว่ารูปแบบ SVG ต่อไปนี้เป็นการให้ข้อมูลโดยธรรมชาติ จะมีการรวม role="img" ไว้ในแต่ละรูปแบบ รูปแบบ SVG แรกใช้ <title> และ <text> ร่วมกับ CSS เพื่อซ่อนเนื้อหาจากผู้ใช้ที่มองเห็น รูปแบบ SVG สองรูปแบบถัดไปเกี่ยวข้องกับองค์ประกอบ <title> และ <desc> แต่มีแอตทริบิวต์ aria-labelledby ที่เพิ่มลงในรูปแบบสุดท้าย

ดี: role="img" + <title> + <text>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The first little pig built a house out of straw.</title> <text class="visually-hidden">Sadly, he was eaten by the wolf.</text>... </svg>

ดีกว่า: role="img" + <title> + <desc>

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The second little pig built a house out of sticks.</title> <desc>Sadly, he too was eaten by the big, bad wolf.</desc>... </svg>

ดีที่สุด: role="img" + <title> + <desc> + aria-labelledby="[id]"

 <svg xmlns="https://www.w3.org/2000/svg" xmlns:xlink="https://www.w3.org/1999/xlink" version="1.1" role="img" aria-labelledby="pig3house pig3wolf" x="0px" y="0px" viewBox="0 0 511.997 511.997" xml:space="preserve"> <title>The third little pig built a house out of bricks.</title> <desc>Thankfully he wasn't eaten by the wolf.</desc>... </svg>

มาดูรูปแบบแรกกันก่อนโดยใช้ <title> และ <text> และ CSS ที่มองเห็นได้ ไม่เหมือนกับข้อความที่ซ่อนไว้อย่างเห็นได้ชัดในรูปแบบก่อนหน้า นี้ มีความสัมพันธ์โดยธรรมชาติระหว่างองค์ประกอบ <title> และ <text> เนื่องจากถูกจัดกลุ่มภายใต้กลุ่มองค์ประกอบ SVG เดียวกัน อย่างไรก็ตาม ความสัมพันธ์นี้ไม่ได้แข็งแกร่งมาก ที่จริงแล้ว หากคุณมองย้อนกลับไปที่งานวิจัยของฉันเกี่ยวกับรูปแบบ SVG เราจะเห็นว่ามีเพียง 3 ใน 8 เบราว์เซอร์/AT เท่านั้นที่ได้ยินข้อความทั้งหมด (หมายเหตุ: ลายหมู #1 เทียบเท่ากับลายหลอดไฟ #7)

สิ่งนี้เป็นจริงแม้ว่าข้อกำหนด W3C SVG ที่ใช้งานได้จะกำหนดองค์ประกอบ <text> เป็น "องค์ประกอบกราฟิกที่ประกอบด้วยข้อความ...อักขระที่จะวาดจะแสดงเป็นข้อมูลอักขระ ด้วยเหตุนี้ ข้อมูลข้อความในเนื้อหา SVG จึงสามารถเข้าถึงได้โดยง่ายสำหรับผู้พิการทางสายตา” รูปแบบแรกนี้ใช้ได้ แต่เราสามารถทำได้ดีกว่านี้

รูปแบบที่สองลบองค์ประกอบ <text> และแทนที่ด้วยองค์ประกอบ <desc> สถานะข้อมูลจำเพาะของ W3C SVG:

“องค์ประกอบย่อย <title> แสดงถึงทางเลือกข้อความสั้นสำหรับองค์ประกอบ... และองค์ประกอบ <desc> แสดงถึงข้อมูลที่เป็นข้อความที่มีรายละเอียดมากขึ้นสำหรับองค์ประกอบ เช่น คำอธิบาย”

ความหมาย <title> และ <desc> องค์ประกอบใน SVG สามารถใช้ในลักษณะเดียวกับข้อความแสดงแทนรูปภาพและตัวเลือกคำอธิบายแบบยาวที่พบในองค์ประกอบ <img> หลังจากเพิ่มองค์ประกอบ <desc> ลงใน SVG ที่สอง เราจะเห็นการรองรับเบราว์เซอร์/AT ที่คล้ายกันโดยมีชุดค่าผสม 3 ใน 8 ชุดที่ได้ยินข้อความทั้งหมด (หมายเหตุ: รูปแบบหมู #2 เทียบเท่ากับรูปแบบหลอดไฟ #10) แม้ว่าผลการทดสอบเหล่านี้ดูเหมือนจะสะท้อนรูปแบบแรก เหตุผลที่รูปแบบนี้ชนในหมวด "ดีกว่า" ก็คือการใช้โค้ด- ง่ายกว่าเล็กน้อย อย่างชาญฉลาดและส่งผลกระทบต่อผู้ใช้ AT มากขึ้น เนื่องจากทำงานบน JAWS, เดสก์ท็อป VoiceOver และ VoiceOver บนมือถือ ในขณะที่รูปแบบแรกรองรับเบราว์เซอร์/AT ที่ได้รับความนิยมน้อยกว่า

รูปแบบที่สามใช้องค์ประกอบ <title> และ <desc> อีกครั้ง แต่ตอนนี้มี aria-labelledby plus ID ที่เพิ่มลงในส่วนผสม จากการทดสอบ SVG เดียวกัน การเพิ่มโค้ดเพิ่มเติมนี้หมายความว่าเราสามารถรองรับการผสมผสานเบราว์เซอร์/AT ได้ 7 ใน 8 ตัว (หมายเหตุ: รูปแบบหมู #3 เทียบเท่ากับรูปแบบหลอดไฟ #11) จากรูปแบบ SVG สามรูปแบบ รูปแบบที่สามนี้ "ดีที่สุด" เนื่องจากรองรับอุปกรณ์ AT ส่วนใหญ่ แต่รูปแบบนี้มีข้อเสียเปรียบในการใช้เบราว์เซอร์/AT ผสมกัน; คุณจะได้ยินชื่อรูปภาพ/เนื้อหาคำอธิบายที่ซ้ำกันสำหรับรูปแบบนี้ ในขณะที่อาจสร้างความรำคาญให้กับผู้ใช้ แต่โดยทั่วไปแล้ว การได้ยินเนื้อหาที่ซ้ำกันนั้นดีกว่าการไม่ได้ยินเลย

ปิดความคิด

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

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

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

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

แหล่งข้อมูลที่เกี่ยวข้อง

เครื่องมือ

• การสนับสนุนการช่วยสำหรับการเข้าถึง, Michael Fairchild, a11ysupport.io
• การช่วยการเข้าถึง HTML5, Steve Faulkner

ไลบรารีรูปแบบ

• โครงการการช่วยเหลือพิเศษ
• คู่มือรูปแบบการช่วยการเข้าถึง
• ส่วนประกอบที่สามารถเข้าถึงได้ Scott O'Hara
• ปลั๊กอินเรียงลำดับรายการ drag-and-drop เข้าถึงได้ Harris Schneiderman
• ห้องสมุดรูปแบบ ARIA ของ Deque
• ไลบรารี React ที่เข้าถึงได้ของ Deque
• ระบบออกแบบ GOV.UK
• รวมส่วนประกอบ Heydon Pickering
• ระบบออกแบบเว็บไซต์ของสหรัฐอเมริกา (USWDS)
• บทช่วยสอนการเข้าถึงเว็บ