ما الاختبارات التي يجب أن يجتازها نموذج التواصل قبل الإطلاق؟

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

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

افحص اسم الحقل الظاهر وارتباطه البرمجي بعنصر الإدخال. توصي إرشادات W3C بتسميات وصفية مرتبطة بعناصرها. قد يساعد النص المؤقت داخل الحقل على شرح الصيغة، لكنه يختفي عند الكتابة؛ ولذلك لا ينبغي أن يتحمل وحده مهمة تعريف الحقل.

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

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

المراجع: W3C WAI: associated form labels

تنقّل بلوحة المفاتيح وراقب انتقال التركيز بين العناصر. يحتاج كل عنصر تفاعلي إلى حالة تركيز مرئية، ويجب ألا يحجب العنوان الثابت أو شريط الموافقة العنصر النشط. افحص تسلسل التنقل الفعلي؛ فانعكاس الشكل العربي لا يبرر ترتيب قراءة أو تعامل مربكاً.

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

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

المراجع: W3C Internationalization: text direction and dir=auto · W3C WCAG 2.2: visible keyboard focus · W3C WCAG 2.2: focus not obscured

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

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

مرّر الجدول أفقيًا لقراءة جميع الأعمدة.

المراجع: W3C WAI: form error and success notifications · W3C WCAG 2.2: error identification

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

للرسائل التي تظهر ديناميكياً، اطلب من المطوّر عرض الإعلان عنها باستخدام قارئ شاشة مدعوم. لا تحكم بسهولة الوصول لمجرد وجود خاصية aria في الكود. سجّل المتصفح والتقنية المساعدة والخطوات والنتيجة المرصودة.

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

1. أكمل النموذج ببيانات اصطناعية ولوحة المفاتيح، وسجّل ترتيب التركيز ووضوحه.
2. أدخل خطأ واحداً وافحص اسم الحقل وشرح المشكلة وطريق العودة إليه.
3. اختبر أخطاء متعددة وتأكد من أن اللون ليس الوسيلة الوحيدة لاكتشاف أي منها.
4. صحّح القيم وتحقق من الاحتفاظ بالمدخلات المفيدة ووضوح الحالة التالية.
5. حاكِ تعطل مزوّد الاستقبال في بيئة معزولة وتأكد من عدم إعلان النجاح.
6. افحص حالة النجاح والخطوة التالية الموثّقة دون اختراع وعد بزمن رد.

المراجع: W3C WAI: form error and success notifications

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

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

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

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

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

أُعدّ هذا الدليل بمساعدة الذكاء الاصطناعي، مع فحص المعلومات المتعلقة بالمنصات مقابل المراجع الأصلية أدناه وقت النشر. أطر القرار وقوائم الفحص توصيات تحريرية من بياواي؛ الأمثلة الموصوفة بأنها توضيحية ليست قصص عملاء أو نتائج فعلية. قد تتغير واجهات المنصات وشروطها.

• W3C WAI: associated form labels
• W3C WAI: form error and success notifications
• W3C Internationalization: text direction and dir=auto
• W3C WCAG 2.2: visible keyboard focus
• W3C WCAG 2.2: error identification
• W3C WCAG 2.2: focus not obscured