سأجرب هذا لاحقًا، ولكن هذا ليس الحل لأنك لا تقوم بتنفيذ الخطوات التي يقوم بها قارئ الشاشة الفعلي. بما أنني أنتقل إلى منشور معين، يمكن افتراض أنني أرغب في قراءة هذا المنشور. علامة التبويب ليست أمر قراءة ولكنها طريقة لنقل التركيز إلى العنصر التالي الذي يمكنه اكتساب التركيز. أمر القراءة سيكون باستخدام مفاتيح الأسهم لأسفل أو أمر SayAll الخاص بقارئ الشاشة. على الأقل مفتاح السهم لأسفل وهو أمر القراءة المفضل لدي يفشل، فالتركيز ليس حيث يكون بصريًا على الإطلاق ولكنه عادةً قبل قائمة المنشورات.
بالطبع، يمكن أن تكون علامة التبويب هي الطريقة القذرة لحل هذه المشكلة ولكنها ليست حل المشكلة نفسها.
شكراً @thoeg@nolan، أقدر ذلك كثيراً. أعتقد أنني أرى ما هي المشكلة. نحن نستخدم حالياً عنصراً فارغاً span لتعيين التركيز على المنشور. هذا العنصر يحتوي على aria-hidden=true و tabindex=-1، وأعتقد أن هذا يجعل العنصر غير مرئي لقارئات الشاشة.
أعتقد أنه من الأفضل تحويل التركيز إلى أول عنصر قابل للتركيز في المنشور. في معظم الحالات، سيكون ذلك رابط اسم المستخدم، أي مؤلف المنشور.
هذا منطقي. يجب أن يخفي Ariahidden العنصر ويمنعه -1 من الحصول على التركيز. إذا كان هذا العنصر سيأخذ التركيز إلى عنوان الموضوع، فسيكون ذلك جيدًا. قد يكون من المثير للاهتمام معرفة ما حدث إذا قمت فقط بتعيين tabindex=0 بدلاً من ذلك،
نعم، أسمعك يا @anni_anni، سنقوم بإصلاح هذا. لقد حاولت القيام بمحاولة أولى الأسبوع الماضي، لكن كان عليّ التراجع عنها لأنها تسببت في بعض الآثار الجانبية غير المرغوب فيها. سأحاول اتباع نهج مختلف قريبًا جدًا.
حسنًا، أخيرًا، تم دمج محاولة أخرى لإصلاح هذا. التنفيذ الحالي هو تعيين التركيز على أول عنصر قابل للتركيز في منشور، والذي سيكون في معظم الحالات، اسم المستخدم الخاص بمنشئ المنشور. عند الانتقال إلى منشور والضغط على مفتاح Tab، يجب أن يبدو الأمر كالتالي في Chrome:
ما زلت أرى السلوك القديم المعطل على Meta و community.fly.io مع Chrome، ولكن يمكنني تأكيد أن الإصلاح يعمل على موقع discourse.team الخاص بنا. هل تعمل هذه بإصدارات مختلفة من Discourse؟ أنا أستخدم نفس إصدار Chrome بنفس الملف الشخصي.
حسنًا، قد تكون المواقع الثلاثة في إصدارات مختلفة قليلاً من Discourse، لكنني أعتقد أن جميعها تحتوي على التغيير المرتبط أعلاه. ميتا، على وجه الخصوص، محدثة دائمًا بأحدث التغييرات في فرع tests-passed الخاص بنا، لذلك أنا قلق بعض الشيء من أن هذا لا يعمل هنا…
حسنًا، لدي المزيد من المعلومات لك حول هذا الأمر، تمت ملاحظته على موقع discourse.team الخاص بنا حيث أبلغت عن عمل هذا.\n\nإذا نقرت على منشور جديد تمامًا لم أقرأه من قبل، فلن أتلقى أي ملاحظات صوتية، ويبدو أن التركيز يهبط بشكل عشوائي على ما أفترض أنه الصفحة الأولى من المشاركات.\n\nإذا نقرت على موضوع تمت زيارته سابقًا، فإن التركيز يهبط بشكل صحيح وأتلقى ملاحظات صوتية.\n\nيبدو أن هذا السلوك متسق بين Firefox و Chrome الآن. أعتقد أن Firefox كان يضع التركيز بشكل صحيح على المنشور الأول عند عرض سلسلة جديدة. سيكون من الجيد استعادة هذا السلوك إذا أمكن حتى تتصرف تجارب القراءة الأولى والعودة بنفس الطريقة. أنا سعيد لأنه على الأقل يستعيد آخر موضع قراءة لي في Chrome الآن على الأقل لأن ذلك مطلوب للعمل.\n\nمن المدهش أن هذه السلوكيات كانت مختلفة جدًا بين Firefox و Chrome.\n\nشكرًا على كل الجهود المبذولة في هذا الأمر.
هذا خبر رائع! لقد قصرت بالفعل التغييرات هنا على التنقل إلى المشاركات التي ليست أول مشاركة في موضوع. بالنسبة للمستخدمين العائدين، غالبًا ما يكون ذلك تنقلًا إلى الموضوعات التي قرأتها بالفعل ولكن لديها الآن ردود جديدة.
هذا شيء جيد أن نعرفه، أعتقد أن لدينا مسارًا للتكرار وإصلاح هذا. إذا كان بإمكانك مشاركة الترتيب الدقيق للأوامر التي تستخدمها، فسيكون ذلك مفيدًا أيضًا.
على متصفح Chrome العادي الخاص بي، إذا ذهبت إلى موضوع جديد لم أقرأه وضغطت على Tab، فإن التركيز يهبط على عنوان الموضوع، وهو ما يبدو معقولًا بالنسبة لي ولكنه ربما لا يكفي لحالة الاستخدام الخاصة بك.
شكرًا مرة أخرى على ملاحظاتك المستمرة، نقدرها كثيرًا!
هذا غريب مع Jaws و Chrome والاختبار في موضوع جديد على Meta، رأيت سلوكًا جديدًا من Jaws. بعد الضغط على Enter على عنوان الموضوع، أحصل على المعلومات المعتادة حول الصفحة التي تم تحميلها للتو، وهو سلوك Jaws القياسي. سيحدث الشيء نفسه عندما أعود إلى قائمة المواضيع وأضغط على Enter على نفس الموضوع، يتم وضع التركيز فقط على آخر مشاركة تمت قراءتها. يبدو أن هذا قد حل مشكلتين على الأقل هنا. لم أختبر الانتقال إلى آخر مشاركة في قائمة المواضيع، لكن تخميني هو أن هذا سيعمل.
ومع ذلك، بالطبع، ليس كل شيء جيدًا، ولكن هذا قد لا يكون متعلقًا على الإطلاق. عندما أستخدم زر الرجوع للعودة إلى قائمة المواضيع، يتم فقدان التركيز، ولا يتم إعادتي إلى الموضوع الذي فتحته وكنت أقرأه. قد يكون هذا خطأ في Jaws/Chrome، وقد رأينا شيئًا مشابهًا من قبل، ولكنه قد يكون أيضًا من جانبك. سأضطر إلى التحقق من NVDA.
لقد جربت للتو باستخدام nvda و chrome وهنا لا يعمل أي شيء، أي أنني لم أعد أستطيع الضغط على Enter على أي من عناوين المواضيع في الجدول. أنا متأكد من أن هذا كان يعمل. بالطبع، بما أنني مستخدم لـ Jaws، فلن يزعجني هذا، ولكن بالنسبة لمستخدمي nvda، فهذه قصة أخرى.
نظرًا لأن nvdadid لم يعمل حقًا، لا يمكنني اختبار المشكلة مع التركيز عند العودة من موضوع إلى قائمة المواضيع.
ومع ذلك، فإن JAWS موثوق به هنا، حيث يتم وضع التركيز في أعلى الصفحة.
في أحدث إصدار من Chrome على موقع discourse.team الخاص بنا، يؤدي النقر على موضوع تمت زيارته سابقًا إلى إعادتي إلى حيث توقفت عن القراءة، ويعلن NVDA بشكل صحيح عنوان المنشور الذي تم التركيز عليه.
للأسف، لا يؤدي النقر على موضوع جديد إلى تركيز المؤشر على المنشور الأول في الموضوع. وبالمثل، يفشل استخدام “h” لمحاولة وضع التركيز على المنشور الأول. يجب عليّ العثور عليه يدويًا لبدء القراءة.
لاحظ أن الموضع يبدو أنه تم تعيينه بشكل صحيح في المنشورات الجديدة على Firefox. يبدو أن المشكلة تقتصر على Chrome لسبب ما.
بشكل عام، يسعدني استعادة الموضع في المواضيع السابقة نظرًا لأنها تمثل أكبر مشكلة بالنسبة لي. آمل أن نحصل على سلوك متسق وصحيح عبر كلتا الحالتين.
هذا صحيح أيضًا. التنفيذ الحالي يتخطى تحديدًا تعيين التركيز إذا كان المنشور المستهدف هو المنشور الأول. حاولت إضافة نفس الشيء إلى المنشور الأول، ولكنه غالبًا ما يؤدي إلى تمرير غير ضروري عند تحميل عنوان URL للموضوع وكان ذلك مزعجًا جدًا لجميع المستخدمين.
يجب أن يعمل هذا. سأقوم ببعض الاختبارات وأرى ما إذا كان بإمكاننا إصلاح هذا.
عند نشر موضوع جديد، القائمة المنسدلة لإضافة العلامات/الفئات غريبة بعض الشيء. أولاً، التسمية بالنسبة لي هي “Filter by” (التصفية حسب). لا أعرف ما إذا كانت معروضة بصريًا أم لا، لكن استغرق الأمر سنوات حرفيًا مني في نشر المشاركات على Discourse قبل أن أدرك أن هذا هو المكان الذي تتم فيه إضافة العلامات. استخدام كلمة “Filter” (تصفية) بالنسبة لي يعني شيئًا مثل “تصفية شيء من الماء”، وليس إضافة شيء جديد. إذا كانت هذه معروضة بصريًا، فافعل ما تراه مناسبًا بهذه الملاحظات، ولكن إذا كانت خاصة بـ ARIA فقط، فقد تستفيد من بعض التعديلات.
بعد ذلك، يؤدي النقر على قائمة العلامات إلى ظهور ما يبدو أنها أزرار اختيار. إذا ضغطت على Space (مسافة) عليها (أي وفقًا لـ نمط ARIA radio group)، يبدو أن هذا يؤدي إلى تشغيل بحث. نعم، يمكنني الضغط على Enter هنا بدلاً من ذلك، لكنني معتاد على الضغط على Space لتشغيل تفاعلات الأزرار لأن إبهامي موجود هناك.
بالتأكيد ليست مشكلة مانعة، ولكن اكتشافها أصعب بالتأكيد، ويجب علي التفكير بشكل إضافي لتذكر/إعادة اكتشاف كيفية عملها في كل مرة أنشر فيها. تاريخيًا، كنت أنقر على فئات فردية، ولكن هذا حد من قدرتي على استخدام علامات متعددة.
أعتقد أن نمط ARIA combobox قد يكون مناسبًا بشكل أفضل لهذا التفاعل. على وجه التحديد، يتصرف editable combobox بطريقة أقل إرباكًا بكثير. إذا كتبت “A”، يمكنني الانتقال لأسفل إلى “Alabama”. لا يتم تقديمه كزر اختيار، لذا فإن استجابتي التلقائية ليست الضغط على Space هناك، ولكن إذا فعلت ذلك، فإنه يُدخل المسافة كما هو متوقع. قد يكون كل ما هو مطلوب هو إزالة عرض زر الاختيار، ولكن ربما يمكن أن يكون أقل تفصيلاً بشأن عدد النتائج أيضًا.
إذا كتبت رمزًا تعبيريًا في مربع تحرير المنشور (على سبيل المثال، :)) وركزت على هذا الرمز التعبيري أثناء التحرير، فلا يمكنني استخدام السهم لأعلى/لأسفل للانتقال إلى السطر السابق أو التالي. يجب عليّ التحرك بالسهم يسارًا/يمينًا للخروج من الرمز التعبيري أولاً.
هل هذا بسبب سلوك الإكمال التلقائي؟ أتساءل عما إذا كان يمكن تعطيل هذا السلوك إما في الحالات التي يوجد فيها تطابق واحد فقط، أو ما لم يتم الضغط على Enter أو مفتاح آخر؟ أتفهم سلوك الإكمال التلقائي للإدخال الأولي والتعديلات، ولكنه كان بالتأكيد صعبًا في محاولة تصحيح سبب عدم قدرتي على نقل التركيز في بعض الحالات ويبدو أن هذا هو السبب. يبدو أن نوعًا من القائمة المنسدلة التي يتم تشغيلها يدويًا للتعديلات هو الخيار الصحيح هنا.
