تسجيل الدخول

إمكانية الوصول في تطبيقات الأجهزة المحمولة: متطلبات WCAG 2.2 لنظامي iOS وAndroid

16 min read
قابل للحملIosأندرويد

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

يمتلك أكثر من 72% من البالغين ذوي الإعاقة هاتفًا ذكيًا، ووفقًا لأحد الاستطلاعات، يعتمد ما يقرب من 86% من مستخدمي قارئات الشاشة على جهاز محمول — وهي نسبة أعلى من مستخدمي أجهزة سطح المكتب أو الحواسيب المحمولة. ومع ذلك، فإن نفس المؤسسات التي تُجري تدقيقات منتظمة لمواقعها الإلكترونية غالبًا ما تمتلك تطبيقات جوال لم تُختبر مطلقًا وفق أي معيار من معايير الوصول. هذا الفجوة تُغلق بسرعة، مدفوعة بتطور اللوائح، وتزايد الدعاوى القضائية، والأهم من ذلك — إرشادات W3C نفسها التي ترسم بشكل صريح خريطة WCAG 2.2 على تطبيقات iOS وAndroid الأصلية.

لماذا تنطبق WCAG 2.2 على تطبيق الجوال الخاص بك

هناك أسطورة مستمرة مفادها أن WCAG معيار خاص بالويب فقط. هذا غير صحيح. لا يمتلك W3C إرشادات منفصلة لإتاحة استخدام الأجهزة المحمولة — بل يتم تناول إتاحة استخدام الأجهزة المحمولة ضمن إطار عمل WCAG القائم، وقد أنتجت مجموعة عمل إتاحة الأجهزة المحمولة في W3C (Mobile Accessibility Task Force - MATF) إرشادات مخصصة بعنوان Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile) ترسم خريطة كل معيار نجاح من المستوى A وAA على تطبيقات الجوال الأصلية، وتطبيقات الويب على الجوال، والتطبيقات الهجينة.

الأثر العملي لذلك كبير. عندما تقرأ معيار نجاح في WCAG يشير إلى "صفحة ويب"، يستبدل مستند WCAG2Mobile هذه اللغة بـ "شاشة" أو "عرض". وعندما يناقش المعيار "وكيل المستخدم"، فإنه يقصد نظام تشغيل الجوال. مبادئ POUR الأربعة — قابل للإدراك (Perceivable)، قابل للتشغيل (Operable)، قابل للفهم (Understandable)، متين (Robust) — تُترجم مباشرة إلى كيفية تفاعل المستخدم مع عرض SwiftUI في iOS أو تخطيط Jetpack Compose على Android.

من الناحية القانونية، لم يعد الضغط نظريًا. بموجب الباب الثاني من قانون الأمريكيين ذوي الإعاقة (ADA)، تتطلب لوائح وزارة العدل (DOJ) المحدّثة الصادرة في أبريل 2024 صراحةً من الحكومات المحلية وحكومات الولايات جعل تطبيقاتها على الجوال متاحة وفق WCAG 2.1 AA. وتواجه مؤسسات الرعاية الصحية التي تقبل Medicare أو Medicaid متطلبات مماثلة بموجب قواعد وزارة الصحة والخدمات الإنسانية (HHS) التي تم إقرارها في مايو 2024. وعلى الرغم من أن الدعاوى القضائية الخاصة بتطبيقات الجوال في القطاع الخاص لا تزال أقل تكرارًا من تلك المتعلقة بالمواقع الإلكترونية، فقد استهدف على الأقل مدعٍ واحد عالي النشاط تطبيقات الجوال تحديدًا بسبب نقص الوصول العادل بموجب ADA، ومن المتوقع أن يتسارع هذا الاتجاه مع حلول جداول الامتثال للباب الثاني في 2026.

يتطلب قانون الإتاحة الأوروبي (EAA)، الذي دخل حيز التنفيذ في 28 يونيو 2025 ويعتمد على EN 301 549 كمعياره التقني المفترض، أيضًا الالتزام بـ WCAG 2.2 للمنتجات والخدمات الرقمية بما في ذلك تطبيقات الجوال المباعة أو المعروضة في أسواق الاتحاد الأوروبي. بالنسبة لأي مؤسسة لديها قاعدة مستخدمين عالمية، فإن WCAG 2.2 على الجوال ليس طموحًا مستقبليًا — بل هو التزام حالي.

ما الذي تغيّر في WCAG 2.2 ويهم الجوال أكثر

يضيف WCAG 2.2، الذي نُشر كتوصية من W3C في أكتوبر 2023، تسعة معايير نجاح جديدة ويزيل المعيار 4.1.1 Parsing الذي أصبح الآن متجاوزًا. وهو متوافق بالكامل مع الإصدارات السابقة: الامتثال لـ 2.2 يعني ضمنًا الامتثال لـ 2.1 و2.0. كُتبت عدة معايير جديدة مع مراعاة أنماط التفاعل على الجوال بشكل صريح، وحتى تلك المؤطرة حول استخدام لوحة المفاتيح لها نظائر مباشرة في تقنيات المساعدة على iOS وAndroid.

من المفيد فهم التسلسل التاريخي هنا. بعد 2018، ضمنت مجموعة عمل إتاحة الأجهزة المحمولة أن تؤثر اعتبارات الجوال في كل من WCAG 2.1 و2.2. معايير مثل 1.3.4 Orientation (AA)، و1.4.10 Reflow (AA)، و2.5.1 Pointer Gestures (A)، و2.5.4 Motion Actuation (A)، والمعايير الجديدة 2.5.7 Dragging Movements (AA)، و2.5.8 Target Size Minimum (AA)، و3.3.7 Redundant Entry (A) تعكس جميعها أنماط استخدام محددة على الجوال تم تحديدها من خلال اختبارات واقعية مع مستخدمين ذوي إعاقة على الهواتف الذكية والأجهزة اللوحية.

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

المعايير الجديدة في WCAG 2.2 وكيف تنطبق على iOS وAndroid

2.5.8 Target Size Minimum (المستوى AA)

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

بالنسبة للتطوير الأصلي على الجوال، يُعد حد 24 × 24 في WCAG 2.2 في الواقع حدًا أدنى وليس أقصى. توصي إرشادات واجهة المستخدم من Apple بحجم هدف لمس أدنى يبلغ 44 × 44 نقطة على iOS وiPadOS. وتوصي Material Design من Google بـ 48 × 48 بكسل مستقلة عن الكثافة (dp) على Android. إذا كان تطبيقك يلتزم بإرشادات منصة Apple أو Google، فأنت تتجاوز بالفعل الحد الأدنى لـ WCAG 2.2 — لكن العديد من التطبيقات لا تفعل ذلك. تلك الأزرار الصغيرة للإغلاق في النوافذ المنبثقة، ومربعات الاختيار الرفيعة في شاشات الإعدادات، وإجراءات شريط الأدوات المعتمدة على الأيقونات فقط والتي تقيس 20 × 20 dp كلها إخفاقات في الامتثال تنتظر أن تُكشف في تدقيق.

ملاحظة عملية: يتناول مطلب WCAG منطقة التفاعل القابلة للنقر، وليس الحجم البصري للأيقونة. أيقونة بحجم 16 نقطة ملفوفة في 14 نقطة من الحشو على كل جانب تمتلك هدف نقر فعّال بحجم 44 × 44 نقطة. هذا يعني أن بإمكان المطورين تلبية المعيار دون تكبير العناصر بصريًا — لكن يجب عليهم تعيين هذا الحشو بشكل متعمد، لا الاعتماد على النظام للقيام بذلك تلقائيًا.

2.5.7 Dragging Movements (المستوى AA)

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

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

2.4.11 Focus Not Obscured — Minimum (المستوى AA) و2.4.12 (محسّن، المستوى AAA)

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

بالنسبة للجوال الأصلي، يُفسَّر "تركيز لوحة المفاتيح" بشكل واسع ليشمل حلقة التركيز المستخدمة في Switch Control أو Switch Access، وFull Keyboard Access (iOS 15+)، وVoice Control/Access. يفشل التطبيق الذي ينزلق فيه العنصر الذي عليه التركيز تحت شريط التنقل السفلي أثناء مسح Switch Control لهذا المعيار، حتى لو لم تكن هناك لوحة مفاتيح فعلية. يجب أن يتجنب تصميم واجهة التطبيق حجب عناصر التحكم التي عليها التركيز بواسطة طبقات يخلقها المطور، أو أشرطة ثابتة، أو أسطح عابرة.

2.4.13 Focus Appearance (المستوى AA)

يحدد هذا المعيار متطلبات دنيا للخصائص البصرية لمؤشر التركيز: يجب أن يمتلك مساحة دنيا تعادل محيط المكوّن × 2 بكسل CSS، ونسبة تباين لا تقل عن 3:1 مقابل الألوان المجاورة. على منصات الجوال الأصلية، تتحكم أنظمة التشغيل في حلقة التركيز لـ VoiceOver وTalkBack، ولا يمكن للمطورين تغيير شكلها — ما يعني أن المطورين يُمنحون عادة استثناءً لهذا المعيار تحديدًا. ومع ذلك، يجب ألا يقلل أسلوب تصميم التطبيق من وضوح التركيز، على سبيل المثال، عبر وضع طبقة شفافة فوق عناصر التحكم التي عليها التركيز.

3.3.8 Accessible Authentication — Minimum (المستوى A)

يمثل هذا المعيار خطوة كبيرة نحو الإتاحة المعرفية. فهو يتطلب ألا تعتمد عمليات المصادقة فقط على اختبار وظيفة معرفية — أي لا يجب أن يُطلب من المستخدم حفظ كلمة مرور، أو حل لغز، أو نسخ CAPTCHA — ما لم يوفر التطبيق بديلًا متاحًا. على iOS، يعني هذا دعم Keychain من Apple وSign in with Apple للسماح للمستخدمين بالمصادقة دون حفظ بيانات الاعتماد. على Android، يعني هذا دعم إطار عمل Autofill من Google، والمصادقة البيومترية، وعدم حظر استخدام مديري كلمات المرور من جهات خارجية.

بشكل أكثر تحديدًا: إذا كان تطبيقك يحظر عمليات اللصق في حقول كلمات المرور، فمن المرجح أنه غير متوافق مع 3.3.8. إذا كان مسار المصادقة الثنائية في تطبيقك يتطلب من المستخدم كتابة رمز OTP يدويًا من إشعار دون توفير آلية نسخ ولصق، فإنه يفرض عبئًا معرفيًا غير ضروري. يوفر تطبيق Messages على Android بالفعل زر "نسخ الرمز" في إشعارات OTP لهذا السبب بالذات — موائمًا سلوك المنصة مع هدف المعيار.

رؤية أساسية: دعم المصادقة البيومترية (Face ID، Touch ID، Android Biometric API) ليس مجرد تحسين لتجربة المستخدم — بل هو آلية امتثال لـ WCAG 2.2 للمستخدمين ذوي الإعاقات المعرفية الذين لا يمكنهم تذكر كلمات المرور بشكل موثوق.

3.3.7 Redundant Entry (المستوى A)

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

3.2.6 Consistent Help (المستوى A)

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

معايير WCAG 2.1 التي لا تزال حاسمة للجوال

تحظى المعايير الجديدة في WCAG 2.2 بمعظم الاهتمام، لكن العديد من متطلبات WCAG 2.1 التي تم تقديمها خصيصًا مع مراعاة الجوال لا تزال تُخفق فيها التطبيقات الأصلية بشكل متكرر، ولا ينبغي لمديري الامتثال تجاهلها أثناء التدقيقات.

1.3.4 Orientation (AA) يحظر قفل التطبيق على وضع عمودي أو أفقي ما لم يكن هذا الوضع ضروريًا لوظيفة المحتوى. العديد من التطبيقات تُقفل على الوضع العمودي أثناء مسارات الإعداد الأولي أو مشغلات الفيديو داخل التطبيق دون مبرر. يؤثر هذا بشكل غير متناسب على المستخدمين الذين لديهم أجهزة مثبتة على الكراسي المتحركة لا يمكن تدويرها. يتطلب 1.4.10 Reflow (AA) أن يمكن عرض المحتوى دون تمرير أفقي عند عرضه بعرض 320 بكسل CSS (ما يعادل تكبير 400%)، وهو ما يعني في سياق الجوال دعم Dynamic Type وتكبير حجم النص على مستوى النظام دون كسر التخطيط أو اقتطاع المحتوى.

يتطلب 2.5.1 Pointer Gestures (A) أن تكون أي وظيفة تستخدم إيماءات متعددة النقاط أو قائمة على المسار — مثل القرص للتكبير، أو السحب بإصبعين — لها بديل بمؤشر واحد. يتطلب 2.5.4 Motion Actuation (A) أن تكون الوظائف التي تُشغَّل عبر هز الجهاز أو إمالته قابلة للتشغيل أيضًا من خلال عناصر تحكم قياسية في واجهة المستخدم، وأن يتمكن المستخدمون من تعطيل المشغلات القائمة على الحركة لتجنب التفعيل العرضي.

بالنسبة للعرض البصري، يتطلب 1.4.3 Contrast Minimum (AA) نسبة لا تقل عن 4.5:1 للنص العادي و3:1 للنص الكبير. لا تزال العديد من التطبيقات تُخفق هنا لأن نص العنصر النائب في حقول الإدخال، وتسميات الأزرار المعطلة، والنص على الخلفيات المصوّرة تقع تحت الحد الأدنى. يجب على المطورين التأكد من أن جميع النصوص، وعناصر التحكم، والمحتوى تعمل مع Dynamic Type، ونص عريض (Bold Text)، والوضع الداكن، وخيارات التباين على مستوى النظام على كل من iOS وAndroid.

إرشادات تنفيذ خاصة بالمنصة

iOS وSwiftUI / UIKit

توفر Apple دعمًا واسعًا للإتاحة الأصلية من خلال واجهة برمجة التطبيقات UIAccessibility وفي SwiftUI من خلال معدّلات الإتاحة. لدعم VoiceOver، يجب أن يمتلك كل عنصر تفاعلي تسمية إتاحة ذات معنى، وتلميحًا، وقيمة. يجب أن تعتمد عناصر التحكم المخصصة التي لا ترث من مكوّنات UIKit القياسية صراحة سمة إتاحة مناسبة — مثل .isButton، و.isHeader، و.isLink — حتى يعلنها VoiceOver بشكل صحيح. يمكن أن يساعد Xcode Accessibility Inspector في كشف التسميات المفقودة وعدم تطابق السمات أثناء التطوير.

بالنسبة لـ Dynamic Type، تعمل خطوط النظام في UIKit مثل UIFont.preferredFont(forTextStyle:) وفي SwiftUI مثل .font(.body) على التدرج تلقائيًا مع حجم النص المفضل لدى المستخدم. ستفشل أحجام الخطوط المرمّزة بقيم ثابتة بالنقاط والتي لا تستخدم scaledValue(for:) في المعيار 1.4.4 Resize Text. بالنسبة لأحجام الأهداف، يمكنك توسيع منطقة النقر لرمز صغير باستخدام contentEdgeInsets في UIKit أو المعدّل .contentShape() في SwiftUI دون تغيير العرض البصري للعنصر.

// SwiftUI: توسيع منطقة النقر دون تغيير الحجم البصري
Image(systemName: 'xmark')
    .frame(width: 20, height: 20)
    .contentShape(Rectangle().size(CGSize(width: 44, height: 44)))
    .accessibilityLabel('Close')
    .accessibilityAddTraits(.isButton)

Android وJetpack Compose / Views

تُعرض إتاحة Android من خلال واجهة برمجة التطبيقات AccessibilityNodeInfo، والتي يستهلكها TalkBack وSwitch Access. في Jetpack Compose، يتيح لك Modifier.semantics تعيين أوصاف المحتوى، والأدوار، وأوصاف الحالة، ودمج الدلالات الفرعية. بالنسبة لواجهات المستخدم القائمة على View، يسمح ViewCompat.setAccessibilityDelegate() بالتلاعب برمجيًا بخصائص الإتاحة على أي View.

بالنسبة لحجم أهداف اللمس، توصي إرشادات Material Design بحد أدنى يبلغ 48 × 48 dp. إذا كان composable أو view أصغر بصريًا، يمكنك استخدام Modifier.minimumInteractiveComponentSize() في Compose (المقدمة في Material3) لفرض حد أدنى تلقائي يبلغ 48 dp، أو تغليف view صغير في TouchDelegate لتوسيع منطقة النقر الخاصة به في نظام View القديم. بالنسبة لتدرج النص، تأكد من أن جميع أحجام النص محددة بوحدة sp (بكسل مستقلة عن المقياس)، وليس dp، حتى تحترم تفضيلات حجم الخط التي يحددها المستخدم في إعدادات العرض في Android.

// Jetpack Compose: زر أيقونة متاح مع حجم أدنى
IconButton(
    onClick = { onClose() },
    modifier = Modifier
        .minimumInteractiveComponentSize() // يفرض حدًا أدنى 48dp
        .semantics { contentDescription = 'Close dialog' }
) {
    Icon(
        imageVector = Icons.Default.Close,
        contentDescription = null // موصوف من العنصر الأب
    )
}

اختبار تطبيقك وفق WCAG 2.2

يتطلب اختبار إتاحة الجوال مزيجًا من الأدوات الآلية والاختبار اليدوي باستخدام تقنيات المساعدة الحقيقية. يمكن للأدوات الآلية — بما في ذلك axe DevTools Mobile من Deque، وAccessibility Scanner من Google لـ Android، وAccessibility Inspector من Apple في Xcode — اكتشاف التسميات المفقودة، وعدم كفاية التباين، وأهداف اللمس التي تقع تحت الحدود الدنيا للمنصة. ومع ذلك، تلتقط الأدوات الآلية جزءًا فقط من مشكلات الإتاحة الحقيقية. يعد الاختبار اليدوي باستخدام VoiceOver على iOS وTalkBack على Android ضروريًا للتحقق من ترتيب القراءة الصحيح، والتسميات ذات المعنى، وإدارة التركيز المنطقية عبر المسارات المعقدة.

بالنسبة لمعايير WCAG 2.2 المحددة، يكون الاختبار اليدوي مهمًا بشكل خاص. لاختبار 2.5.8 (Target Size)، استخدم إصبعك الفعلي — وليس مؤشر الفأرة في iOS Simulator — لمحاولة التفاعل مع عناصر التحكم الصغيرة. لاختبار 3.3.8 (Accessible Authentication)، تحقق من أن مسار تسجيل الدخول يسمح باللصق في حقول كلمات المرور، ويدعم مديري كلمات المرور (1Password، Bitwarden، keychain النظامي)، ويدعم المصادقة البيومترية. لاختبار 2.4.11 (Focus Not Obscured)، تنقّل في تطبيقك بالكامل عبر Switch Control على iOS أو Switch Access على Android، وتأكد من أن أي عنصر عليه التركيز لا يختفي خلف شريط تنقل، أو طبقة منبثقة، أو زر عائم.

يجب أن تتضمن خطة اختبار الإتاحة الشاملة اختبارًا على جهازين فعليين على الأقل — iPhone واحد وجهاز Android واحد — عند حجم الخط الافتراضي للمستخدم وعند أقصى حجم خط على مستوى النظام، مع تفعيل VoiceOver وTalkBack على التوالي. سيُفوّت الاختبار على المحاكيات فقط اختلافات العرض في العالم الحقيقي وسلوك تقنيات المساعدة.

فكّر في دمج فحوصات الإتاحة في خط أنابيب CI/CD الخاص بك. يدعم كل من Espresso (Android) وXCUITest (iOS) كتابة اختبارات واجهة مستخدم آلية تتحقق من خصائص الإتاحة — مثل أوصاف المحتوى، والسمات، وحالات التفعيل — بحيث تُكتشف التراجعات قبل دمج الشيفرة بدلًا من اكتشافها في تدقيق بعد الإطلاق.

الحجة القانونية والتجارية للتحرك الآن

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

يتصاعد الخطر القانوني. تستمر الدعاوى القضائية التي تستهدف الشركات ذات إخفاقات الإتاحة الرقمية في النمو عامًا بعد عام. إن اعتماد وزارة العدل WCAG كمعيار تقني للامتثال لـ ADA، ومواعيد إنفاذ الباب الثاني في 2026، ودخول EAA حيز التنفيذ في يونيو 2025 مجتمعة تخلق متطلب امتثال متعدد الولايات القضائية يشمل الآن صراحة تطبيقات الجوال الأصلية. لا يُظهر تدقيق سابق لـ WCAG 2.1 تلقائيًا الامتثال لـ WCAG 2.2 — تحتاج مسارات المصادقة، وحقول النماذج، والمكوّنات التفاعلية، وإدارة التركيز جميعها إلى إعادة تقييم مقابل معايير النجاح التسعة الجديدة.

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

أهم النقاط

  • WCAG 2.2 ينطبق على تطبيقات iOS وAndroid الأصلية. ترسم إرشادات WCAG2Mobile من W3C خريطة كل معيار نجاح من المستوى A وAA على شاشات وعروض الجوال، ما يعني أن تطبيقك الأصلي مشمول — وليس موقعك على الجوال فقط.
  • حجم هدف اللمس هو أكثر حالات الفشل الجديدة شيوعًا في تدقيقات الجوال. حد 24 × 24 في WCAG 2.2 هو الحد الأدنى؛ توصي Apple بـ 44 × 44 pt وتوصي Google بـ 48 × 48 dp. وسّع مناطق النقر باستخدام الحشو وواجهات برمجة التطبيقات الأصلية للمنصة، وليس عبر تكبير الأيقونات بصريًا.
  • حظر اللصق في حقول كلمات المرور من المرجح أن ينتهك 3.3.8 Accessible Authentication. ادعم keychains على مستوى النظام، ومديري كلمات المرور، والقياسات الحيوية، والملء التلقائي لرموز OTP لتلبية متطلبات الإتاحة المعرفية لمسارات تسجيل الدخول على كلا المنصتين.
  • الاختبار اليدوي باستخدام VoiceOver وTalkBack غير قابل للتفاوض. تلتقط الأدوات الآلية جزءًا فقط من مشكلات الإتاحة. اختبر على أجهزة فعلية عند أقصى حجم خط، مع تفعيل تقنيات المساعدة، عبر كل مسار مستخدم حرج.
  • ابنِ الإتاحة في نظام التصميم الخاص بك الآن، وليس بعد الإطلاق. إصلاح التطبيقات غير المتاحة بعد الإطلاق أكثر تكلفة بكثير من فرض معايير مكوّنات متاحة منذ اليوم الأول. مع اقتراب جداول إنفاذ DOJ وHHS وEAA في 2025–2026، تُغلق نافذة العمل منخفض التكلفة للامتثال.