เมื่อ CSS ไม่เพียงพอ: ข้อกำหนด JavaScript สำหรับส่วนประกอบที่สามารถเข้าถึงได้

ในฐานะผู้เขียน ModernCSS.dev ฉันเป็นผู้สนับสนุนโซลูชัน CSS รายใหญ่ และฉันชอบที่จะเห็นวิธีที่ชาญฉลาดที่ผู้คนใช้ CSS สำหรับการออกแบบและการโต้ตอบที่แปลกใหม่! อย่างไรก็ตาม ฉันสังเกตเห็นแนวโน้มที่จะส่งเสริมองค์ประกอบ "CSS เท่านั้น" โดยใช้วิธีการเช่น "การแฮ็กช่องทำเครื่องหมาย" ขออภัย การแฮ็กในลักษณะนี้ทำให้ผู้ใช้จำนวนมากไม่สามารถใช้อินเทอร์เฟซของคุณได้

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

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

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

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

การพิจารณาว่า CSS เท่านั้นเป็นโซลูชันที่เหมาะสมหรือไม่

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

• นี้เพื่อความบันเทิงของคุณเอง?
  จากนั้นใช้ CSS อย่างเต็มที่ ผลักดันขอบเขต และเรียนรู้สิ่งที่ภาษาสามารถทำได้!
• คุณลักษณะนี้รวมถึงการแสดงและการซ่อนเนื้อหาหรือไม่
  จากนั้นคุณต้องใช้ JS เป็นอย่างน้อยสลับ aria และเพื่อเปิดใช้งานการปิด Esc สำหรับส่วนประกอบบางประเภทที่เปลี่ยนสถานะด้วย คุณอาจต้องแจ้งการเปลี่ยนแปลงด้วยการกระตุ้นการอัปเดตภายในภูมิภาคที่ใช้งานจริงของ ARIA
• ลำดับการโฟกัสที่เป็นธรรมชาติเหมาะสมที่สุดหรือไม่?
  หากลำดับตามธรรมชาติสูญเสียความสัมพันธ์ระหว่างทริกเกอร์และองค์ประกอบที่ทริกเกอร์ หรือผู้ใช้แป้นพิมพ์ไม่สามารถเข้าถึงเนื้อหาผ่านลำดับแท็บปกติได้ คุณจะต้องใช้ JS เพื่อช่วยในการจัดการโฟกัส
• ตัวควบคุมที่มีสไตล์ให้ข้อมูลที่ถูกต้องเกี่ยวกับฟังก์ชันการทำงานหรือไม่
  ผู้ใช้เทคโนโลยีอำนวยความสะดวก เช่น โปรแกรมอ่านหน้าจอ จะได้รับข้อมูลตามความหมายและ ARIA ที่ช่วยให้พวกเขาระบุได้ว่าตัวควบคุมทำหน้าที่อะไร และผู้ใช้การรู้จำคำพูดจะต้องสามารถระบุป้ายกำกับหรือประเภทของส่วนประกอบเพื่อกำหนดวลีเพื่อใช้ในการควบคุม ตัวอย่างเช่น หากองค์ประกอบของคุณมีรูปแบบเหมือนแท็บแต่ใช้ปุ่มตัวเลือกเพื่อ “ทำงาน” เหมือนกับแท็บ โปรแกรมอ่านหน้าจออาจได้ยิน “ปุ่มตัวเลือก” และผู้ใช้ที่เป็นคำพูดอาจพยายามใช้คำว่า “แท็บ” เพื่อใช้งาน ในกรณีเหล่านี้ คุณจะต้องใช้ JS เพื่อเปิดใช้งานโดยใช้การควบคุมและความหมายที่เหมาะสม เพื่อให้ได้ฟังก์ชันที่ต้องการ
• เอฟเฟกต์ขึ้นอยู่กับโฮเวอร์และ/หรือโฟกัสหรือไม่
  จากนั้นคุณอาจต้องใช้ JS เพื่อช่วยในโซลูชันทางเลือกเพื่อให้เข้าถึงเนื้อหาได้เท่าเทียมกันหรือเข้าถึงเนื้อหาโดยเฉพาะสำหรับผู้ใช้หน้าจอสัมผัสและผู้ใช้ที่ใช้การซูมเดสก์ท็อป 200%+ หรือซอฟต์แวร์ขยาย

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

เคล็ดลับเครื่องมือ

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

โซลูชัน CSS เท่านั้นที่นี่อาจดูเหมือนใช้ได้อย่างสมบูรณ์ และสามารถทำได้ด้วยบางสิ่งเช่น:

 <button class="tooltip-trigger">I have a tooltip</button> <span class="tooltip">Tooltip</span> .tooltip { display: none; } .tooltip-trigger:hover + .tooltip, .tooltip-trigger:focus + .tooltip { display: block; }

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

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

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

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

คำแนะนำสำหรับพฤติกรรมของคำแนะนำเครื่องมือมาจาก WCAG Success Criterion 1.4.13 — เนื้อหาบนโฮเวอร์หรือโฟกัส เกณฑ์นี้มีขึ้นเพื่อช่วยเหลือผู้ใช้ที่มีความบกพร่องทางสายตาและผู้ที่ใช้ซอฟต์แวร์ซูมและขยาย หลักการชี้นำสำหรับคำแนะนำเครื่องมือ (และเนื้อหาอื่นๆ ที่ปรากฏบนโฮเวอร์และโฟกัส) ได้แก่:

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

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

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

ทางเลือกอื่นสำหรับคำแนะนำเครื่องมือ

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

“เหตุใดฉันจึงเพิ่มข้อความนี้ใน UI มันจะไปไหนได้อีก”

— Sarah Higley จากการนำเสนอ “Tooltips: Investigation Into Four Parts”

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

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

สำหรับข้อมูลเพิ่มเติม โปรดดูการนำเสนอของ Sarah บน YouTube รวมถึงบทความที่ครอบคลุมเกี่ยวกับคำแนะนำเครื่องมือ หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับคำแนะนำเครื่องมือเทียบกับคำแนะนำสลับและข้อมูลเพิ่มเติมอีกเล็กน้อยเกี่ยวกับสาเหตุที่ไม่ใช้ title ให้อ่านบทความของ Heydon Pickering จากส่วนประกอบที่รวม: เคล็ดลับเครื่องมือและ Toggletips

Modals

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

ฉันได้เห็นรูปแบบเฉพาะของ CSS สองสามรูปแบบแล้ว (และมีความผิดในการสร้างรูปแบบสำหรับพอร์ตโฟลิโอรุ่นเก่าของฉัน) พวกเขาอาจใช้ "การแฮ็กช่องทำเครื่องหมาย" ใช้ประโยชน์จากพฤติกรรมของ :target หรือพยายามทำให้เป็น :focus (ซึ่งน่าจะเป็นคำแนะนำเครื่องมือขนาดใหญ่เกินจริงในการปลอมตัว)

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

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

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

นี่คือ ลำดับของเหตุการณ์ที่เกี่ยวข้องกับโมดอล ที่ต้องจัดการด้วย JavaScript:

1. ฟังเหตุการณ์บนปุ่มเปิดโมดอล
2. โฟกัสถูกวางไว้ภายในกิริยา องค์ประกอบใดแตกต่างกันไปตามเนื้อหาที่เป็นกิริยาช่วย (ดูแผนผังการตัดสินใจ)
3. โฟกัสติดอยู่ภายในกิริยาจนกว่าจะถูกละทิ้ง
4. โดยเฉพาะอย่างยิ่ง ผู้ใช้สามารถปิดโมดอลด้วย ปุ่ม Esc เพิ่มเติมจากปุ่มปิดเฉพาะ หรือ การทำงานของปุ่มทำลายล้าง เช่น “ยกเลิก” หากจำเป็นต้องรับทราบเนื้อหาที่เป็นโมดอล
   1. หากอนุญาตให้ใช้ Esc การคลิกที่ฉากหลังที่เป็นโมดอลควรยกเลิกโมดอลด้วย
5. เมื่อเลิกใช้ หากไม่มีการนำทางเกิดขึ้น โฟกัสจะกลับไปที่องค์ประกอบปุ่มทริกเกอร์

แผนผังการตัดสินใจโฟกัสแบบโมดอล

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

• หัวเรื่องหลักของโมดอลคือรูปแบบ
  โฟกัสฟิลด์ฟอร์มแรก
• เนื้อหาที่เป็นโมดอลนั้นมีความยาวมากและผลักการกระทำกิริยาออกไปให้พ้นสายตา
  เน้นหัวข้อถ้ามีหรือย่อหน้าแรก
• วัตถุประสงค์ของโมดอลเป็นขั้นตอน (ตัวอย่าง: การยืนยันการกระทำ) พร้อมการดำเนินการที่มีอยู่หลายรายการ
  มุ่งเน้นไปที่การดำเนินการ "ทำลายน้อยที่สุด" ตามบริบท (ตัวอย่าง: "ตกลง")
• วัตถุประสงค์ของโมดอลเป็นขั้นตอนเดียว
  โฟกัสที่องค์ประกอบที่โฟกัสได้ตัวแรก

เคล็ดลับด่วน : ในกรณีที่จำเป็นต้องโฟกัสองค์ประกอบที่ไม่สามารถโฟกัสได้ เช่น หัวเรื่องหรือย่อหน้า ให้เพิ่ม tabindex="-1" ซึ่งช่วยให้องค์ประกอบสามารถโฟกัสได้ด้วยโปรแกรมด้วย JS แต่ไม่เพิ่มลงในลำดับแท็บ DOM .

อ้างถึงการสาธิตโมดอล WAI-ARIA สำหรับข้อมูลเพิ่มเติมเกี่ยวกับข้อกำหนดอื่นๆ สำหรับการตั้งค่า ARIA และรายละเอียดเพิ่มเติมเกี่ยวกับวิธีเลือกองค์ประกอบที่จะเพิ่มโฟกัส การสาธิตยังรวมถึง JavaScript เพื่อแสดงตัวอย่างวิธีจัดการโฟกัส

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

แท็บ

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

นี่คือคุณสมบัติของแท็บที่ต้องใช้ JavaScript:

1. สลับแอตทริบิวต์ที่ aria-selected เป็น true สำหรับแท็บปัจจุบันและ false สำหรับแท็บที่ไม่ได้เลือก
2. การสร้างแท็บ เร่ร่อน เพื่อแยกการเลือกแท็บจากโฟกัส
3. ย้ายโฟกัสระหว่างแท็บโดยตอบสนองต่อเหตุการณ์แป้นลูกศร (และตัวเลือก Home และ End )

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

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

เกี่ยวกับการท่องเที่ยว tabindex

แนวคิดของเร่ร่อน tabindex คือค่าของค่า tabindex ถูกควบคุมโดยทางโปรแกรมเพื่อจัดการลำดับโฟกัสขององค์ประกอบ ในส่วนที่เกี่ยวกับแท็บ นี่หมายความว่าเฉพาะแท็บที่เลือกเท่านั้นที่เป็นส่วนหนึ่งของลำดับโฟกัสโดยการตั้งค่า tabindex="0" และแท็บที่ไม่ได้เลือกจะถูกตั้งค่าเป็น tabindex="-1" ซึ่งจะลบออกจากลำดับโฟกัสของแป้นพิมพ์ปกติ

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

ตัวอย่างรูปแบบแท็บ

ต่อไปนี้คือรูปแบบการอ้างอิงบางส่วนสำหรับการสร้างแท็บ:

• สาธิตแท็บจาก Deque University
• การทดสอบวิดเจ็ตแท็บจาก Scott O'Hara (ทดสอบรูปแบบการทำงานหลายรูปแบบ)
• อินเทอร์เฟซแบบแท็บจาก ส่วนประกอบแบบรวม ของ Heydon Pickering ซึ่งแสดงให้เห็นว่าแท็บสามารถปรับปรุงสารบัญแบบก้าวหน้าได้อย่างไร

ม้าหมุน

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

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

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

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

ต่อไปนี้คือข้อควรพิจารณาเกี่ยวกับ JavaScript ขึ้นอยู่กับคุณลักษณะภาพหมุนของคุณ:

• การใช้การควบคุมที่มีการแบ่งหน้า
  เมื่อเลือกรายการที่มีหมายเลขแล้ว ให้โฟกัสสไลด์ที่เกี่ยวข้องโดยทางโปรแกรม สิ่งนี้จะเกี่ยวข้องกับการตั้งค่าคอนเทนเนอร์สไลด์โดยใช้ roving tabindex เพื่อให้คุณสามารถโฟกัสที่สไลด์ปัจจุบัน แต่ป้องกันการเข้าถึงสไลด์นอกหน้าจอ
• ใช้เล่นอัตโนมัติ
  รวมการควบคุมการหยุดชั่วคราว และยังเปิดใช้งานการหยุดชั่วคราวเมื่อวางเมาส์เหนือสไลด์หรือองค์ประกอบแบบโต้ตอบภายในถูกโฟกัส นอกจากนี้ คุณสามารถตรวจสอบ prefers-reduced-motion ภายใน JavaScript เพื่อโหลดสไลด์โชว์ในสถานะหยุดชั่วคราวเพื่อให้สอดคล้องกับการตั้งค่าของผู้ใช้
• การใช้ตัวควบคุมก่อนหน้า/ถัดไป
  รวมองค์ประกอบที่มองเห็นได้ซึ่งถูกทำเครื่องหมายเป็น aria-live="polite" และเมื่อเปิดใช้งานการควบคุมเหล่านี้ ให้เติมข้อมูลในพื้นที่ที่มีการระบุตำแหน่งปัจจุบัน เช่น "สไลด์ 2 จาก 4"

แหล่งข้อมูลสำหรับการสร้าง Carousels ที่เข้าถึงได้

• รายละเอียดการใช้งานอย่างละเอียดและข้อควรพิจารณารวมถึงตัวอย่างโค้ดแบบเต็มจากบทช่วยสอนการเข้าถึงเว็บ W3C บนภาพหมุน
• ตัวอย่างของ Deque University ในการปรับปรุงส่วนต่อประสานแท็บให้เป็นภาพหมุน
• ตัวอย่าง WAI-ARIA Authoring Practices ของภาพหมุนอัตโนมัติ
• การเลือกทรัพยากรแบบหมุนในการสรุปส่วนประกอบที่เข้าถึงได้ของ Smashing

เมนูแบบเลื่อนลง

หมายถึงส่วนประกอบที่ปุ่มสลับเปิดรายการลิงก์ ซึ่งโดยทั่วไปใช้สำหรับเมนูการนำทาง การใช้งาน CSS ที่หยุดแสดงเมนูเมื่อ :hover หรือ :focus พลาดรายละเอียดที่สำคัญบางอย่างเท่านั้น

ฉันยอมรับ ฉันยังคิดว่าการใช้คุณสมบัติ :focus-within ที่ใหม่กว่า เราสามารถใช้โซลูชัน CSS เท่านั้นได้อย่างปลอดภัย คุณจะเห็นว่าบทความของฉันเกี่ยวกับเมนูดรอปดาวน์ CSS ได้รับการแก้ไขเพื่อรวมบันทึกและทรัพยากรใน JavaScript ที่จำเป็น (ฉันเก็บชื่อไว้เพื่อให้ผู้อื่นที่ค้นหาโซลูชันนั้นหวังว่าจะใช้งาน JS ให้เสร็จสมบูรณ์ด้วย) โดยเฉพาะอย่างยิ่ง การใช้ CSS เพียงอย่างเดียวหมายถึงการละเมิด WCAG Success Criterion 1.4.13: เนื้อหาบน Hover หรือ Focus ซึ่งเราได้เรียนรู้เกี่ยวกับคำแนะนำเครื่องมือ

เราจำเป็นต้องเพิ่มใน JavaScript สำหรับเทคนิคบางอย่างที่ควรฟังดูคุ้นเคย ณ จุดนี้:

• สลับ aria-expanded บนปุ่มเมนูระหว่าง true และ false โดยฟังเหตุการณ์การ click
• การปิดเมนูที่เปิดอยู่เมื่อใช้ ปุ่ม Esc และกลับโฟกัสไปที่ปุ่มสลับเมนู
• แนะนำให้ปิดเมนูที่เปิดอยู่เมื่อย้ายโฟกัสออกนอกเมนู
• ทางเลือก : ใช้ปุ่มลูกศรเช่นเดียวกับปุ่ม Home และปุ่ม End สำหรับการนำทางด้วยแป้นพิมพ์ระหว่างปุ่มสลับเมนูและลิงก์ภายในดรอปดาวน์

เคล็ดลับด่วน : ตรวจสอบให้แน่ใจว่าการใช้งานเมนูดรอปดาวน์ถูกต้องโดยเชื่อมโยงการแสดงเมนูกับตัวเลือกของ .dropdown-toggle[aria-expanded= " true " ] + .dropdown แทนที่จะใช้การแสดงเมนูตามการมีอยู่ของ JS- เพิ่มเติม เพิ่มคลาสเช่น active วิธีนี้จะช่วยขจัดความซับซ้อนบางอย่างออกจากโซลูชัน JS ของคุณด้วย!

ซึ่งเรียกอีกอย่างว่า "รูปแบบการเปิดเผย" และคุณสามารถดูรายละเอียดเพิ่มเติมได้ในเมนูการนำทางการเปิดเผยข้อมูลตัวอย่างของ WAI-ARIA Authoring Practices

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

• คู่มือฉบับสมบูรณ์ของ Smashing สำหรับส่วนประกอบ Front-End ที่เข้าถึงได้
• บทความของ Carie Fisher ดี ดีกว่า ดีที่สุด: แก้ปริศนาโลกแห่งรูปแบบที่เข้าถึงได้ที่ซับซ้อน
• การสาธิตและข้อมูลเกี่ยวกับรูปแบบการออกแบบทั่วไปและวิดเจ็ตจาก WAI-ARIA Authoring Practices 1.2
• ห้องสมุดรหัสของมหาวิทยาลัย Deque
• ส่วนประกอบที่เข้าถึงได้ของ Scott O'Hara
• ส่วนประกอบรวมของ Heydon Pickering