مقدمة عن "شجرة تسهيل الاستخدام"
لنفترض أنّك بصدد إنشاء واجهة مستخدم لمستخدمي برامج قراءة الشاشة فقط. في هذه الحالة، لا تحتاج إلى إنشاء أي واجهة مستخدم مرئية على الإطلاق، بل ما عليك سوى تقديم معلومات كافية لاستخدامها في قارئ الشاشة.
ما ستُنشئه هو نوع من واجهات برمجة التطبيقات التي تصف بنية الصفحة، على غرار واجهة برمجة التطبيقات DOM، ولكن يمكنك الاستغناء عن معلومات أقل وعدد أقل من العقد، لأنّ الكثير من هذه المعلومات مفيدة فقط للعرض المرئي. قد يشبه الإجراء التالي ما يلي:
هذا هو ما يقدّمه المتصفّح في الأساس لقارئ الشاشة. يأخذ المتصفح شجرة نموذج العناصر في المستند ويعدّلها في شكل مفيد للتكنولوجيا المساعدة. نشير إلى هذه الشجرة المعدَّلة باسم شجرة الصعوبات.
قد تتصور شجرة تسهيل الاستخدام وكأنها صفحة ويب قديمة تعود إلى فترة التسعينيات: بضع صور، والكثير من الروابط، وربما حقل وزر.
تمنحك عملية فحص الصفحة بصريًا في مثل هذه الحالة تجربة مشابهة لتلك التي يحصل عليها مستخدم قارئ الشاشة. تتوفّر الواجهة، ولكنها بسيطة ومباشرة، تمامًا مثل واجهة شجرة تسهيل الاستخدام.
شجرة إمكانية الوصول هي التي تتفاعل معها معظم التقنيات المساعدة. إليك مثال على مسار الإحالة الناجحة:
- يعرِض تطبيق (المتصفّح أو تطبيق آخر) إصدارًا دلاليًا من واجهة مستخدمه للتكنولوجيا المساعِدة من خلال واجهة برمجة تطبيقات.
- قد تستخدم التكنولوجيا المساعِدة المعلومات التي تقرأها من خلال واجهة برمجة التطبيقات لمحاولة إنشاء عرض بديل لواجهة المستخدم. على سبيل المثال، ينشئ قارئ الشاشة واجهة يسمع فيها المستخدم تمثيلاً ملفوظًا للتطبيق.
- قد تسمح التكنولوجيا المساعدة أيضًا للمستخدم بالتفاعل مع التطبيق بطريقة مختلفة. على سبيل المثال، توفّر معظم برامج قراءة الشاشة عناصر ربط للسماح للمستخدم بمحاكاة نقرة الماوس أو نقرة الإصبع بسهولة.
- تُنقل التكنولوجيا المساعِدة نية المستخدم (مثل "النقر") إلى التطبيق من خلال واجهة برمجة تطبيقات Accessibility API. بعد ذلك، يتحمّل التطبيق مسؤوليةinterpret معالجة الإجراء بشكل مناسب في سياق واجهة المستخدم الأصلية.
بالنسبة إلى متصفّحات الويب، هناك خطوة إضافية في كل اتجاه، لأنّ المتصفّح هو منصّة لتطبيقات الويب التي تعمل داخله. لذا يحتاج المتصفّح إلى ترجمة تطبيق الويب إلى شجرة تسهيل الاستخدام، والتأكّد من تنشيط الأحداث المناسبة في JavaScript استنادًا إلى إجراءات المستخدم الواردة من التكنولوجيا المساعِدة.
إلا أن مسؤولية ذلك تقع على عاتق المتصفّح بالكامل. إنّ مهمتنا كمطوّري صفحات الويب هي إعلامك فقط بأنّ هذا يحدث، وتطوير صفحات ويب تستفيد من هذه العملية لتوفير تجربة سهلة الاستخدام للمستخدمين.
نفعل ذلك من خلال التأكّد من التعبير عن الدلالات في صفحاتنا بشكل صحيح: التأكّد من أنّ العناصر المهمة في الصفحة تتضمّن الأدوار والحالات والسمات الصحيحة التي يمكن الوصول إليها، ومن أنّنا نحدّد الأسماء والوصف المتوافقَين مع أدوات المساعدة. يمكن للمتصفح بعد ذلك السماح للتكنولوجيا المساعدة بالوصول إلى تلك المعلومات لإنشاء تجربة مخصصة.
دلالات في ترميز HTML الأصلي
يمكن للمتصفّح تحويل شجرة نموذج عناصر المستند إلى شجرة تسهيل الاستخدام لأنّ الكثير من نموذج عناصر المستند له معنى دلالي ضمني. وهذا يعني أنّ DOM يستخدم عناصر HTML الأصلية التي تتعرّف عليها المتصفّحات وتعمل على النحو المتوقّع على مجموعة متنوعة من منصّات التشغيل. وتتم معالجة إمكانية الوصول إلى عناصر HTML الأصلية، مثل الروابط أو الأزرار، تلقائيًا. يمكننا الاستفادة من ميزة تسهيل الاستخدام المضمّنة في المحتوى من خلال كتابة علامات HTML تعبر عن الدلالات في عناصر صفحتنا.
ومع ذلك، نستخدم أحيانًا عناصر تبدو مثل العناصر الأصلية ولكنها ليست كذلك. على سبيل المثال، هذا "الزر" ليس زرًا على الإطلاق.
ويمكن إنشاؤه باستخدام HTML بعدة طرق، وسنعرض طريقة واحدة أدناه.
<div class="button-ish">Give me tacos</div>
عندما لا نستخدم عنصر زر فعليًا، لا يمكن لقارئ الشاشة معرفة العنصر الذي تم النقر عليه. سيكون علينا أيضًا بذل جهد إضافي لإضافة علامة tabindex لجعلها قابلة للاستخدام من قِبل مستخدمي لوحة المفاتيح فقط، لأنّه لا يمكن استخدامها سوى بالموس.
يمكننا إصلاح ذلك بسهولة باستخدام عنصر button عادي بدلاً من div.
يفيد استخدام عنصر أصلي أيضًا في الاهتمام
بتفاعلات لوحة المفاتيح من أجلنا. ولا داعي لخسارة تأثيراتك المرئية الرائعة
فقط لأنّك تستخدم عنصرًا أصليًا. يمكنك تصميم العناصر الأصلية
لإضفاء المظهر الذي تريده عليها مع الاحتفاظ بالدلالات والسلوك ضمنيًا.
لاحظنا سابقًا أن برامج قراءة الشاشة ستعلن عن دور العنصر واسمه وحالته وقيمته. من خلال استخدام العنصر الدلالي والدور والحالة والقيمة المناسبين، تتم تغطية العناصر، ولكن علينا أيضًا التأكّد من أنّ اسم العنصر يمكن اكتشافه.
بشكل عام، هناك نوعان من الأسماء:
- التصنيفات المرئية التي يستخدمها جميع المستخدمين لربط معنى بأحد العناصر
- بدائل النص، التي لا تُستخدم إلا عند عدم الحاجة إلى تصنيف مرئي.
بالنسبة إلى العناصر على مستوى النص، ليس علينا اتّخاذ أي إجراء، لأنّه بحكم التعريف، سيكون لها بعض المحتوى النصي. ومع ذلك، بالنسبة إلى عناصر الإدخال أو عناصر التحكّم والمحتوى المرئي، مثل الصور، يجب التأكّد من تحديد اسم. في الواقع، يُعدّ توفير بدائل نصية لأي محتوى غير نصي العنصر الأول في قائمة التحقّق من WebAIM.
وإحدى طرق إجراء ذلك هي اتّباع اقتراحهم بأنّ "مدخلات النموذج لها علامات نص مرتبطة". هناك طريقتان لربط تسمية بأحد عناصر النموذج، مثل مربع الاختيار. يؤدي استخدام أيّ من الطريقتَين إلى أن يصبح نص التصنيف أيضًا هدفًا للنقر على مربّع الاختيار، ما يُعدّ مفيدًا أيضًا لمستخدمي الماوس أو الشاشة التي تعمل باللمس. لربط تصنيف بعنصر، يمكنك اتّباع إحدى الطريقتَين التاليتَين:
- وضع عنصر الإدخال داخل عنصر تصنيف
<label>
<input type="checkbox">Receive promotional offers?
</label>أو
- استخدِم سمة
forللعلامة والإشارة إلىidللعنصر.
<input id="promo" type="checkbox">
<label for="promo">Receive promotional offers?</label>
عندما يتم وضع علامة في مربّع الاختيار بشكل صحيح، يمكن لقارئ الشاشة الإبلاغ عن أنّ العنصر له دور "مربّع اختيار"، وأنّه يحمل اسم "هل تريد تلقّي عروض ترويجية؟"
