إمكانية الوصول ليست طبقة تُضاف في نهاية المشروع، لأن كثيرًا من القرارات الأساسية تُتخذ أثناء بناء HTML والتفاعل. مستخدم لوحة المفاتيح، قارئ الشاشة، zoom، contrast العالي، أو شخص لديه صعوبة حركية يتعامل مع نفس التطبيق بطرق مختلفة. أفضل نتيجة تأتي من استخدام عناصر المنصة الصحيحة ثم اختبار المسارات الأساسية بدون mouse قبل إضافة حلول مخصصة.
كل شيء تفاعلي يجب أن يعمل بلوحة المفاتيح
زر أو رابط أو قائمة أو dialog يجب أن يمكن الوصول إليه وتنفيذه بدون mouse. لا تضف tabindex=0 لكل div؛ استخدم button و a والعناصر الأصلية متى أمكن.
إدارة Focus عند التغيرات الكبيرة
عند فتح dialog انقل focus داخلها بطريقة منطقية، وعند الإغلاق أعدها للعنصر الذي فتحها. عند التنقل في SPA أو ظهور error، قرر هل يحتاج المستخدم إعلانًا أو نقل focus بدل تركه في مكان اختفى.
أسماء العناصر مهمة
Icon button تحتاج accessible name. Input تحتاج label. صورة زخرفية لها alt فارغة، وصورة تحمل معنى تحتاج وصفًا مناسبًا. لا تكرر نصًا بصريًا طويلًا في aria-label بلا حاجة.
الألوان ليست القناة الوحيدة
حالة error أو success لا تُعرض بالأحمر/الأخضر فقط؛ أضف نصًا أو icon ومعنى. راقب contrast للنص والحدود المهمة، و focus indicator.
خطوات عملية
- تصفح الصفحة ب ـTab.
- نفذ كل action ب ـEnter/Space حسب العنصر.
- اختبر قارئ شاشة لمسار أساسي.
- جرب Zoom.
- فعل prefers-reduced-motion.
- راجع رسائل errors.
الحركة تحتاج خيارًا أقل
Animations الكبيرة أو parallax قد تزعج بعض المستخدمين. احترم prefers-reduced-motion وخفف/أوقف الحركة غير الضرورية بدون إزالة feedback الوظيفي.
ARIA تستخدم عندما تحتاجها
ARIA تصف state/role عندما HTML وحدها لا تكفي، لكنها لا تضيف keyboard behavior تلقائيًا. إذا بنيت custom combobox مثلًا، عليك تنفيذ pattern كامل لا role فقط.
قائمة مراجعة
- Semantic HTML أولًا.
- Keyboard كاملة.
- Focus واضحة.
- Labels موجودة.
- Errors معلنة.
- Contrast مناسب.
- Reduced motion محترمة.
استخدم Live Regions بحذر
عندما يتغير status بدون انتقال focus، يمكن aria-live إعلان الرسالة لقارئ الشاشة، مثل نجاح حفظ أو خطأ async. لا تجعل كل تحديث live لأن كثرة الإعلانات تربك المستخدم. اختر الرسائل التي يحتاج معرفتها فورًا، واستخدم politeness مناسبة.
رسائل الخطأ يجب أن تكون مرتبطة بالحقل
عند validation، ضع رسالة واضحة قرب input واربطها ب ـaria-describedby أو آلية مناسبة، وحدد aria-invalid عند الحاجة. عند submit فاشل، انقل focus أو أعلن summary بطريقة تساعد المستخدم على الوصول لأول خطأ بدل تركه يبحث بصريًا.
اختبر قارئ شاشة واحدًا على الأقل فعليًا
ال ـlinters و automated audits تكتشف مشاكل كثيرة لكنها لا تخبرك إن رحلة الاستخدام مفهومة. نفذ flow أساسي باستخدام قارئ شاشة مع keyboard فقط، واستمع للأسماء والحالات والترتيب. ستظهر مشاكل لا تراها من DOM inspector وحده.
اختبر الصفحة بلا Mouse
هذا يكشف سريعًا معظم مشاكل focus والترتيب والتفاعل التي لا تظهر بالاختبار البصري وحده.
شارك في تقييم ونقاش المقال
رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.
النقاش
جارٍ تحميل التعليقات…