يؤدي تحسين إمكانية الوصول إلى جعل موقعك الإلكتروني أكثر قابلية للاستخدام من قِبل الجميع.
من المهم إنشاء مواقع إلكترونية شاملة ومتاحة للجميع. هناك ستة مجالات رئيسية للإعاقة على الأقل يمكنك تحسينها: البصرية والسمع والحركة والإدراك والكلام والعصبي. من خلال العديد من الأدوات والموارد، حتى لو كنت جديدًا تمامًا في إمكانية الوصول إلى الويب.
أكثر من مليار شخص العيش مع شكل من أشكال الإعاقة.
يجب أن تعمل المواقع الإلكترونية على عدة أجهزة حتى يمكن الوصول إليها. بأحجام مختلفة للشاشة وأنواع مختلفة من الإدخالات، مثل برامج قراءة الشاشة. علاوة على ذلك، يجب أن تكون المواقع قابلة للاستخدام من قبل مجموعة أوسع من المستخدمين، بما في ذلك ذوي الإعاقة.
في ما يلي بعض الإعاقات التي قد يواجهها المستخدمون:
| الرؤية | أدوات سمعية | التنقّل |
|---|---|---|
|
|
|
| الإدراك | الكلام | عصبية |
|
|
|
تتراوح المشاكل المرئية بين عدم القدرة على تمييز الألوان أو عدم القدرة على الرؤية على الإطلاق.
- التأكّد من أنّ المحتوى النصي يستوفي الحد الأدنى من المتطلبات الحد الأدنى لنسبة التباين.
- تجنب توصيل المعلومات باستخدام اللون فقط والتأكد من أن جميع النصوص resizable
- التأكد من إمكانية استخدام جميع مكونات واجهة المستخدم مع التقنيات المساعدة مثل برامج قراءة الشاشة ومكبرات الشاشة وأجهزة العرض بلغة برايل يستلزم هذا ضمان ترميز مكونات واجهة المستخدم بحيث يمكن لواجهات برمجة التطبيقات لإمكانية الوصول تحديد الدور والحالة والقيمة والعنوان لأي عنصر.
أعيش شخصيًا يعاني من ضعف في النظر، وكثيرًا ما أجد نفسي أقوم بالتكبير على المواقع، أدوات مطوري البرامج والمحطة الطرفية بينما لا يتوفر أبدًا دعم التكبير/التصغير في مقدمة مطوِّري البرامج وقوائم المهام يمكن أن يُحدث فرقًا كبيرًا لمستخدمي مثلي.
تشير مشاكل السمع إلى أنّ المستخدم قد يواجه مشاكل في سماع الصوت الصادر من الصفحة.
- تقديم المِنح بدائل النصوص لجميع أنواع المحتوى الذي لا يقتصر على النصوص فقط
- اختبار أن مكونات واجهة المستخدم لا تزال تعمل بدون صوت.
قد تشمل مشاكل الحركة عدم القدرة على تشغيل ماوس أو لوحة مفاتيح أو شاشة تعمل باللمس.
- جعل محتوى مكونات واجهة المستخدم الخاصة بك وظيفيًا من خلال لوحة المفاتيح لأي إجراءات قد يستخدم الشخص الماوس من أجلها.
- التأكّد من ترميز الصفحات بشكل صحيح للتكنولوجيا المساعِدة، بما في ذلك وقارئات الشاشة وبرامج التحكم الصوتي وعناصر التحكم في المفاتيح المادية والتي إلى استخدام واجهات برمجة التطبيقات نفسها.
تعني المشكلات الإدراكية أن المستخدم قد يحتاج إلى تقنيات مساعدة لمساعدتهم في قراءة النصوص، لذلك من المهم التأكّد من توفُّر بدائل للنص.
كن حذرًا عند استخدام الرسوم المتحركة. تجنب الفيديوهات والصور المتحركة التي تكرار أو فلاش، ما قد يؤدي إلى مشاكل لبعض المستخدمين.
prefers-reduced-motionيتيح لك استعلام وسائط CSS الحد من الرسوم المتحركة والتشغيل التلقائي للفيديوهات للمستخدمين الذين يفضّلون الحركة المنخفضة:/* If the user expresses a preference for reduced motion, don't use animations on buttons. */ @media (prefers-reduced-motion: reduce) { button { animation: none; } }تجنب التفاعلات استنادًا إلى التوقيت:
قد يبدو هذا وكأنه هناك الكثير من الأساسيات التي يجب تناولها، لكننا سنتابع عملية تقييم ثم تحسين إمكانية الوصول إلى مكونات واجهة المستخدم.
للحصول على مزيد من الدعم المرئي، أنشأ فريق تسهيل الاستخدام GOV.UK سلسلة من الممارسات الرقمية المسموح بها وغير المسموح بها بشأن إمكانية الوصول والتي يمكنك استخدامها لمشاركة أفضل الممارسات مع فريقك.
قياس إمكانية الوصول إلى مكوِّنات واجهة المستخدم
عند تدقيق مكونات واجهة المستخدم لصفحتك من أجل تسهيل الاستخدام، اسأل نفسك:
هل يمكنك استخدام لوحة المفاتيح فقط لاستخدام واجهة المستخدم؟
هل يدير المكوِّن التركيز ويتجنب الفخاخ؟ هل يمكنه الاستجابة إلى أحداث لوحة المفاتيح المناسبة؟
هل يمكنك استخدام مكوّن واجهة المستخدم مع قارئ شاشة؟
هل قدمت بدائل نصية لأي معلومات يتم تقديمها بشكل مرئي؟ هل أضفت معلومات دلالية باستخدام ARIA؟
هل يمكن أن يعمل مكوّن واجهة المستخدم بدون صوت؟
أوقف تشغيل مكبرات الصوت وراجع حالات الاستخدام.
هل يمكن أن يعمل مكوّن واجهة المستخدم بدون ألوان؟
التأكد من إمكانية استخدام مكون واجهة المستخدم من قبل شخص لا يمكنه رؤية الألوان. وهناك أداة مفيدة لمحاكاة عمى الألوان وهي عبارة عن إضافة في Chrome تسمى عمى الألوان: (جرِّب جميع الأشكال الأربعة المتاحة من محاكاة عمى الألوان). قد يهمّك أيضًا الاطّلاع على الدلتونيز الإضافة، وهو أمر مفيد مماثل.
هل يمكن أن يعمل مكوّن واجهة المستخدم مع تفعيل وضع التباين العالي؟
تدعم جميع أنظمة التشغيل الحديثة وضع التباين العالي. التباين العالي هي إضافة Chrome يمكنها مساعدتك في هذا الشأن.
تتوفّر عناصر التحكّم الموحّدة (مثل <button> و<select>) لتسهيل الاستخدام.
مضمنة في المتصفح. يمكن التركيز عليها باستخدام مفتاح Tab.
تستجيب لأحداث لوحة المفاتيح (مثل Enter وSpace ومفاتيح الأسهم)
ولديها أدوار وحالات وخصائص دلالية تستخدمها أدوات تسهيل الاستخدام.
ويجب أن يستوفي التصميم التلقائي أيضًا متطلبات تسهيل الاستخدام المُدرَجة.
مكونات واجهة المستخدم المخصصة (باستثناء المكونات التي توسّع نطاق
الأخرى مثل <button>) أي إمكانات مضمَّنة، بما في ذلك
سهولة الوصول، لذا عليك تقديمها. يعد مكانًا جيدًا للبدء عندما
فإن تنفيذ إمكانية الوصول هو مقارنة المكون الخاص بك بمعايير مشابهة
(أو مزيج من العديد من العناصر القياسية، اعتمادًا على مدى التعقيد
المكون الخاص بك).
تتيح معظم أدوات مطوّري البرامج في المتصفح فحص شجرة إمكانية الوصول لإحدى الصفحات. في "أدوات مطوري البرامج في Chrome"، يمكنك الوصول إلى علامة التبويب تسهيل الاستخدام في لوحة العناصر.
ويتضمّن Firefox أيضًا لوحة تسهيل الاستخدام.
ويعرض متصفّح Safari معلومات تسهيل الاستخدام في علامة التبويب العقدة ضمن لوحة العناصر.
فيما يلي قائمة بالأسئلة التي يمكنك طرحها على نفسك عند محاولة جعل مكونات واجهة المستخدم أكثر سهولة.
تحسين تركيز لوحة المفاتيح
من الناحية المثالية، عليك التأكد من إمكانية الوصول إلى جميع الوظائف في مكوّن واجهة المستخدم. باستخدام لوحة مفاتيح. عند تصميم تجربة المستخدم لديك، فكر في كيفية استخدام العنصر مع لوحة المفاتيح وحدها والتوصل إلى مجموعة متسقة من تفاعلات لوحة المفاتيح.
أولاً، تأكد من أن لديك هدف تركيز معقول لكل مكون. على سبيل المثال، قد يكون المكون المعقد مثل القائمة هو هدف تركيز واحد داخل ولكن يجب بعد ذلك إدارة التركيز داخلها حتى لا يظهر عنصر القائمة النشط التركيز دائمًا.
استخدام مفتاح Tabindex
يمكنك إضافة تركيز لوحة المفاتيح للعناصر ومكوّنات واجهة المستخدم باستخدام tabindex.
. يحتاج مستخدمو لوحة المفاتيح فقط والتكنولوجيا المساعدة إلى وضع
تركيز لوحة المفاتيح على العناصر للتفاعل معها.
يمكن التركيز بشكل ضمني على العناصر التفاعلية المضمنة (مثل <button>)، لذا
لا يحتاجون إلى السمة tabindex، إلا إذا احتجت إلى تغيير موضعهم.
بترتيب التنقل بـ Tab.
هناك ثلاثة أنواع من قيم tabindex:
tabindex="0"هو الأكثر شيوعًا ويضع العنصر في علامة التبويب الطبيعية الترتيب (مُحدَّد من خلال طلب DOM).- تؤدي قيمة
tabindexالتي تساوي -1 إلى استخدام العنصر آليًا ولكن ليس بترتيب التنقل. - تؤدي قيمة
tabindexالأكبر من 0 إلى وضع العنصر في ترتيب التنقل بـ Tab يدويًا. تتم زيارة جميع العناصر في الصفحة ذات القيمةtabindexالموجبة في ترتيب عددي، قبل العناصر بترتيب التنقل الطبيعي.
تعرَّف على بعض حالات استخدام "tabindex" في المقالة.
استخدام Tabindex.
التأكّد من أنّ التركيز مرئي دائمًا، سواء باستخدام حلقة التركيز التلقائية أو من خلال تطبيق نمط تركيز مخصص واضح. تذكر عدم المجاز مستخدمو لوحة المفاتيح - يجب أن يكونوا قادرين على نقل التركيز بعيدًا عن العنصر باستخدام لوحة المفاتيح فقط.
استخدام ميزة "التركيز التلقائي"
تتيح سمة التركيز التلقائي على HTML للمؤلف تحديد أن قيمة معينة
العنصر الذي ينبغي أن يركز تلقائيًا على
عند تحميل الصفحة.
سبق أن تمت الإشارة إلى autofocus على
جميع عناصر التحكم في نماذج الويب،
بما في ذلك الأزرار.
للتركيز التلقائي على العناصر في مكونات واجهة المستخدم المخصصة لديك،
استدعاء طريقة focus()،
على جميع عناصر HTML التي يمكن التركيز عليها
(مثلاً، document.querySelector('myButton').focus()).
إضافة تفاعل باستخدام لوحة المفاتيح
بمجرد أن يصبح عنصر واجهة المستخدم قابلاً للتركيز، قدم قصة تفاعل جيدة باستخدام لوحة المفاتيح
عند التركيز على أحد المكوِّنات من خلال التعامل مع أحداث لوحة المفاتيح المناسبة.
على سبيل المثال، السماح للمستخدم باستخدام مفاتيح الأسهم لتحديد خيارات القائمة
وSpace أو Enter لتفعيل الأزرار.
دليل أنماط التصميم في ARIA
بعض الإرشادات هنا.
وأخيرًا، تأكَّد من أنّ اختصارات لوحة المفاتيح قابلة للاكتشاف. من الممارسات الشائعة استخدام وسيلة إيضاح لاختصارات لوحة المفاتيح (نص على الشاشة) لإعلام المستخدم بوجود اختصارات. على سبيل المثال، "اضغط على ؟ للوحة المفاتيح الاختصارات". يمكن بدلاً من ذلك استخدام تلميح مثل هذا التلميح لإعلام المستخدم حول اختصار.
لا يمكن المبالغة في أهمية إدارة التركيز. وخير مثال على ذلك درج تنقل. إذا قمت بإضافة مكون واجهة المستخدم إلى الصفحة، تحتاج إلى توجيه التركيز إلى عنصر بداخله؛ وإلا فقد يضطر المستخدمون إلى التنقل عبر الصفحة بأكملها للوصول إلى هناك. قد تكون هذه تجربة محبطة، لذا تأكد من اختبار التركيز على جميع مكونات التنقل بلوحة المفاتيح في صفحتك.
// Example for expanding and collapsing a category with the Space key
const category = await page.$(`.category`);
// verify tabIndex, role and focus
expect(await page.evaluate(elem => elem.getAttribute(`role`), category)).toEqual(`button`);
expect(await page.evaluate(elem => elem.getAttribute(`tabindex`), category)).toEqual(`0`);
expect(await page.evaluate(elem => window.document.activeElement === elem, category)).toEqual(true);
// verify aria-expanded = false
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`false`);
// toggle category by pressing Space
await page.keyboard.press('Space');
// verify aria-expanded = true
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`true`);
التأكّد من الاستخدام الناجح لقارئ الشاشة
يستخدم حوالي 1٪ إلى 2٪ من الأشخاص قارئ الشاشة. هل يمكنك فهم جميع المعلومات والتفاعل مع المكون باستخدام قارئ الشاشة ولوحة المفاتيح بمفردي؟
يجب أن تساعدك الأسئلة التالية في معالجة إمكانية وصول قارئ الشاشة.
هل تحتوي جميع المكونات والصور على بدائل نصية ذات مغزى؟
أي مكان إذا كانت المعلومات عن الاسم أو الغرض للمكون التفاعلي يتم نقلها بصريًا، توفر بديل نص يسهل الوصول إليه.
على سبيل المثال، إذا كان مكوِّن واجهة المستخدم <fancy-menu> يعرض رمز ترس فقط
للإشارة إلى أنها قائمة إعدادات،
فإنها تحتاج إلى بديل نص يمكن الوصول إليه، مثل "الإعدادات"،
ينقل نفس المعلومات.
اعتمادًا على السياق،
يمكنك تقديم بديل نصي باستخدام السمة alt
أي سمة aria-label أو aria-labelledby
أو نص عادي في Shadow DOM.
يمكنك العثور على نصائح فنية عامة في المرجع السريع WebAIM.
يجب أن يوفر أي مكون في واجهة المستخدم يعرض صورة آلية
لتوفير نص بديل لتلك الصورة، مماثل للسمة alt.
هل توفر المكونات معلومات دلالية؟
تنقل التكنولوجيا المساعدة المعلومات الدلالية التي يتم التعبير عنها المستخدمين المبصرين باستخدام إشارات مرئية، مثل التنسيق أو نمط المؤشر أو الموضع. تحتوي العناصر الموحدة على هذه المعلومات الدلالية مضمنة في المتصفح، ولكن بالنسبة للمكونات المخصصة، يجب عليك استخدام ARIA لإضافة المعلومات
بوجه عام، أي مكوّن يستمع إلى نقرة بالماوس أو حدث تمرير نوعًا ما من أدوات معالجة أحداث لوحة المفاتيح ودور ARIA، ربما حالات وسمات ARIA أيضًا.
على سبيل المثال، قد يؤدي عنصر واجهة مستخدم <fancy-slider> مخصّص دور ARIA كشريط التمرير،
الذي يتضمّن بعض سمات ARIA ذات الصلة: aria-valuenow وaria-valuemin وaria-valuemax
من خلال ربط هذه السمات بالخصائص ذات الصلة في المكوِّن المخصص،
يمكنك السماح لمستخدمي التكنولوجيا المساعدة بالتفاعل مع العنصر،
وتغير قيمته، وحتى تتسبب في تغير العرض التقديمي المرئي للعنصر وفقًا لذلك.
<fancy-slider role="slider" aria-valuemin="1" aria-valuemax="5" aria-valuenow="2.5">
</fancy-slider>
هل يمكن للمستخدمين فهم كل شيء دون الاعتماد على اللون؟
يجب عدم استخدام الألوان باعتبارها الوسيلة الوحيدة لنقل المعلومات، مثل يشير إلى حالة ما، أو مطالبة المستخدم بالرد، أو تصور البيانات. على سبيل المثال، إذا كان لديك مخطط دائري، فقدم تسميات وقيم لكل شريحة حتى يتمكن المستخدمون الذين يعانون من إعاقات بصرية من فهم المعلومات، حتى إذا لم يتمكّنوا من معرفة موضع بدء الشرائح ونهايتها:
هل هناك تباين كافٍ؟
يجب أن يتوافق أي محتوى نصي معروض في المكون مع الحد الأدنى لدرجة التباين على مستوى WCAG AA. تقديم مظهر عالي التباين يلبّي أعلى من حد AAA، والتأكد من إمكانية تطبيق أوراق أنماط وكيل المستخدم إذا كان المستخدمون يحتاجون إلى تباين مخصص أو ألوان مختلفة. يمكنك استخدام أداة التحقّق من تباين الألوان هذه. كأداة مساعدة عند تصميم المكون.
هل المحتوى المتحرّك أو الوامض آمن ويمكن إيقافه؟
يجب أن يكون المستخدمون قادرين على إيقاف المحتوى مؤقتًا أو إيقافه أو إخفاؤه أو تحريكه أو تمريره يومض لمدة تزيد عن خمس ثوانٍ. بوجه عام، تجنَّب وامض المحتوى.
إذا كان من المفترض أن يومض شيء ما، فتأكد من أنه لا يومض أكثر من ثلاث مرات في الثانية.
اختبارات وأدوات تسهيل الاستخدام
هناك أكثر من 100 أداة متاحة تقييم سهولة الوصول إلى موقعك الإلكتروني ومكوناته. تعمل بعض الأدوات بطريقة آلية، بينما يتطلّب البعض الآخر اختبارًا يدويًّا.
في ما يلي بعض التقارير التي يمكنك أخذها في الاعتبار:
- يوفر Axe إمكانية الوصول التلقائية. اختبار إطار العمل أو المتصفح الذي تختاره. محرك دمى الفأس يمكن استخدامها لكتابة اختبارات إمكانية الوصول الآلية.
أدوات تسهيل الاستخدام من Lighthouse التدقيق رؤى مفيدة لاكتشاف مشكلات الوصول الشائعة. نتيجة إمكانية الوصول هي متوسط مرجّح لجميع عمليات تدقيق إمكانية الوصول. استنادًا إلى تقييمات تأثير مستخدمي Axe. لمراقبة إمكانية الوصول من خلال الدمج المستمر، راجع Lighthouse CI:
Tenon.io مفيد لاختبار المشاكل الشائعة لإمكانية الوصول. توفّر منصة Tenon دعمًا قويًا للدمج في أدوات التصميم والمتصفّحات (من خلال والإضافات) وحتى برامج تحرير النصوص.
هناك العديد من الأدوات الخاصة بالمكتبة وإطار العمل لإبراز مشكلات إمكانية الوصول مع المكونات. على سبيل المثال، يمكنك استخدام eslint-plugin-jsx-a11y لإبراز مشكلات إمكانية الوصول لمكونات React في المحرر.
في حال استخدام Angular، يتم استخدام codelyzer يوفر عمليات تدقيق لإمكانية الوصول داخل المحرر أيضًا:
العمل على التقنيات المساعدة
- يمكنك دراسة الطريقة التي ترى بها التقنيات المساعدة محتوى الويب باستخدام
Accessibility Inspector (أداة فحص إمكانية الوصول) (نظام التشغيل Mac)
أو أدوات اختبار واجهة برمجة التطبيقات Windows Automation API
وAccProbe (نظام التشغيل Windows).
يمكنك أيضًا الاطّلاع على شجرة تسهيل الاستخدام الكاملة التي ينشئها Chrome.
من خلال الانتقال إلى
about://accessibility. - إن أفضل طريقة لاختبار دعم قارئ الشاشة على جهاز Mac هي استخدام VoiceOver
الأخرى. يمكنك استخدام
⌘F5لتفعيلها أو إيقافها، وCtrl+Option ←→للتنقّل. وCtrl+Shift+Option + ↑↓للانتقال للأعلى أو للأسفل في إعدادات تسهيل الاستخدام شَجَرَة لمزيد من الإرشادات التفصيلية، يمكنك الاطّلاع على القائمة الكاملة لأوامر VoiceOver. وقائمة أوامر VoiceOver للويب. NVDA عبارة عن شاشة مجانية مفتوحة المصدر على نظام التشغيل Windows. قارئ البطاقات. ومع ذلك، فإن بها منحنى تعلم شديد للمستخدمين المبصرين.
يتضمّن نظام التشغيل ChromeOS قارئ شاشة مضمَّن.
لا يزال أمامنا طريق طويل لتحسين إمكانية الوصول على الويب. وفقًا لتقويم الويب:
- 4 من كل 5 مواقع بها نص يندمج في الخلفية، مما يجعلها غير قابلة للقراءة.
- لا تزال 49.91% من الصفحات لا تقدّم سمات
altلبعض صورها. - أن 24% فقط من الصفحات التي تستخدم أزرارًا أو روابط تتضمن تصنيفات.
- توفر% 22.33 فقط من الصفحات تصنيفات لكل البيانات التي يتم إدخالها في النموذج.
هناك الكثير مما يمكننا القيام به لإنشاء تجارب يسهل الوصول إليها الجميع.