يُعد الاختيار بين استخدام طبقة وصولية (accessibility overlay) والمعالجة اليدوية من أكثر القرارات تأثيرًا التي يمكن لمالك موقع ويب اتخاذها في عام 2025. يوضح هذا الدليل بالتفصيل ما يقدمه كل نهج بالضبط، وأين يقصر كل منهما، وكيف تجمع الفرق المتطلعة إلى المستقبل بين الاثنين لبناء مواقع ويب شاملة حقًا وقابلة للدفاع عنها قانونيًا.
في عام 2024، شكّلت 25% من جميع الدعاوى القضائية المتعلقة بإتاحة المواقع الرقمية في الولايات المتحدة — أكثر من 1,000 قضية — حالات تم فيها ذكر أدوات التراكب الخاصة بالإتاحة بشكل صريح كعوائق وليست حلولًا. في العام نفسه، غرّمت لجنة التجارة الفيدرالية أحد أكبر مزوّدي التراكبات في هذا القطاع مبلغ 1 مليون دولار بسبب الإعلانات المضللة. ومع ذلك، لا تزال ملايين المواقع تعتمد على أيقونة شريط أدوات عائم كاستراتيجيتها الأساسية للإتاحة. إذا كنت مالك موقع أو مطوّرًا أو مسؤول امتثال وتحاول فهم الجدل بين التراكبات مقابل المعالجة اليدوية، فهذا الدليل موجّه لك: بلا مبالغة تسويقية، بلا ترويج للبائعين — بل نظرة دقيقة لما يقدّمه كل نهج فعليًا، وأين يقدّم كل منهما فائدة حقيقية، وكيف تبني استراتيجية تصمد في المحكمة، والأهم من ذلك، تعمل فعليًا مع المستخدمين ذوي الإعاقة في العالم الحقيقي.
ما هي تراكبات الإتاحة وكيف تعمل؟
تراكبات الإتاحة — وتُسمّى أيضًا أدوات أو أشرطة أدوات الإتاحة — هي منتجات مبنية على JavaScript تُحمَّل فوق موقع ويب قائم. عادةً ما تعرض للمستخدمين لوحة تحكم تقدّم خيارات مثل تكبير النص، وضع التباين العالي، تكبير المؤشر، ومجموعة من "الملفات التعريفية" للإعاقة (مثل وضع قارئ الشاشة أو تبديل خط مناسب لعسر القراءة). فئة ثانية من وظائف التراكب تحاول اكتشاف وإصلاح إخفاقات الإتاحة تلقائيًا في الخلفية، دون أي تفاعل من المستخدم، باستخدام أتمتة قائمة على القواعد أو الذكاء الاصطناعي.
جاذبية هذا النهج واضحة. فعملية التثبيت غالبًا لا تتعدى لصق وسم سكربت واحد في عنصر <head> في موقعك، وتبدأ تكاليف الاشتراك من 49–$500 شهريًا. بالنسبة لمالك نشاط تجاري صغير تلقّى للتو خطاب مطالبة ويحتاج إلى التحرك بسرعة، يبدو العرض لا يُقاوَم: سطر واحد من الشيفرة، نشر فوري، وشهادة امتثال لعرضها على فريقك القانوني. لكن الواقع، كما سنستكشف بتفصيل، أكثر تعقيدًا بكثير.
من المهم التمييز بين شيئين مختلفين تمامًا غالبًا ما يُجمعان تحت مسمّى "التراكب". أولًا، هناك أدوات تفضيلات موجهة للمستخدم — أدوات تتيح للزائرين ضبط حجم النص، وتباين الألوان، وتقليل الحركة، وإعدادات العرض المشابهة. هذه الأدوات لها فائدة حقيقية لكثير من المستخدمين، وتُعد تحسينًا مدروسًا عندما تُبنى فوق موقع متاح بالفعل. ثانيًا، هناك أدوات الإصلاح الآلي للامتثال — منتجات تدّعي اكتشاف وإصلاح انتهاكات WCAG تلقائيًا دون لمس الشيفرة المصدرية الأساسية. هذه الفئة الثانية هي التي جذبت إجراءات تنظيمية، ودعاوى جماعية، وإدانة شبه إجماعية من مجتمع خبراء الإتاحة. فهم هذا التمييز مهم للغاية عند تقييم أي منتج في هذا المجال.
ما هي المعالجة اليدوية (Manual Remediation)؟
تشير المعالجة اليدوية إلى عملية تحديد إخفاقات الإتاحة بشكل منهجي في الشيفرة المصدرية الفعلية للموقع وإصلاحها مباشرة — في HTML وCSS وJavaScript وأي قوالب أو مكوّنات أساسية. تبدأ العملية بتدقيق إتاحة: مراجعة منظّمة تجمع بين أدوات الفحص الآلي (التي يمكنها كشف مجموعة فرعية من المشكلات القابلة للاكتشاف بسرعة) واختبار بشري خبير باستخدام تقنيات مساعدة فعلية مثل JAWS وNVDA وVoiceOver وأجهزة Switch Access.
ينتج عن التدقيق تقرير مفصّل يوثّق كل إخفاق مع ربطه بمعايير النجاح ذات الصلة في WCAG 2.1 أو 2.2، مع تقييمات للخطورة وإرشادات للمعالجة. بعد ذلك ينفّذ المطوّرون الإصلاحات مباشرة في قاعدة الشيفرة: إضافة ارتباطات <label> صحيحة لعناصر النماذج، تصحيح تسلسل العناوين، ضمان أن العناصر التفاعلية لها أسماء متاحة، تنفيذ أدوار ARIA وحالاتها بشكل صحيح للمكوّنات الديناميكية، إصلاح قيم تباين الألوان، إضافة نص بديل ذي معنى، وهكذا. بعد تنفيذ الإصلاحات، تؤدَّى جولة ثانية من الاختبارات — بما في ذلك إعادة الاختبار مع مستخدمي تقنيات مساعدة — للتحقق من التغييرات.
تستغرق هذه العملية وقتًا أطول وتكلّف أكثر مقدمًا من تثبيت أداة تراكب. فعمليات التدقيق المتخصصة في الإتاحة لموقع متوسط الحجم عادةً ما تتراوح بين 2,500 و20,000 دولار، ويمكن أن تضيف المعالجة التقنية 5,000 إلى 20,000 دولار أخرى حسب التعقيد. أما الصيانة المستمرة — مراقبة آلية مع إعادة تدقيق يدوي دوري — فتضيف 200 إلى 2,000 دولار شهريًا. قد تبدو هذه الأرقام مرتفعة مقارنة باشتراك تراكب بقيمة 99 دولارًا شهريًا. لكن كما سنرى، تبدو مقارنة التكلفة مختلفة تمامًا عندما تأخذ في الحسبان التعرض القانوني، وديمومة الإصلاح، وما الذي تحصل عليه فعليًا مقابل أموالك.
المشكلة التقنية الجوهرية في التراكبات
القيْد الأساسي لأي أداة تراكب هو معماري، ولا يمكن لأي قدر من تطوّر الذكاء الاصطناعي تجاوزه بالكامل: تقوم التراكبات بحقن JavaScript يعدّل شجرة DOM المعروضة بعد تحميل الصفحة، لكن قارئات الشاشة وغيرها من التقنيات المساعدة تحلّل الشيفرة المصدرية لـ HTML عند التحميل — قبل تنفيذ هذا الـ JavaScript. هذا يعني أن كثيرًا من "الإصلاحات" التي يطبّقها التراكب تكون غير مرئية للتقنيات المساعدة التي يدّعي المنتج دعمها.
حتى لو تجاوزنا مشكلة التوقيت هذه، فإن أدوات الكشف الآلي — بما في ذلك أكثر التراكبات تطورًا المعتمدة على الذكاء الاصطناعي — لا يمكنها واقعيًا تحديد أكثر من حوالي 30% من انتهاكات معايير النجاح في WCAG. أما الـ 70% المتبقية من المشكلات فتتطلب حكمًا بشريًا: تحديد ما إذا كان النص البديل لصورة ما ذا معنى في سياقه (وليس مجرد وجوده)، وما إذا كانت العلاقات في جدول بيانات معقّد موصوفة بشكل صحيح، وما إذا كان يتم استخدام منطقة ARIA حية بشكل صحيح، أو ما إذا كان مسار نموذج متعدد الخطوات قابلًا فعليًا للتنقل باستخدام لوحة المفاتيح. يمكن للتراكب إضافة خاصية alt لصورة؛ لكنه لا يستطيع أن يحدّد بشكل موثوق ما إذا كان النص الذي يولّده يصف تلك الصورة بدقة في سياقها.
فئات محددة من المشكلات التي لا يمكن للتراكبات إصلاحها بنيويًا تشمل:
- أخطاء HTML الدلالية — استخدام
<div>حيث يلزم<button>، أو تسلسل عناوين مكسور مدمج في قالب - تسميات النماذج المفقودة أو غير الصحيحة — يجب أن توجد علاقة التسمية الصحيحة في الشيفرة المصدرية
- إدارة التركيز في المحتوى الديناميكي — النوافذ المنبثقة (modals) والشرائح (carousels) وتغييرات المسارات في تطبيقات الصفحة الواحدة تتطلب تنفيذًا على مستوى الشيفرة
- الترجمة النصية للفيديو والوصف الصوتي — لا يمكن إضافة إتاحة المحتوى عبر طبقة JavaScript
- إتاحة ملفات PDF والمستندات — خارج نطاق أي تراكب ويب تمامًا
- تباين الألوان المضمّن في CSS — يمكن للتراكب أن يقدّم مفتاح تبديل للتباين، لكنه لا يستطيع تغيير نظام تصميم علامتك التجارية للمستخدمين الذين لا يعرفون بوجود هذا التبديل أو لا يقومون بتفعيله
الامتثال لـ WCAG يعني استيفاء جميع معايير النجاح المنطبقة عند مستوى معيّن. وبما أن التراكبات عاجزة بشكل واضح عن معالجة الطيف الكامل لهذه المعايير، فهي لا يمكن أن تقدّم الامتثال الذي تعد به — بغض النظر عن مدى تطور ادعاءاتها في مجال الذكاء الاصطناعي.
الواقع القانوني: التراكبات تجذب الدعاوى بدلًا من منعها
تروي بيانات التقاضي قصة متسقة. في عام 2023، تعرّض أكثر من 900 نشاط تجاري يستخدم أدوات إتاحة تراكبية لدعاوى قضائية — بزيادة 62% عن العام السابق. في عام 2024، ارتفع هذا العدد إلى أكثر من 1,000، ما شكّل نحو 25% من جميع الدعاوى القضائية المتعلقة بإتاحة الويب المرفوعة في ذلك العام. وفي النصف الأول من 2025 وحده، استهدفت 456 دعوى قضائية مواقع كانت قد نصّبت أدوات إتاحة تراكبية، ما مثّل 22.64% من إجمالي قضايا ADA خلال تلك الفترة — وكان المعدل الشهري للدعاوى المرتبطة بالتراكبات أعلى باستمرار من الفترة نفسها في 2024.
جزء من سبب أن التراكبات تجذب التقاضي بدلًا من منعه يعود إلى طريقة عمل مكاتب المحاماة الممثلة للمدّعين. أدوات مثل BuiltWith تجعل من السهل للغاية تحديد المواقع التي تستخدم منتجات تراكب معيّنة. يعرف محامو المدّعين، من خلال خبرة واسعة، أن الموقع الذي يستخدم تراكبًا من المرجّح جدًا أن يحتوي على انتهاكات جوهرية مستمرة لـ WCAG — لأن التراكب لا يمكنه إصلاحها. كما أن وجود الأداة يعمل كدليل على أن النشاط التجاري كان على علم بالتزاماته المتعلقة بالإتاحة، ما يمكن أن يقوّي موقف المدّعي القانوني عبر الإيحاء بأن الشركة اختارت اختصارًا غير كافٍ بدلًا من التصرف بحسن نية.
كانت المحاكم واضحة لا لبس فيها. ففي تسوية قضية LightHouse for the Blind v. ADP, Inc.، نصّ الاتفاق صراحة على أن "حلول التراكب لن تكون كافية لتحقيق الإتاحة" وألزم ADP بالسعي إلى معالجة حقيقية على مستوى الشيفرة المصدرية. وفي قضية Murphy v. Eyebobs، فرضت التسوية الامتثال الكامل لـ WCAG 2.1، والاستعانة باستشاري إتاحة، وتدريبًا داخليًا للموظفين — وهي بالضبط الأمور التي كان من المفترض أن تجعلها التراكبات غير ضرورية. وفي أبريل 2025، خلص الأمر النهائي للجنة التجارة الفيدرالية ضد accessiBe، الذي غرّم الشركة 1 مليون دولار، إلى أن ادعاءاتها المتعلقة بالامتثال "غير مدعومة بأدلة كفؤة وموثوقة". هذه ليست حالات استثنائية؛ بل تمثّل إجماعًا قانونيًا واضحًا على أن محاكاة الإتاحة ليست هي تحقيق الإتاحة.
الصورة الأوروبية واضحة بالقدر نفسه. فـ "قانون الإتاحة الأوروبي" الذي دخل حيّز التنفيذ الكامل في يونيو 2025، يفرض الامتثال لمستوى WCAG 2.1 AA على المنتجات والخدمات الرقمية المباعة داخل الاتحاد الأوروبي. وقد صرّحت المفوضية الأوروبية علنًا بأن تراكبات الإتاحة — سواء كانت مدعومة بالذكاء الاصطناعي أم لا — لا تشكّل مسارًا صالحًا للامتثال لـ WCAG. بالنسبة للمنظمات التي تعمل داخل أسواق الاتحاد الأوروبي أو تبيع لها، تحمل استراتيجيات الاعتماد على التراكبات وحدها مخاطر تنظيمية بالإضافة إلى مخاطر التقاضي.
أين يمكن أن تضيف التراكبات قيمة حقيقية؟
بالنظر إلى كل ما سبق، سيكون من غير النزيه فكريًا القول إن التراكبات لا دور مشروع لها على الإطلاق. لها دور — لكن فقط في سياق محدّد ومفهوم جيدًا: كـ طبقة تفضيلات مكمّلة للمستخدم تُضاف فوق موقع متاح بالفعل.
توفّر عناصر التحكم الموجهة للمستخدم في حجم النص، وضبط التباين، وتقليل الحركة، وتباعد الأسطر، وتبديل الخطوط فائدة حقيقية للمستخدمين ذوي ضعف البصر، أو الإعاقات الإدراكية، أو الحساسية للضوء، أو صعوبات القراءة الذين يرغبون في تخصيص تجربتهم بما يتجاوز ما يوفّره نظام التشغيل. تصبح هذه الميزات ذات قيمة فعلية عندما تكون التجربة الأساسية متاحة بالفعل — لأنها توسّع قابلية الاستخدام بدلًا من محاولة التعويض عن إخفاقات بنيوية جوهرية.
يمكن أن تؤدي التراكبات أيضًا دورًا مشروعًا خلال فترة الانتقال في عملية المعالجة. إذا كان لديك موقع كبير ومعقّد، وجدول زمني واقعي من 6–12 شهرًا لإكمال المعالجة الكاملة على مستوى الشيفرة المصدرية، يمكن لتراكب يُنشر بالتوازي مع العمل النشط على المعالجة أن يعالج بعض المشكلات السطحية بينما يجري العمل الأعمق — طالما يُفهَم على أنه جسر مؤقت، لا وجهة نهائية. الخطر هنا هو الجمود التنظيمي: وجود أداة تراكب يمكن أن يخلق شعورًا زائفًا بالثقة ويبطئ العمل الحقيقي إذا اعتقد أصحاب المصلحة أن المشكلة قد حُلّت بالفعل.
تم تصميم حزمة Accsible SDK، كأداة قائمة على الودجت، بهذه الفلسفة في الاعتبار: فهي توفّر عناصر تحكم في الإتاحة قابلة للتهيئة من قبل المستخدم وميزات تحسين تكمل خط الأساس القائم لإتاحة الموقع، وتمنح المستخدمين قدرة حقيقية على التحكم في تجربتهم. الفارق بين التحسين والاستبدال هو الفارق الحاسم. فالتراكب الذي يساعد مستخدمًا قادرًا بالفعل على التنقل في موقعك على القيام بذلك براحة أكبر يختلف جوهريًا عن تراكب يدّعي أن موقعك غير المتاح أصبح الآن ممتثلًا.
المعالجة اليدوية: الإيجابيات والسلبيات والعملية
الميزة الحاسمة للمعالجة اليدوية هي أنها تعمل فعليًا. فالإصلاحات على مستوى الشيفرة المصدرية تعالج من حيث المبدأ 100% من معايير النجاح في WCAG — بما في ذلك الأنماط التفاعلية المعقّدة، وإتاحة الفيديو، ومعالجة المستندات، ومشكلات البنية الدلالية التي لا يمكن لأي أداة آلية التعامل معها. الإصلاحات دائمة: فهي لا تعتمد على تحميل سكربت طرف ثالث في كل صفحة، ولا تخلق مخاوف تتعلق بالخصوصية من خلال تتبع تفضيلات المستخدم، ولا تتعارض مع إعدادات تقنيات المساعدة التي قام المستخدمون ذوو الإعاقة بضبطها بعناية لتناسب أسلوب عملهم.
من الناحية القانونية، المعالجة اليدوية هي النهج الوحيد الذي لبّى باستمرار متطلبات المحاكم والجهات التنظيمية. فشهادة امتثال مؤرّخة، وVPAT (نموذج تطوّعي لإتاحة المنتج) مفصّل، وسجلات موثّقة لعمليات التدقيق والمعالجة تشكّل أقوى دفاع ممكن قائم على حسن النية في مواجهة تحدٍّ قانوني. المنظمات التي يمكنها إثبات برنامج إتاحة منظّم يقوده خبراء تكون في وضع قانوني مختلف جذريًا عن تلك التي تعتمد على اشتراك في أداة تراكب.
لكن السلبيات الصريحة للمعالجة اليدوية حقيقية. التكلفة والوقت هما العائقان الأساسيان. فقد يكلّف تدقيق شامل لموقع أعمال مكوّن من 50 صفحة ما بين 8,000 و20,000 دولار، مع إضافة المعالجة 10,000–30,000 دولار أخرى حسب حجم الدين التقني. يمكن أن تصل تطبيقات المؤسسات الكبيرة إلى مبالغ من ستة أرقام. بالنسبة للأعمال الصغيرة والشركات الناشئة، قد يبدو هذا الاستثمار مرهقًا — وهذا بالضبط الفراغ الذي يستغله مزوّدو التراكبات من خلال تسعير اشتراكاتهم الشهرية المنخفضة.
تتطلب المعالجة اليدوية أيضًا استثمارًا مستمرًا. فالمواقع ليست ثابتة: المحتوى الجديد، وتحديثات الميزات، وتجديدات التصميم، والتكاملات مع أطراف ثالثة تقدّم مشكلات إتاحة جديدة بانتظام. مشروع معالجة لمرة واحدة دون برنامج مراقبة وصيانة مستمر سيشهد تراجعًا في الامتثال خلال أشهر. أكثر المنظمات فاعلية تتعامل مع الإتاحة كما تتعامل مع الأمن: انضباط مستمر، لا مشروعًا لمرة واحدة.
بناء استراتيجية عملية للإتاحة: الجمع بين النهجين
تصوير المسألة على أنها "تراكب مقابل معالجة يدوية" كخيار ثنائي يغفل ما تفعله المنظمات الذكية فعليًا. أكثر استراتيجيات الإتاحة دفاعًا وفعالية تستخدم الأدوات الآلية بشكل استراتيجي — كبنية تحتية للكشف والمراقبة، لا كاختصار للامتثال — مع إرساء كل شيء على إصلاحات على مستوى الشيفرة المصدرية.
إليك إطارًا عمليًا لحالات تنظيمية مختلفة:
- نشاط تجاري صغير بميزانية محدودة: ابدأ بفحص آلي لتحديد المشكلات الأعلى تأثيرًا، وأعطِ الأولوية لإصلاح العوائق الحرجة في الشيفرة المصدرية (تسميات النماذج، التنقل بلوحة المفاتيح، النص البديل المفقود، تباين الألوان)، واستخدم تراكب تفضيلات للمستخدم كتحسين إضافي — لا كاستراتيجية امتثال. وثّق كل خطوة تقوم بها.
- منظمة متوسطة الحجم تواجه موعدًا نهائيًا للامتثال: اطلب تدقيقًا يدويًا كاملًا فورًا. ابدأ في معالجة المشكلات الحرجة والجدّية بالتوازي. استخدم المراقبة الآلية لتتبع التراجع بين دورات التدقيق. يمكن أن يعمل التراكب كإجراء مؤقت لسد فجوات محددة معروفة بينما يعمل فريق التطوير على تراكم مهام المعالجة — لكن حدّد موعدًا نهائيًا واضحًا لإزالته أو إعادة تصنيفه.
- مؤسسة كبيرة أو قطاع منظّم (الرعاية الصحية، التمويل، الحكومة): المعالجة اليدوية غير قابلة للتفاوض. أدخِل الإتاحة في دورة حياة تطوير البرمجيات (SDLC) من مرحلة التصميم. نفّذ عمليات فحص آلي ربع سنوية وتدقيقات يدوية كاملة سنوية مع اختبار باستخدام تقنيات مساعدة. يمكن أن يكون ودجت تفضيلات المستخدم إضافة مدروسة لتجربة الاستخدام، لكنه لا يحمل أي وزن من ناحية الامتثال.
- التجارة الإلكترونية: تمثّل مواقع التجارة الإلكترونية 77% من جميع الدعاوى القضائية المتعلقة بإتاحة الويب. تدفقات الدفع، وصفحات المنتجات، والنماذج، والتفاعلات الديناميكية لعربة التسوق كلها مناطق عالية المخاطر من ناحية التقاضي لا يمكن للتراكبات التعامل معها بشكل موثوق. المعالجة على مستوى الشيفرة المصدرية ضرورية بشكل خاص هنا، والمراقبة المستمرة أساسية نظرًا لمدى تكرار تحديث مكوّنات المنتجات والعربة.
أحد أكثر عناصر استراتيجية الإتاحة المستدامة التي يُغفل عنها هو تدريب المطوّرين. عندما يفهم فريقك HTML الدلالي، وأفضل ممارسات ARIA، وإدارة التركيز، وأنماط التنقل بلوحة المفاتيح من البداية، تنخفض تكلفة المعالجة بشكل كبير مع كل دورة بناء لاحقة. المنظمات التي تنفق أقل على الإتاحة على المدى الطويل هي تلك التي دمجت معرفة الإتاحة في ثقافة التطوير لديها — لا تلك التي أوكلت المشكلة إلى سكربت طرف ثالث.
الخلاصات الأساسية
- لا يمكن للتراكبات تحقيق الامتثال لـ WCAG بمفردها. يمكن للأدوات الآلية اكتشاف 30–40% فقط من مشكلات WCAG في أفضل الأحوال، وتقوم قارئات الشاشة بتحليل الشيفرة المصدرية قبل تنفيذ JavaScript الخاص بالتراكب — ما يجعل كثيرًا من "الإصلاحات" غير مرئية للتقنيات المساعدة. المحاكم، ولجنة التجارة الفيدرالية، والمفوضية الأوروبية، وأكثر من 800 من محترفي الإتاحة توصّلوا جميعًا إلى النتيجة نفسها.
- تشغيل تراكب دون معالجة أساسية يزيد من مخاطرك القانونية بدلًا من تقليلها. في عام 2024، استهدفت 25% من جميع الدعاوى القضائية الأميركية المتعلقة بإتاحة الويب مواقع تستخدم ودجتات. يقوم محامو المدّعين بمسح التراكبات بنشاط كأهداف للتقاضي، وقد قضت المحاكم بأن تثبيت ودجت لا يُعد دليلًا على امتثال قائم على حسن النية.
- المعالجة اليدوية هي المسار الوحيد نحو امتثال حقيقي يمكن الدفاع عنه. الإصلاحات على مستوى الشيفرة المصدرية دائمة، وتغطي الطيف الكامل لمعايير النجاح في WCAG، وتنتج الوثائق (تقارير التدقيق، وVPATs، وسجلات المعالجة) التي تصمد فعليًا في السياقات القانونية والتنظيمية.
- للتراكبات دور مشروع كتحسينات لتفضيلات المستخدم — مثل تكبير النص، وعناصر التحكم في التباين، وتقليل الحركة — عندما تُنشر فوق موقع متاح بالفعل. المشكلة هي استخدامها كبديل للإتاحة، لا كمكمّل لها.
- أكثر استراتيجيات الإتاحة فعالية من حيث التكلفة هي الاستباقية والمستمرة. الاستثمار في الإتاحة أثناء التطوير أرخص بكثير من المعالجة تحت ضغط قانوني. أدخِل المراقبة في سير عملك، درّب مطوّريك، وتعامل مع الإتاحة كبرنامج مستمر — لا خانة تضع فيها علامة مرة واحدة ثم تنساها.