مختبر يختبر رسائل الحالة لقارئ الشاشة: مشاريع تخرج تطوير الويب

يضغط الطالب زر حفظ نموذج طويل، فتظهر عبارة «تم الحفظ» أعلى الصفحة من دون أن ينتقل التركيز إليها. يرى المستخدم المبصر التغيير، لكن مستخدم قارئ الشاشة قد لا يعرف أن العملية انتهت. يمكن لمشاريع تخرج تطوير الويب إنشاء منصة صغيرة لاختبار رسائل الحالة في واجهات عربية؛ تعرض متى تغير النص، ودلالته في شجرة الوصول، وما إذا كان نقل التركيز ضرورياً أم سيقطع المستخدم عن عمله. لا تحكم المنصة على المطابقة من لون أو لقطة شاشة.

ما المقصود برسالة الحالة؟

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

لا تصمم حلاً واحداً لكل رسالة. تنبيه مهم وعاجل قد يناسب نمط alert، بينما تحديث متكرر صغير يمكن أن يكون status أقل إزعاجاً. يشرح دليل WAI-ARIA APG لنمط alert أن التنبيه الديناميكي يعلن للمستخدم عادة من دون تغيير تركيز لوحة المفاتيح، ويحذر من تحويله إلى نافذة حوار عندما لا تتطلب الحالة مقاطعة. استخدم هذه المصادر كإطار للفحص، لا كقائمة تمنح حكماً آلياً على تجربة كل مستخدم.

ابنِ حالات يمكن تكرارها

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

سجل عناصر DOM قبل الإجراء وبعده، نص الرسالة ودورها وخصائصها، موضع التركيز، والتوقيت بين فعل المستخدم والتحديث. لا تسجل صوت المستخدم أو أي معلومات شخصية من جهازه. قد يختلف سلوك الإعلان باختلاف قارئ الشاشة والمتصفح وإعداداته؛ سجل هذه المجموعة كما اختبرها الفريق. إذا لم يكن الاختبار الآلي قادراً على رصد الكلام الفعلي، ضع النتيجة «تحتاج اختباراً يدوياً» بدلاً من تحويل وجود aria-live إلى إثبات أن الإعلان وصل.

مسار تجربة واضح

شغل الصفحة في المتصفح، ضع التركيز على زر الحفظ، ثم فعّل الإجراء باستخدام لوحة المفاتيح. راقب بقاء focus في موضع منطقي، وراقب تحديث accessibility tree؛ بعد ذلك اطلب من مختبر يستخدم قارئ شاشة أن يسجل الإعلان الفعلي وخطواته إن أمكن. للمقارنة، اعرض نسخة لا تحتوي رسالة برمجية ونسخة معدلة، مع المكونات المرئية نفسها. يجب أن يكون لكل حالة رقم إصدار كي لا تنسب نتيجة نسخة إلى أخرى.

مثال: يبحث الطالب عن كتاب، فتتغير القائمة إلى «لم نعثر على نتائج». النموذج يعرض أن الرسالة تغيرت وأنها ضمن العنصر ذي الدلالة المعلنة. إذا نقلت الواجهة focus إلى رأس الصفحة في كل تحديث، يسجل المختبر المقاطعة كحالة مستقلة. لا نقول إن ذلك أخفق لمجرد وجود تغيير؛ يحدد الفريق هل نقل focus يخدم المستخدم أو يعطل تتابع البحث. وثق القرار مع معيار الاختبار لا مع ذوق المصمم فقط.

افحص العربية والاتجاه

أضف حالات للنص العربي المختلط بأرقام أو اسم ملف إنجليزي، وتحقق من ترتيب القراءة ومن أن عناصر الرسالة لا تنقطع عند التحديث. قد يختلف موضع رمز الحالة بصرياً عن ترتيبه في شجرة الوصول، لذلك افصل فحص الاتجاه عن فحص الإعلان. لا تضع نص الرسالة داخل صورة أو canvas. اجعل العبارات قصيرة ومباشرة: ما الذي انتهى؟ هل هناك خطوة تالية؟ وإذا وقع خطأ، كيف يصل المستخدم إلى الحقل المطلوب دون فقد موضعه؟

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

اختبارات القبول

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

اختبر الرسالة عند حدوث تحديثين متتاليين، وعند بقاء العنصر في DOM مع تغير النص، وعند إضافة العنصر بعد تحميل الصفحة. سجل حالات المتصفح أو قارئ الشاشة التي ظهر فيها فرق. إذا تناقضت نتيجة الأداة مع المراجعة البشرية، احتفظ بالتناقض كي يعاد فحصه. يمكن أن تكون المخرجات لوحة تقارير وقائمة إصلاحات، لكنها لا تصنف الموقع كله «متاحاً» من اختبار واحد.

حدود المشروع وتسليمه

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

في التقرير، أدرج السيناريو، المتوقع، النتيجة الآلية، نتيجة المختبر اليدوي، والقيود. لا تحتفظ بأسماء أو أصوات المشاركين داخل نسخة عامة. بيّن أن معيار W3C يحدد هدفاً للسلوك، لكن التنفيذ قد يتطلب تقييماً للسياق والوسيط. يكون النجاح أن يعرف الفريق أين اختبر وما بقي مجهولاً، لا أن يضع علامة صح على كل سطر في فحص سريع.