معايير نجاح WCAG · Level AAA
WCAG 2.3.2: ثلاث ومضات
تتطلب WCAG 2.3.2 ألا تحتوي صفحات الويب على أي محتوى يومض أكثر من ثلاث مرات في أي فترة مدتها ثانية واحدة، دون استثناء للومضات الصغيرة أو منخفضة التباين. يحمي هذا المعيار الأكثر صرامة من المستوى AAA المستخدمين المصابين بالصرع الحساس للضوء واضطرابات النوبات الأخرى من ردود الفعل العصبية التي قد تهدد الحياة.
ماذا يعني هذا المعيار
المعيار WCAG 2.3.2 Three Flashes هو معيار نجاح من المستوى AAA ضمن مبدأ إمكانية التشغيل (Operable). ينص على أن صفحات الويب يجب ألا تحتوي على أي شيء يومض أكثر من ثلاث مرات في أي فترة مدتها ثانية واحدة. وعلى عكس نظيره من المستوى AA (2.3.1 Three Flashes or Below Threshold)، فإن هذا المعيار لا يسمح بأي استثناءات للمناطق الصغيرة اللامعة أو الومضات التي تقع تحت عتبة الوميض العامة أو عتبة الوميض الأحمر. القاعدة مطلقة: إذا كان المحتوى يومض أكثر من ثلاث مرات في الثانية، فإنه يفشل، بغض النظر عن الحجم أو اللون أو التباين.
يُعرِّف WCAG الوميض بأنه زوج من التغييرات المتعاكسة في اللمعان النسبي يمكن أن يسبب نوبات صرع لدى بعض الأشخاص. وبشكل عملي أكثر، فإن أي وميض مرئي تشغيل/إيقاف، أو حركة تشبه الستروب، أو صور تتناوب بسرعة، أو فيديو يومض ويُكمل أكثر من ثلاث دورات كاملة في الثانية يقع ضمن نطاق هذا المعيار. يشير مصطلح "three flashes" إلى ثلاث ذبذبات كاملة — أي محتوى يتناوب بين حالة أكثر سطوعًا وأخرى أكثر قتامة ثلاث مرات خلال ثانية واحدة.
أنواع المحتوى المتأثرة واسعة وتشمل صور GIF المتحركة، ورسوم CSS المتحركة باستخدام @keyframes، وتحديثات DOM المدفوعة بـ JavaScript التي تسبب تبديلًا بصريًا سريعًا، ورسوم HTML5 Canvas المتحركة، والمحتوى المرئي المضمَّن، ورسوم SVG المتحركة، وشبكات الإعلانات أو الويدجت الخاصة بالجهات الخارجية التي تدمج وسائط متحركة. حتى الوميض الطفيف في نص شريط متحرك (marquee) أو في تصورات البيانات التي تُحدَّث بسرعة يمكن أن يفعّل هذا المعيار إذا تجاوز المعدل ثلاث ومضات في الثانية.
يُعتبَر النجاح وفق 2.3.2 أن الصفحة لا تحتوي على أي محتوى يومض على الإطلاق يتجاوز عتبة ثلاث ومضات في الثانية. ويحدث الفشل في أي وقت يَومض فيه أي جزء من الصفحة — بغض النظر عن مدى صغر المنطقة — أكثر من ثلاث مرات خلال أي نافذة زمنية مدتها ثانية واحدة. لا يوجد استثناء لمنطقة آمنة في هذا المعيار، وهذا ما يميّزه عن 2.3.1. يمكن أن يشكّل مؤشر وامض صغير، أو مؤشر تحميل متحرك، أو لافتة إعلان تتناوب بسرعة حالات فشل إذا كانت تومض بتردد يتجاوز 3 هرتز.
لماذا يهم هذا المعيار
الصرع الحساس للضوء يؤثر على حوالي 1 من كل 4,000 شخص عالميًا، لكن إجمالي عدد الأشخاص المعرضين لنوع من الاستجابة العصبية الحساسة للضوء — بما في ذلك الصداع النصفي الحساس للضوء، واضطرابات الجهاز الدهليزي، والحساسية غير الصرعية للضوء — أكبر بكثير. بالنسبة لهؤلاء الأفراد، فإن التعرض لمحتوى يومض بسرعة على الشاشة ليس مجرد إزعاج: يمكن أن يسبب نوبات صرع كبرى (grand mal)، أو فقدان الوعي، أو إصابات، أو في حالات نادرة الوفاة. وعلى عكس العديد من حواجز الوصول التي تضعف تجربة المستخدم، فإن المحتوى اللامع يمثل خطرًا مباشرًا على السلامة.
فكّر في سيناريو عملي: موقع إخباري تركي يضم شريط أخبار مباشر مع تأثير تمييز متحرك ينبض عند 8 هرتز لجذب الانتباه إلى الأخبار العاجلة. يفتح مستخدم مصاب بالصرع الحساس للضوء الصفحة على هاتفه أثناء التنقل. خلال ثوانٍ، يؤدي الوميض السريع إلى نوبة بؤرية، مما يتسبب في إسقاط الهاتف وفقدان السيطرة على العضلات للحظات. لم يكن لديه أي تحذير، ولا طريقة لتعطيل التأثير مسبقًا، ولا وسيلة للتدارك. هذا السيناريو يمكن منعه بالكامل عن طريق حصر معدلات الوميض في ثلاث مرات في الثانية أو أقل — أو بإزالة المحتوى اللامع تمامًا، كما يقتضي 2.3.2.
إلى جانب بُعد السلامة العصبية، فإن الامتثال لهذا المعيار يفيد أيضًا المستخدمين الذين يعانون من اضطرابات دهليزية (ويشعرون بالدوار أو الغثيان أو التشوش بسبب الحركة)، والمستخدمين الذين تُحفَّز لديهم نوبات الصداع النصفي بواسطة الأنماط البصرية، والمستخدمين الذين يعانون من اضطرابات نقص الانتباه ويجدون المحتوى اللامع بسرعة مستحيل التجاهل أو التحايل عليه. تقليل أو إزالة المحتوى اللامع يميل أيضًا إلى تحسين الانطباع عن احترافية الصفحة وتقليل معدلات تخلّي المستخدمين، إذ إن العديد من المستخدمين — سواء كانوا من ذوي الإعاقة أم لا — يجدون الرسوم المتحركة العدوانية مزعجة.
من منظور تحسين محركات البحث (SEO) والأداء، فإن إزالة الرسوم المتحركة الثقيلة والانتقالات السريعة في CSS يقلل من حمل وحدة المعالجة المركزية (CPU) ووحدة معالجة الرسوميات (GPU)، ويحسّن مؤشرات Core Web Vitals مثل Total Blocking Time و Cumulative Layout Shift، وكلاهما من إشارات الترتيب لدى Google.
قواعد Axe-core ذات الصلة
يتطلب المعيار WCAG 2.3.2 اختبارًا يدويًا. لا توجد قاعدة آلية في axe-core تطابق هذا المعيار مباشرة، وهذا مقصود — وإليك سبب عدم قدرة الأدوات الآلية على اكتشاف الانتهاكات بشكل موثوق:
- يتطلب اختبارًا يدويًا — كشف معدل الوميض: تقوم أدوات الفحص الآلي لإمكانية الوصول بفحص DOM و CSS الثابتين في لحظة زمنية واحدة. لا يمكنها ملاحظة كيفية تصرف المحتوى على مدار ثانية كاملة من تشغيل الرسوم المتحركة، أو قياس تردد تذبذب اللمعان في فيديو أو صورة GIF متحركة، أو تقييم معدل الإطارات في رسم Canvas متحرك. معدل الوميض خاصية زمنية تتطلب ملاحظة في الوقت الفعلي، مما يجعلها خارج نطاق أدوات التحليل الثابتة مثل axe-core. يجب على مختبِر بشري — أو أدوات تحليل حساسية الضوء المتخصصة مثل Photosensitive Epilepsy Analysis Tool (PEAT) — مراجعة المحتوى المتحرك أثناء الحركة لتحديد ما إذا كان يتجاوز عتبة ثلاث ومضات في الثانية.
- يتطلب اختبارًا يدويًا — المحتوى المضمَّن ومن جهات خارجية: الإعلانات، ومقاطع الفيديو المضمَّنة، وويدجت وسائل التواصل الاجتماعي، و iframes قد تحقن محتوى متحركًا لا يستطيع axe-core تحليله، لأنه يعمل ضمن قيود سياسة نفس الأصل (same-origin policy) في المتصفح. يجب على المختبِر ملاحظة كل المحتوى المضمَّن ومن جهات خارجية يدويًا أثناء التشغيل لتقييم الامتثال.
- يتطلب اختبارًا يدويًا — الرسوم المتحركة المدفوعة بـ JavaScript: التبديل السريع لفئات CSS، أو تحديث بكسلات canvas، أو التلاعب بعناصر SVG عبر JavaScript بتردد عالٍ يمكن أن ينتج تأثيرات وميض لا تظهر في لقطة DOM ثابتة. يجب على المختبِرين تشغيل الصفحة في متصفح حي، وملاحظة جميع الحالات المتحركة، وقياس دورات الوميض يدويًا أو باستخدام أدوات تحليل معدل الإطارات.
كيفية الاختبار
- تشغيل فحص آلي كنقطة انطلاق: استخدم axe DevTools أو Lighthouse أو أداة التدقيق المدمجة في ويدجت Accsible لتحديد أي مشكلات متعلقة بالرسوم المتحركة تم الإبلاغ عنها. رغم عدم وجود قاعدة تطابق 2.3.2 مباشرة، قد تُظهر هذه الأدوات تحذيرات ذات صلة حول رسوم CSS المتحركة أو مناطق ARIA الحية التي تُحدَّث بسرعة. دوّن أي عناصر تم الإبلاغ عنها، لكن افهم أن تقريرًا آليًا نظيفًا لا يؤكد الامتثال لـ 2.3.2.
- تحديد كل المحتوى المتحرك يدويًا: حمّل الصفحة في متصفح وراقبها لمدة لا تقل عن 30 ثانية دون تفاعل. لاحظ كل عنصر يومض أو يلمع أو يتحرك أو يغيّر حالته البصرية بشكل متكرر. ضمّن مؤشرات التحميل، واللافتات، ورسوم hero المتحركة، ومقاطع الفيديو التي تُشغَّل تلقائيًا، والخلفيات المتحركة، وأي ويدجت من جهات خارجية. أنشئ قائمة جرد بهذه العناصر.
- استخدام Photosensitive Epilepsy Analysis Tool (PEAT): بالنسبة لمحتوى الفيديو أو تسجيلات الشاشة للرسوم المتحركة، استخدم PEAT (أداة مجانية من Trace Research and Development Center) لتحليل اللقطات إطارًا بإطار. سيُعلِمك PEAT بأي تسلسلات تتجاوز عتبات الوميض ويُبلغ عن كل من عتبة الوميض العامة وعتبة الوميض الأحمر. أي فشل وفق 2.3.2 هو أي وميض يتجاوز ثلاث مرات في الثانية بغض النظر عن العتبات الأخرى.
- قياس معدلات الرسوم المتحركة في CSS و JavaScript: افتح أدوات المطور (DevTools) في المتصفح (Chrome أو Firefox) واستخدم تبويب Performance لتسجيل جلسة مدتها 5 ثوانٍ أثناء تشغيل الرسوم المتحركة. افحص مخطط اللهب (flame graph) بحثًا عن عمليات رسم أو تخطيط تتكرر بسرعة. يمكنك أيضًا فتح لوحة Animations في Chrome DevTools لرؤية الرسوم المتحركة الجارية ومددها — اقسم 1000ms على مدة الرسوم المتحركة لحساب التردد بالهرتز.
- الاختبار باستخدام NVDA + Firefox و VoiceOver + Safari و JAWS + Chrome: مستخدمو قارئات الشاشة ليسوا مستثنين من حساسية الضوء. شغّل كل قارئ شاشة وتصفّح الصفحة بشكل عادي. إذا تم تقديم أي محتوى يومض بصريًا بطريقة تسبب تحديثات سريعة للشاشة (مثل منطقة حية تعلن كل إطار من عدّاد)، فقم بتوثيق ذلك. يظل الوميض البصري انتهاكًا حتى لمستخدمي قارئات الشاشة لأن لديهم قدراً من الرؤية الوظيفية.
- التحقق من المحتوى المضمَّن ومن جهات خارجية: مرّر خلال جميع iframes، والمنشورات المضمَّنة من وسائل التواصل الاجتماعي، ومواضع الإعلانات، ومشغلات الفيديو. شغّل يدويًا أي فيديو لا يُشغَّل تلقائيًا وراقب الوميض السريع. افحص صور GIF المتحركة بالنقر بزر الفأرة الأيمن وفحص بيانات الإطار في محرر صور أو في تبويب Network في المتصفح لتقدير معدل الإطارات.
- تكرار الاختبار عبر الأجهزة والمتصفحات: بعض الرسوم المتحركة تعمل بسرعات مختلفة على الأجهزة المحمولة مقارنة بسطح المكتب بسبب اختلافات تسريع العتاد. اختبر على متصفح سطح مكتب وعلى جهاز محمول (Safari على iOS و Chrome على Android) للتأكد من الامتثال المتسق.
كيفية الإصلاح
رسوم CSS Keyframe متحركة تومض بسرعة كبيرة — غير صحيح
<!-- A badge that flashes to draw attention, completing 8 cycles per second -->
<style>
@keyframes flash-badge {
0%, 49% { background-color: red; }
50%, 100% { background-color: transparent; }
}
.alert-badge {
animation: flash-badge 0.125s infinite; /* 8 Hz — far exceeds 3 per second */
}
</style>
<span class='alert-badge'>NEW</span>
رسوم CSS Keyframe متحركة تومض بسرعة كبيرة — صحيح
<!-- Animation slowed to complete fewer than 3 cycles per second -->
<style>
@keyframes flash-badge {
0%, 49% { background-color: red; }
50%, 100% { background-color: transparent; }
}
.alert-badge {
animation: flash-badge 0.4s infinite; /* ~2.5 Hz — safely below the 3 Hz threshold */
}
</style>
<span class='alert-badge'>NEW</span>
<!-- Better still: remove the animation entirely and use a static high-contrast badge -->
تبديل DOM عبر JavaScript يسبب وميضًا سريعًا — غير صحيح
<!-- Script toggles visibility 10 times per second to simulate a strobe effect -->
<div id='strobe-element' style='width:200px;height:200px;background:white;'></div>
<script>
setInterval(function() {
var el = document.getElementById('strobe-element');
el.style.background = el.style.background === 'white' ? 'black' : 'white';
}, 100); /* Fires every 100ms = 10 flashes per second -- a serious seizure risk */
</script>
تبديل DOM عبر JavaScript يسبب وميضًا سريعًا — صحيح
<!-- Removed the rapid toggle entirely; convey state change through text or icon instead -->
<div id='status-element' style='width:200px;height:200px;background:#005fcc;'>
<p style='color:white;padding:1rem;'>System Active</p>
</div>
<!-- If animation is genuinely needed, keep it well under 3 Hz and prefer opacity/color
transitions over high-contrast luminance switches -->
صورة GIF متحركة ذات معدل إطارات عالٍ — غير صحيح
<!-- An animated GIF advertisement that cycles through frames at 10 fps -->
<img src='promo-flash.gif' alt='Special offer — 50% off this weekend only'>
<!-- The GIF's internal frame delay is set to 10ms per frame, creating rapid flicker -->
صورة GIF متحركة ذات معدل إطارات عالٍ — صحيح
<!-- Replace the animated GIF with a static image, or re-export the GIF
with a minimum frame delay of 334ms per frame (3 fps or slower) -->
<img src='promo-static.png' alt='Special offer — 50% off this weekend only'>
<!-- If motion must be preserved, use a CSS animation with prefers-reduced-motion support -->
<picture>
<source srcset='promo-static.png' media='(prefers-reduced-motion: reduce)'>
<img src='promo-slow.gif' alt='Special offer — 50% off this weekend only'>
</picture>
الأخطاء الشائعة
- افتراض أن استثناء "المساحة الصغيرة" من 2.3.1 ينطبق على 2.3.2: يسمح WCAG 2.3.1 بالمحتوى اللامع الذي يشغل أقل من 25% من مجال بصري بزاوية 10 درجات. لا يحتوي WCAG 2.3.2 على مثل هذا الاستثناء — مؤشر وامض صغير أو نقطة تحميل صغيرة تومض أكثر من ثلاث مرات في الثانية يُعد انتهاكًا كاملًا على مستوى AAA.
- تعيين قيمة CSS animation-duration إلى 0.1s أو 0.2s دون حساب معدل الوميض الناتج: الرسوم المتحركة لمدة 0.1s التي تتذبذب بين حالتين تُكمل 10 دورات في الثانية (10 هرتز). اقسم 1 على المدة بالثواني للحصول على التردد بالهرتز؛ تأكد من أن النتيجة 3 أو أقل.
- تضمين سكربتات إعلانات من جهات خارجية دون مراجعة سلوك الرسوم المتحركة: شبكات الإعلانات غالبًا ما تقدم مواد إعلانية متحركة ذات معدلات وميض عالية محسّنة للنقر، لا لإمكانية الوصول. راجع دائمًا المحتوى من جهات خارجية باستخدام PEAT أو فحص الإطارات يدويًا قبل النشر.
- استخدام حلقات
setIntervalأوrequestAnimationFrameلتبديل فئات CSS بسرعة لمؤشرات التحميل أو التقدم: أي حلقة JavaScript تغيّر لمعان عنصر أو رؤيته أكثر من ثلاث مرات في الثانية تخلق انتهاكًا لـ 2.3.2، حتى لو بدا التأثير طفيفًا في ظروف العرض العادية. - عدم اختبار رسوم SVG و Canvas المتحركة: الرسوم المتحركة لـ SVG باستخدام
<animate>أو SMIL، وألعاب Canvas أو تصورات البيانات، نادرًا ما تُختبر باستخدام PEAT أو أدوات معدل الإطارات، ومع ذلك فهي قادرة تمامًا على تجاوز عتبة الوميض. - الاعتماد فقط على axe-core أو Lighthouse لتأكيد الامتثال لـ 2.3.2: لا يمكن للأدوات الآلية اكتشاف هذا المعيار. نتيجة فحص آلي نظيفة لا تعني شيئًا بالنسبة لـ 2.3.2؛ وحده الاستعراض اليدوي وتحليل PEAT يمكنهما تأكيد الامتثال.
- اعتبار
prefers-reduced-motionحلاً كاملاً لـ 2.3.2: احترام استعلام الوسائطprefers-reduced-motionممارسة جيدة ومفيد للعديد من المستخدمين، لكنه آلية تعتمد على اختيار المستخدم. يتطلب WCAG 2.3.2 أن يكون المحتوى آمنًا بشكل افتراضي، لا فقط عندما يضبط المستخدم تفضيل النظام. يظل المستخدمون الذين لم يضبطوا هذا الإعداد معرضين للخطر. - تطبيق حدود معدل الوميض على الفيديو فقط دون CSS أو JavaScript أو صور GIF المتحركة: أحيانًا تقوم الفرق بتدقيق محتوى الفيديو باستخدام PEAT لكنها تغفل رسوم CSS keyframe المتحركة والتبديلات المدفوعة بـ JavaScript. يجب تقييم جميع تقنيات الرسوم المتحركة.
- استخدام خصائص background-image في CSS لعرض صور GIF متحركة: صور GIF المتحركة المستخدمة كصور خلفية في CSS أقل وضوحًا للمختبِرين الذين يقومون بمسح بصري، ويسهل إغفالها أثناء التدقيق. ضمّن دائمًا صور الخلفية في قائمة جرد الرسوم المتحركة.
- الفشل في إعادة الاختبار بعد أن تضيف تغييرات A/B testing أو التخصيص محتوى متحركًا جديدًا: يمكن لأنظمة التسويق والتخصيص أن تحقن ديناميكيًا لافتات أو تراكبات تحتوي على رسوم متحركة لم تُراجع مطلقًا من حيث الامتثال لـ WCAG 2.3.2. أنشئ بوابة مراجعة لأي محتوى يُحقن ديناميكيًا.
العلاقة مع لوائح إمكانية الوصول في تركيا
التعميم الرئاسي التركي 2025/10، المنشور في الجريدة الرسمية رقم 32933 بتاريخ 21 يونيو 2025، يضع معايير إلزامية لإمكانية الوصول على الويب وعلى الأجهزة المحمولة لمجموعة واسعة من الكيانات العاملة في تركيا. يعتمد التعميم WCAG 2.2 كإطار مرجعي تقني، مع اشتراط الامتثال الإلزامي عمومًا على مستويي A و AA.
المعيار WCAG 2.3.2 هو معيار من المستوى AAA، وبالتالي لا يُفرض قانونيًا بموجب التعميم على معظم الكيانات المشمولة. ومع ذلك، فإن موضوعه — منع المحتوى الذي يمكن أن يسبب نوبات صرع — يتقاطع مباشرة مع واجب العناية العام ومبادئ عدم التمييز التي يقوم عليها التنظيم. الأنواع التالية من الكيانات مشمولة بالتعميم ويجب أن تتعامل مع 2.3.2 كالتزام قوي لأفضل الممارسات حتى عندما لا يكون مطلوبًا بشكل صارم: منصات التجارة الإلكترونية، والمؤسسات العامة والهيئات الحكومية، والبنوك والمؤسسات المالية، والمستشفيات ومقدمو الرعاية الصحية، وشركات الاتصالات التي لديها 200,000 مشترك أو أكثر، ووكالات السفر، وشركات النقل الخاصة، والمدارس الخاصة المرخَّصة من قبل وزارة التربية الوطنية (MoNE).
بالنسبة للمؤسسات العامة ومقدمي الرعاية الصحية على وجه الخصوص، فإن الأبعاد الأخلاقية لـ 2.3.2 عالية بشكل خاص. بوابة صحية حكومية أو صفحة معلومات للمرضى في مستشفى تتسبب في نوبة صرع لزائر حساس للضوء ستمثل فشلًا في السلامة وأزمة سمعة في آن واحد. رغم أن التعميم لا يفرض صراحة الامتثال لمستوى AAA، فإن المنظمات التي تسعى لإظهار إمكانية وصول رائدة — سواء لأهلية المناقصات، أو الثقة العامة، أو الشراكات التجارية الدولية — ينبغي أن تطبق 2.3.2 إلى جانب التزاماتها الإلزامية في المستويين A و AA.
يجب على المنظمات التي تقدم خدمات لسوق الاتحاد الأوروبي أيضًا ملاحظة أن قانون إمكانية الوصول الأوروبي (EAA)، الذي بدأ تطبيقه في يونيو 2025، يشير إلى المعيار EN 301 549، الذي يشير بدوره إلى WCAG. قد تواجه الشركات التركية التي تصدّر منتجات أو خدمات رقمية إلى دول الاتحاد الأوروبي متطلبات أكثر صرامة عبر تلك القناة. إن تطبيق 2.3.2 بشكل استباقي يضع المنظمات التركية في موقع جيد من حيث الامتثال المحلي وعبر الحدود.
من منظور التنفيذ العملي، يمكن لحزمة SDK الخاصة بويدجت Accsible overlay أن تساعد الكيانات المشمولة من خلال توفير خيار للمستخدمين لإيقاف أو إيقاف جميع الرسوم المتحركة على الصفحة، مما يساعد في تقليل مخاطر حساسية الضوء للمستخدمين الذين يدركون حالتهم. ومع ذلك، فإن هذا التحكم الذي يفعّله المستخدم هو إجراء تكميلي، وليس بديلًا عن إزالة المحتوى اللامع أو إبطائه من المصدر، كما يتطلب 2.3.2.
المصادر والمراجع
- W3C Understanding 2.3.2 Three Flashes
- W3C Techniques for 2.3.2
- WebAIM: Seizure and Vestibular Disorders
- Trace Center: Photosensitive Epilepsy Analysis Tool (PEAT)
- MDN: prefers-reduced-motion
- MDN: CSS animation-duration
- W3C General Technique G19: Ensuring no component flashes more than three times in any 1-second period
