ARIA وأنماط العناصر التفاعلية

لماذا يهم

العناصر المخصصة (Custom widgets) من أسهل المواضع التي تتعطل فيها إمكانية الوصول في تطبيقات الويب الحديثة، لأن كل ما يقدمه العنصر الأصلي يجب أن يُعاد بناؤه يدوياً: الدور والاسم والحالة وحركة التركيز وكل مفتاح. فنافذة حوار يفلت منها التركيز إلى الصفحة التي خلفها، أو تبويبات لا تتغير حالة اختيارها أبداً، أو مربع تحرير وسرد لا يُعلَن فيه الخيار المميَّز، قد تمنع مستخدم لوحة المفاتيح أو قارئ الشاشة من إتمام عملية دفع أو نموذج. وهذه إخفاقات في معايير نجاح WCAG 2.2 مثل 4.1.2 الاسم والدور والقيمة (Name, Role, Value) و2.1.1 لوحة المفاتيح (Keyboard) و2.4.3 ترتيب التركيز (Focus Order)، وكلها من المستوى A.

وقد تكون ARIA الخاطئة أسوأ من غيابها: فالدور يَعِد بسلوك معيّن، وإذا غاب السلوك ضُلِّل المستخدم. وبالنسبة إلى المختبِر، تحوّل الأنماط ملاحظة غامضة مثل «التبويبات غير قابلة للوصول» إلى توقعات دقيقة قابلة للفحص يستطيع المطور العمل بها، وتساعد على الفصل بين إخفاقات WCAG الحقيقية والانحرافات عن عُرف متّبع.

ARIA في فقرة واحدة، والقاعدة الأولى

يشرح دليل اختبار قارئات الشاشة ARIA بالتفصيل؛ وهذه هي الخلاصة التي يبني عليها هذا الدرس. الأدوار (Roles) تقول ما هو العنصر (tab وdialog وmenu وcombobox). والحالات (States) أوضاع تتغير أثناء عمل المستخدم (aria-expanded وaria-selected وaria-checked). والخصائص (Properties) سمات وعلاقات أكثر ثباتاً (aria-label وaria-labelledby وaria-controls وaria-haspopup). ويُحسب الاسم القابل للوصول كما يصفه ذلك الدليل، مع تقدّم aria-labelledby وaria-label على غيرهما. وبعض الأدوار لا معنى لها إلا في سياقها: فالعنصر tab مكانه داخل tablist، وoption داخل listbox، وmenuitem داخل menu.

والقاعدة الأولى لاستخدام ARIA: إذا كان في HTML عنصر أو سمة أصلية فيها الدلالات والسلوك المطلوبان، فاستخدمها بدلاً من إضافة ARIA. فالعنصر <button> أفضل من <div role="button"> لأنه يقبل التركيز ويستجيب لـ Enter وSpace من تلقاء نفسه؛ والعنصران <details> و<summary> يقدّمان عنصر إفصاح جاهزاً؛ والعنصر <dialog> المفتوح بالدالة showModal() يجعل بقية الصفحة خاملة (inert). لذلك فأول سؤال في مراجعة أي عنصر مخصص: هل يحتاج إلى ARIA أصلاً؟ أما التبويبات وأزرار القوائم ومربعات التحرير والسرد ذات القوائم المخصصة فليس لها مقابل أصلي كامل، ولهذا تهمّ أنماطها المختبِرين.

كيف تقرأ صفحة نمط في APG

تتكوّن كل صفحة نمط في APG من الأجزاء نفسها، وكل جزء يتحول إلى نوع من الاختبارات. فاكتب النتائج المتوقعة قبل أن تفتح المنتج.

فمثلاً، يصبح مدخل Right Arrow في نمط التبويبات اختباراً بلوحة المفاتيح: ضع التركيز على تبويب، واضغط Right Arrow، وتوقّع انتقال التركيز إلى التبويب التالي، وعلى التبويب الأخير توقّع أن يلتفّ التركيز إلى الأول. ويصبح قسم الأدوار فحصاً في الشجرة: كل تبويب عنصر tab داخل tablist، ولا يحمل aria-selected="true" إلا التبويب الذي تظهر لوحته.

• About This Pattern (عن هذا النمط): الغرض من العنصر. طابِق العنصر بسلوكه لا بمظهره: فصفّ من الأزرار يبدّل اللوحات في مكانها هو تبويبات، وزر «عرض المزيد» عنصر إفصاح (Disclosure)، وقائمة روابط الموقع المنسدلة تنقّلٌ (Navigation) وليست menu.
• Keyboard Interaction (تفاعل لوحة المفاتيح): مدخل لكل مفتاح، وكل مدخل خطوة اختبار لها نتيجة متوقعة. والمفاتيح الموسومة «(Optional)»، مثل Home وEnd في التبويبات، ليست إلزامية، لكن إذا نفّذها المنتج وجب أن تعمل كما هو موصوف.
• WAI-ARIA Roles, States, and Properties (الأدوار والحالات والخصائص): الأدوار وأيّها يحتوي الآخر، والحالات التي يجب أن تتغير أثناء التشغيل، والخصائص التي تسمّي الأجزاء وتربط بينها. وكل سطر فحص في شجرة إمكانية الوصول. واقرأ الشروط بعناية: فعبارة «إذا كان لقائمة التبويبات تسمية مرئية» هي التي تحسم الاختيار بين aria-labelledby وaria-label.
• Examples (الأمثلة): نماذج عاملة، لكل منها جدول لدعم لوحة المفاتيح وجدول للأدوار والخصائص والحالات وقيم tabindex. ويكشف عمود tabindex أسلوب إدارة التركيز الذي يستخدمه المثال.
• الخيارات التي يتركها النمط مفتوحة: التفعيل التلقائي أو اليدوي للتبويبات، والاتجاه الأفقي أو العمودي. اسأل الفريق أي صيغة اختار، وسجّلها في أساس الاختبار (Test basis)؛ وإلا فلن تستطيع التمييز بين العيب والقرار التصميمي.

<div الجزء 1:1role="tablist" الجزء 2:2aria-label="Order details">
  <button الجزء 3:3role="tab" id="t1" الجزء 4:4aria-selected="true"
          الجزء 5:5aria-controls="p1" الجزء 6:6tabindex="0">Items</button>
  <button الجزء 3:3role="tab" id="t2" الجزء 4:4aria-selected="false"
          الجزء 5:5aria-controls="p2" الجزء 6:6tabindex="-1">Delivery</button>
</div>
<div الجزء 7:7role="tabpanel" id="p1" الجزء 8:8aria-labelledby="t1"
     الجزء 9:9tabindex="0">…</div>
<div الجزء 7:7role="tabpanel" id="p2" الجزء 8:8aria-labelledby="t2"
     الجزء 9:9tabindex="0" الجزء 10:10hidden>…</div>

التحقق من خمسة أنماط من البداية إلى النهاية

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

• نافذة الحوار المشروطة (Modal dialog). الشجرة: دور dialog يسمّيه عنوانه المرئي، مع aria-modal="true" في النافذة المخصصة، أو عنصر <dialog> أصلي مفتوح بالدالة showModal(). لوحة المفاتيح: ينتقل التركيز إلى داخل النافذة عند فتحها، ويدور Tab وShift+Tab داخلها، ويغلقها Escape، ويعود التركيز إلى عنصر التحكم الذي فتحها. قارئ الشاشة: يُعلَن دور النافذة واسمها عند فتحها، ولا تتسرب القراءة بمفاتيح الأسهم إلى الصفحة التي خلفها.
• الإفصاح والأكورديون (Disclosure وAccordion). الشجرة: عنصر button تطابق قيمة aria-expanded فيه ما هو ظاهر؛ وفي الأكورديون يقع كل زر رأس داخل عنصر عنوان. لوحة المفاتيح: Enter وSpace يوسّعان القسم ويطويانه، ولا يصل Tab إلى المحتوى المطوي. قارئ الشاشة: تتحول «مطوي» (collapsed) إلى «موسَّع» (expanded) عند الضغط على الزر.
• التبويبات (Tabs). الشجرة: tablist له اسم؛ وعناصر tab تحمل aria-controls وaria-selected؛ وعناصر tabpanel يسمّيها تبويبها عبر aria-labelledby، واللوحات غير النشطة مخفية. لوحة المفاتيح: قائمة التبويبات محطة Tab واحدة تستقر على التبويب النشط؛ ويتنقل Left Arrow وRight Arrow بين التبويبات ويلتفّان عند الطرفين؛ وضغطة Tab التالية تدخل اللوحة، التي تأخذ هي نفسها tabindex="0" إذا لم يكن في أول محتواها ما يقبل التركيز. وفي التخطيط من اليمين إلى اليسار، تحقّق من اتجاه الأسهم الذي سجّله فريقك. قارئ الشاشة: يُعلن كل تبويب اسمه ودوره وحالة اختياره، وغالباً موضعه، مثل ⁦2⁩ من ⁦3⁩.
• زر القائمة (Menu button). الشجرة: عنصر button يحمل aria-haspopup، وaria-expanded="true" ما دامت القائمة مفتوحة، ويفتح menu من عناصر menuitem. لوحة المفاتيح: Enter أو Space يفتح القائمة على أول عنصر فيها (وقد يفتحها Down Arrow أيضاً)، وUp Arrow وDown Arrow يتنقلان، وEnter يفعّل العنصر ويغلق القائمة، وEscape يغلقها ويعيد التركيز إلى الزر. قارئ الشاشة: يُعلن الزر أنه يفتح قائمة، ويُعلَن كل عنصر على أنه عنصر قائمة.
• مربع التحرير والسرد (Combobox). الشجرة: لحقل الإدخال دور combobox، واسم من تسميته، وaria-expanded تطابق حالة القائمة، وaria-controls تشير إلى listbox من عناصر option، وaria-activedescendant مضبوطة على معرّف الخيار المميَّز، الذي يحمل aria-selected="true". لوحة المفاتيح: الكتابة تصفّي الخيارات، وDown Arrow يتنقل بينها بينما يبقى التركيز في الحقل، وEnter يقبل الخيار، وEscape يغلق القائمة. قارئ الشاشة: يُقرأ كل خيار مميَّز أثناء التنقل، وتبقى الكتابة ممكنة.

جرّبها: منسّق HTML جرّبها: مولّد حالات الاختبار

أسلوبا التركيز: tabindex المتنقل وaria-activedescendant

العناصر المركّبة (Composite widgets) مثل التبويبات والقوائم وصناديق القوائم والشبكات محطة Tab واحدة، ومفاتيح الأسهم تتنقل داخلها. ويصف APG طريقتين لبناء ذلك. في أسلوب tabindex المتنقل (Roving tabindex) يحمل العنصر الحالي tabindex="0" وكل عنصر آخر tabindex="-1"؛ ومع كل ضغطة سهم تنقل الشيفرة القيمة 0 إلى العنصر الجديد وتستدعي focus() عليه. فيتحرك تركيز DOM فعلاً، ويمرّر المتصفح العنصر إلى مجال الرؤية، وإذا غادر المستخدم العنصر بـ Tab ثم عاد، رجع التركيز إلى العنصر الذي تركه.

أما في أسلوب aria-activedescendant فيبقى تركيز DOM على عنصر واحد (الحاوية، أو حقل الإدخال في مربع التحرير والسرد)، وتضبط الشيفرة السمة على معرّف (id) العنصر النشط، فتعامله التقنيات المساعدة كأنه صاحب التركيز. وعلى الشيفرة أن ترسم مؤشر التركيز المرئي وأن تمرّر العنصر إلى مجال الرؤية بنفسها، لأن المتصفح لا يفعل أياً منهما. ويحتاج مربع التحرير والسرد إلى هذا الأسلوب ليواصل المستخدم الكتابة وهو يتنقل بين الخيارات.

ولتميّز بينهما، افتح لوحة Elements في أدوات المطور في Chrome أو Edge واضغط مفاتيح الأسهم، ولاحظ أي سمة تتغير. ثم أضف document.activeElement تعبيراً حياً (Live expression) عبر أيقونة العين أعلى Console، فيظل يُظهر أين يقع تركيز DOM فعلاً. ولكل أسلوب أعطال يمكن التعرف عليها:

• أسلوب tabindex المتنقل: تحتفظ عدة عناصر بالقيمة tabindex="0"، فيمرّ Tab على كل تبويب بدلاً من الانتقال إلى اللوحة؛ أو لا يحمل أي عنصر القيمة 0 بعد إعادة الرسم، فلا يمكن الوصول إلى العنصر بـ Tab إطلاقاً (2.1.1).
• أسلوب tabindex المتنقل: يحرّك مفتاح السهم التمييز المرئي لكن focus() لا تُستدعى، فيبقى مؤشر التركيز وقارئ الشاشة على العنصر القديم.
• أسلوب tabindex المتنقل: تبقى القيمة 0 على العنصر الأول، فيعود Shift+Tab إلى تبويب غير التبويب المختار.
• أسلوب aria-activedescendant: تشير السمة إلى معرّف لم يعد موجوداً، وغالباً بعد تصفية القائمة وإعادة بنائها؛ فيتحرك التمييز ولا يقول قارئ الشاشة شيئاً.
• أسلوب aria-activedescendant: تتغير السمة لكن لا يُرسم أي تمييز، فلا يرى مستخدمو لوحة المفاتيح المبصرون موضعهم (ويُبلَّغ عنه عادةً تحت 2.4.7 Focus Visible)؛ أو يبقى الخيار النشط خارج مجال الرؤية.
• أسلوب aria-activedescendant: العنصر المشار إليه بلا دور option أو menuitem، أو يقع خارج العنصر والقائمة التي يتحكم بها، فيُعلَن نصاً عادياً أو لا يُعلَن أصلاً.

مثال تطبيقي: اختبار تبويبات الطلب وكتابة العيوب

في صفحة طلب ثلاثة تبويبات: «المنتجات» و«التوصيل» و«الدفع». واختار الفريق أثناء التهذيب (Refinement) نمط التبويبات في APG مع التفعيل التلقائي، فصار ذلك أساس الاختبار. وتُنتج الجولات الثلاث أربع ملاحظات، تُصنَّف كل منها قبل الإبلاغ عنها.

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

• الشجرة: الحاوية عنصر <div> عادي، فتقع التبويبات الثلاثة تحت عقدة عامة (generic) بلا دور tablist وبلا اسم. وتشترط WAI-ARIA أن يكون tab داخل tablist؛ فالتجميع الذي يراه المستخدم غير مكشوف، وهذا إخفاق في 1.3.1 المعلومات والعلاقات (Info and Relationships)، وهو المعيار الذي تربطه به قاعدة ACT من W3C المسماة «ARIA required context role».
• الشجرة وقارئ الشاشة: بعد Right Arrow إلى «التوصيل» تظهر لوحة التوصيل، لكن aria-selected="true" تبقى على «المنتجات»، ولا يعلن قارئ الشاشة أن «التوصيل» مختار. فالحالة الظاهرة على الشاشة ليست الحالة المكشوفة: إخفاق في 4.1.2، بخطورة رئيسي (Major)، لأن المستخدم الكفيف لا يعرف أي لوحة يقرأ.
• لوحة المفاتيح: كل تبويب يحمل tabindex="0"، فيمرّ Tab على التبويبات الثلاثة قبل الوصول إلى اللوحة، ولا يفعل Right Arrow شيئاً على «الدفع» بدلاً من الالتفاف إلى «المنتجات». ومع ذلك يعمل كل تبويب من لوحة المفاتيح، فالمعيار 2.1.1 مستوفى: أبلغ عنه انحرافاً عن تفاعل لوحة المفاتيح في APG، بخطورة ثانوي (Minor)، ودون معيار WCAG.
• الشجرة: للوحات دور tabpanel لكن بلا aria-labelledby، فيدخل المستخدم اللوحة دون أن يسمع إلى أي تبويب تنتمي. وتشترط WAI-ARIA 1.2 اسماً للعنصر ذي الدور tabpanel، فأبلغ عنه استناداً إلى النمط وإلى WAI-ARIA، بخطورة ثانوي.

العنوان:   تبويبات الطلب: حالة الاختيار تبقى على «المنتجات» بعد الانتقال إلى «التوصيل»
المكوّن:   تبويبات تفاصيل الطلب، /orders/1042 · نمط APG Tabs، تفعيل تلقائي
البيئة:    Windows 11 · Firefox · NVDA (الإصدارات في المرفق)
الخطوات:   1. انتقل بـ Tab إلى تبويب «المنتجات».  2. اضغط Right Arrow.
المتوقع:   ينتقل التركيز واللوحة والاختيار إلى «التوصيل»:
           aria-selected="true" على «التوصيل» و"false" على «المنتجات»؛
           ويعلن قارئ الشاشة «التوصيل» تبويباً مختاراً.
الفعلي:    تظهر لوحة «التوصيل»، لكن aria-selected="true" تبقى على «المنتجات»؛
           ولا يعلن NVDA حالة الاختيار.
المعيار:   WCAG 2.2 4.1.2 Name, Role, Value (المستوى A)
الخطورة:   رئيسي (Major)
الدليل:    لقطتا لوحة إمكانية الوصول قبل وبعد، ومقتطف DOM

جرّبها: مولّد وصف الأخطاء بالذكاء الاصطناعي

أسئلة شائعة

المراجع

• ARIA Authoring Practices Guide (APG)W3C Web Accessibility Initiative (WAI)أنماط للعناصر الشائعة (التبويبات والقوائم ونوافذ الحوار والقوائم المنسدلة) مع تفاعل لوحة المفاتيح المتوقع واستخدام ARIA — المرجع الذي تُقارَن به المكونات المخصصة.
• Accessible Rich Internet Applications (WAI-ARIA) 1.2W3C · 2023توصية W3C التي تعرّف أدوار ARIA وحالاتها وخصائصها — أي كيف تُعلن عناصر الواجهة المخصّصة معناها للتقنيات المساعدة.
• Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024توصية W3C التي تحدد معايير النجاح القابلة للاختبار لإتاحة محتوى الويب، مرتّبةً تحت أربعة مبادئ وثلاثة مستويات مطابقة (A وAA وAAA).
• Understanding WCAG 2.2W3C Web Accessibility Initiative (WAI)الشرح التوضيحي لكل إرشاد ومعيار نجاح في WCAG 2.2: الغرض، ومن يستفيد، والأمثلة والتقنيات (غير إلزامي).