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

أيضًا ، نظرًا لأن إنشاء تطبيقات ومواقع ويب يمكن الوصول إليها لا يعتبر أمرًا مثيرًا ، فمن الصعب التشكيك في هذا الخط.

لا يزال الوصول خروف أسود ، حتى في عام 2020.

So، نظرًا لأن نسخة UX هي مسؤولية المصمم وخصائص ARIA هي مسؤولية المطور ، والذي تقع مسؤوليته بالضبط على قارئي الشاشة؟ منذ:

1. يتم التعبير عن نسخة UX الخاصة بقارئ الشاشة على أنها طريقة برايل أو الإملاء (فكيف يمكننا إيصال ذلك عندما تكون أدوات واجهة المستخدم مرئية؟)
2. التنفيذ هو منطقة المطورين (لذا هل يمكننا حقًا نقل مسؤولية كتابة نسخة UX إلى المطورين؟)

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

هذا هو مكان Adobe XD CC تسليم التصميم و النماذج الصوتية الميزات في متناول اليدين. في هذه المقالة ، سنناقش ما يجب مراعاته عند التصميم لقراء الشاشة ، وسنستعرض أيضًا كيفية استخدام الميزات المذكورة أعلاه.

ما هي قارئات الشاشة؟

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

إذا كنت من مستخدمي Apple ، على سبيل المثال ، فستكون على دراية إلى حد ما أبل فويس أوفر، وهو برنامج إملاء Apple أصلي يعمل كقارئ شاشة. ومع ذلك ، فإن مستخدمي Windows يستخدمون عادةً أيضًا JAWS or NVDA، نظرًا لعدم وجود أي أدوات قارئ شاشة أصلية في نظام التشغيل Windows.

دعونا الغوص في.

1. استخدم العناوين

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

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

بينما تتوفر حلول التعليمات البرمجية (مثل aria-label السمة) ، وجود مرئي يوفر العنوان بشكل شامل تجربة أوضح لـ الجميعسواء معطل أم لا.

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

من الناحية الفنية ، القاعدة هي أن كل قسم (كما هو محدد من قبل أ <section> or <article> علامة) يجب ألا يكون لها عنوان فقط ، بل يجب أن يكون عنوانًا صريحًا يتعارض مع أي عنوان آخر. كمثال ، إذا كان أعلى مستوى داخل القسم هو <h2>، ثم يجب ألا يكون هناك أخرى <h2> تتجه داخل هذا القسم. خلاف ذلك ، فإن قراء الشاشة لا يعرفون شيئًا عن العنوان الذي يحمل عنوان القسم.

2. استخدام التسميات

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

الصور لها متطلبات مماثلة ، باستثناء أن نصها الوصفي يتم تنفيذه عبر alt بطاقة شعار. ومع ذلك ، تأكد من التواصل عندما تكون الصورة مزخرفة ، حيث سيحتاج المطورون بعد ذلك إلى إخفائها من قارئي الشاشة باستخدامها aria-hidden="true".

استخدام ميزة Handoff Design (تصميم التسليم) لتوصيل نص قارئ الشاشة

سواء كنت تستخدم نصًا بديلًا ، أو تسميات ARIA للعناصر التي لا تحتوي على أي نص مرئي ، أو تسميات ARIA التي تهدف إلى "استبدال" النص المرئي (للسياق المضاف) ، أو حتى مجرد تحديد متى يجب تجاهل الصورة تمامًا من خلال الشاشة القراء ، فإن أداة تسليم التصميم في Adobe XD CC هي الأداة المناسبة لاستخدامها في ذلك.

سيبدو سير العمل شيئًا مثل هذا:

1. انقر فوق مساحة العمل "مشاركة".
2. تكوين الإعدادات (على الجانب الأيمن).
3. انقر على "إنشاء رابط" ثم انقر على الرابط نفسه.
4. داخل نافذة تسليم التصميم ، انقر فوق زر "ضع دبوسًا" للتعليق على عناصر محددة في التصميم.
5. ترك تعليقات. فمثلا:
   • إملاء النسخة غير المختصرة لكل عملة
   • تُترجم هذه الصورة إلى "الصورة الرمزية للمؤلف: Daniel Schwarz"
   • هذه الصورة زخرفية - يجب على قارئي الشاشة تجاهلها

3. تفصيل عند الضرورة

لنفترض مكونًا مكوّنًا من زرين. أحدهما يسمى "حداثة" ، والآخر "بالتسلسل".

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

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

نسخة UX التالية أفضل لمن يستخدمون برامج قراءة الشاشة:

• "ترتيب فصول الحداثة"
• "ترتيب الفصول بالتسلسل"

وعند النقر على زر:

• "يتم ترتيب الفصول الآن عن طريق حداثة"
• "يتم ترتيب الفصول بالتسلسل"

استخدام النماذج الصوتية لإيصال التغييرات الديناميكية

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

سيبدو سير عمل Adobe XD CC على النحو التالي:

1. انقر على مساحة عمل "النموذج الأولي".
2. خلق تفاعل، كما تفعل عادة.
3. حدد "Action" → "Voice Playback" (على الجانب الأيمن).
4. اكتب النص الذي يتحدث به قارئي الشاشة تحت "الكلام".

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

• "(X) أرسل لك رسالة"
• "ستنتهي جلستك خلال (x) ثانية"
• "هل أنت متأكد من أنك تريد الإلغاء؟ [نعم / لا]"

وفي الختام

موقع الويب ليس مجرد مستند يجب قراءته من الأعلى إلى الأسفل - على الأقل ، ليس عندما يتعلق الأمر بالمهام والتفاعلات.

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

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

المكافأة: ميزات تباين الألوان في أدوات تصميم واجهة المستخدم

UXPin يقدم ميزة أصلية للتحقق من تباين الألوان ، وكذلك محاكي عمى الألوان. الفاصوليا الصغيرة ، لكنها لا تزال الأولى. إذا لم تكن تستخدم UXPin ، فإن الخيارات هي أدوات قائمة على الويب مثل WebAIM، ملحقات أداة واجهة المستخدم مثل البرنامج المساعد ستارك, التباين لنظام macOSالطرق أو محلل تباين الألوان لنظام التشغيل Windows. لسوء الحظ ، لسبب ما ، لم يكن تباين الألوان من أهم الاعتبارات في أدوات تصميم واجهة المستخدم.

هنا تأمل لعام 2020!

المكافأة: يتيح Adobe XD التحكم الصوتي

بدأ Adobe XD مؤخرًا في دعم التحكم الصوتي، مما يعني أن هناك الآن المزيد من الطرق للتفاعل مع Adobe XD ، وبالتالي ، كن مصممًا. هذه أخبار رائعة لأولئك الذين لديهم مخاوف تتعلق بإمكانية الوصول ، والأداة تفيد حتى أولئك الذين لم يتم تعطيلهم. كيف ذلك للتصميم الشامل؟

"افتح XD!"

تعرف على المزيد حول إمكانية الوصول باستخدام إمكانية الوصول للجميع من A List Apart على SitePoint Premium.

المصدر: https://www.sitepoint.com/how-to-design-for-screen-readers-with-adobe-xd-cc/؟utm_source=rss