منهجية التقييم الصادرة عن W3C

توفر WCAG-EM 2.0 هيكلاً مشتركاً للمقيمين والمؤسسات. وتتمثل خطواتها الخمس الرئيسية في تحديد نطاق التقييم، واستكشاف المنتج المستهدف، واختيار عينة ممثلة، وتقييم العينة، ثم إعداد تقرير بالنتائج. ويمكن استخدام المنهجية للتقييم الداخلي أو للتقييم الذي تنفذه جهة مستقلة. [1] [2]

تفترض المنهجية معرفة متينة بإرشادات WCAG والتصميم الميسّر والتقنيات المساعدة وأساليب التقييم والحواجز التي يواجهها الأشخاص ذوو الإعاقات المختلفة. ولا توفر الأداة هذه الخبرة. كما توصي W3C بإشراك الأشخاص ذوي الإعاقة، لأن تقييم المستخدمين قد يكشف حواجز في سهولة الاستخدام لا يظهرها اختبار التوافق وحده. [1] [7]

يجب فهم قيد أساسي. فادعاء التوافق مع WCAG يشمل جميع الصفحات والإجراءات الكاملة داخل النطاق المحدد. وتعتمد معظم عمليات التدقيق الاحترافية على عينة ممثلة لأن اختبار كل صفحة وحالة قد يكون غير عملي. ويمكن للعينة أن تقدم أدلة قوية عن المنتج المقيم، لكن WCAG-EM 2.0 توضح أن العينة وحدها لا تبرر عادة ادعاء توافق موقع كامل. لذلك يجب أن يصف بيان التقييم النطاق الفعلي والنتيجة بدقة. [1]

ليس كل تدقيق مفيد بحاجة إلى الادعاء بأنه يطبق WCAG-EM 2.0 بالكامل. فقد يكون فحص الإطلاق، أو تدقيق نظام التصميم، أو تقييم رحلة حرجة مناسباً إذا كان الغرض والقيود واضحين. ضيق النطاق ليس المشكلة. المشكلة هي تقديم تقييم محدود بوصفه دليلاً على توافق المنتج كله.

لماذا لا يعد الفحص الآلي تدقيقاً كاملاً

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

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

ينبغي استخدام الفحص الآلي عادة للأغراض الآتية.

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

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

تحديد الغرض والنطاق

القرار الأول في التدقيق ليس اختيار الأداة، بل تحديد سبب طلب التقييم. فقد يتطلب اعتماد إطلاق منتج، أو مراجعة مشتريات، أو استجابة قانونية، أو وضع خط أساس لإعادة التصميم، أو اختبار قبول لمورد، أو إعداد تقرير ACR درجات مختلفة من العمق والأدلة والتقارير.

ينبغي أن يحدد النطاق المكتوب العناصر الآتية على الأقل.

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

يعد WCAG 2.2 بالمستوى AA الهدف المقبول عموماً للأعمال الحالية، وتصف WCAG-EM 2.0 المستوى AA بأنه الهدف الموصى به. ومع ذلك، قد يحدد نظام أو جهة مختصة أو عقد WCAG 2.0 أو WCAG 2.1 أو EN 301 549 أو Section 508 أو متطلباً آخر. يجب أن يختبر التقرير المتطلب المنطبق فعلياً ويصفه، بدلاً من استبداله بصمت بمعيار مفضل. [1] [3]

استكشاف المنتج واختيار العينة

يستكشف المقيم المحترف المنتج قبل اعتماد العينة النهائية. والهدف هو فهم طريقة بناء المنتج واستخدامه، لا اختيار قائمة ملائمة من الروابط. تحدد مرحلة الاستكشاف الواجهات الشائعة والوظائف الأساسية وتنوعات المحتوى والتقنيات والخدمات الخارجية والمهام الحساسة أو عالية المخاطر. [1]

تشمل العينة الممثلة للموقع عادة العناصر الآتية.

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

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

تجمع WCAG-EM 2.0 بين عينة منظمة وعينة عشوائية تساوي 10 في المائة من حجم العينة المنظمة. ويستخدم الاختيار العشوائي للتحقق مما إذا كانت العينة المخططة قد أغفلت أنواعاً من المحتوى أو نتائج مهمة. ينطبق هذا المتطلب عندما يوصف التقييم بأنه يتبع WCAG-EM 2.0. أما عمليات التدقيق المستهدفة الأخرى فقد تستخدم منهجاً مختلفاً بشرط توثيقه. [1]

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

أساليب الاختبار التي ينبغي أن يجمعها التدقيق الاحترافي

لا تغطي طريقة واحدة المنتج كله. ويجمع التدقيق الاحترافي بين أساليب متكاملة، ويسجل الصفحات والأدوات والمتصفحات والتقنيات المساعدة والإجراءات التي استخدمت. [1] [8] [9]

المراجعة اليدوية المتخصصة

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

• البدائل النصية ذات المعنى والعناوين والمعالم الدلالية والقوائم والجداول وترتيب القراءة.
• تباين الألوان واستخدام اللون ووضوح التركيز وإعادة تدفق المحتوى وتباعد النص والمحتوى عند مستويات تكبير مختلفة.
• الوصول بلوحة المفاتيح وتسلسل التركيز والاختصارات وبدائل المؤشر وتجنب حبس لوحة المفاتيح.
• تسميات حقول النماذج والتعليمات والحقول المطلوبة وتحديد الأخطاء والاقتراحات ورسائل الحالة.
• الأسماء والأدوار والقيم والحالات الميسّرة لعناصر التحكم الأصلية والمخصصة.
• التسميات التوضيحية والنصوص المكتوبة والوصف الصوتي وعناصر التحكم في الصوت والفيديو والرسوم المتحركة.
• التوقيت والحركة والمحتوى الوامض والمحتوى الذي يظهر عند المرور بالمؤشر أو التركيز والمقاطعات.
• متطلبات المصادقة والمساعدة وتكرار الإدخال وحجم الهدف التي أضيفت أو عززت في WCAG 2.2.

اختبار لوحة المفاتيح

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

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

الاختبار بالتقنيات المساعدة

يتحقق الاختبار بالتقنيات المساعدة من طريقة تواصل المنتج وسلوكه من خلال برامج المستخدم المهمة لجمهوره. وينبغي للنطاق تحديد التركيبات التي ستختبر، بدلاً من تقديم وعد غير واقعي باختبار كل تقنية مساعدة مع كل متصفح. تسمي WCAG-EM ذلك خط أساس دعم إمكانية الوصول. [1]

قد يشمل خط الأساس، بحسب المنتج والمستخدمين، تركيبات مختارة مثل الآتي.

• NVDA مع متصفح مدعوم على نظام Windows.
• JAWS مع متصفح مدعوم على نظام Windows عندما يكون مناسباً للجمهور أو لمتطلبات المشتريات.
• VoiceOver مع Safari على نظام macOS أو iOS.
• TalkBack مع Chrome على نظام Android للخدمات الموجهة إلى الهاتف.
• تكبير الشاشة أو أوضاع الألوان الإجبارية أو التحكم الصوتي عندما يتطلب المنتج وأهداف التدقيق ذلك.

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

اختبار العرض المتجاوب والتفاعل

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

المحتوى والوسائط والمستندات

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

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

مكونات الأطراف الخارجية

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

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

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

ينبغي أن يشمل اختبار العربية والخدمات ثنائية اللغة العناصر الآتية.

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

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

ما الذي ينبغي أن يتضمنه تقرير التدقيق

التقرير هو المخرج العملي الرئيسي. ويجب أن يمكّن قارئاً مستقلاً من فهم ما خضع للتقييم، وإعادة إنتاج العيب، وتقدير أثره، والتخطيط لمعالجته. تؤكد W3C أهمية الشفافية وإمكانية تكرار الاختبار، بينما توصي Section508.gov بتوثيق النطاق والأساليب والبيئات والنتائج والشدة والأدلة ومعلومات المعالجة بالتفصيل. [1] [9]

ينبغي أن يتضمن التقرير الكامل الأقسام الآتية.

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

يجب أن يوفر كل عيب مسجل لفريق التنفيذ معلومات كافية للعمل. وتشمل الحقول المفيدة ما يأتي.

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

ينبغي أن يكون تقرير التدقيق نفسه ميسّراً. ويجب تنظيم العناوين والجداول والروابط وتباين الألوان وترتيب القراءة بصورة صحيحة، واختبار أي ملفات جداول بيانات أو PDF في صيغتها النهائية. يفقد التقرير المتعلق بإمكانية الوصول مصداقيته عندما لا يستطيع القراء المعنيون استخدامه. [1] [9]

شدة العيوب والمعالجة وإعادة الاختبار

مستوى WCAG لا يحدد شدة العيب

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

ينبغي أن تراعي درجة الشدة عوامل مثل الآتي.

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

إرشادات المعالجة

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

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

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

التحقق من الإصلاحات

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

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