اختبار إمكانية الوصول باستخدام مكتبة اختبار React
تعلم كيفية اختبار إمكانية الوصول كعقد عرض قابل للملاحظة باستخدام الاستعلامات الدلالية، والتفاعل الذي يتم عبر لوحة المفاتيح، والتحقق من ARIA، وفحوصات aXe الآلية المدمجة في CI.
مع تطور تطبيقات React ، غالبًا ما تصبح إمكانية الوصول تفاعلية وليست معمارية. تضيف فرق التطوير سمات ARIA في مراحل متأخرة من التطوير، وتكتب اختبارات مرئية ناجحة، وتفترض أن واجهة المستخدم إذا بدت صحيحة، فهي متاحة للجميع. لكن إمكانية الوصول ليست مسألة بصرية، بل هي عقد عرض دلالي. لا "ترى" التقنيات المساعدة المكونات، بل تستخدم الأدوار والأسماء والعلاقات وتحديثات المناطق المباشرة التي يُجريها React في شجرة إمكانية الوصول.
يُضفي نموذج العرض المتزامن في React 19 أهميةً بالغةً على هذا التنسيق. قد تُوقف حدود الترقب بعض المناطق مؤقتًا. وقد تُؤجل الانتقالات التحديثات. وقد تُظهر واجهة المستخدم المتفائلة حالةً مؤقتةً لفترة وجيزة. وخلال كل ذلك، يجب أن تبقى شجرة إمكانية الوصول متماسكة. ويجب أن ينتقل التركيز بشكلٍ مقصود. ويجب أن تُعلن المناطق النشطة عن تغييراتٍ جوهريةٍ في الحالة. ويجب أن تظل علاقات ARIA صالحةً عبر عمليات إعادة العرض.
المشكلة الحقيقية التي يجب علينا حلها هي هذه:
كيف نختبر إمكانية الوصول بطريقة تتحقق من صحة إخراج الدلالية وسلوك لوحة المفاتيح، وليس من تفاصيل التنفيذ أو البنية المرئية؟
تتناغم مكتبة اختبار React بشكل طبيعي مع هذا الهدف لأنها تشجع على استعلام DOM بالطريقة التي تتبعها التقنيات المساعدة: حسب الدور، تسمية، والاسم المُتاح. عندما نختبر إمكانية الوصول بشكل صحيح، فإننا لا "نختبر ARIA"، بل نتحقق من أن كل عملية دمج ذات معنى تُنتج تحديثًا دلاليًا متزامنًا. كما نُعزز هذا النهج من خلال عمليات تدقيق آلية لإمكانية الوصول باستخدام أدوات مثل aXe، مما يضمن اكتشاف أي تراجعات باستمرار في التكامل المستمر.
تخيل شجرة مكونات ذات طبقتين متوازيتين. الأولى هي نموذج كائن المستند المرئي (DOM) الذي يراه المستخدمون. أما الثانية فهي شجرة إمكانية الوصول، وتتألف من الأدوار، والتسميات، والعلاقات، وتحديثات المناطق الحية. في كل مرة يُجري فيها React عملية عرض، يتم تحديث الطبقتين معًا. يجب أن تُحدِّث عمليات التراجع المعلقة، وأخطاء التحقق، والحالات المعلقة، ليس فقط الطبقة المرئية، بل أيضًا الطبقة الدلالية. يتحقق اختبار إمكانية الوصول من بقاء هاتين الطبقتين متزامنتين أثناء التفاعل والتحديثات غير المتزامنة.
اختبار إمكانية الوصول من خلال الدلالات، وتدفق لوحة المفاتيح، وحالة ARIA
يبدأ اختبار إمكانية الوصول بالاستعلامات الدلالية. وظائف مثلgetByRole ،getByLabelText ، وgetByText يتم العمل على شجرة إمكانية الوصول بدلاً من بنية المكون الداخلية. عند استخدام هذه الاستعلامات، نتأكد من تعريف الأدوار والأسماء التي يمكن الوصول إليها بشكل صحيح. إذا فشل الاستعلام، فغالبًا ما يشير ذلك إلى أن المكون يفتقر إلى تسمية، أو أن دوره غير صحيح، أو أنه غير قابل للوصول إليه على الإطلاق.
يُعدّ التنقل باستخدام لوحة المفاتيح جزءًا من متطلبات إمكانية الوصول. يُعتبر العنصر الذي يبدو تفاعليًا ولكن لا يمكن الوصول إليه عبر مفتاح Tab أو تفعيله باستخدام مفتاح Enter معيبًا من منظور إمكانية الوصول. يُؤكد اختبار التفاعل باستخدام لوحة المفاتيح أن ترتيب التركيز قابل للتنبؤ وأن التركيز ينتقل عمدًا عند نقاط التقاء سير العمل، كما هو الحال بعد فتح نافذة نافذة منبثقة أو ظهور خطأ في التحقق من الصحة.
يضمن التحقق من ARIA نقل تغييرات الحالة بشكل دلالي. سمات مثلaria-invalid ،aria-describedby ، وaria-busy ربط التغييرات المرئية إخراج التكنولوجيا المساعدة. المناطق الحية (role="status" أوrole="alert" ) الإعلان عن التحديثات الديناميكية. اختبار ذلك يعني التأكد من وجود الأدوار والعلاقات المناسبة عند حدوث تغييرات في الحالة.
يُوسّع التدقيق الآلي لإمكانية الوصول باستخدام aXe نطاق الاختبارات السلوكية ليشمل التحقق من البنية. فبينما يتحقق RTL من دلالات وتفاعل المستخدم، يفحص aXe المخالفات القائمة على القواعد، مثل غياب التسميات، أو مشاكل التباين، أو الاستخدام غير الصحيح لـ ARIA. ويُحوّل دمج aXe في التكامل المستمر إمكانية الوصول من مجرد إجراء يدوي لاحق إلى ضمانة معمارية مستمرة.
يبقى المبدأ التوجيهي ثابتاً: اختبار ما يمكن للتقنيات المساعدة إدراكه والتفاعل معه، وليس كيفية تنفيذ المكونات داخلياً.
مثال: التحقق من عقد إمكانية الوصول باستخدام الاختبارات الدلالية والاختبارات التي تعتمد على لوحة المفاتيح
سنقوم الآن بإثبات صحة النموذج الذهني من خلال بناء نافذة تسجيل صغيرة يسهل الوصول إليها واختبارها باستخدام الاستعلامات الدلالية (getByRole ،getByLabelText يتضمن ذلك التنقل باستخدام لوحة المفاتيح، وتحريك التركيز المتعمد، والتحقق من حالة ARIA، وإعلانات المنطقة المباشرة، وتدقيق إمكانية الوصول باستخدام aXe. سنُضمّن أيضًا بيئة اختبار يدوية لتشغيل المجموعة في Sandpack. الهدف ليس اختبار تفاصيل التنفيذ، بل ...