เหตุใดการเข้าถึงและการยินยอมจึงทับซ้อนกันในปัจจุบัน

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

ในด้านการเข้าถึง กฎหมายการเข้าถึงของยุโรป (EAA) ที่ถ่ายโอนเป็นกฎหมายระดับชาติทั่วประเทศสมาชิก EU ทำให้ WCAG 2.1 AA เป็นข้อกำหนดขั้นต่ำสำหรับเว็บไซต์และแอปของภาคเอกชนที่ให้บริการผู้บริโภค ระบบโทษแตกต่างกันตามประเทศ แต่โดยทั่วไปอยู่ในช่วง €50,000 ถึง €500,000 ต่อการละเมิด บวกกับคำสั่งถอนออกจากตลาดสำหรับการไม่ปฏิบัติตามอย่างต่อเนื่อง

ข้อกำหนด WCAG หลักสำหรับแบนเนอร์คุกกี้

การใช้งานแป้นพิมพ์

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

การดักจับโฟกัสในแบนเนอร์โมดัล

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

การประกาศของโปรแกรมอ่านหน้าจอ

แบนเนอร์ต้องประกาศเป็นกล่องโต้ตอบที่มีชื่อและบทบาทที่เข้าถึงได้ ใช้ role="dialog" หรือ role="alertdialog" พร้อม aria-labelledby ที่ชี้ไปยังหัวข้อแบนเนอร์ และ aria-describedby ที่ชี้ไปยังข้อความอธิบาย

ความเปรียบต่างของสี

ข้อความเนื้อหาต้องมีความเปรียบต่าง 4.5:1 เทียบกับพื้นหลัง ข้อความขนาดใหญ่ (18pt+ หรือ 14pt ตัวหนา) ต้องการ 3:1 ข้อความปุ่ม ไอคอน และตัวบ่งชี้โฟกัสมีค่าความเปรียบต่างขั้นต่ำของตัวเอง ปุ่ม "ปฏิเสธ" สีเทาอ่อนบนพื้นหลังสีขาวเป็นความล้มเหลว WCAG ที่พบบ่อยในการตรวจสอบ

ไม่มีสัญญาณที่ใช้สีเพียงอย่างเดียว

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

รูปแบบมืดและการเข้าถึง

WCAG 2.2 แนะนำเกณฑ์ใหม่ที่กำหนดเป้าหมายรูปแบบมืดโดยตรง — มีความเกี่ยวข้องเป็นพิเศษสำหรับการยินยอม:

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

RTL และการทำให้เป็นสากล

การเข้าถึงขยายไปยังภาษาที่เขียนจากขวาไปซ้าย (อาหรับ ฮีบรู เปอร์เซีย อูรดู) และการออกเสียงของโปรแกรมอ่านหน้าจอ:

• ตั้งค่า dir="rtl" บนแบนเนอร์ เมื่อภาษาของเอกสารเป็น RTL เพื่อให้ลำดับปุ่มและการไหลของโฟกัสตรงกับทิศทางการอ่าน
• ใช้แอตทริบิวต์ lang ที่ถูกต้อง บนข้อความแบนเนอร์ที่แปลแล้วเพื่อให้โปรแกรมอ่านหน้าจอออกเสียงคำด้วยการออกเสียงที่ถูกต้อง
• สะท้อนไอคอนกราฟี — เครื่องหมายมุม ลูกศร และตัวบ่งชี้ความคืบหน้าควรพลิกสำหรับสถานที่ RTL

การทดสอบแบนเนอร์สำหรับการปฏิบัติตาม WCAG

อย่าพึ่งพาเครื่องมือเดียว รวมการสแกนอัตโนมัติกับการทดสอบเทคโนโลยีช่วยเหลือจริง:

• axe DevTools หรือ Lighthouse — จับความล้มเหลว WCAG ประมาณ 30-40% โดยอัตโนมัติ
• NVDA หรือ JAWS บน Windows, VoiceOver บน Mac/iOS, TalkBack บน Android — ทดสอบด้วยโปรแกรมอ่านหน้าจอจริง แบนเนอร์สามารถประกาศ นำทาง และปิดได้โดยใช้โปรแกรมอ่านหน้าจอเท่านั้นหรือไม่?
• การนำทางด้วยแป้นพิมพ์เท่านั้น — ถอดเมาส์ออก ถ้าคุณไม่สามารถยอมรับ ปฏิเสธ และจัดการการตั้งค่าได้ ผู้ใช้แป้นพิมพ์ก็ทำไม่ได้เช่นกัน
• การจำลองตาบอดสี — Chrome DevTools มีตัวจำลองความบกพร่องทางการมองเห็นในตัว ตรวจสอบว่ายอมรับและปฏิเสธสามารถแยกแยะได้ภายใต้ protanopia, deuteranopia และ tritanopia
• ซูมไปที่ 400% — WCAG กำหนดให้เนื้อหาต้องยังคงใช้งานได้ที่การซูม 400% โดยไม่ต้องเลื่อนในแนวนอน แบนเนอร์ที่มีตำแหน่งคงที่มักจะล้มเหลวในการทดสอบนี้

ความล้มเหลวในการเข้าถึงที่พบบ่อยที่เราเห็น

• ซ่อนปฏิเสธไว้หลังไอคอนฟันเฟือง — รูปแบบมืดบวกกับความล้มเหลวในการเข้าถึง (ไม่มีชื่อที่เข้าถึงได้บนปุ่มไอคอน)
• โฟกัสไม่เคยถึงแบนเนอร์ — แบนเนอร์ที่ดึงดูดความสนใจทางสายตาแต่ถูกข้ามในลำดับ Tab
• แบนเนอร์โมดัลที่ไม่มีการดักจับโฟกัส — ผู้ใช้สามารถกด Tab เข้าสู่หน้าพื้นหลังในขณะที่แบนเนอร์อ้างว่าบล็อกการโต้ตอบ
• ไม่มี aria-live บนการเปลี่ยนแปลงการตั้งค่า — ผู้ใช้โปรแกรมอ่านหน้าจอไม่ได้ยินการยืนยันว่าตัวเลือกของพวกเขาถูกบันทึก
• แบนเนอร์ที่แปลแล้วโดยไม่มีแอตทริบิวต์ lang — โปรแกรมอ่านหน้าจอออกเสียงข้อความภาษาสเปนด้วยการออกเสียงภาษาอังกฤษ

วิธีที่ FlexyConsent มอบการเข้าถึง