ARIA: سم أم علاج؟

كيف يساعد الكذب على برامج قراءة الشاشة في علاج سهولة الوصول، عندما لا يفرك الملح!

ما هو ARIA؟

تتيح ARIA لمؤلفي الويب ابتكار واقع بديل، لا يظهر إلا لبرامج قراءة الشاشة 🤥

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

عندما توجد ملاحظة ملصقة سحرية، فإنها تتجاهل اقتناعنا حول ماهية كل أداة، أو شيئًا يتعلق بالأداة. مثال: "الشيء التالي هو مسدس غراء". على الرغم من أنه لا يزال صندوقًا أزرق فارغًا يكون هناك على منضدة العمل، فإن الملاحظة الملصقة السحرية ستجعلنا نرى أنها مسدس غراء. ويمكننا أيضًا إضافة "امتلأ بنسبة 30%!". سيبلغك قارئ الشاشة الآن عن وجود مسدس غراء كامل بنسبة 30٪.

الويب المكافئ لذلك هو أخذ عنصر مربع عادي (div) مع صورة بداخله، واستخدام ARIA لتقول إنه شريط تمرير بقيمة 30 من 100.

ما هو ARIA؟

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

لم يقم ARIA بتنفيذ أي شيء لتركيز لوحة المفاتيح أو ترتيب التنقل بمفتاح التبويب (Tab). ويتم كل ذلك باستخدام HTML، ويتم أحيانًا تعديله باستخدام أجزاء من JavaScript.

ما هي آلية عمل ARIA؟

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

ما سبب اختيار ARIA؟

لماذا نرغب في الكذب على مستخدمينا!؟

لنفترض أن السوق المحلي على الويب لا يبيع جميع التطبيقات المصغّرة التي نحتاجها. لكننا، MacGyver، بالتأكيد. يمكننا فقط اختراع تطبيقاتنا المصغّرة من أدوات أخرى! FWIW، الأشياء السبعة الأكثر استخدامًا في MacGyver هي سكاكين الجيش السويسري، والعلكة، وخيوط الأحذية، وأعواد ثقاب، ومشابك الورق، وشموع عيد الميلاد، وشريط لاصق. إنه يستخدمها لصنع قنابل وأشياء أخرى لا تكتفي بالمنتشرة. هذا مشابه تمامًا لمؤلف الويب الذي يحتاج إلى إنشاء شريط قوائم. أشرطة القوائم مفيدة جدًا لدرجة أنك قد تعتقد أنها ستكون جزءًا من HTML، لكنها ليست كذلك. حسنًا. لم تعتقد أن المؤلفين سيكونون سعداء بالروابط والأزرار، أليس كذلك؟ لذلك سيجمع المؤلف أحدها معًا باستخدام أدواته المفضلة: عناصر divs والصور والنمط ومعالجات النقرات ومعالجات الضغط على المفاتيح والبصق وARIA.

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

مثال على شريط القوائم

دعم الأشخاص الذين يستخدمون نقر الماوس

لنقم بإنشاء شريط قوائم معًا. نعرض مجموعة من العناصر في عناصر مربع عامة تسمى divs. في أي وقت ينقر فيه المستخدم على علامة div، يتم تنفيذ الأمر المقابل. رائع، إنها تناسب الأشخاص الذين يستخدمون الماوس!

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

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

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

تسهيل الوصول إلى لوحة مفاتيح شريط القوائم

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

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

• إذا ضغط المستخدم على مفتاح سهم، فلنلقي نظرة على مخططات شريط القوائم الداخلية ونقرر ما ينبغي أن يكون عليه عنصر القائمة النشط الجديد. سنقوم بمحو أي نقاط بارزة حالية وتسليط الضوء على عنصر القائمة الجديد حتى يعرف المستخدم المبصر مكانه بصريًا. من المفترض أن تستدعي صفحة الويب event.preventDefault() بعد ذلك لمنع المتصفّح من تنفيذ الإجراء المعتاد (التمرير في الصفحة في هذه الحالة).
• إذا ضغط المستخدم على مفتاح Enter، يمكننا التعامل معه كنقرة، وتنفيذ الإجراء المناسب (أو حتى فتح قائمة أخرى).
• إذا ضغط المستخدم على مفتاح يجب أن يفعل شيئًا آخر، فلا تأكل ذلك! إعادتها إلى الصفحة على النحو المنشود في الطبيعة. على سبيل المثال، لا يحتاج شريط القوائم إلى مفتاح Tab، لذا ارجع إليه مرة أخرى. من الصعب حدوث ذلك بشكل صحيح، وغالبًا ما يخلط المؤلفون الأمر. على سبيل المثال، يحتاج شريط القوائم إلى مفاتيح الأسهم، وليس Alt+Arrow أو Command+السهم. هذه هي اختصارات للانتقال إلى الصفحة السابقة/التالية في سجل الويب لعلامة تبويب المتصفح. وإذا لم يكن المؤلف حريصًا، فإن شريط القوائم سيتناولها. يحدث هذا النوع من الأخطاء كثيرًا، ولم نبدأ حتى بـ ARIA بعد!

وصول قارئ الشاشة إلى شريط القوائم

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

لكن هذا ليس عادلاً! يعمل شريط القوائم بشكل جيد للمستخدم المبصر.

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

يكمن الأول، وهو ahem، ARIA، في استخدام السمة aria-activedescendant، وضبطها على معرّف عنصر القائمة النشط حاليًا، مع الحرص على تعديلها كلما تغيرت. مثلاً، aria-activedescendant="settings-menuitem". تجعل هذه الكذبة البيضاء الصغيرة قارئ الشاشة يعتبر عنصر ARIA النشط محور التركيز، والذي تتم قراءته بصوت عالٍ أو عرضه على جهاز عرض بلغة برايل.

الرجوع إلى aria-activedescendant من خلال استخدامه للإشارة من شريط القوائم محل التركيز إلى عنصر قائمة محدد، يعرف قارئ الشاشة الآن المكان الذي انتقل فيه المستخدم، ولكن لا يعرف أي شيء آخر عن الكائن. ما هو عنصر div هذا على أي حال؟ وهنا يأتي دور سمة الدور. نستخدم role="menubar" في العنصر الذي يحتوي على العنصر بأكمله، ثم نستخدم role="menu" في مجموعات العناصر، ثم على role="menuitem" في ... الطبل ... عناصر القائمة الفردية.

وماذا لو كان عنصر القائمة يمكن أن يؤدي إلى قائمة فرعية؟ يحتاج المستخدم إلى معرفة ذلك أليس كذلك؟ بالنسبة إلى المستخدم المبصر، قد يكون هناك صورة صغيرة لمثلث في نهاية القائمة، لكن قارئ الشاشة لا يعرف كيفية قراءة الصور تلقائيًا، على الأقل في هذه المرحلة. يمكننا إضافة aria-expanded="false" على كل عنصر من عناصر القائمة القابلة للتوسيع، للإشارة إلى 1) توفّر عنصر يمكن توسيعه، و2) عدم توسيع هذا العنصر حاليًا. لإضافة لمسة، يجب أن يضع المؤلف role="none" على مثلث الصورة المصغرة للإشارة إلى أن ذلك لأغراض التوضيح فقط. يمنع ذلك قارئ الشاشة من قول أي شيء عن الصورة التي تكون متكررة في أحسن الأحوال وربما تكون مزعجة.

التعامل مع الأخطاء

أخطاء لوحة المفاتيح (HTML!)

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

أمثلة على الأخطاء:

• يستخدم مربّع الاختيار مفتاح المسافة للتبديل، ولكن نسي المؤلف طلب الرقم preventDefault(). سيعمل مفتاح المسافة الآن على تبديل مربع الاختيار والصفحة لأسفل، وهو سلوك المتصفح الافتراضي بالنسبة إلى مفتاح المسافة.
• يريد مربع حوار ARIA المشروط أن يميّز التنقل بين علامات التبويب داخله، وينسى المؤلف السماح تحديدًا للتحكّم+Tab بالوصول إلى المتصفِّح. أما الآن، فبإمكان Control+Tab التنقّل بسهولة داخل مربّعات الحوار، ولا يبدِّل علامات التبويب في المتصفِّح على النحو المطلوب. أُف.
• ينشئ المؤلف قائمة تحديد، وينفذ لأعلى/لأسفل، لكنه لا يقوم بتنفيذ home/end/pageup/pagedown أو التنقل بالحرف الأول.

يجب على المؤلفين اتباع الأنماط المعروفة. يُرجى مراجعة قسم الموارد لمزيد من المعلومات.

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

غالبًا ما تكون أخطاء لوحة المفاتيح أخطاءً في محتوى الويب، وخاصةً في HTML وJavaScript، وليس في ARIA.

أخطاء ARIA: لماذا هناك الكثير من الأخطاء؟

هناك العديد من الأماكن التي قد يخطئ فيها المؤلفون في أخطاء ARIA، وسيؤدّي كل منها إلى تعطُّل كامل أو اختلافات طفيفة. ومن المحتمل أن تكون العناوين الخفية أسوأ من ذي قبل، لأن المؤلف لن يكتشف معظمها قبل نشرها.

بعد كل شيء، ما لم يكن المؤلف مستخدمًا متمرسًا لقارئ الشاشة، فسيحدث خطأ ما في ARIA. في مثال شريط القوائم لدينا، يمكن للمؤلف أن يعتقد أن دور "الخيار" كان سيتم استخدامه عندما يكون " Menuitem" صحيحًا. ويمكن أن ينسى استخدام aria-expanded، أو ينسى ضبط aria-activedescendant ومحوه في الأوقات المناسبة، أو ينسى وجود شريط قوائم يحتوي على القوائم الأخرى. وماذا عن أعداد عناصر القائمة؟ عادةً ما يتم تقديم عناصر القائمة بواسطة برامج قراءة الشاشة بشيء مثل "العنصر 3 من 5" حتى يعرف المستخدم مكان وجوده. يتم احتساب هذا عادةً بشكل تلقائي من خلال المتصفّح، ولكن في بعض الحالات، وفي بعض مجموعات برامج قراءة الشاشة في المتصفِّح، قد يتم احتساب أرقام خاطئة ويحتاج المؤلف إلى إلغاء هذه الأرقام باستخدام aria-posinset وaria-setsize.

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

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

ملخّص

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

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

الملحق 1: موارد إضافية

مرجع مختلط يضم معلومات لوحة المفاتيح وأمثلة على الرموز

• ممارسات تأليف ARIA في W3C: توثّق هذه الرسالة خصائص التنقّل المهمة بلوحة المفاتيح لكل مثال وتوفّر رموز JS/CSS/ARIA صالحة. تركّز الأمثلة على ما يحقّق النجاح حاليًا، ولا تتناول الأجهزة الجوّالة.

الملحق 2: لأي غرض يتم استخدام ARIA بشكل أكبر؟

وبما أنّ ARIA يمكنها أن تحل محل الحقائق الصغيرة أو الكبيرة أو تكملها، تكون مفيدة بشكل عام لقول الأشياء التي يهتم بها قارئ الشاشة.

في ما يلي بعض الاستخدامات الشائعة لـ ARIA.

• تطبيقات مصغّرة خاصة غير موجودة في HTML، مثل شريط القوائم أو الإكمال التلقائي أو الشجرة أو جدول البيانات
• تطبيقات مصغّرة متوفرة بتنسيق HTML، إلا أن المؤلف ابتكر تطبيقاتها الخاصة على أي حال، ربما يكون ذلك لأنه يحتاج إلى تعديل طريقة عمل الأداة العادية أو مظهرها. على سبيل المثال، يُعدّ عنصر HTML <input type="range"> شريط تمرير في الأساس، ولكن يريد المؤلفون جعله يبدو مختلفًا. في معظم الحالات، يمكن استخدام CSS، ولكن بالنسبة إلى input type="range"، يُعدّ CSS طريقة غير ملائمة. يمكن للمؤلف إنشاء شريط تمرير خاص به، واستخدام role="slider" عليه مع aria-valuenow لتوضيح القيمة الحالية.
• تخبر المناطق المباشرة برامج قراءة الشاشة "في هذه المنطقة من الصفحة، أي شيء يتغير يستحق إخبار المستخدم عنه".
• المعالم (لدى HTML الآن مكافئات). تشبه هذه إلى حد ما العناوين من حيث أنها تساعد مستخدمي قارئ الشاشة في العثور على ما يريدون بشكل أسرع. ومع ذلك، فهي مختلفة في أنها تحتوي على المنطقة ذات الصلة بالكامل. مثل، "هذه الحاوية هي المنطقة الرئيسية من الصفحة" و "هذه الحاوية هنا هي لوحة تنقل".

الملحق 3: ما هي واجهة برمجة التطبيقات Accessibility API؟

واجهة برمجة التطبيقات Accessibility API هي الطريقة التي يعرف بها قارئ الشاشة أو التكنولوجيا المساعدة الأخرى ما يوجد في الصفحة وما يحدث الآن. وتشمل الأمثلة MSAA، وIA2، وUIA. وهذا فقط نظام Windows! هناك جزءان لواجهة واجهة برمجة التطبيقات Accessibility API:

• "شجرة" من العناصر التي تمثل تدرجًا هرميًا للحاويات. هذه تشبه الدمى المتداخلة الروسية، ولكن كل دمية يمكن أن تحتوي على عدة دمى أخرى. على سبيل المثال، يمكن أن يحتوي المستند على مجموعة من الفقرات، ويمكن أن تحتوي الفقرة على نص وصور وروابط وخط غامق وما إلى ذلك. ويمكن أن يحتوي كل عنصر في شجرة الكائنات على خصائص مثل دور (ما أنا؟)، واسم/تصنيف، وقيمة يُدخلها المستخدم، ووصفًا، بالإضافة إلى الحالات المنطقية مثل يمكن التركيز عليها، والتركيز، والمطلوب، وتحديدها. يمكن لـ ARIA تجاوز أي من هذه الخصائص. يستخدم قارئ الشاشة الشجرة لمساعدة المستخدم في التنقل في وضع المخزن المؤقت الافتراضي، مثل "الانتقال إلى العنوان التالي من فضلك".
• سلسلة من الأحداث التي تحدث تصف التغييرات التي تطرأ على الشجرة، مثل "أصبح التركيز الآن هنا!". يستخدم قارئ الشاشة الأحداث لإبلاغ المستخدم بما حدث للتو. عندما يتغيّر ترميز HTML أو ARIA، يتم تنشيط الحدث لإعلام قارئ الشاشة بحدوث تغيير.

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