ARIA وHTML

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

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

دعونا نستعرض تاريخًا موجزًا لـ ARIA، وسبب أهميته، ومتى وكيف من الأفضل استخدامها.

مقدّمة عن ARIA

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

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

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

مجموعة WAI

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

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

ينشئ المتصفح شجرة تسهيل الاستخدام بناءً على المعيار شجرة نموذج كائن المستند (DOM) وكما هي الحال في شجرة نماذج 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 بشكل صحيح في تضمن قاعدة التعليمات البرمجية أن مستخدمي 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 DevTools أو اختباره باستخدام قارئ شاشة.

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

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

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

التحقق من فهمك

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