لافتات الموافقة غير القابلة للوصول باتت تُنشئ التزامين قانونيين، لا واحداً

منذ 28 يونيو 2025، لم تعد لافتة الموافقة التي لا يستطيع مستخدم لوحة المفاتيح التنقل فيها بالكامل مجرد إخفاق في إمكانية الوصول — بل أصبحت انتهاكاً لـ GDPR. دخل قانون إمكانية الوصول الأوروبي (EAA) حيز التنفيذ في كل الدول السبع والعشرين الأعضاء في الاتحاد الأوروبي في ذلك التاريخ، جاعلاً WCAG 2.2 المستوى AA المعيار القابل للتنفيذ قانونياً للخدمات الرقمية، بما في ذلك واجهات الموافقة التي تعتمد عليها أدوات التحليلات.

أصبح النظامان التنظيميان مرتبطين مباشرة الآن. أصلح أحدهما دون الآخر وستبقى عرضة للمساءلة.

ما يتطلبه EAA فعلياً

يرتبط EAA بالمعيار الأوروبي EN 301 549، الذي يشير بدوره إلى WCAG 2.2. أما المتطلبات الأهم عملياً لواجهات الموافقة فهي:

• عدم حجب التركيز (WCAG 2.4.11): عندما ينتقل المستخدم بمفتاح Tab إلى زر، يجب ألا يكون مخفياً كلياً خلف اللافتة نفسها أو رأس ثابت.
• إمكانية الوصول بلوحة المفاتيح (WCAG 2.1.1): كل عنصر تفاعلي — قبول، رفض، إدارة التفضيلات — يجب أن يكون قابلاً للوصول والتشغيل دون فأرة.
• مؤشرات تركيز مرئية (WCAG 2.4.7): يجب أن تكون حلقات التركيز مرئية. تُثبِّط كثير من منصات إدارة الموافقة أنماط التركيز الافتراضية للمتصفح لأسباب تجميلية، مما يفشل في هذا المعيار.
• تباين ألوان كافٍ (WCAG 1.4.3): يجب أن يحقق النص مقابل الخلفية نسبة 4.5:1 لنص المحتوى. روابط "رفض الكل" بلون رمادي باهت بجوار أزرار "قبول" زرقاء غامقة نمط فشل شائع.
• عدم الإغلاق التلقائي: لا يمكن أن تُغلق اللافتة دون تفاعل مستخدم صريح. القبول التلقائي بعد وقت محدد، حتى بعد عدة ثوانٍ، غير صالح.

تتفاوت العقوبات بحسب الدولة العضو. تفرض ألمانيا حتى 100,000 يورو لكل انتهاك. وتصعِّد إسبانيا إلى 1,000,000 يورو في الحالات الشديدة. وتجمع فرنسا بين الغرامات المالية واحتمال تعليق الخدمة غير الممتثلة.

لماذا تُبطل إخفاقات إمكانية الوصول موافقة GDPR

يتطلب الاعتبار 32 من GDPR أن تكون الموافقة "حرة ومحددة ومستنيرة ولا لبس فيها". وتضيف المادة 7 أن سحب الموافقة يجب أن يكون "سهلاً مثل منحها". تصمد هذه المتطلبات فقط إذا كان بوسع المستخدم فعلاً الوصول إلى واجهة الموافقة.

مستخدم قارئ شاشة لا يستطيع التنقل إلى زر "رفض" لا يستطيع منع الموافقة. الموافقة التي يُسجِّلها خط أنابيب التحليلات لذلك المستخدم لا معنى لها قانونياً — ليس لأنه رفضها، بل لأن الآلية لم تكن قابلة للوصول. بموجب GDPR، يُعدّ ذلك بمنزلة عدم موافقة على الإطلاق.

أوضحت CNIL هذا المنطق صراحةً في إجراء التنفيذ في سبتمبر 2025 ضد Google، حيث ترتبت غرامة قدرها 325 مليون يورو جزئياً على التصميم غير المتماثل — القبول يتطلب نقرة واحدة، والرفض يتطلب التنقل إلى شاشة إعدادات. أي تصميم يجعل الرفض أصعب هيكلياً من القبول، بما في ذلك لافتة لا يستطيع مستخدم لوحة المفاتيح تشغيلها بالكامل، يُقوِّض الصلاحية القانونية لكل سجل موافقة يُنتجه.

نتائج التدقيق ليست مشجعة

اختبارات مستقلة لمنصات إدارة الموافقة الواسعة الاستخدام في 2025 وجدت أنه ولا حل واحد من تلك التي فُحصت حقق الامتثال الكامل لـ WCAG 2.2 المستوى AA. وشملت الإخفاقات الشائعة مؤشرات تركيز مُثبَّطة، وتبايناً غير كافٍ على أزرار الإجراءات الثانوية، ووسم لافتة موضوعاً متأخراً في DOM — مما يجعل قارئات الشاشة تصادف محتوى الصفحة قبل واجهة الموافقة.

هذه ليست حالات هامشية. إنها السلوك الافتراضي للأدوات التي تنشرها عشرات الآلاف من المواقع لاستخدام التحليلات دون إجراء التحليل القانوني بأنفسها.

ما ستكلفك إياه لافتة ممتثلة من الناحية التشغيلية

افترض أنك أصلحت مشكلات إمكانية الوصول. لديك الآن لافتة يستطيع قارئ الشاشة التنقل فيها بالكامل، مع عناصر تحكم قابلة للوصول بلوحة المفاتيح، وتباين كافٍ، وبلا إغلاق تلقائي. لا تزال تواجه:

• فقدان البيانات بسبب الرفض: تُظهر الدراسات باستمرار أن 15-30% من الزوار إما يرفضون كوكيز التحليلات أو يُغلقون اللافتة دون تفاعل. هذه الفئة غير مرئية لتحليلاتك.
• تباين معدل الموافقة بحسب الجهاز: يُغلق مستخدمو الأجهزة المحمولة اللافتات بمعدلات أعلى من مستخدمي سطح المكتب. بيانات تحليلاتك متحيزة منهجياً نحو المستخدمين الذين قبلوا على سطح المكتب.
• الصيانة المستمرة: WCAG 2.2 قيد التطوير بالفعل نحو WCAG 3.0. كل تحديث لمنصة الموافقة لديك هو تراجع محتمل في الامتثال لإمكانية الوصول تحتاج إلى إعادة اختباره.

إصلاح اللافتة يعالج التعرض لـ EAA. لكنه لا يعالج مشكلة جودة البيانات.

البديل الهيكلي

التحليلات بلا كوكيز التي لا تمس الجهاز أبداً — لا كوكيز، ولا localStorage، ولا بصمات — لا تُفعِّل متطلبات موافقة PECR. لا حاجة لآلية موافقة، فلا توجد واجهة موافقة لتكون غير قابلة للوصول.

نهج تجزئة الزائر اليومية — SHA-256(IP + UA + SALT_SECRET + YYYY-MM-DD) — يعمل بالكامل من جهة الخادم عند الحافة، ولا يُنتج مُعرِّفاً دائماً، ولا يُخزِّن شيئاً على جهاز الزائر. لا تفاعل لـ WCAG لتحكمه ولا سجل موافقة لـ GDPR للتحقق منه.

هذا ليس حلاً بديلاً. إنه النتيجة التقنية لبناء نظام تحليلات لا يعالج فعلاً بيانات شخصية. حين لا يوجد شيء توافق عليه، تختفي آلية الموافقة وكل التزامات الامتثال الخاصة بها.

السؤالان الجديران بالطرح الآن

إن كان موقعك يُشغِّل التحليلات حالياً خلف لافتة موافقة، فإن سؤالين يُحدِّدان تعرضك:

1. Can a keyboard-only user reach the "Reject All" option in your banner
   without a mouse, with a visible focus indicator, on every browser
   you support?

2. If yes — what percentage of visitors reject or dismiss the banner,
   and how does your analytics account for that gap?

السؤال الأول هو سؤال EAA. والثاني هو سؤال جودة البيانات. لافتة موافقة ممتثلة يُغلقها 20% من الزوار لا تزال تترك لك نقطة عمياء بنسبة 20% تتراكم مع الوقت كلما اتُّخذت قراراتك بناءً على بيانات حركة غير مكتملة.

لا يطرح أي من السؤالين نفسه إن لم تكن هناك لافتة للتنقل فيها.