هل يستطيع الجميع استخدام تطبيقك المبني بالذكاء الاصطناعي؟ دليل بسيط لسهولة الوصول

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

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

لماذا ينهار تصميم تطبيقي عندما يكبّر أحدهم الشاشة؟

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

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

هذا أكثر أعطال سهولة الوصول شيوعًا في التطبيقات المبنية بالذكاء الاصطناعي، وهو غير مرئي حتى يكبّر أحدهم الشاشة. اطلب من أداة البناء الخاصة بك: “تأكد من أن التصميم يظل يعمل عندما يُكبَّر النص إلى 200%. لا ينبغي أن يتداخل أي شيء أو يُقطع.” ثم اختبر ذلك بنفسك — على هاتفك، ارفع حجم خط النظام إلى أقصى إعداد وافتح تطبيقك. إذا تحطّم التصميم، فهذا أول إصلاح عليك القيام به.

لماذا لا ينبغي أن يعتمد تطبيقي على اللون وحده لإظهار الحالة؟

لأن نحو واحد من كل اثني عشر رجلًا يرى الألوان بشكل مختلف، والأكثر شيوعًا هو الأحمر والأخضر — فالحالة التي تُعرض فقط كنقطة حمراء مقابل نقطة خضراء تبدو متطابقة لهم، ولا يستطيعون فعليًا التمييز بين “مدفوع” و”متأخر”.

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

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

لماذا تكتفي قارئات الشاشة بقول “زر” بدلًا من تسميته؟

لأن زر الأيقونة غير المُسمّى — سلة مهملات، قلم رصاص، عدسة تكبير بلا كلمات — لا يملك نصًا يعلنه قارئ الشاشة (البرنامج الذي يستخدمه ضعاف البصر والمكفوفون لقراءة الشاشة بصوت عالٍ)، فيقرأ، حرفيًا، “زر”. ليس “حذف”. ليس “تعديل”. فقط “زر”.

تحب أدوات البناء بالذكاء الاصطناعي أزرار الأيقونات النظيفة لأنها تبدو عصرية. لكن تخيّل استخدام تطبيق يُسمّى فيه كل عنصر تحكم “زر” وعليك أن تخمّن ماهيته. لست مضطرًا لإضافة نص مرئي إلى كل أيقونة — عليك فقط التأكد من أن لكل عنصر تحكم اسمًا كامنًا، ولو غير مرئي، يستطيع قارئ الشاشة إعلانه. اطلب من أداة البناء الخاصة بك: “أعطِ كل زر أيقونة تسمية يمكن للوصول إليها — أيقونة سلة المهملات ينبغي أن تُعلن باسم ‘حذف’، وأيقونة القلم باسم ‘تعديل’.” إنه تغيير صغير، وهو الفارق بين تطبيق يستطيع مستخدم كفيف التنقل فيه وآخر يبدو جدارًا من الأزرار المجهولة.

ما الحجم المناسب لمناطق اللمس في تطبيق الهاتف المحمول؟

القاعدة التقريبية التي يستخدمها المصممون هي أن أي عنصر قابل للمس ينبغي أن يكون بحجم نحو 44 بكسل — أي بحجم طرف الإصبع تقريبًا — مع تباعد حقيقي بحيث لا يتلاصق عنصران قابلان للمس حافةً بحافة.

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

كيف أختبر سهولة وصول تطبيقي في خمس دقائق؟

يمكنك اكتشاف معظم هذا بنفسك دون أي أدوات، عبر ثلاثة فحوصات سريعة على الشاشة الأكثر استخدامًا:

1. كبّرها. ارفع نص هاتفك أو متصفحك إلى أقصى إعداد وافتح الشاشة الرئيسية. هل يتداخل شيء، أو يختفي، أو يُقطع؟
2. أفرغها من اللون. انظر إلى كل مكان في تطبيقك يستخدم اللون لإيصال معنى — الحالة، الأخطاء، الحقول المطلوبة. إذا تخيّلت كل ذلك بالرمادي، هل ما زلت تستطيع معرفة ما يجري؟ إن لم تستطع، أضف كلمة أو أيقونة.
3. شغّل قارئ الشاشة لدقيقتين. كل من الآيفون (VoiceOver) والأندرويد (TalkBack) يحتوي على قارئ شاشة مدمج. شغّله، أغلق عينيك، وحاول القيام بالمهمة الرئيسية التي صُمم تطبيقك من أجلها. ستسمع فورًا أي الأزرار بلا اسم.

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

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