قد يبدو تحديد ما إذا كان من الممكن الوصول إلى موقع الويب أو التطبيق الخاص بك مهمة مربكة. إذا كنت تقترب من سهولة الوصول لأول مرة، فقد يجعلك اتساع الموضوع الواضح تتساءل من أين تبدأ. بعد كل شيء، يعني العمل على استيعاب مجموعة متنوعة من القدرات أن هناك مجموعة متنوعة بالمقابل من المشكلات التي يجب مراعاتها.
تقسّم هذه المشاركة هذه المشكلات إلى عملية منطقية وخطوة بخطوة لمراجعة موقع إلكتروني حالي للتحقق من إمكانية الوصول.
البدء بلوحة المفاتيح
بالنسبة للمستخدمين الذين لا يستطيعون أو يختارون عدم استخدام الماوس، فإن التنقل بلوحة المفاتيح هو الوسيلة الأساسية للوصول إلى كل شيء على الشاشة. وتشمل شريحة الجمهور هذه المستخدمين الذين يعانون من إعاقات حركية، مثل الإصابة بالإجهاد المتكرر (RSI) أو الشلل، فضلاً عن مستخدمي برامج قراءة الشاشة.
للحصول على تجربة لوحة مفاتيح جيدة، استهدف أن يكون لديك ترتيب التنقل بـ Tab منطقي وأنماط تركيز واضحة.
ابدأ باستخدام علامات التبويب في موقعك الإلكتروني. يجب أن يتبع الترتيب الذي يتم التركيز به ترتيب DOM. إذا لم تكن متأكدًا من العناصر التي يجب التركيز عليها، يمكنك الاطّلاع على مقالة أساسيات التركيز لتنشيط ذاكرتك. أفضل ممارسة هي أن أي عنصر تحكم يمكن للمستخدم التفاعل معه أو تقديمه مدخلات يجب أن يكون قابلاً للتركيز وأن يعرض مؤشرًا للتركيز (مثل حلقة التركيز).
يجب أن يكون التركيز على عناصر التحكّم التفاعلية المخصّصة. إذا استخدمت JavaScript لتحويل
<div>إلى قائمة منسدلة فاخرة، لن يتم إدراجه تلقائيًا في ترتيب التنقل بـ Tab. للتمكّن من التركيز على عنصر تحكّم مخصّص، عليك منحهtabindex="0". تؤدي قيمtabindexالأكبر من 0 إلى تغيير ترتيب التنقل بـ Tab ويمكن أن تكون مُربكة لمستخدمي برامج قراءة الشاشة.جعل المحتوى التفاعلي فقط قابلاً للتركيز. تؤدي إضافة
tabindexإلى العناصر غير التفاعلية، مثل العناوين، إلى إبطاء مستخدمي لوحة المفاتيح الذين يمكنهم رؤية الشاشة، ولا تساعد مستخدمي برامج قراءة الشاشة لأنّهم يعرفون ذلك مسبقًا.إذا أضفت محتوى جديدًا إلى صفحة، فوجه تركيز المستخدم إلى ذلك المحتوى أولاً حتى يتمكن من اتخاذ إجراء بشأنه. راجِع إدارة التركيز على مستوى الصفحة للحصول على أمثلة.
صمِّم موقعك الإلكتروني بحيث يتمكن المستخدم دائمًا من التركيز على العنصر التالي عندما يريد ذلك. يجب توخّي الحذر من أدوات الإكمال التلقائي والسياقات الأخرى التي يمكن أن تحجب تركيز لوحة المفاتيح. يمكنك حصر التركيز مؤقتًا عندما تريد أن يتفاعل المستخدم مع شكل مشروط وليس مع بقية الصفحة، ولكن يجب عليك دائمًا توفير طريقة يسهل الوصول إليها من خلال لوحة المفاتيح للهروب من نمط الصفحة. راجع الأزرار ومصائد لوحة المفاتيح للحصول على مثال.
سهولة استخدام عناصر التحكّم في التركيز
إذا أنشأت عنصر تحكّم مخصّص، عليك السماح للمستخدمين بالوصول إلى جميع ميزاته باستخدام لوحة المفاتيح فقط. اقرأ إدارة التركيز في المكونات للتعرف على أساليب تحسين الوصول إلى لوحة المفاتيح.
إدارة المحتوى خارج الشاشة
تتضمّن العديد من المواقع الإلكترونية محتوًى خارج الشاشة متاحًا في نموذج العناصر في المستند (DOM) ولكنّه غير مرئي، مثل الروابط المضمّنة في قائمة درج متجاوبة أو زر داخل نافذة شكلية لم يتم عرضها بعد. قد يؤدي ترك هذه العناصر في DOM إلى إنشاء تجربة لوحة مفاتيح مربكة، خاصةً لبرامج قراءة الشاشة، التي تعلن عن المحتوى خارج الشاشة كما لو كان جزءًا من الصفحة.
راجِع التعامل مع المحتوى خارج الشاشة للحصول على نصائح للتعامل مع هذه العناصر.
الاختبار باستخدام قارئ شاشة
يضع تحسين الدعم العام للوحة المفاتيح بعض الأساس للخطوة التالية، وهي التحقق من الصفحة للتحقق من وضع العلامات والدلالات بشكل صحيح وأي عوائق للتنقل عبر قارئ الشاشة.
إذا لم تكن على دراية بكيفية تفسير ترميز دلالي باستخدام التكنولوجيا المساعِدة، اطّلِع على بنية المحتوى.
- تأكَّد من توفّر نص
altمناسب في جميع الصور. يُستثنى من هذه الممارسة عندما تكون الصور لأغراض العرض بشكل أساسي ولا تكون أجزاءً أساسية من المحتوى. للإشارة إلى أنّه يجب على برامج قراءة الشاشة تخطّي إحدى الصور، اضبط القيمة على سلسلة فارغة:alt="". - تحقَّق من جميع عناصر التحكّم لتصنيف. بالنسبة إلى عناصر التحكم المخصّصة، قد يتطلب ذلك
استخدام
aria-labelأوaria-labelledby. راجع تصنيفات وعلاقات ARIA للحصول على أمثلة. - تحقَّق من جميع عناصر التحكّم المخصّصة بحثًا عن سمة
roleمناسبة وأي سمات ARIA مطلوبة توضّح حالتها. على سبيل المثال، يحتاج مربّع الاختيار المخصّص إلىrole="checkbox"وaria-checked="true|false"لنقل حالته بشكل صحيح. راجِع مقدمة عن ARIA للحصول على نظرة عامة حول كيفية توفير ARIA لدلالات مفقودة لعناصر التحكّم المخصّصة. - جعل تدفق المعلومات عبر صفحتك منطقيًا. ولأنّ برامج قراءة الشاشة يتنقّلون في الصفحة بترتيب DOM، سيعلِنون عن أي عناصر غيّرت موضعها مرئيًا باستخدام CSS بترتيب لا معنى له. إذا كنت تريد أن يظهر شيء ما في موضع سابق من الصفحة، فانقله فعليًا في نموذج العناصر في المستند (DOM).
- احرِص على إتاحة التنقّل باستخدام قارئ الشاشة لكل المحتوى على الصفحة. التأكّد من عدم إخفاء أي أقسام في الموقع الإلكتروني نهائيًا أو حظرها من وصول قارئ الشاشة
- إذا كان يجب إخفاء المحتوى عن قارئ الشاشة، على سبيل المثال، إذا كان خارج الشاشة أو عرضيًا فقط، اضبط ذلك المحتوى على
aria-hidden="true". للحصول على شرح أكثر تفصيلاً، يمكنك الاطّلاع على إخفاء المحتوى.
- إذا كان يجب إخفاء المحتوى عن قارئ الشاشة، على سبيل المثال، إذا كان خارج الشاشة أو عرضيًا فقط، اضبط ذلك المحتوى على
التعرّف على برامج قراءة الشاشة
على الرغم من أنه قد يبدو تعلم قارئ الشاشة أمرًا شاقًا، إلا أنها في الواقع سهلة الاستخدام. بشكل عام، يمكن لمعظم مطوّري البرامج فعل ذلك باستخدام عدد قليل من الأوامر الرئيسية البسيطة.
إذا كنت تستخدم جهاز Mac، يمكنك مشاهدة هذا الفيديو عن VoiceOver، وهو قارئ الشاشة الذي يتضمّن نظام التشغيل Mac. إذا كنت تستخدم جهاز كمبيوتر، يمكنك مشاهدة هذا الفيديو حول NVDA، وهو قارئ شاشة مفتوح المصدر ومتوافق مع نظام التشغيل Windows.
لا يمنع aria-hidden تركيز لوحة المفاتيح
ومن المهم معرفة أنّ ARIA لا يمكنها سوى التأثير في دلالات العنصر، وليس لذلك أي تأثير على سلوك العنصر. يمكنك إخفاء عنصر عن برامج قراءة الشاشة باستخدام aria-hidden="true"، ولكن ذلك لن يغيّر سلوك التركيز عليه. بالنسبة إلى المحتوى التفاعلي خارج الشاشة،
بالنسبة إلى المحتوى التفاعلي خارج الشاشة، استخدِم السمة inert
للتأكّد من إزالته من مسار لوحة المفاتيح. بالنسبة إلى المتصفّحات القديمة،
يمكنك دمج "aria-hidden="true"" مع "tabindex="-1"".
يجب أن تشير العناصر التفاعلية إلى الغرض منها وحالتها
يساعد تقديم تلميحات مرئية أو خصائص حول الدور الذي سيؤديه عنصر التحكم مجموعة كبيرة من المستخدمين على مجموعة متنوعة من الأجهزة في تشغيل موقعك الإلكتروني والتنقّل فيه.
- يجب أن تكون العناصر التفاعلية، مثل الروابط والأزرار، مميزة عن العناصر غير التفاعلية. يصعب على المستخدمين التنقل في موقع أو تطبيق عندما لا يمكنهم معرفة ما إذا كان العنصر قابلاً للنقر أم لا. هناك العديد من الطرق الصالحة للإشارة إلى العناصر التفاعلية. تتمثل إحدى الممارسات الشائعة في تمييز الروابط لتمييزها عن النص المحيط بها.
- على غرار متطلبات التركيز، تتطلب العناصر التفاعلية مثل الروابط والأزرار حالة
hoverلإعلام مستخدمي الماوس عندما يكون المؤشر فوق عنصر قابل للنقر. ومع ذلك، يجب أن تكون هذه العناصر قابلة للتمييز بدون حالةhoverلتسهيل الوصول إليها من خلال طرق إدخال أخرى.
استغلال العناوين والمعالم
تمنح العناوين وعناصر المعالم الصفحة بنية دلالية، وتزيد بشكل كبير من كفاءة التنقل لمستخدمي التكنولوجيا المساعِدة. أبلغ العديد من مستخدمي برامج قراءة الشاشة بأنّهم يحاولون عادةً التنقل باستخدام العناوين عندما يصلون إلى صفحة غير مألوفة لأوّل مرة.
وبالمثل، توفر برامج قراءة الشاشة أيضًا إمكانية الانتقال إلى المعالم المهمة
مثل <main> و<nav>. لهذه الأسباب، من المهم التفكير في كيفية
استخدام هيكل صفحتك لتوجيه تجربة المستخدم.
- استخدام هيكل
h1-h6الهرمي فكر في العناوين كأدوات لإنشاء مخطط تفصيلي لصفحتك. لا تعتمد على تصميم العناوين المضمَّن. بدلاً من ذلك، تعامل معها كما لو كانت جميعها بنفس الحجم واستخدم المستوى المناسب دلاليًا للمحتوى الأساسي والثانوي والثالث. ثم استخدم CSS لجعل العناوين تتناسب مع تصميمك. - استخدِم عناصر المَعلم وأدواره ليتمكّن المستخدمون من تجاوز المحتوى المتكرّر. توفِّر العديد من التكنولوجيات المساعِدة اختصارات للانتقال إلى أقسام محدّدة من الصفحة، مثل الأقسام المحددة في العناصر
<main>أو<nav>. تحتوي هذه العناصر على أدوار معالم ضمنية. يمكنك أيضًا استخدام سمة ARIAroleلتحديد المناطق على الصفحة بشكل واضح، كما في<div role="search">. راجِع الدلالات والتنقّل في المحتوى للحصول على مزيد من الأمثلة. - ننصحك بعدم استخدام
role="application"إلا إذا كنت تملك خبرة في استخدامها. يطلب دور مَعلمapplicationمن التكنولوجيا المساعِدة إيقاف اختصاراته وتمرير جميع الضغطات الرئيسية على الصفحة. ويعني هذا أنّ مفاتيح قارئ الشاشة التي يستخدمها المستخدمون عادةً للتنقّل في الصفحة لم تعُد صالحة، وعليك تنفيذ جميع طرق معالجة لوحة المفاتيح بنفسك.
مراجعة العناوين والمعالم باستخدام قارئ شاشة
توفر برامج قراءة الشاشة، مثل VoiceOver وNVDA، قائمة سياقات للتخطي إلى المناطق المهمة على الصفحة. عند إجراء اختبار لإمكانية الوصول، يمكنك استخدام هذه القوائم للحصول على نظرة عامة على الصفحة وتحديد ما إذا كانت مستويات العناوين مناسبة والمعالم المستخدمة.
لمعرفة المزيد من المعلومات، راجع هذه الفيديوهات التعليمية حول أساسيات VoiceOver وNVDA.
أتمتة العملية
إنّ اختبار الموقع الإلكتروني يدويًا للتأكّد من إمكانية الوصول قد يكون مملاً وعُرضة للخطأ. من المفيد الاختبار الآلي قدر الإمكان. يمكنك استخدام إضافات المتصفح ومجموعات اختبار إمكانية الوصول في سطر الأوامر.
- هل تجتاز الصفحة جميع الاختبارات من إضافة المتصفّح
aXe
أو WAVE؟ تتوفر خيارات أخرى، ولكن يمكن أن تكون هذه الإضافات
إضافة مفيدة إلى أي عملية اختبار يدوي لأنّها قد تعالج مشاكل بسيطة مثل تعذُّر نسب التباين وغياب سمات ARIA.
- إذا كنت تفضّل العمل على سطر الأوامر، يوفّر axe-cli الميزات نفسها التي يوفّرها امتداد متصفّح aXe، ولكن يمكن تشغيله من خلال الوحدة الطرفية.
- لتجنُّب أي تراجع، لا سيما في بيئة تكامل مستمر، ادمج مكتبة مثل axe-core في مجموعة الاختبار الآلية. يكون axe-core هو المحرك نفسه الذي يشغِّل إضافة aXe Chrome، ولكن في أداة سطر أوامر.
- إذا كنت تستخدم إطار عمل أو مكتبة، فهل توفر أدوات إمكانية الوصول الخاصة بها؟ على سبيل المثال، protractor-accessibility-extension لـ Angular. استفد من الأدوات المتاحة كلما أمكن ذلك.
استخدام Lighthouse لاختبار تطبيقات الويب التقدّمية (PWA)
Lighthouse هي أداة تقيس أداء تطبيق الويب التقدّمي (PWA). وتستخدم المكتبة الأساسية لإجراء اختبارات إمكانية الوصول.
إذا كنت تستخدم Lighthouse بالفعل، فابحث عن اختبارات إمكانية الوصول غير الناجحة في تقريرك. يجب إصلاح الأخطاء لتحسين تجربة المستخدم بشكل عام على موقعك الإلكتروني.