متطلبات إمكانية الوصول والتدويل

متطلبات إمكانية الوصول والتدويل

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

لماذا يتولى المحلل هذه المتطلبات؟

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

أساسيات إمكانية الوصول للمحللين

المعيار الدولي الرئيسي هو WCAG 2.2 (إرشادات إمكانية الوصول لمحتوى الويب)، المنظَّم حول أربعة مبادئ: القابلية للإدراك، والقابلية للتشغيل، والقابلية للفهم، والمتانة — ويُحفظ اختصارها بـPOUR. يحتوي كل مبدأ على معايير نجاح عند مستويات: A (الحد الأدنى)، وAA (مستهدف الامتثال القياسي لمعظم الأنظمة التجارية والحكومية)، وAAA (المعزّز).

• القابلية للإدراك: كل محتوى غير نصي له بديل نصي (نص alt للصور، تعليقات توضيحية للفيديو). اللون وحده لا يكون أبداً الوسيلة الوحيدة لنقل المعلومات. الحد الأدنى لنسبة التباين 4.5:1 للنص العادي (WCAG AA).
• القابلية للتشغيل: جميع الوظائف قابلة للوصول عبر لوحة المفاتيح وحدها. لا تتطلب أي تفاعل أكثر من إيماءة مؤشر واحدة دون بديل لوحة مفاتيح. تنبّه مهلات الجلسة المستخدمين وتتيح التمديد.
• القابلية للفهم: حقول النماذج لها تسميات مرئية (لا نص عنصر نائب فحسب). تُحدّد رسائل الخطأ الحقلَ، وتصف المشكلة، وتقترح تصحيحاً. يُعلَن عن لغة الصفحة في الترميز.
• المتانة: الترميز صالح وقابل للتحليل من قِبَل التقنيات المساعدة. تُستخدم أدوار ARIA والمناطق الحية استخداماً صحيحاً — لا للزينة.

دورك كمحلل هو ترجمة هذه المبادئ إلى معايير قبول قابلة للاختبار. "يجب أن يكون النظام قابلاً للوصول" ليس متطلباً. "يجب أن تحتوي جميع حقول إدخال النماذج على تسميات مرتبطة برمجياً؛ يتحقق من ذلك فحص axe الآلي الذي لا يُرجع أي انتهاكات حرجة" — هذا هو المتطلب.

متطلبات التدويل (i18n)

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

أبعاد التدويل الرئيسية التي يجب تحديدها:

• اتجاه النص: اللغات العربية والعبرية والفارسية والأردية تُكتب من اليمين إلى اليسار (RTL). منصة لوجستية تتوسع في أسواق الخليج يجب أن تنص على: "يجب أن تدعم الواجهة تخطيط RTL الكامل. يجب استخدام القيم المنطقية (start/end) لا الفيزيائية (left/right). يُتحقق من انعكاس الصفحة على Chrome وFirefox."
• تنسيقات التاريخ والوقت: اللحظة الزمنية ذاتها تظهر 06/10/2026 في أمريكا، و10/06/2026 في بريطانيا، و10 يونيو 2026 بالعربية — أو بالتقويم الهجري في سياقات معينة. حدّد مكتبة التنسيق المدركة للمنطقة وأنظمة التقويم المطلوب دعمها.
• تنسيقات الأرقام والعملات: 1,234.56 (أمريكي) مقابل 1.234,56 (ألماني) مقابل ١٢٣٤٫٥٦ (أرقام عربية هندية). أنظمة العملات المتعددة تستلزم تحديد الدقة، وقواعد التقريب، وموضع الرمز.
• فصل النصوص: يجب تخزين جميع النصوص المعروضة للمستخدم (تسميات، رسائل خطأ، تلميحات، قوالب بريد) في ملفات موارد، لا مُضمَّنة في الكود أبداً. حدّد صيغة المفتاح-القيمة (JSON، YAML، مصفوفات PHP) وسير عمل الترجمة.
• التوسع النصي: الترجمات الألمانية والعربية للنصوص الإنجليزية أطول عادةً بنسبة 30-40%. يجب أن تستوعب التخطيطات هذا التوسع دون كسر. حدّد حدوداً دنيا وعليا لعدد الأحرف في عناصر UI المقيّدة كالتنقل والأزرار.
• الفرز والترتيب الأبجدي: الترتيب الأبجدي في العربية لا يتبع ترتيب نقاط كود يونيكود. نظام يعرض قائمة أسماء منتجات عربية مرتبة يجب أن يستخدم ترتيباً مدركاً للمنطقة.

تخطيط RTL: ماذا يتغير وماذا تحدد

بالنسبة لنظام يجب أن يدعم العربية أو العبرية، يجب على المحلل توثيق ما يلي في مواصفة متطلبات واجهة المستخدم:

• التخطيط بأكمله يُعكس أفقياً: التنقل الرئيسي ينتقل من اليسار إلى اليمين، ويتعكس ترتيب التنقل والقراءة، وتنقلب الأيقونات ذات المعنى الاتجاهي (الأسهم، مؤشرات التقدم).
• حقول النماذج تبقى محاذاة لليسار عند كتابة أحرف لاتينية (يكتشفها المتصفح تلقائياً)، لكن التسميات والتخطيط المحيط يبقيان RTL.
• الجداول: تدفق رؤوس الأعمدة وبيانات الصفوف من اليمين إلى اليسار. الأعمدة الرقمية (الأسعار، الكميات) يمكن إبقاؤها LTR داخل جدول RTL.
• الصور: صورة رئيسية لشخص "ينظر نحو المحتوى" يجب انعكاسها بحيث ينظر الشخص يساراً (نحو المحتوى) في RTL.

توثيق متطلبات إمكانية الوصول والتدويل

تنتمي هذه المتطلبات إلى قسم المتطلبات غير الوظيفية (NFR) في مواصفة متطلبات البرمجيات (SRS)، أو كقسم فرعي مخصص لـإمكانية الوصول والتدويل. استخدم لغة SHALL / SHOULD / MAY ذاتها وتأكد من قابلية كل متطلب للاختبار.

جمع هذه المتطلبات من أصحاب المصلحة

نادراً ما يُفصح أصحاب المصلحة طوعاً عن احتياجات إمكانية الوصول والتدويل. يجب على المحلل السؤال مباشرة:

• "هل من المحتمل أن يستخدم أي من مستخدميكم تقنيات مساعدة — قارئات شاشة، أو التحكم الصوتي، أو مفاتيح التبديل؟"
• "هل لدى مؤسستكم التزام قانوني أو تنظيمي بتحقيق مستوى WCAG AA؟" (الجهات الحكومية في الاتحاد الأوروبي والمملكة المتحدة والولايات المتحدة غالباً ما تمتلك هذا الالتزام.)
• "ما الدول أو أسواق اللغات التي سيخدمها هذا النظام الآن، وخلال العامين المقبلين؟"
• "هل أي من الأسواق المستهدفة ناطقة أساساً بلغات RTL؟"
• "من سيتولى إدارة الترجمات — فريق داخلي، أم وكالة ترجمة، أم مجتمع مفتوح؟"

التحقق من إمكانية الوصول والتدويل في النماذج الأولية

حتى النموذج الأولي HTML عالي الدقة يمكن تقييمه جزئياً مقابل متطلبات إمكانية الوصول والتدويل قبل بدء التطوير:

• شغّل تدقيق axe DevTools أو Lighthouse على النموذج الأولي القابل للنقر لاكتشاف التسميات المفقودة وإخفاقات التباين والمعالم الناقصة.
• استخدم إضافة متصفح (مثل NoCoffee Vision Simulator) لمحاكاة ضعف البصر وعمى الألوان والرؤية الضبابية على شاشات النموذج.
• اختبر النموذج بقارئ شاشة (NVDA + Firefox على ويندوز، VoiceOver + Safari على macOS) — تنقّل عبر التدفق الرئيسي بعيون مغلقة.
• للتدويل، بدّل النموذج إلى أطول ترجمة وتأكد من عدم تجاوز العناصر حدودها. لـRTL، طبّق dir="rtl" على عنصر جذر النموذج وافحص التخطيط.

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