5 خطوات لتصميم التطبيقات مع وضع إمكانية الوصول إلى لوحة المفاتيح في الاعتبار

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

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

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

كيف تعمل إمكانية الوصول إلى لوحة المفاتيح؟

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

أساسيات التنقل باستخدام لوحة المفاتيح

فيما يلي بعض المفاتيح الأساسية المستخدمة للتنقل باستخدام لوحة المفاتيح:

• التنقل إلى عنصر التحكم التالي: Tab (أو مفتاح السهم الأيمن أو السفلي لأزرار الاختيار ذات الصلة وتحديد الخيارات)
• التنقل إلى عنصر التحكم السابق: Shift + Tab (أو مفتاح السهم الأيسر أو العلوي لأزرار الاختيار ذات الصلة وتحديد الخيارات)
• النقر فوق عنصر التحكم: أدخل و / أو مفتاح المسافة
• التنقل بين أزرار الاختيار ذات الصلة أو تحديد الخيارات: مفاتيح الأسهم

ترتيب التركيز

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

قد يعجبك أيضًا: التصميم العام: 11 نصيحة عملية لجعل الوصول إلى مواقعك وتطبيقاتك أكثر سهولة.

إمكانية الوصول باستخدام لوحة المفاتيح وإرشادات الوصول إلى محتوى الويب (WCAG)

تحدد إرشادات الوصول إلى محتوى الويب (WCAG) ثلاثة مستويات من التوافق - المستوى A والمستوى AA والمستوى AAA - والتي تم اعتمادها كمعايير لقوانين الوصول إلى الويب الإقليمية أو الوطنية حول العالم.

تعد إمكانية الوصول إلى لوحة المفاتيح أحد معايير النجاح للامتثال للمستوى أ. تصف معايير المستوى أ الميزات التي يجب توفرها لجميع محتويات الويب. كما أنها تعتبر الأسهل في التنفيذ.

"من السهل أيضًا أن تخطئ في إمكانية الوصول إلى لوحة المفاتيح إذا لم نكن حذرين."

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

• حالات التركيز غير المحسوسة
• ترتيب التركيز غير صحيح
• العناصر التفاعلية التي لا يمكن أن تتلقى التركيز
• المكونات المعقدة التي لا تلتقط تفاعلات لوحة المفاتيح

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

5 خطوات لبناء تطبيقات يمكن الوصول إليها من خلال لوحة المفاتيح

1. تصميم تفاعلات بديهية

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

"إذا كنا لا نعرف سلوكيات لوحة المفاتيح القياسية المرتبطة بالأزرار أو الروابط أو المدخلات ، فقد نخلق عن غير قصد تجارب مربكة لمستخدمي لوحة المفاتيح."

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

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

2. أنشئ تطبيقك بحيث يمكن للوحة المفاتيح أن تفعل كل ما في وسع الماوس

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

تمكننا JavaScript من إضافة أدوات استماع للأحداث تجعل العناصر غير المتحكم بها تستجيب لنقرات الماوس أو الإيماءات. في React ، على سبيل المثال ، يمكننا استخدام onClick لإضافة تفاعل إلى عنصر عنصر قائمة.

عندما نضيف تفاعلًا إلى عناصر غير تحكم ، نحتاج إلى ضبط سمة tabIndex الخاصة بهم على 0 . سيسمح هذا للعنصر بتلقي التركيز بترتيب التركيز الصحيح عند الضغط على مفتاح Tab. نحتاج أيضًا إلى تنفيذ معالجات حدث الضغط على المفاتيح أو keydown لتسجيل "النقرات" عبر مفتاح Enter و / أو مفتاح المسافة (يمكن النقر فوق الروابط باستخدام كليهما ، بينما لا تدعم الأزرار سوى مفتاح Enter).

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

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

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

3. قم بالعمل الإضافي عند تجاوز ترتيب التركيز الافتراضي

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

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

قد يعجبك أيضًا: بناء تنقل سهل الوصول إليه باستخدام Liquid و Shopify.

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

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

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

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

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

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

من الشائع جدًا للمصممين والمطورين استبدال حالات التركيز الافتراضية التي تقدمها المتصفحات. قد يتضمن ذلك تحديث outline الافتراضي ، أو إزالته تمامًا واستبداله بخاصية CSS أخرى ، مثل background أو border أو box-shadow أو color أو transform .

قد يعجبك أيضًا: إنشاء ترقيم صفحات يمكن الوصول إليه باستخدام سائل.

ومع ذلك ، قررنا عرض حالات التركيز المخصصة في تطبيقاتنا ، يجب أن نتأكد من أنها تفي بمتطلبات إمكانية الوصول التالية:

• تباين كافٍ للألوان: يجب أن يكون هناك تباين كافٍ بين حالة تركيزنا والألوان المحيطة بها بحيث يمكن للمستخدمين الذين يعانون من إعاقة بصرية بسهولة تتبع العنصر الذي يتم التركيز عليه حاليًا.
• تقترن التغييرات في اللون بمؤشرات مرئية أخرى: قد لا يكون تغيير لون حد العنصر أو الخط أو الخلفية ملحوظًا للمستخدمين المصابين بعمى الألوان. يجب إقرانها بالتغييرات المرئية الأخرى التي لا تتطلب من المستخدمين أن يكونوا قادرين على تمييز الألوان. ينطبق هذا أيضًا على حالات التمرير والخطأ التي تتضمن تغييرات في اللون.
• مرئي في السمات عالية التباين: يتم تجاهل بعض خصائص CSS ، بما في ذلك background box-shadow ، عند تمكين وضع التباين العالي على أجهزة Windows. قد لا يتم تسجيل التغييرات في اللون أيضًا ، وهذا هو السبب في أنه من المهم بشكل مضاعف الاعتماد على مؤشرات إضافية يمكن إدراكها للأشخاص الذين يحتاجون إلى مزيد من التباين بين ألوان الخلفية والمقدمة.

على الرغم من أنه من المقبول تجاوز خاصية outline الافتراضية ، فلا تقم مطلقًا بإزالة حالات التركيز الافتراضية دون توفير بديل.

5. توفير اختصارات لمستخدمي لوحة المفاتيح

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

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

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

تعد روابط التخطي أكثر من مجرد اختصارات ملائمة. إنها مثال على الكتل الالتفافية المطلوبة لتلبية معايير WCAG من المستوى A.

اختبر تطبيقك كثيرًا عن طريق أن تصبح مستخدم لوحة المفاتيح بنفسك

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

فيما يلي بعض الأسئلة التي يجب وضعها في الاعتبار أثناء اختبار تطبيقنا لإمكانية الوصول إلى لوحة المفاتيح:

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

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

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