WCAG 4.1.3: رسائل الحالة

ماذا تعني هذه القاعدة

ينص معيار النجاح 4.1.3 من WCAG الخاص برسائل الحالة (المستوى AA، المُقدَّم في WCAG 2.1 والمستمر في WCAG 2.2) على ما يلي: "في المحتوى المُنفَّذ باستخدام لغات الترميز، يجب أن يكون من الممكن تحديد رسائل الحالة برمجياً من خلال الدور أو الخصائص بحيث يمكن تقديمها للمستخدم بواسطة تقنيات المساعدة دون أن تتلقى التركيز."

عملياً، يعني هذا أنه كلما قام واجهتك بإنتاج رسالة لإبلاغ المستخدم بنتيجة ما — مثل عودة نتائج من عملية بحث، أو نجاح إرسال نموذج، أو إضافة عنصر إلى سلة التسوق، أو حدوث خطأ بعد التحقق من صحة البيانات، أو اكتمال عملية ما — يجب كشف هذه الرسالة لتقنيات المساعدة (AT) بطريقة لا تتطلب من المستخدم الانتقال إليها. القيد الأساسي هو أن الإعلان عن الرسالة يجب ألا يعتمد على حصولها على تركيز لوحة المفاتيح أو التركيز البرمجي.

ينطبق هذا المعيار على أي محتوى مكتوب بلغة ترميز (HTML، SVG، إلخ) ويغطي أربع فئات عامة من رسائل الحالة التي تعترف بها WCAG:

• رسائل النجاح: تأكيدات مثل "تم تقديم طلبك" أو "تم حفظ الإعدادات بنجاح."
• رسائل الخطأ أو التحذير: تغذية راجعة للتحقق من الصحة مثل "عنوان البريد الإلكتروني غير صالح" أو "يرجى إكمال جميع الحقول المطلوبة."
• رسائل التقدم أو تحديثات الحالة: رسائل مثل "جاري التحميل… يرجى الانتظار" أو "اكتمل التحميل بنسبة 60%."
• رسائل تغيير السياق: تحديثات ديناميكية مثل "تم العثور على 5 نتائج" أو "3 عناصر في سلة التسوق الخاصة بك."

تُعتبَر الرسالة مستوفية لهذا المعيار عندما تُسنَد إليها خاصية أو دور مناسب لمنطقة ARIA حية — وغالباً ما يكون role="status" أو role="alert" أو aria-live="polite" أو aria-live="assertive" — بحيث تقوم برامج قراءة الشاشة بالإعلان عنها تلقائياً عند ظهورها أو تغيّرها، دون حاجة المستخدم للانتقال إليها باستخدام المفتاح Tab.

وتُعتبَر الرسالة غير مستوفية عندما تُحقَن ديناميكياً في DOM (عبر JavaScript) دون أي دلالات لمنطقة حية، مما يترك مستخدمي برامج قراءة الشاشة غير مدركين لحدوث أي تغيير في الصفحة.

استثناء مهم تحدده WCAG: إذا تم تقديم رسالة الحالة عن طريق نقل التركيز إلى عنصر الرسالة (على سبيل المثال، حوار يحصل على التركيز، أو مربع حوار alert())، فإن المعيار لا ينطبق على هذا التفاعل — إذ إن حركة التركيز نفسها تفي بالحاجة. يختص هذا المعيار تحديداً بالرسائل التي تظهر دون تغيير في التركيز.

لماذا يهم هذا الأمر

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

المستخدمون ذوو الإعاقات الحركية الذين يعتمدون على الوصول بالمفاتيح التبادلية (switch access) أو تقنيات تتبع العين يتأثرون بنفس القدر. غالباً لا يستطيع هؤلاء المستخدمون مسح الصفحة بسرعة بحثاً عن محتوى جديد؛ بل يعتمدون على تقنيات المساعدة لجلب المعلومات ذات الصلة إليهم. بدون إعلانات المناطق الحية، تصبح كل رسالة حالة مشكلة "إبرة في كومة قش".

كما يستفيد المستخدمون ذوو التنوع المعرفي: فالتغذية الراجعة الواضحة والفورية تؤكد اكتمال الإجراء وتقلل العبء المعرفي الناجم عن عدم اليقين. عندما تعلن تقنيات المساعدة "تمت إضافة العنصر إلى السلة"، لا يحتاج المستخدم ذو الإعاقة المعرفية إلى البحث بصرياً عن تأكيد قبل المتابعة.

سيناريو واقعي ملموس: مستخدم كفيف يملأ نموذج تأمين متعدد الحقول على موقع بنك تركي. يقوم بإرسال النموذج، لكن التحقق من صحة البيانات على جانب العميل يعمل ويعرض خمس رسائل خطأ باللون الأحمر بالقرب من الحقول. وبسبب عدم وجود منطقة حية، يظل قارئ الشاشة الخاص بالمستخدم (JAWS أو NVDA) صامتاً. يفترض المستخدم أن النموذج تم إرساله بنجاح ويغلق علامة تبويب المتصفح — فيفقد طلب التأمين بالكامل. مع تطبيق صحيح لـ role="alert" أو منطقة حية تلخص الأخطاء، كانت تقنيات المساعدة ستعلن فوراً "تم العثور على 3 أخطاء. يرجى مراجعة الحقول المميزة"، مما يتيح للمستخدم تصحيح المشكلات.

من منظور الأعمال، يؤدي عدم إتاحة رسائل الحالة إلى الإضرار مباشرة بمعدلات التحويل. يعيش حوالي 1.3 مليار شخص حول العالم مع شكل من أشكال الإعاقة، وضمان إتاحة رسائل الحالة يقلل من التخلي عن النماذج، وحجم تذاكر الدعم، والمخاطر القانونية المرتبطة بعدم الامتثال. بالنسبة للمنظمات التركية، قد يشكل عدم الإتاحة أيضاً انتهاكاً لقانون الإعاقة رقم 5378 والالتزامات الجديدة الواردة في التعميم الرئاسي الموضحة لاحقاً في هذه المقالة.

قواعد axe-core ذات الصلة

• aria-live (آلياً): تتحقق قاعدة aria-live في axe-core من أن العناصر التي تستخدم خاصية aria-live قد أُسنِدت إليها إحدى القيم الصالحة: off أو polite أو assertive. وتُعلِم عن العناصر التي تم تعيين aria-live لها بقيمة غير صالحة أو بها خطأ إملائي (مثل aria-live="true" أو aria-live="yes")، والتي قد تؤدي إلى تجاهل المنطقة الحية بصمت من قِبل تقنيات المساعدة. تضمن هذه القاعدة أنه عندما يعتزم المطورون إنشاء منطقة حية، يتم تشكيل الخاصية بشكل صحيح بحيث تحترمها برامج قراءة الشاشة فعلياً.
• الاختبار اليدوي (مطلوب للتغطية الكاملة): لا يمكن للأدوات الآلية تدقيق معيار WCAG 4.1.3 بالكامل لأن نمط الفشل الأساسي هو غياب منطقة حية على رسالة يتم إنشاؤها ديناميكياً — وهو غياب يصعب على تحليل الشيفرة الساكنة اكتشافه بشكل موثوق. لا يمكن للأداة التي تفحص DOM قبل تفاعل المستخدم أن تعرف أي العناصر ستصبح لاحقاً رسائل حالة. قد لا يقوم axe-core بالإبلاغ عن <div> سيستقبل نصاً مُحقناً بعد نقر زر، لأن هذا العنصر يكون فارغاً أو غير موجود عند وقت الفحص. لذلك يُعد الاختبار اليدوي باستخدام قارئ شاشة فعّال أمراً أساسياً: يجب على المختبِر تشغيل رسالة الحالة والاستماع للإعلان. إذا لم يُسمَع أي إعلان ولم يتحرك التركيز، يفشل المعيار بغض النظر عما تُبلِغ عنه الأدوات الآلية.

كيفية الاختبار

1. فحص آلي باستخدام axe DevTools أو Lighthouse: ثبّت إضافة المتصفح axe DevTools (Chrome أو Firefox) وأجرِ فحصاً كاملاً للصفحة. ابحث عن أي انتهاكات تحت قاعدة aria-live. تحقق أيضاً من المشكلات المُعلَمة تحت سوء استخدام aria-roledescription أو aria-atomic. تذكّر أن الفحص الآلي النظيف لا يعني أن المعيار 4.1.3 مستوفى — بل يعني فقط أنه لم يتم العثور على خصائص مناطق حية مشكّلة بشكل خاطئ. دوّن جميع العناصر المُعلَمة وقم بحلها قبل الانتقال إلى الخطوات اليدوية.
2. تحديد جميع رسائل الحالة الديناميكية: راجع الصفحة وملفات JavaScript الخاصة بها لحصر كل تفاعل للمستخدم ينتج رسالة حالة دون إعادة تحميل الصفحة أو تغيير التركيز. تشمل الأمثلة الشائعة: تغذية راجعة لإرسال النماذج، شارات كمية السلة، عدد نتائج البحث، تقدم تحميل الملفات، تأكيدات الاشتراك في النشرات البريدية، تحديثات نتائج الفلاتر، وتحذيرات انتهاء الجلسة.
3. اختبار يدوي باستخدام NVDA + Firefox: افتح الصفحة مع تشغيل NVDA. قم بتشغيل كل رسالة حالة تم حصرها (إرسال نموذج، إضافة عنصر إلى السلة، إجراء بحث). استمع بعناية — يجب أن يعلن NVDA نص الرسالة تلقائياً خلال ثانية أو ثانيتين. إذا لم تسمع شيئاً ولم يتحرك التركيز، يفشل المعيار. استخدم عارض الكلام في NVDA (Tools > Speech Viewer) لرؤية سجل نصي لجميع الإعلانات للتحقق من الدقة.
4. اختبار يدوي باستخدام JAWS + Chrome: كرر التفاعلات نفسها باستخدام JAWS. تأكد من أن رسائل role="status" تُعلَن بمقاطعة مهذبة، وأن رسائل role="alert" تقاطع القراءة فوراً. تحقق من أن JAWS لا يعلن الرسالة نفسها عدة مرات بسبب إعدادات غير صحيحة لـ aria-atomic أو aria-relevant.
5. اختبار يدوي باستخدام VoiceOver + Safari (macOS/iOS): استخدم VoiceOver على macOS مع Safari وكرر التفاعلات نفسها. لاحظ أن تعامل VoiceOver مع aria-live قد يختلف قليلاً عن برامج قراءة الشاشة على Windows — تأكد من حدوث الإعلانات وأن صياغتها منطقية.
6. فحص DOM بعد التفاعل: باستخدام أدوات تطوير المتصفح، قم بتشغيل رسالة الحالة ثم افحص العنصر الذي ظهر. تأكد من أنه يحتوي على role="status" أو role="alert" أو خاصية aria-live صالحة. إذا تم حقن الرسالة كنص عادي داخل حاوية غير مميزة، فهذا فشل. تحقق أيضاً من أن حاوية المنطقة الحية كانت موجودة في DOM قبل حقن الرسالة — إذ تعلن برامج قراءة الشاشة فقط عن التغييرات في المناطق الحية الموجودة مسبقاً، وليس العناصر التي أُدرِجت حديثاً في DOM.

كيفية الإصلاح

ملخص التحقق من صحة النموذج — غير صحيح

<!-- Error summary injected after failed submission -->
<div id='error-summary' class='error-box'>
  <p>Please fix the following errors before submitting:</p>
  <ul>
    <li>Email address is required.</li>
    <li>Password must be at least 8 characters.</li>
  </ul>
</div>
<!-- Problem: no role or aria-live attribute; screen readers will not announce this -->

ملخص التحقق من صحة النموذج — صحيح

<!-- role="alert" causes immediate announcement when content is injected -->
<div id='error-summary' role='alert' class='error-box'>
  <p>Please fix the following errors before submitting:</p>
  <ul>
    <li>Email address is required.</li>
    <li>Password must be at least 8 characters.</li>
  </ul>
</div>
<!-- The container must be present in the DOM before JavaScript injects content into it -->

عدد عناصر سلة التسوق — غير صحيح

<!-- Cart badge updated via JavaScript after user clicks "Add to cart" -->
<button id='add-to-cart'>Add to Cart</button>
<span id='cart-count' class='badge'>0</span>
<!-- Problem: cart-count has no live region; update from 0 to 1 is silent to screen readers -->

عدد عناصر سلة التسوق — صحيح

<!-- Separate polite live region announces cart update without interrupting the user -->
<button id='add-to-cart'>Add to Cart</button>
<span id='cart-count' class='badge' aria-hidden='true'>1</span>

<!-- Visually hidden live region provides the announcement -->
<div
  id='cart-status'
  role='status'
  aria-live='polite'
  aria-atomic='true'
  class='visually-hidden'
>
  <!-- JavaScript updates this text: "1 item in your cart" -->
</div>
<!-- aria-atomic="true" ensures the full sentence is read, not just the changed number -->

عدد نتائج البحث — غير صحيح

<!-- Results count rendered after AJAX search -->
<p id='results-info'>Showing 24 of 140 results for "laptop"</p>
<!-- Problem: element is replaced entirely via innerHTML; no live region present -->

عدد نتائج البحث — صحيح

<!-- Live region pre-exists in the DOM; JavaScript updates its content after search -->
<p
  id='results-info'
  role='status'
  aria-live='polite'
  aria-atomic='true'
>
  Showing 24 of 140 results for "laptop"
</p>
<!-- role="status" implies polite + atomic; explicit attributes added for clarity and compatibility -->

تقدم تحميل الملف — غير صحيح

<!-- Progress percentage injected into DOM during upload -->
<div class='progress-container'>
  <div class='progress-bar' style='width: 60%'></div>
  <span id='progress-text'>60%</span>
</div>
<!-- Problem: percentage updates are visual only; no announcement to AT -->

تقدم تحميل الملف — صحيح

<!-- Use aria-valuenow on a progressbar role, plus a separate polite status for milestones -->
<div class='progress-container'>
  <div
    role='progressbar'
    aria-valuenow='60'
    aria-valuemin='0'
    aria-valuemax='100'
    aria-label='File upload progress'
    class='progress-bar'
    style='width: 60%'
  >
  </div>
</div>
<div
  id='upload-status'
  role='status'
  aria-live='polite'
  aria-atomic='true'
  class='visually-hidden'
>
  Upload complete. Your file has been saved.
</div>
<!-- Only announce key milestones (25%, 50%, 75%, complete) to avoid over-announcement -->

الأخطاء الشائعة

• إنشاء عنصر المنطقة الحية في نفس وقت الرسالة: إضافة role="alert" إلى عنصر DOM تم إنشاؤه للتو وملؤه بالمحتوى فوراً غالباً ما يفشل لأن برامج قراءة الشاشة لم تسجل بعد العقدة الجديدة كمنطقة حية. احرص دائماً على عرض الحاوية الفارغة عند تحميل الصفحة ثم تحديث محتواها النصي فقط عندما تكون رسالة الحالة جاهزة.
• استخدام aria-live="assertive" للرسائل غير العاجلة: تقاطع المناطق الحية من النوع assertive ما يقرؤه قارئ الشاشة في تلك اللحظة. استخدام assertive للرسائل الروتينية مثل "تمت إضافة العنصر إلى السلة" سيُحبط المستخدمين بسبب قطع تدفق القراءة باستمرار. احتفظ بـ assertive (أو role="alert") للأخطاء أو التحذيرات الحساسة للوقت؛ واستخدم polite لكل ما عدا ذلك.
• تعيين aria-live لقيمة غير صالحة مثل "true" أو "1": القيم الصالحة الوحيدة هي "off" و"polite" و"assertive". القيم غير الصالحة تعطل المنطقة الحية بصمت دون تحذير من المتصفح، مما يدفع قاعدة aria-live في axe-core إلى الإبلاغ عن العنصر.
• الاعتماد فقط على اللون أو الأيقونات للتعبير عن الحالة: أيقونة علامة صح خضراء أو إطار أحمر يُحقَن في الصفحة هو إشارة بصرية فقط. بدون نص مصاحب في منطقة حية، لا يتلقى مستخدمو برامج قراءة الشاشة أي معلومات. احرص دائماً على إقران المؤشرات البصرية بإعلان نصي في منطقة حية.
• إهمال aria-atomic="true" عند تحديث جزء من جملة: إذا قام JavaScript بتحديث رقم فقط داخل جملة (مثل تغيير "3" إلى "4" في "4 items in cart")، فبعض برامج قراءة الشاشة ستعلن العقدة المتغيرة فقط، قائلة "4" دون سياق. يوضح تعيين aria-atomic="true" على الحاوية لتقنيات المساعدة أنه يجب قراءة المنطقة بأكملها كوحدة واحدة.
• الإعلان عن كل تحديث تقدّم تدريجي: حقن رسالة حالة جديدة كل ثانية أثناء تحميل ملف ("10%"، "11%"، "12%"…) يغمر المستخدم بالإعلانات ويجعل قارئ الشاشة غير قابل للاستخدام. أعلن فقط عن المحطات المهمة أو حالة الاكتمال النهائية.
• وضع حاوية المنطقة الحية داخل عناصر تُخفى بشكل شرطي باستخدام display:none أو visibility:hidden: المنطقة الحية داخل عنصر أب مخفي تكون خاملة ولن تعلن أي شيء، حتى لو كان عنصر المنطقة الحية نفسه مرئياً. تأكد من أن سلسلة الأسلاف لحاوية المنطقة الحية ليست مخفية وقت الإعلان.
• استخدام role="alert" لرسائل النجاح التي تظهر بعد التنقل: عندما تستمر رسالة حالة عبر إعادة تحميل الصفحة (مثل رسالة فلاش يتم عرضها من جانب الخادم بعد إعادة التوجيه)، قد يؤدي استخدام role="alert" إلى إعلانات مكررة أو عدوانية للغاية. فكّر في استخدام role="status" أو نقل التركيز إلى منطقة الرسالة بدلاً من ذلك، بحيث يندمج الإعلان بشكل طبيعي في تنقل المستخدم.
• افتراض أن مكتبات التلميحات أو التوست تتعامل مع المناطق الحية تلقائياً: العديد من مكتبات مكونات واجهة المستخدم الشائعة (مثل Bootstrap Toasts وأنظمة التلميحات المخصصة) لا تضيف خصائص مناطق ARIA الحية افتراضياً. افحص دائماً HTML الناتج عن المكونات الخارجية وأضف role="status" أو aria-live عند غيابه.
• عدم الاختبار باستخدام برامج قراءة شاشة حقيقية قبل الإصدار: لا يمكن للأدوات الآلية مثل axe اكتشاف غياب منطقة حية على رسالة حالة ديناميكية. الاعتماد فقط على التدقيق الآلي سيترك حالات فشل 4.1.3 دون اكتشاف. اجعل الاختبار اليدوي باستخدام برامج قراءة الشاشة — مثل NVDA وJAWS وVoiceOver — جزءاً معيارياً من عملية ضمان الجودة لأي ميزة تولّد تغذية راجعة ديناميكية.

العلاقة مع لوائح الإتاحة في تركيا

يُرسّخ التعميم الرئاسي رقم 2025/10 في تركيا، المنشور في الجريدة الرسمية رقم 32933 بتاريخ 21 June 2025، التزامات ملزمة بشأن الإتاحة الرقمية لمجموعة واسعة من المنظمات العاملة في تركيا. يشير التعميم إلى WCAG 2.1 وWCAG 2.2 باعتبارهما المعيار التقني للامتثال، ويتطلب صراحة الالتزام بمستوى AA كخط أساس لمعظم الكيانات المشمولة.

يُعد معيار WCAG 4.1.3 الخاص برسائل الحالة معياراً من مستوى AA، ما يعني أنه يقع مباشرة ضمن النطاق الإلزامي للتعميم لجميع الكيانات المشمولة. تشمل أنواع المنظمات التالية على وجه التحديد:

• المؤسسات والهيئات العامة — يجب على جميع الهيئات الحكومية المركزية والمحلية والوزارات والبلديات والمؤسسات المملوكة للدولة تحقيق الامتثال بمستوى AA عبر خدماتها الرقمية.
• البنوك والمؤسسات المالية — الخاضعة لرقابة هيئة التنظيم والرقابة المصرفية (BDDK)، وتقدم هذه الكيانات خدمات إلكترونية حيوية (الخدمات المصرفية عبر الإنترنت، طلبات القروض، إدارة البطاقات) حيث تكون تغذية الحالة الديناميكية — مثل تأكيدات المعاملات، ورسائل الخطأ، وتحديثات الأرصدة — شائعة للغاية. تؤدي حالات الفشل في 4.1.3 إلى إعاقة الاستقلال المالي للمستخدمين ذوي الإعاقة بشكل مباشر.
• منصات التجارة الإلكترونية — تُعد التجارة الإلكترونية حالة استخدام رئيسية لرسائل الحالة (تحديثات السلة، تأكيدات الطلب، تنبيهات المخزون). يجب على مشغلي التجارة الإلكترونية ضمان أن تكون هذه الإشعارات الديناميكية متاحة لجميع المستخدمين.
• المستشفيات والمؤسسات الصحية — تستخدم أنظمة حجز المواعيد وبوابات نتائج الفحوصات ولوحات معلومات المرضى رسائل الحالة بشكل متكرر. قد يكون لعدم إتاحة المعلومات الصحية عواقب خطيرة على المرضى ذوي الإعاقة.
• شركات الاتصالات التي لديها 200,000 مشترك أو أكثر — يجب أن تمتثل بوابات إدارة الحسابات وإشعارات الفواتير وتحديثات حالة الخدمة جميعها لمستوى AA، بما في ذلك 4.1.3.
• وكالات السفر وشركات النقل الخاصة — تُعد تأكيدات الحجز، وتغذية اختيار المقاعد، ورسائل تحديث خط السير عناصر أساسية في تجربة المستخدم ويجب أن تكون قابلة للتحديد برمجياً.
• المدارس الخاصة والمؤسسات التعليمية المرخّصة من وزارة التربية الوطنية (MoNE) — يجب أن تتيح أنظمة إدارة التعلم وبوابات الدرجات ومنصات التسجيل رسائل الحالة بشكل متاح لخدمة جميع الطلاب وأولياء الأمور.

يُعد شعار الإتاحة (Erişilebilirlik Logosu)، الصادر عن وزارة الأسرة والخدمات الاجتماعية، علامة الاعتماد الرسمية للمواقع والتطبيقات التركية المتاحة رقمياً. لكي تكون المنظمة مؤهلة للحصول على الشعار، يجب أن تُظهر امتثالاً كاملاً لمستوى AA — بما في ذلك 4.1.3. ونظراً لأن رسائل الحالة منتشرة في واجهات الويب الحديثة، ينبغي على أي منظمة تسعى للحصول على Erişilebilirlik Logosu أن تتعامل مع 4.1.3 كعنصر تدقيق إلزامي وأن تطبق أنماط المناطق الحية بشكل متسق عبر جميع مناطق المحتوى الديناميكي.

تخاطر المنظمات غير الممتثلة بالتعرض لإجراءات إدارية بموجب التعميم، وفقدان الأهلية للحصول على شعار الإتاحة، والضرر بسمعتها في سوق يزداد وعياً بقضايا الإتاحة. إن التطبيق الصحيح لمعيار WCAG 4.1.3 ليس مجرد خانة فنية للتأشير — بل هو استثمار ملموس في الوصول الرقمي المتكافئ لما يقرب من 8.5 مليون مواطن في تركيا يعيشون مع إعاقة.