عدم القدرة على الوصول إلى التذييل بسبب التمرير اللانهائي هو فشل في إمكانية الوصول

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

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

أي مجتمع يستخدم هذا الإعداد لن يجتاز المستوى A من معايير WCAG 2.1.

يُعتبر المستوى A هو المستوى الأساسي والأكثر أهمية في إمكانية الوصول إلى الويب.

لقد قمت بمراجعة مجتمع ما، وأصنف هذه المشكلة كفشل في معيار النجاح:

2.2.2 إيقاف، إيقاف، إخفاء (المستوى A) حاسم
بالنسبة لأي معلومات يتم تحديثها تلقائيًا (1) تبدأ تلقائيًا و (2) تُعرض بالتوازي مع محتوى آخر، يجب أن توجد آلية للمستخدم لإيقافها أو إخفائها أو التحكم في تكرار التحديث، ما لم يكن التحديث التلقائي جزءًا من نشاط يكون فيه ضروريًا.

3.2.5 التغيير عند الطلب (المستوى AAA) جاد
يتم بدء تغييرات السياق فقط بناءً على طلب المستخدم، أو يتوفر آلية لإيقاف مثل هذه التغييرات.

الحل:

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

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

آمل أن يساعد هذا في توضيح الحاجة إلى التغييرات المطلوبة.

أي تذييل تتحدثون عنه هنا؟

لا يحتوي نظام Discourse الافتراضي على أي تذييل، كما يمكنكم رؤيته في صفحات مثل Categories - Discourse Meta.

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

شكرًا لك على الرد السريع.

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

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

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

يدعم التذييل معايير النجاح (SC): 2.4.5 طرق متعددة (AA)

  • يتوفر أكثر من طريقة للعثور على صفحة ويب ضمن مجموعة من صفحات الويب، ما لم تكن صفحة الويب نتيجة لعملية أو خطوة فيها.

عدم إيقاف التذييل في صفحات معينة يدعم معيار النجاح 3.2.3 التنقل المتسق (AA)

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

هل موقف Discourse هو أنه إذا اخترت هذا المزيج، فإن المشكلة تقع على عاتقك؟
هل تعرف ما إذا كانت هناك أي نصائح حول هذا الموضوع مُدرجة في وثائق ما تنص على هذه الحقيقة: “بما أن إضافة تذييل على موقع يتصفح بشكل لانهائي سيجعله غير قابل للوصول”؟

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

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

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

إذن، إذا فهمتُ التاريخ بالكامل بشكل صحيح، فإن مشكلتك هي:

  • يحتوي موقعك الرئيسي للعقارات على تذييل.
  • ترغب في أن يبدو موقعك العقاري الرئيسي ونموذج Discourse الخاص بك مألوفًا.
  • لن يحتوي Discourse على تذييل بارز في بعض الصفحات، حيث يتم التمرير التلقائي للتذييل بعيدًا.
  • لا ترغب في وجود التذييل في بعض الصفحات فقط.

أدرك أن هذا موقف معقد، ولكن بكونك متحليًا بالهدوء، فإن لديك خيارين فقط إذا كنت ترغب في استخدام Discourse:

  1. ضع التذييل.
    استخدم صفحة بدون تمرير تلقائي كصفحة رئيسية، مثل https://meta.discourse.org/categories، بحيث تكون بارزة ولا تقلق بشأن عدم إمكانية الوصول إليها في المسار /latest.

  2. لا تضع التذييل.
    تحتوي صفحة discourse.org الخاصة بنا على تذييل، وكذلك مدونتنا. لكننا لا نملك نفس التذييل هنا. تفعل العديد من الشركات الشيء نفسه، وقد يكون فعل العكس مجرد محاولة لإدخال مسمار مربع في فتحة دائرية.

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

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

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

هل تعتقد أنك قد تكون تسير في الاتجاه الخاطئ، نظرًا لعدم وجود تذييل؟

ربما يمكنك إضافة نص في أعلى الصفحة لشرح أن هذه صفحة ذات تمرير لانهائي ولا تحتوي على تذييل.

فيما يتعلق باحتمال أن أبدو متحيزًا قليلاً، لا أعتقد أنه عادل تمامًا تصنيف Discourse على أنه صفحة ويب.

إنه تطبيق ويب، وبالتالي يخلط بين حدود صفحات الويب والتطبيقات.

إذا تعاملت معه كتطبيق، فهل يغير ذلك الأمور بشكل كبير؟

عند فتحه كتطبيق ويب تقدمي (PWA)، يبدو أنه يتصرف كتطبيق بشكل مقنع إلى حد ما.

عند فتح تطبيق Mail على iOS، أين يوجد التذييل؟

(حسنًا، حسنًا، توجد بعض عناصر التحكم الأساسية في لوحة عائمة في الأسفل، لكن هذا ينطبق أيضًا على Discourse في وضع الـ hub)

هل يتم انتقاد Apple لعدم وجود تذييل؟

وماذا عن Gmail؟

كيف يكون مقبولاً أن يحتوي Gmail وMail على التمرير اللانهائي للرسائل، بينما لا يكون مقبولاً فيما يتعلق بقوائم المواضيع؟ أليسوا متشابهين دلاليًا إلى حد كبير؟

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

لماذا خلص خبراء إمكانية الوصول لديهم إلى أن التمرير اللانهائي مقبول لهذين التطبيقين؟

إذن، هل هذه المبادئ التوجيهية قابلة للتطبيق في هذه الحالة؟

يحتوي المنتدى الموجود على https://thepavilion.io/ على تذييل إضافي يمكنك استخدامه للإلهام. يعمل بشكل جيد على iOS Safari، وأقل جودة (أو بشكل مختلف على الأقل) على تطبيق Discourse لنظام iOS.