نحن ننفذ دعم إمكانية الوصول دون تغيير المكون المرئي لتطبيق الهاتف المحمول

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

سيكون حول تنفيذ إمكانية الوصول (إمكانية الوصول) في تطبيق الهاتف المحمول.

خلفية موجزة


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

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

لذلك ، قررت أن أذكر كل هذا في مقالة منفصلة.

بشكل عام ، دعنا نذهب.

عناصر غير مرئية


المشكلة


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

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

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

الحل


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

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

الإخراج المباشر للرسائل الصوتية باستخدام برنامج الوصول إلى الشاشة نفسه


المشكلة


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

الحل


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

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

حصة!


المشكلة


هذه توصية بدلاً من كونها مجرّد حياة ، لكنني مضطر إلى ذكر ذلك.

تذكر أن هناك كائنات فقط على الشاشة لبرنامج الوصول إلى الشاشة؟

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

الحل


الحل بسيط للغاية: استخدم العناصر كما هو مقصود.

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

الخاتمة


في الختام ، أريد أن أقول إن تطوير Windows ، على الرغم من أنه ليس ضروريًا ، يختلف عن تطوير الأنظمة الأساسية المحمولة ، لذلك تختلف ميزات إمكانية الوصول لنظام Windows عن ميزات Android / Ios.

Source: https://habr.com/ru/post/ar432756/


All Articles