أدوار وسمات ARIA: مقارنة أفضل الاختيارات
تعد أدوار ARIA وسماتها الخاصة بمواصفات WAI-ARIA 1.2 من W3C تتجاوز المائة، ولكنها قد تؤدي إلى حل معظم مشكلات الوصول إلى عناصر واجهة المستخدم XHTML وCSS. هناك دور يحدد ما هو عنصر وسمة لحالة أو علاقات، لكن ARIA لا تغير سلوك المتصفح: كل دور إضافي يتطلب تنفيذ التفاعل باستخدام JavaScript.
تطبيقات الإنترنت الغنية التي يمكن الوصول إليها (ARIA) هي إحدى مواصفات W3C التي تضيف دلالات إلى عناصر HTML التي لا تحتوي عليها في نموذج أصلي. يصف الدور ما هو *العنصر (“زر”، و”علامة تبويب”، و”مربع حوار”)، بينما تصف السمة حالته أو علاقاته (aria-expanded، aria-controls، aria-labeledby). القاعدة الأولى لـ ARIA، التي نشرها W3C في استخدام ARIA، صريحة: إذا كان هناك عنصر HTML أصلي يقوم بالمهمة بالفعل، فاستخدمه ولا تضف ARIA.
والسبب هو أن ARIA لا يقوم بتعديل سلوك المتصفح. لا يتلقى <div role="button"> التركيز مع علامة التبويب، ولا يستجيب لمفتاح Enter أو المسافة، ولا يتم إرساله مع نموذج. إنه يغير فقط ما تعلنه التكنولوجيا المساعدة. يجب تنفيذ كافة التفاعلات باستخدام JavaScript وإدارتها بعناية. في مشاريع XHTML/CSS حيث يكون HTML ثابتًا وJS في حده الأدنى، فهذا يعني أن كل من أدوار وسمات الأغنية التي تتم إضافتها هي وعد يجب أن تفي به التعليمات البرمجية الخاصة بك.
تطلب القاعدة الثانية من ARIA عدم تغيير الدلالات الأصلية إلا إذا كانت لا غنى عنها. يؤدي <h2 role="tab"> إلى كسر بنية العناوين وإرباك برامج قراءة الشاشة التي تتنقل حسب المناطق. تتطلب القاعدة الثالثة أن تكون جميع عناصر تحكم ARIA قابلة للتشغيل باستخدام لوحة المفاتيح. الرابع يطلب عدم استخدام aria-hidden=‘true’ على العناصر التي يتم التركيز عليها. الخامس، والأكثر نسيانًا، يذكرنا بأن أي عنصر تفاعلي يتطلب اسمًا يمكن الوصول إليه: الدور بدون تسمية هو زر كتم الصوت.
كيفية الاختيار: المعايير قبل القائمة
اختيار الدور أو السمة ليس مسألة ذوق. هذه المعايير، المطبقة بالترتيب، تتجنب معظم الأخطاء المتعلقة بأدوار وسمات الأغنية:
- هل يوجد عنصر HTML أصلي؟ إذا كان الأمر كذلك، فاستخدمه.
<button>،<details>،<dialog>،<input type="checkbox">تغطي حالات أكثر مما يعتقده الناس. - هل تحتاج الأداة إلى حالات ديناميكية؟ إذا كانت تتغير بين مفتوح/مغلق، أو محدد/غير محدد، أو موسعة/مطوية، فستحتاج إلى سمات الحالة (
aria-expanded،aria-selected،aria-pressed). - هل تحتاج إلى علاقات بين العناصر؟ تربط سمات العلاقة (
aria-controls،aria-labeledby،aria-describedby،aria-owns) الأجزاء التي لا تستطيع شجرة الوصول استنتاجها من DOM. - هل تحتاج إلى إعلانات مباشرة؟ تعمل المناطق المباشرة (
aria-live،role="status"،role="alert") على حل التحديثات دون نقل التركيز. - هل يمكنني صيانته؟ يعد نمط ARIA المعقد بدون اختبارات لوحة المفاتيح أو قارئ الشاشة أسوأ من عدم وجود أي شيء.
تكلفة الصيانة هي المعيار الأكثر تجاهلا. يتطلب “role = “tablist"" المصمم جيدًا إدارة مفاتيح الأسهم، وتدوير “tabindex”، ومزامنة “aria-selected”، و”aria-controls”، والإخفاء الصحيح للوحات غير النشطة. إذا لم يتمكن الفريق من التعامل مع ذلك، فسيكون الوصول إلى مجموعة الروابط ذات الروابط أكثر سهولة وأرخص.
ذات صلة: — ويدجت إمكانية الوصول بخطة مجانية للتمكن من ذلك بنفس الطريقة.
مقارنة أدوار ARIA الأكثر فائدة
يلخص الجدول التالي الأدوار التي تظهر مرة أخرى في عمليات التدقيق الحقيقية، مع ما يعادلها من السكان الأصليين عندما تكون موجودة والخطأ الأكثر شيوعاً.
| الدور | الغرض منه | البديل الأصلي | الخطأ الشائع |
|---|---|---|---|
زر | التحكم في تنفيذ إجراء | <زر> | لم يتم إضافة طريقة إلى Enter/Space أو tabindex="0" |
الرابط | تصفح عنوان URL آخر | <a href> | استخدم الإجراءات التي لا تتصفحها |
| ”الحوار” | نافذة منبثقة (Modal) أو غير منبثقة | <حوار> | عدم حجز التركيز أو إعادته عند الإغلاق |
tablist' / tab/tabpanel` | واجهة التطبيقات | لا يوجد بديل مباشر | لا يمكن مزامنة “الأغنية المحددة” مع اللوحة المرئية |
القائمة / القائمة | قائمة التطبيق | <select> قائمة الملحقات | استخدام قوائم تصفح الويب |
تنبيه | رسالة عاجلة وفورية | role = "status" لعدم الاستعجال | الإفراط في استخدامه مما يؤدي لإزعاج قارئ الشاشة |
| ”الحالة” | تحديث المعلومات | <الإخراج> | لم يتم إدراجه في DOM قبل التحديث |
شريط التقدم | تقدم مهمة | <التقدم> | لم يتم تحديث aria-valuenow |
تلميح الأداة | الوصف الناشئ | العنوان (محدود) | لا يوجد ارتباط بـ “الأغنية الموصوفة بواسطة” |
مربع التحرير والسرد | Campo con lista de Sugerencias | <datalist> (محدود) | لم يتم الإعلان عن رقم النتائج |
يعد الاختيار بين role="alert" وrole="status" مثالًا جيدًا على القرار الذي يتضمن الفروق الدقيقة فيما يتعلق بأدوار الأغنية وسماتها. التنبيه يقاطع قراءة قارئ الشاشة الحالية؛ “الحالة” تنتظر انتهاء المستخدم. بالنسبة لخطأ في التحقق من صحة النموذج، يكون alert مناسبًا. بالنسبة إلى “تم العثور على 3 نتائج” أثناء قيام المستخدم بالكتابة، تكون “الحالة” صحيحة وينتج عن “التنبيه” أن تكون متطفلة.
سمات ARIA غير قابلة للتمييز وهي مدمجة
ترتبط السمات بأربع عائلات، وكل واحدة منها تحل مشكلة مميزة.
يستحق نظرة: — إمكانية الوصول إلى الإدارة: أتمتة مجمعة مع مراجعة بشرية.
Etiquetado. يوفر aria-label اسمًا في حالة عدم وجود نص مرئي. يشير aria-labeledby إلى معرف عنصر آخر ويفضل عندما يكون النص موجودًا بالفعل على الشاشة، لأنه يحتفظ بمصدر واحد للحقيقة. يضيف `aria-describedby’ وصفًا أطول، مثل نص المساعدة الخاص بالحقل. الفرق مهم: الاسم هو ما يسمعه المستخدم عند التركيز؛ الوصف هو سياق إضافي يمكن مقاطعته.
Estados. aria-expanded (صواب/خطأ) للأكورديون والقوائم المنسدلة. “تم تحديد الأغنية” لعلامات التبويب والخيارات. aria-checked لمربعات الاختيار المخصصة، مع القيمة mixed لحالات الحالة الثلاثية. “تم الضغط على الأغنية” لأزرار التبديل. aria-disabled عندما يظل العنصر قابلاً للتركيز ولكنه غير قابل للتشغيل، على عكس السمة الأصلية disabled، التي تزيله من ترتيب علامات التبويب.
العلاقات. تشير aria-controls إلى العنصر الذي يتحكم فيه الزر. يعيد aria-owns تنظيم شجرة إمكانية الوصول عندما لا يعكس DOM العلاقة المرئية. يسمح لك aria-activedescendant بالحفاظ على التركيز على الحاوية أثناء الإعلان عن العنصر النشط، وهو نمط شائع في مربعات التحرير والسرد.
المناطق المباشرة. تحدد aria-live="polite" أو "assertive" مدى الإلحاح. aria-atomic="true" يتسبب في إعلان الكتلة بأكملها بدلاً من الجزء المعدل فقط. المرشحات “ذات الصلة بالأغنية” التي يتم الإعلان عن التغييرات فيها.
التفاصيل التي غالبًا ما يتم التغاضي عنها: تعمل سمات ARIA فقط على العناصر ذات الدور الصالح. لن يتم الإعلان عن aria-expanded' على
بدون دور. وقيم ARIA المنطقية هي سلاسل نصية ("صحيح"، "خطأ")، وليست قيم منطقية لجافا سكريبت؛ كتابة aria-expanded=“false”` كخاصية منطقية ستؤدي إلى نتائج غير متناسقة.ذات صلة: — الشهادة المهنية التي تمنحك الخبرة والقدرة على الوصول إليها.
الأخطاء التي تؤدي إلى إمكانية الوصول إلى عنصر واجهة مستخدم
الخطأ الأكثر تكلفة هو استخدام ARIA لضبط بنية HTML سيئة. قم بإضافة role="navigation" إلى <div> عند وجود <nav> متاح في مناطق مكررة وخلط الملاحة حسب المعالم.
الخطأ الثاني هو التركيز. عنصر واجهة المستخدم المشروط الذي لا يحرك التركيز عند فتحه، ولا يحجزه أثناء فتحه ولا يعيده إلى المشغل عند الإغلاق، يترك مستخدم لوحة المفاتيح يتنقل عبر محتوى غير مرئي. يحل عنصر <dialog> الأصلي جزءًا من هذا، ولكن ليس كله: إعادة التركيز لا تزال مسؤولية المطور.
الخطأ الثالث مخفي مع عناصر “مخفية للأغنية” والتي ستظل مرئية بشكل واضح. قائمة مغلقة تحتوي على أغنية مخفية = “true” ولكن بدون عرض: لا يوجد أو `رؤية: مخفية’ يتم حفظها في ترتيب الجدول، ويركز المستخدم على عناصر لا يمكنه رؤيتها. المجموعة الصحيحة مرئية بشكل خفي وشجرة يمكن الوصول إليها مرة واحدة.
الخطأ الرابع هو الاسم الغائب الذي يمكن الوصول إليه. يتطلب <button> الذي يحتوي على أيقونة SVG واحدة aria-label أو <span class="visually-hidden"> مع النص. يتطلب SVG المزخرف aria-hidden="true" وfocusable="false"، لذلك لا يقوم Internet Explorer وبعض المتصفحات القديمة بتضمينه في ترتيب علامات التبويب.
أدوات اختبار الأدوار والسمات ARIA
لا توجد أداة بدلاً من الاختبار باستخدام قارئ شاشة فعلي، ولكن مجموعة الأدوات المتنوعة تكشف معظم حالات الفشل في أدوار وسمات الأغنية.
التحقق الثابت. يكتشف مدقق W3C ARIA (جزء من Nu HTML Checker) الأدوار غير الموجودة، والسمات المكتوبة بشكل سيء، والمجموعات المحظورة. تشير أدوات ax DevTools وLighthouse إلى الأدوار التي لا تحتوي على أسماء يمكن الوصول إليها وتفتقد السمات الإلزامية.
فحص شجرة إمكانية الوصول. تسمح لك أدوات تطوير Chrome وFirefox برؤية شجرة إمكانية الوصول تمامًا كما تتلقاها التكنولوجيا المساعدة. إنها أسرع طريقة للتحقق مما إذا كان الدور قد تم تطبيقه بالفعل والاسم الذي يمكن الوصول إليه والذي حسبه المتصفح.
الاختبار اليدوي. يمكنك التنقل عبر الأداة بالكامل باستخدام لوحة المفاتيح فقط (Tab، Shift+Tab، الأسهم، Enter، Space، Escape) ثم باستخدام NVDA على Windows، أو JAWS إذا كان متاحًا، أو VoiceOver على macOS وiOS. يغطي الجمع بين قارئ سطح المكتب وقارئ الهاتف المحمول غالبية الحالات الحقيقية.
الوثائق المرجعية. يتضمن W3C دليل ممارسات التأليف ARIA (APG) أنماطًا شاملة مع أمثلة على لوحة المفاتيح والتعليمات البرمجية. وهذا هو المصدر الذي يجب الرجوع إليه قبل اختراع نمط جديد.
كيف نقرر مشروع XHTML/CSS الحقيقي
في مواقع XHTML التي تحتوي على CSS وJavaScript خفيفة الوزن، تكون الإستراتيجية الأكثر فعالية من حيث التكلفة هي البدء باستخدام HTML الأصلي وإضافة ARIA فقط في الأماكن التي لا يصل إليها النص الأصلي. يتطلب النموذج الذي يحتوي على <label> و<fieldset> و<legend> الصحيح القليل جدًا من ARIA. جدول البيانات الذي يحتوي على <النطاق> لا يفعل ذلك أيضًا. تأتي أدوار ARIA عندما تظهر أنماط لا يغطيها HTML: علامات التبويب والأكورديونات ومربعات التحرير والسرد مع التصفية ومربعات الحوار المشروطة والإشعارات الديناميكية.
يُنصح بتوثيق كل استخدام لأدوار وسمات ARIA في الكود نفسه مع تعليق يوضح سبب وجوده. عندما يقوم شخص ما بإعادة بناء المكون بعد ستة أشهر، سيعرف ما إذا كانت “عناصر التحكم في الأغنية” لا تزال ضرورية أم أنها أصبحت معزولة. تعد سمات ARIA المعزولة - التي تشير إلى معرفات لم تعد موجودة - مصدرًا صامتًا للفشل الذي لا يكتشفه أي مدقق بشكل موثوق.
وأخيرًا، تعامل مع إمكانية الوصول كجزء من تعريف المكون لـ “تم”، وليس كتدقيق لاحق. إن عنصر واجهة المستخدم بأدوار ARIA الذي تم اختباره باستخدام لوحة المفاتيح وقارئ الشاشة منذ الالتزام الأول يكلف أقل بكثير من تكلفة إصلاحه بعد التدقيق.
الوجبات السريعة الرئيسية
- أدوار وسمات ARIA لا تضيف سلوكًا: الدور بدون لوحة المفاتيح وإدارة التركيز أسوأ من عدم وجود أي شيء.
- القاعدة الأولى في ARIA هي استخدام HTML الأصلي متى كان موجودًا؛ تغطي
<button>و<dialog>و<details>حالات أكثر مما قد يعتقده المرء. - يتم تجميع السمات في التصنيف، والحالات، والعلاقات، والمناطق الحية؛ كل عائلة تحل مشكلة مختلفة.
- مقاطعة
role="alert"وانتظارrole="status": يؤدي الاختيار بشكل غير صحيح إلى إشباع مستخدم قارئ الشاشة. - قيم ARIA المنطقية هي سلاسل (“صحيح”
/”خطأ”`)، وتعمل السمات فقط على العناصر ذات الدور الصالح. - الاختبار باستخدام لوحة المفاتيح وقارئ الشاشة الحقيقي إلزامي؛ يكتشف المدققون جزءًا فقط من حالات الفشل.
المصادر ومزيد من القراءة
- WAI-ARIA — ويكيبيديا: مبادرة إمكانية الوصول إلى الويب - تطبيقات الإنترنت الغنية التي يمكن الوصول إليها (WAI-ARIA) هي مواصفات فنية نشرها اتحاد شبكة الويب العالمية (W3C) والتي…
الأسئلة المتداولة
ما هو الفرق بين دور وسمة ARIA؟
يحدد الدور ما هو العنصر بالنسبة للتكنولوجيا المساعدة، مثل role="tab" أو role="dialog". تصف السمة حالتها أو علاقاتها، مثل “aria-expanded” أو “aria-labeledby”. يتم تطبيق الأدوار على العنصر الذي يمثل المكون؛ يتم تطبيق السمات عادةً على نفس العنصر أو تلك المرتبطة به.
هل تريد استخدام ARIA في مكان HTML الأصلي؟
فقط في حالة عدم وجود عنصر HTML يغطي النمط. القاعدة الأولى لـ W3C ARIA واضحة: إذا كان هناك عنصر أصلي، فاستخدمه. أدوار ARIA مطلوبة لعلامات التبويب والأكورديونات ومربعات التحرير والسرد ذات التصفية ومربعات الحوار المشروطة، من بين الأنماط الأخرى التي لا يمكن لـ HTML تنفيذها بمفردها.
ما هو معنى أن العنصر لديه رقم يمكن الوصول إليه؟
الاسم الذي يمكن الوصول إليه هو النص الذي يعلنه قارئ الشاشة عند التركيز على العنصر. ويتم حسابه من المحتوى، من aria-label، أو من aria-labeledby أو من <label> المرتبط، بترتيب الأولوية الذي تحدده المواصفات. يعتبر الدور التفاعلي بدون اسم يمكن الوصول إليه بمثابة عنصر تحكم لا يمكن للمستخدم التعرف عليه.
¿لماذا لا أستجيب لـ role="button" على اللوحة؟
لأن ARIA لا يضيف السلوك. يحتاج <div role="button"> إلى tabindex="0" لتلقي التركيز ومعالجات keydown لـ Enter وSpace. الحل الأبسط والأقوى هو استخدام العنصر <button> الأصلي، والذي يتضمن بالفعل التركيز وتنشيط لوحة المفاتيح وإرسال النموذج.
هل من الخطأ استخدام aria-hidden="true"؟
من الصحيح إخفاء المحتوى المزخرف أو المكرر من شجرة إمكانية الوصول، ولكن لا ينبغي أبدًا تطبيقه على العناصر التي تتلقى التركيز. إذا تم ترك عنصر قابل للتركيز باستخدام aria-hidden="true"، فقد يركز مستخدم لوحة المفاتيح على شيء لا يعلن عنه قارئ الشاشة. قم دائمًا بدمجها مع الإخفاء البصري الفعلي.
ما هي الأدوات التي تتحقق من صحة أدوار وسمات ARIA؟
يتضمن W3C Nu HTML Checker التحقق من صحة أدوار وسمات ARIA ويكتشف الأدوار غير الموجودة أو المجموعات المحظورة. تشير أدوات axe DevTools وLighthouse إلى الأدوار التي ليس لها اسم يمكن الوصول إليه وتفتقد السمات الإلزامية. للتحقق من النتيجة النهائية، يعرض مفتش شجرة إمكانية الوصول في متصفح DevTools بالضبط ما تتلقاه التكنولوجيا المساعدة.
الأسئلة الشائعة
ما هو الفرق بين دور وسمة ARIA؟
يحدد الدور ما هو العنصر بالنسبة للتكنولوجيا المساعدة، مثل role='tab' أو role='dialog'. تصف السمة حالتها أو علاقاتها، مثل aria-expanded أو aria-labeledby. يتم تطبيق الأدوار على العنصر الذي يمثل المكون؛ يتم تطبيق السمات عادةً على نفس العنصر أو تلك المرتبطة به.
هل تريد استخدام ARIA بدلاً من HTML الأصلي؟
فقط في حالة عدم وجود عنصر HTML يغطي النمط. القاعدة الأولى لـ W3C ARIA واضحة: إذا كان هناك عنصر أصلي، فاستخدمه. أدوار ARIA مطلوبة لعلامات التبويب والأكورديونات ومربعات التحرير والسرد ذات التصفية ومربعات الحوار المشروطة، من بين الأنماط الأخرى التي لا يمكن لـ HTML تنفيذها بمفردها.
ما هو معنى أن العنصر لديه اسم يمكن الوصول إليه؟
الاسم الذي يمكن الوصول إليه هو النص الذي يعلنه قارئ الشاشة عند التركيز على العنصر. يتم حسابه من المحتوى، من aria-label، من aria-labeledby أو من <label> المرتبط، بترتيب الأولوية الذي تحدده المواصفات. يعتبر الدور التفاعلي بدون اسم يمكن الوصول إليه بمثابة عنصر تحكم لا يمكن للمستخدم التعرف عليه.
¿Por qué mi `role='button'` لا تستجيب للوحة المفاتيح؟
لأن ARIA لا يضيف السلوك. يحتاج <div role='button'> إلى tabindex='0' لتلقي التركيز ومعالجات المفاتيح لـ Enter وSpace. الحل الأبسط والأقوى هو استخدام عنصر <button> الأصلي، والذي يتضمن بالفعل التركيز وتنشيط لوحة المفاتيح وإرسال النموذج.
¿Es malo usar `aria-hidden='true''?
من الصحيح إخفاء المحتوى المزخرف أو المكرر من شجرة إمكانية الوصول، ولكن لا ينبغي أبدًا تطبيقه على العناصر التي تتلقى التركيز. إذا تم ترك عنصر قابل للتركيز باستخدام aria-hidden='true'، فقد يركز مستخدم لوحة المفاتيح على شيء لا يعلن عنه قارئ الشاشة. قم دائمًا بدمجها مع الإخفاء البصري الفعلي.
ما هي الأدوات التي تنطبق على الأدوار والسمات ARIA؟
يتضمن W3C Nu HTML Checker التحقق من صحة أدوار وسمات ARIA ويكتشف الأدوار غير الموجودة أو المجموعات المحظورة. تشير أدوات ax DevTools وLighthouse إلى الأدوار التي ليس لها اسم يمكن الوصول إليه وتفتقد السمات الإلزامية. للتحقق من النتيجة النهائية، يعرض مفتش شجرة إمكانية الوصول في متصفح DevTools بالضبط ما تتلقاه التكنولوجيا المساعدة.
¿Cumplir WCAG دون الحاجة إلى تشغيل الكود؟
Superposición de IA الذي يعزز إطراء WCAG خلال 48 ساعة