إمكانية الوصول في HTML: لوحة المفاتيح والتركيز وقارئات الشاشة

اختبار إمكانية الوصول بلوحة المفاتيح خطوة بخطوة

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

التركيز المرئي وترتيبه

لا تزل outline من عناصر التركيز دون توفير بديل واضح. ينبغي أن يستطيع المستخدم معرفة العنصر النشط بصريًا حتى مع تباين الشاشة أو تكبير الصفحة. حافظ على ترتيب DOM منطقيًا؛ استخدام tabindex بقيم موجبة لإعادة ترتيب التركيز غالبًا يزيد التعقيد، والأفضل إصلاح ترتيب العناصر في المصدر.

الأسماء والتسميات الدلالية

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

قائمة اختبار يدوي

1. ابدأ من أعلى الصفحة واضغط Tab حتى تصل إلى كل عنصر تفاعلي.
2. تحقق أن التركيز لا يقفز إلى مواضع غير منطقية ولا يختفي خلف رأس ثابت.
3. افتح قائمة أو نافذة حوار، ثم اختبر إغلاقها وإعادة التركيز.
4. جرّب النموذج دون ماوس، وتأكد أن رسائل الخطأ يمكن الوصول إليها.
5. اختبر مستوى تكبير 200% على الأقل لرصد التداخل وفقدان المحتوى.

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

مكونات تفاعلية تحتاج إدارة تركيز خاصة

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

النوافذ المنبثقة

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

القوائم والتبويبات

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

سجل النتائج وأعد الاختبار

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

تسجيل نتائج اختبار لوحة المفاتيح

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

عالج المشكلة عند مصدرها

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

الاختبار اليدوي مكمل للأدوات

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

طريقة عملية لتدقيق الوصول باستخدام لوحة المفاتيح

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

استخدم عناصر HTML المناسبة

استخدم a للتنقل وbutton لتنفيذ إجراء، ولا تضف tabindex="0" إلى كل عنصر لمجرد جعله قابلًا للتركيز. العناصر الدلالية توفر سلوكًا افتراضيًا متوقعًا، بينما يتطلب العنصر العام المخصص للتفاعل تنفيذ دعم لوحة المفاتيح وإدارة الحالة يدويًا. تجنب القيم الموجبة لـtabindex لأنها قد تنشئ ترتيب تركيز منفصلًا يصعب فهمه وصيانته.

اختبر الحوارات والقوائم

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

اجعل الاختبار جزءًا من التطوير

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

المراجع المفيدة هي شرح WCAG لمعيار لوحة المفاتيح وإرشادات MDN للمكوّنات التفاعلية.

معايير قبول عملية للتنقل بلوحة المفاتيح

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

تجنب الفخاخ الشائعة

لا تزل outline دون توفير بديل مرئي، ولا تجعل العنصر قابلًا للتركيز إذا لم يكن له سلوك مفهوم. لا تستخدم tabindex موجبًا لترتيب التنقل؛ عالج ترتيب DOM أو بنية المكوّن بدل ذلك. إذا احتجت إلى لوحة مفاتيح مخصصة داخل شبكة أو قائمة، طبّق نمطًا معروفًا واختبر مفاتيح الأسهم وHome وEnd وEscape وفق الحاجة.

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