مقدمة عن شجرة تسهيل الاستخدام
لنفترض أنّك تنشئ واجهة مستخدم لمستخدمي قارئ الشاشة فقط. في هذه الحالة، لا تحتاج إلى إنشاء أي واجهة مستخدم مرئية على الإطلاق، ولكن عليك فقط تقديم معلومات كافية ليستخدمها قارئ الشاشة.
ما ستنشئه هو نوع من واجهة برمجة التطبيقات التي تصف بنية الصفحة، على غرار واجهة برمجة تطبيقات DOM، ولكن يمكنك الاستغناء عن بعض المعلومات وبعض العُقد، لأنّ الكثير من هذه المعلومات مفيد فقط للعرض المرئي. قد يبدو شيئًا من هذا القبيل.
هذا هو في الأساس ما يعرضه المتصفح فعليًا لقارئ الشاشة. يأخذ المتصفّح شجرة نموذج العناصر في المستند ويعدّلها إلى شكل مفيد للتكنولوجيا المساعِدة. ونشير إلى هذه الشجرة المعدَّلة باسم شجرة تسهيل الاستخدام.
يمكنك تصوّر شجرة تسهيل الاستخدام على أنّها تشبه إلى حدّ ما صفحة ويب قديمة من التسعينيات: بضع صور والكثير من الروابط، وربما حقل وزر.
يمنحك المسح المرئي لصفحة مثل هذه الحالة تجربة مشابهة لما سيحصل عليه مستخدم قارئ الشاشة. الواجهة موجودة، لكنها بسيطة ومباشرة، تشبه إلى حد كبير واجهة شجرة تسهيل الاستخدام.
تتفاعل معظم التكنولوجيات المساعِدة مع شجرة تسهيل الاستخدام. يكون التدفق على النحو التالي.
- يعرض أحد التطبيقات (المتصفّح أو تطبيق آخر) نسخة دلالية من واجهة المستخدم الخاصة به للتكنولوجيا المساعِدة من خلال واجهة برمجة التطبيقات.
- قد تستخدم التكنولوجيا المساعِدة المعلومات التي تقرأها من خلال واجهة برمجة التطبيقات لإنشاء عرض بديل لواجهة المستخدم. على سبيل المثال، ينشئ قارئ الشاشة واجهة يسمع فيها المستخدم تمثيلاً منطوقًا للتطبيق.
- قد تسمح التكنولوجيا المساعِدة أيضًا للمستخدم بالتفاعل مع التطبيق بطريقة مختلفة. على سبيل المثال، توفر معظم برامج قراءة الشاشة خطافات للسماح للمستخدم بمحاكاة نقرة الماوس أو النقر بالإصبع بسهولة.
- تنقل التكنولوجيا المساعِدة نية المستخدم (مثل "النقر") إلى التطبيق من خلال Accessibility API. بعد ذلك، يكون التطبيق مسؤولاً عن تفسير الإجراء بشكل مناسب في سياق واجهة المستخدم الأصلية.
بالنسبة إلى متصفّحات الويب، هناك خطوة إضافية في كل اتجاه، لأنّ المتصفّح هو في الواقع منصة لتطبيقات الويب التي تعمل داخله. لذلك يحتاج المتصفح إلى ترجمة تطبيق الويب إلى شجرة تسهيل الاستخدام، ويجب التأكد من تشغيل الأحداث المناسبة في 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>
عندما يتم تصنيف مربّع الاختيار بشكل صحيح، يمكن لبرنامج قراءة الشاشة الإبلاغ بأنّ العنصر له دور مربّع اختيار، وأنّه في حالة تم وضع علامة عليه، وأنّه يحمل اسم "هل تريد تلقّي عروض ترويجية؟".