تحديد الهدف قبل طلب عروض الأسعار

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

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

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

الاتفاق على المعايير ونطاق التدقيق

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

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

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

تُطلب من جهة التدقيق آلية واضحة لاختيار العينة. وتعرض إرشادات W3C لتقييم التوافق منهجية تشمل تحديد النطاق، واستكشاف الموقع، واختيار صفحات ممثلة له، وتقييمها، وتوثيق النتائج. ولا يثبت العدد الكبير من الصفحات وحده أن التفاعلات المهمة قد اختُبرت.

تقييم منهجية الاختبار

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

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

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

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

التحقق من خبرة الخدمات ثنائية اللغة والتقنيات المساعدة

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

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

يجب تسمية بيئات اختبار التقنيات المساعدة، بما يشمل قارئ الشاشة ونظام التشغيل والمتصفح. ويُطلب توضيح سبب اختيارها والتفاعلات التي ستُختبر فيها. فذكر NVDA أو JAWS أو VoiceOver في العرض لا يثبت وحده وجود منهجية اختبار مناسبة.

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

طلب نموذج لتقرير تدقيق إمكانية الوصول الرقمي

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

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

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

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

التمييز بين التدقيق والمعالجة وتوثيق التوافق

يحدد التدقيق العوائق ويوثّقها، بينما تغيّر المعالجة المنتج، وتتحقق إعادة الاختبار من التعديلات. وقد تقدّم جهة واحدة هذه الأعمال، لكن يجب تحديد مسؤوليات ومخرجات كل منها في الاتفاق.

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

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