إمكانية الوصول إلى موافقة ملفات تعريف الارتباط: الامتثال لـ WCAG 2.2 لأشرطة الموافقة
شريط ملفات تعريف الارتباط الذي لا يستطيع مستخدمو لوحة المفاتيح رفضه، ولا يستطيع قراء الشاشة الإعلان عنه، أو لا يستطيع الزوار المصابون بعمى الألوان قراءته، ليس مجرد تجربة مستخدم سيئة — بل هو إخفاق في الامتثال على جبهتين. منذ أن دخل قانون إمكانية الوصول الأوروبي حيز التنفيذ في يونيو 2025، يجب أن تستوفي واجهات الموافقة على مواقع الويب التجارية التي تخدم مستخدمي الاتحاد الأوروبي معايير WCAG 2.1 المستوى AA، مع التوصية بشدة بـ WCAG 2.2 لعام 2026. إلى جانب اشتراط GDPR بأن تكون الموافقة "طوعية وخاصة ومستنيرة وغير غامضة"، أصبحت الأشرطة غير القابلة للوصول تحمل الآن تعرضًا قانونيًا مزدوجًا. يشرح هذا الدليل بالضبط ما يبدو عليه شريط ملفات تعريف الارتباط المتوافق مع WCAG في 2026.
لماذا تتداخل إمكانية الوصول والموافقة الآن
يشترط GDPR أن تكون الموافقة قابلة للحصول من كل مستخدم، وليس فقط أولئك الذين يستطيعون رؤية شريط الموافقة والنقر عليه. وقد أوضح المجلس الأوروبي لحماية البيانات أنه إذا لم يتمكن صاحب البيانات من التفاعل بشكل مفيد مع واجهة الموافقة — بسبب إعاقة لم يستوعبها الموقع — فلن تُعدّ الموافقة صالحة. وهذا يعني أن ملفات تعريف الارتباط لم يكن ينبغي تحميلها في المقام الأول.
على صعيد إمكانية الوصول، يجعل قانون إمكانية الوصول الأوروبي (EAA) المُدرَج في القانون الوطني عبر الدول الأعضاء في الاتحاد الأوروبي معايير WCAG 2.1 AA الحد الأدنى لمواقع الويب والتطبيقات في القطاع الخاص التي تقدم خدمات المستهلكين. يتفاوت نظام العقوبات بحسب البلد لكنه يتراوح عادةً بين 50,000 يورو و500,000 يورو لكل مخالفة، إضافةً إلى أوامر سحب السوق في حالات عدم الامتثال المستمر.
متطلبات WCAG الأساسية لأشرطة ملفات تعريف الارتباط
إمكانية التشغيل بلوحة المفاتيح
يجب أن يكون كل عنصر تحكم في الشريط — القبول والرفض وإدارة التفضيلات والإغلاق — قابلاً للوصول والتشغيل بلوحة المفاتيح فقط. يجب أن يتمكن المستخدمون من التنقل بين الأزرار بترتيب منطقي باستخدام Tab وتفعيلها بـ Enter أو Space. يجب أن يكون التركيز مرئيًا بنسبة تباين لا تقل عن 3:1 مقارنةً بالخلفية.
تثبيت التركيز في الأشرطة المنبثقة
إذا حجب الشريط التفاعل مع بقية الصفحة، يجب تثبيت تركيز لوحة المفاتيح داخل الشريط حتى يتخذ المستخدم قراره. لا ينبغي للمستخدمين أن يتمكنوا من استخدام Tab للخروج من الشريط لتمرير الصفحة الخلفية. عند تثبيت التركيز وإغلاق الشريط، يجب أن يعود التركيز إلى العنصر الذي أثار الشريط أو إلى قيمة افتراضية معقولة.
إعلانات قارئ الشاشة
يجب الإعلان عن الشريط كمربع حوار باسم وdور قابل للوصول. استخدم 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 — يكتشف تلقائيًا ما يقارب 30-40% من إخفاقات WCAG.
- NVDA أو JAWS على Windows، وVoiceOver على Mac/iOS، وTalkBack على Android — اختبر مع قراء شاشة فعليين. هل يمكن الإعلان عن الشريط والتنقل فيه ورفضه باستخدام قارئ الشاشة فقط؟
- التنقل بلوحة المفاتيح فقط — افصل الفأرة. إذا لم تستطع القبول والرفض وإدارة التفضيلات، فمستخدمو لوحة المفاتيح أيضًا لن يستطيعوا ذلك.
- محاكاة عمى الألوان — يحتوي Chrome DevTools على محاكيات مدمجة لضعف البصر. تحقق من إمكانية التمييز بين القبول والرفض في ظل البروتانوبيا والديوتيرانوبيا والتريتانوبيا.
- تكبير إلى 400% — تشترط WCAG أن يظل المحتوى قابلاً للاستخدام عند 400% تكبير دون تمرير أفقي. كثيرًا ما تفشل الأشرطة ذات الموضع الثابت في هذا الاختبار.
أخطاء إمكانية الوصول الشائعة التي نراها
- إخفاء الرفض خلف أيقونة ترس — نمط مظلم وإخفاق في إمكانية الوصول (لا يوجد اسم قابل للوصول على زر الأيقونة).
- التركيز لا يصل إلى الشريط أبدًا — أشرطة تسرق الانتباه البصري لكنها تُتخطى في ترتيب Tab.
- شريط منبثق بدون تثبيت تركيز — يمكن للمستخدمين استخدام Tab للدخول إلى الصفحة الخلفية بينما يدّعي الشريط حجب التفاعل.
- لا يوجد aria-live على تغييرات التفضيلات — لا يسمع مستخدمو قارئ الشاشة تأكيدًا بأن اختيارهم قد حُفظ.
- أشرطة مترجمة بدون سمة lang — قراء الشاشة ينطقون النص الإسباني بصوتيات إنجليزية.
كيف يوفر FlexyConsent إمكانية الوصول
FlexyConsent يستوفي WCAG 2.2 AA بشكل افتراضي:
- جميع عناصر التحكم قابلة للتشغيل بلوحة المفاتيح مع مؤشرات تركيز مرئية بنسبة 3:1.
- الاستخدام الصحيح لـ role="dialog" مع aria-labelledby وaria-describedby.
- تثبيت التركيز مع Escape للإغلاق للأشرطة الاختيارية.
- تباين 4.5:1 أو أكثر على كل عنصر نصي، بما في ذلك الرفض.
- انعكاس تلقائي لـ RTL لمناطق اللغة العربية والعبرية والفارسية والأردية.
- سمة lang مُعيَّنة لكل ترجمة لنطق صحيح بقارئ الشاشة.
- تخطيط متحمل للتكبير يظل قابلاً للاستخدام عند 400%.