الرعاية المتصلة9 دقائق قراءة

إتاحة تطبيقات المرضى للأشخاص ذوي الإعاقة: دليل المشتريات

بقلم

حوّل الإتاحة إلى متطلبات شراء قابلة للاختبار في السعودية، تشمل العربية والدخول والحجز والأخطاء والرسائل وأدلة المورد واستمرار الدعم.

أبرز النقاط

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

إعداد إطار العمل التحريري: CareSync Medical Team. نُشر في 22 أكتوبر 2026.

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

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

الخلاصة التنفيذية

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

لماذا تدخل الإتاحة في قرار الشراء؟

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

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

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

حدد الرحلات واحتياجات التفاعل

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

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

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

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

اختبر تسجيل الدخول كرحلة كاملة

قد تبدو شاشة الدخول بسيطة بينما تمنع الوصول إلى بقية الخدمة. اختبر إدخال كلمة المرور ومدير كلمات المرور ورمز الاستخدام الواحد وانتهاء المهلة وتكرار المحاولة واستعادة الوصول. راقب ما يحدث عند الانتقال بين التطبيق والرسالة التي تحتوي على الرمز.

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

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

افحص العربية بما يتجاوز اتجاه الصفحة

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

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

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

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

راجع تكبير النص وإعادة ترتيب المحتوى

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

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

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

اجعل الأفعال ممكنة دون دقة لمس عالية

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

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

اطلب من المورد تحديد المعيار المنطبق وإظهار كيفية استيفائه في الواجهة الحقيقية. واجمع بين القياس وتجربة المهمة؛ فقد يحقق الزر شرط الحجم ويظل صعب الفهم بسبب تسميته أو موقعه أو عدم وضوح النتيجة التي تحدث بعد الضغط عليه.

اجعل الخطأ مفهوماً وقابلاً للإصلاح

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

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

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

اشمل الرسائل والمستندات

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

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

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

اطلب حزمة أدلة محددة النطاق

اطلب تقييماً يحدد إصدار المنتج والرحلات والمنصات واللغات والأساليب المستخدمة والعيوب المعروفة والقيود. يصعب تقييم عبارة «المنتج متاح للجميع» دون معرفة حدود الاختبار الذي استندت إليه.

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

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

حافظ على الإتاحة بعد الإطلاق

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

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

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

كيف تقيّم CareSync ضمن هذا الإطار؟

تصف منصة CareSync للمستشفيات ومنصة العيادات رحلات رقمية للمريض تحت هوية المنشأة. استخدم الرحلات ذات الصلة أساساً للعرض، ولا تستنتج من وصف المنتج شهادة WCAG أو نتيجة اختبار لتقنية مساعدة أو إتاحة شاملة مثبتة.

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

الأسئلة الشائعة

هل يعني وجود لغتين أن التطبيق متاح للجميع؟

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

هل تتساوى جميع الملاحظات في الأولوية؟

لا. عائق يمنع الحجز يحتاج إلى قرار مختلف عن ملاحظة عرض بسيطة. اتفق مع الفرق المسؤولة على تعريف الشدة والترتيبات المؤقتة المقبولة، واحتفظ بسبب القرار ودليل معالجته.

ماذا نحضر إلى العرض التوضيحي؟

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

المراجع