ARIA وHTML

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

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

مراجعة نبذة مختصرة عن ARIA وأهميتها وحالات استخدامها وكيفية الاستفادة منها إلى أقصى حد

مقدمة عن ARIA

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

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

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

مجموعة WAI

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

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

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

لا تغيّر ARIA وحدها وظيفة العنصر أو مظهره المرئي. وهذا يعني أنّ مستخدمي التكنولوجيا المساعدة فقط سيلاحظون اختلافات بين منتج رقمي يتضمّن 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 بشكل صحيح في قاعدة الرموز البرمجية حصول مستخدمي التكنولوجيات المساعدة على جميع المعلومات التي يحتاجون إليها لاستخدام موقعك الإلكتروني أو تطبيقك أو منتجك الرقمي الآخر بنجاح وبشكل عادل.

في الآونة الأخيرة، أتاحت "أدوات مطوّري البرامج في 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: استخدام أسماء يمكن الوصول إليها للعناصر التفاعلية

يجب توضيح الغرض من العنصر التفاعلي للمستخدم قبل أن يعرف كيفية التفاعل معه. تأكَّد من أنّ جميع العناصر تتضمّن اسم العنصر الظاهر على واجهة المستخدم للمستخدمين الذين يستعينون بأجهزة تكنولوجية مساعِدة.

يمكن أن تكون الأسماء التي يسهل الوصول إليها هي المحتوى المحاط بعنصر (في حالة <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 معقّدة، ويجب توخّي الحذر دائمًا عند استخدامها. على الرغم من أنّ أمثلة الرموز البرمجية في هذا الدرس بسيطة إلى حدّ ما، إلا أنّ إنشاء أنماط مخصّصة يسهل استخدامها قد يصبح معقّدًا بسرعة.

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

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