موقع الويب سريع الاستجابة الذي يمكن الوصول إليه ليس هو نفس التطبيق الذي يمكن الوصول إليه - على الرغم من أن كلاهما "يعملان على الهاتف". تشرح هذه المقالة الاختلافات الحاسمة بين إتاحة الوصول إلى موقع ويب وإتاحة الوصول إلى تطبيق iOS أو Android أصلي.
باختصار – ما تتناوله هذه المقالة
تكنولوجيا مختلفة، وقواعد مماثلة
يتم إنشاء موقع ويب سريع الاستجابة من HTML، والذي يحتوي بالفعل على طبقة إمكانية وصول مضمنة (العلامات الدلالية، ARIA) التي تعرف المتصفحات وقارئات الشاشة كيفية تفسيرها. وعلى النقيض من ذلك، يتم إنشاء التطبيق الأصلي من مكونات واجهة المستخدم الخاصة بنظام التشغيل (UIKit/SwiftUI على iOS، وJetpack Compose/Views على Android) - ويحتاج كل مكون إلى وضع علامة إمكانية الوصول الخاصة به، بشكل منفصل عن تصميمه المرئي. تشبه المبادئ الأساسية WCAG (التباين، وحجم هدف اللمس، واسم واضح يمكن الوصول إليه)، ولكن أدوات تنفيذها مختلفة تمامًا.
VoiceOver وTalkBack: ليسا نفس قارئ الشاشة
VoiceOver (iOS) وTalkBack (Android) هما قارئان مختلفان للشاشة، مع إيماءات تنقل مختلفة ودعم مختلف للمكونات المخصصة. قد لا يعمل المكون الذي تم وضع علامة عليه بشكل مثالي على iOS بشكل صحيح على Android إذا لم يختبر المطورون كلا النظامين الأساسيين بشكل منفصل. لا يمكنك الافتراض أننا "اختبرناه على نظام التشغيل iOS، لذا يجب أن يعمل على نظام Android أيضًا."
💡 نقطة مهمة
في كلا النظامين الأساسيين، يحتاج كل مكون تفاعلي (زر، حقل إدخال، صورة) إلى: تسمية واضحة لإمكانية الوصول، ودور/سمة إمكانية الوصول المحددة، وأحيانًا أيضًا تلميح إمكانية الوصول الذي يشرح ما يحدث عند النقر عليه.
ما هو فريد بالنسبة للتطبيقات الأصلية
تواجه التطبيقات الأصلية أيضًا تحديات غير موجودة على مواقع الويب: إيماءات اللمس المخصصة (التمرير السريع والضغط) التي تحتاج إلى بديل يسهل الوصول إليه؛ والتنقل بين الشاشات الذي يجب أن يكون منطقيًا من خلال قارئ الشاشة أيضًا؛ ودفع الإشعارات التي يجب الوصول إليها حتى عندما تظهر خارج التطبيق نفسه. بالإضافة إلى ذلك، يجب أن تلبي أحجام اللمس المستهدفة ما لا يقل عن 44 × 44 بكسل بموجب إرشادات Apple و48 × 48 بكسل وفقًا لإرشادات Google - وهو مطلب لا يوجد دائمًا بنفس الشكل على مواقع الويب.
كيفية اختبار تطبيق يمكن الوصول إليه
- قم بتشغيل VoiceOver أو TalkBack وحاول إكمال المهام الأساسية للتطبيق (الاشتراك والشراء والبحث) باستخدامهما فقط.
- تحقق من التباين وحجم النص من خلال تشغيل إعدادات إمكانية الوصول إلى النظام (نص أكبر، تباين عالٍ).
- تأكيد دعم تغيير حجم النص الديناميكي (النوع الديناميكي على نظام التشغيل iOS) دون "تعطل" التخطيط.
- اختبر على كلا النظامين الأساسيين بشكل منفصل - اختبار واحد فقط ليس كافيًا.
هل لديك أيضًا مستندات مصاحبة لتطبيقك؟
تقوم أداتنا بفحص ملفات PDF المرتبطة بتطبيقك أو موقع الويب الخاص بك - شروط الاستخدام والأدلة والنماذج - وتظهر لك بالضبط الملفات التي تحتاج إلى الاهتمام.
افحص موقعك مجانا ←بعد الفحص، يمكنك أيضًا جعل المستندات التي تم العثور عليها قابلة للوصول مباشرةً ومجانًا عبرAccessiDoc.