ARIA وHTML

معظم المطوّرين على دراية باللغة الترميزية القياسية في الويب الحديث، وهي لغة ترميز النص الفائق (HTML). ومع ذلك، قد لا تكون معتادًا على استخدام تطبيقات الإنترنت الغنية بصريًا (ARIA) (المعروفة رسميًا باسم WAI-ARIA): ما هي وكيفية استخدامها ومتى ولا يتم استخدامها.

يلعب HTML وARIA أدوارًا مهمة في جعل المنتجات الرقمية سهلة الوصول، خاصة عندما يتعلق الأمر بالتكنولوجيا المساعدة (AT) مثل برامج قراءة الشاشة. يُستخدم كلاهما لتحويل المحتوى إلى تنسيق بديل، مثل لغة برايل أو تحويل النص إلى كلام (TTS).

لنراجع سجلًا موجزًا بـ ARIA وسبب أهميته وأفضل طريقة لاستخدامه.

مقدمة عن ARIA

تم تطوير ARIA لأول مرة في عام 2008 من خلال مجموعة مبادرة تسهيل استخدام الويب (WAI)، وهي مجموعة فرعية من اتحاد شبكة الويب العالمية (W3C) الشامل، والتي تحكم وتنظم شبكة الإنترنت.

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

"WAI-ARIA، مجموعة تطبيقات الإنترنت التفاعلية السهلة الوصول إليها تحدد طريقة لتسهيل الوصول إلى محتوى الويب وتطبيقات الويب للأشخاص من ذوي الاحتياجات الخاصة. ويساعد هذا الإجراء بشكل خاص في المحتوى الديناميكي وعناصر التحكّم المتقدّمة في واجهة المستخدم التي تم تطويرها باستخدام HTML وJavaScript والتقنيات ذات الصلة بها".

مجموعة WAI

شجرة تسهيل الاستخدام

يُجري ARIA تعديلاً للتعليمات البرمجية غير الصحيحة أو غير المكتملة لإنشاء تجربة أفضل لمن يستخدمون التكنولوجيا المساعدة (AT) من خلال تغيير أجزاء من شجرة تسهيل الاستخدام وعرضها وتعزيزها.

يتم إنشاء شجرة تسهيل الاستخدام من قِبل المتصفّح استنادًا إلى شجرة نموذج كائن المستند (DOM) العادية. مثل شجرة نموذج العناصر في المستند (DOM)، تحتوي شجرة تسهيل الاستخدام على عناصر تمثّل جميع عناصر الترميز والسمات والعُقد النصية. يتم أيضًا استخدام شجرة تسهيل الاستخدام من خلال واجهات برمجة التطبيقات لإمكانية الوصول الخاصة بالنظام الأساسي لتوفير تمثيل يمكن للتكنولوجيات المساعدة فهمه.

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

الميزات الرئيسية الثلاث لـ ARIA هي الأدوار والخصائص والحالات/القيم.

تحدِّد الأدوار محتوى الصفحة أو التطبيق وما يفعله.

<div role="button">Self-destruct</div>

تعبّر الخصائص عن الخصائص أو العلاقات مع الكائن.

<div role="button" aria-describedby="more-info">Self-destruct</div>

<div id="more-info">This page will self-destruct in 10 seconds.</div>

تحدد الحالات/القيم الشروط الحالية أو قيم البيانات المرتبطة بالعنصر.

<div role="button" aria-describedby="more-info" aria-pressed="false">
  Self-destruct
</div>

<div id="more-info">
  This page will self-destruct in 10 seconds.
</div>

بينما يمكن استخدام عناصر ARIA الثلاثة جميعها في سطر واحد من التعليمات البرمجية، إلا أنه ليس مطلوبًا. بدلاً من ذلك، أضِف أدوار ARIA وخصائصه والحالات/القيم حتى تُحقق الهدف النهائي لإمكانية الوصول. إن دمج ARIA بشكل صحيح في قاعدة التعليمات البرمجية يضمن أن مستخدمي AT سيكون لديهم جميع المعلومات التي يحتاجونها لاستخدام موقع الويب أو التطبيق أو أي منتج رقمي آخر بنجاح ومنصف.

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

حالات استخدام ARIA

في عام 2014، نشرت W3C رسميًا توصية HTML5. وقد أجرينا بعض التغييرات المهمة، بما في ذلك إضافة عناصر معلَمة، مثل <main> و<header> و<footer> و<aside> و<nav>، فضلاً عن إضافة سمات مثل hidden وrequired. مع عناصر وسمات HTML5 الجديدة هذه، إلى جانب التوافق المتزايد مع المتصفح، أصبحت أجزاء معينة من ARIA الآن أقل أهمية.

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

وهذا يقودنا إلى السؤال الجوهري: متى يجب استخدام ARIA؟ لحسن الحظ، طوّرت مجموعة WAI القواعد الخمس لـ ARIA لمساعدتك في تحديد كيفية جعل العناصر سهلة الوصول.

القاعدة 1: عدم استخدام ARIA

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

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

<a role="button">Submit</a>

<button>Submit</button>

إذا كانت لديك شكوك، استخدِم عناصر HTML الدلالية.

القاعدة 2: عدم إضافة ARIA (غير ضروري) إلى HTML

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

<h2 role="tab">Heading tab</h2>

<div role="tab"><h2>Heading tab</h2></div>

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

القاعدة 3: إتاحة التنقل باستخدام لوحة المفاتيح دائمًا

يجب أن تتوفّر إمكانية الوصول إلى جميع عناصر تحكُّم ARIA التفاعلية (غير المتوقفة) باستخدام لوحة المفاتيح. يمكنك إضافة tabindex= "0" إلى أي عنصر يحتاج إلى تركيز لا يحصل عادةً على تركيز لوحة المفاتيح. تجنَّب استخدام فهارس علامات التبويب مع أعداد صحيحة موجبة متى أمكن لمنع المشاكل المحتملة في ترتيب تركيز لوحة المفاتيح.

<span role="button" tabindex="1">Submit</span>

<span role="button" tabindex="0">Submit</span>

القاعدة 4: عدم إخفاء العناصر التي يمكن التركيز عليها

لا تضِف role= "presentation" أو aria-hidden= "true" إلى العناصر التي يجب التركيز عليها، بما في ذلك العناصر التي تتضمّن tabindex= "0". عند إضافة هذه الأدوار/الحالات إلى العناصر، فإنها ترسل رسالة إلى التكنولوجيا المساعدة بأن هذه العناصر ليست مهمة وأن تتخطاها. يمكن أن يؤدي هذا إلى الارتباك أو مقاطعة المستخدمين الذين يحاولون التفاعل مع عنصر ما.

<div aria-hidden="true"><button>Submit</button></div>

<div><button>Submit</button></div>

القاعدة 5: استخدام أسماء التي يمكن الوصول إليها للعناصر التفاعلية

يجب نقل الغرض من العنصر التفاعلي إلى المستخدم قبل أن يعرف كيفية التفاعل معه. التأكد من أن جميع العناصر لها اسم يسهل الوصول إليه لمستخدمي أجهزة التكنولوجيا المساعِدة (AT).

وقد تكون الأسماء التي يمكن الوصول إليها عبارة عن المحتوى المُحاط بعنصر (في حالة <a>) أو نص بديل أو تصنيف.

لكل من عينة التعليمات البرمجية التالية، الاسم الذي يمكن الوصول إليه هو "أحذية جلدية حمراء".

<!-- A plain link with text between the link tags. -->
<a href="shoes.html">Red leather boots</a>

<!-- A linked image, where the image has alt text. -->
<a href="shoes.html"><img src="shoes.png" alt="Red leather boots"></a>

<!-- A checkbox input with a label. -->
<input type="checkbox" id="shoes">
<label for="shoes">Red leather boots</label>

هناك عدة طرق للتحقّق من اسم العنصر الذي يمكن الوصول إليه، بما في ذلك فحص شجرة تسهيل الاستخدام باستخدام أدوات مطوّري البرامج في Chrome أو اختباره باستخدام قارئ الشاشة.

ARIA بتنسيق HTML

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

بالطبع، هناك اقتراحات لتنفيذ ARIA بلغة HTML. الأهم من ذلك: عدم إلغاء أدوار HTML التلقائية، وتقليل التكرار، والانتباه إلى الآثار الجانبية غير المقصودة

لنلقِ نظرة على بعض الأمثلة.

<a role="heading">Read more</a>

<a aria-label="Read more about some awesome article title">Read More</a>

<ul role="list">...</ul>

<ul>...</ul>

<details>
  <summary role="button">more information</summary>
  ...
</details>

<details>
  <summary>more information</summary>
  ...
</details>

تعقيدات ARIA

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

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

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

التحقّق من استيعابك

اختبر معلوماتك حول ARIA وHTML