لقد تلقيت تقريرًا من مستخدم قارئ شاشة يفيد بأن كود التلميح الجديد لا يعمل:
هل واجه أي من زملائي مستخدمي قارئات الشاشة صعوبات مع ميزة التلميحات المحدثة في المنتدى؟ على الأقل أفترض أنه كان هناك تحديث - كان من قبل أن يتم قراءة نص التلميح بشكل طبيعي دون أي إشارة إلى أنه كان من المفترض إخفاء شيء ما، وهو ما لم يكن مثاليًا بالطبع. يبدو أن التحديث قد أصلح هذه المشكلة عن طريق وضع المحتوى خلف منطقة قابلة للطي تحمل عنوان “إظهار المحتوى المخفي”، ولكن لسبب ما لم يتم التقاط النص عند الضغط على الزر لتوسيعه/الكشف عنه. كمرجع، أنا أستخدم VoiceOver، قارئ الشاشة الأصلي من Apple، وقد لاحظت هذا على كل من iOS و Mac OS.
مرحباً @Dannii، شكراً لك على تحديد هذه المشكلة. لقد قمت للتو بنشر إصلاح، والذي يجب أن يحسن الآن السلوك بحيث تقرأ قارئات الشاشة محتويات الجزء المخفي بمجرد تبديله.
هل أنت متأكد من ترقية المكون الإضافي إلى أحدث إصدار؟ (commit 0ee68da)
يبدو أنه يعمل هنا على Meta بالنسبة لي باستخدام VoiceOver. نحن نستخدم أيضًا aria-live كـ polite لهذا ، مما يعني أن قارئ الشاشة لن يكون حازمًا ومزعجًا. بدلاً من ذلك ، سينتظر حتى يكون المستخدم خاملاً للتحدث بالمحتويات.
كيغان، هل يمكنك توضيح المزيد حول كيفية اختبار هذا؟ تبدو لقطة الشاشة الخاصة بك وكأنها متصفح سطح مكتب. هل تستخدم VoiceOver على macOS؟ (في أي متصفح؟)
يُعد VoiceOver على macOS منتجًا مختلفًا تمامًا عن VoiceOver على iOS. من الشائع وجود أخطاء في VoiceOver على macOS لا تظهر في VoiceOver على iOS، والعكس صحيح. (لأسباب مختلفة، يُعد VoiceOver على iOS أكثر شيوعًا بكثير بين المستخدمين المكفوفين مقارنة بـ VoiceOver على macOS.)
أنقر نقرًا مزدوجًا. يصبح النص المخفي غير مشوش بصريًا.
يعلن VoiceOver: “إخفاء المحتوى. موسع. إخفاء المحتوى.” أدعي أن هذا خطأ في Discourse. كان يجب عليه قراءة المحتوى النصي بصوت عالٍ، كما فعل في فيديو كيغان.
أقوم بالتمرير لليمين، والانتقال إلى عنصر التحكم التالي في واجهة المستخدم.
يعلن VoiceOver: “أعجب شخص واحد بهذا المنشور. انقر للعرض. زر تبديل.”
أقوم بالتمرير لليسار، والعودة إلى النص غير المشوش المخفي.
الآن، عليك قراءة هذا المسح بعناية، لأنه يتحدث أولاً عن متصفحات سطح المكتب، ويحتوي على رسم بياني “قارئ الشاشة الأساسي” https://webaim.org/projects/screenreadersurvey9/#primary ولكنه يشير تحديدًا إلى قارئ الشاشة الأساسي “لأجهزة سطح المكتب/الكمبيوتر المحمول”.
يشير هذا الرسم البياني إلى أن “VoiceOver” ليس شائعًا جدًا، ولكنه يشير إلى macOS VoiceOver في هذا القسم. (إذا قمت بالتمرير لأسفل إلى قسم “أنظمة التشغيل”، سترى أن macOS نفسها ليست شائعة جدًا بين مستخدمي قارئات الشاشة.)
JAWS لنظام Windows هو قارئ الشاشة الرائد، يليه NVDA لنظام Windows. macOS VoiceOver هو المركز الثالث البعيد. Windows Narrator يستخدم بنسبة 0.5٪!
لاحظ أن JAWS يكلف المال (وتخطيط الترخيص الخاص به مرهق)، و NVDA مجاني. ولكن أيضًا، يميل NVDA إلى أن يكون به أخطاء أكثر من JAWS؛ حسب تجربتي، أي شيء يعمل في NVDA يعمل أيضًا في JAWS.
يوضح هذا الرسم البياني أن قارئات الشاشة المدمجة في نظام التشغيل تهيمن، مع iOS VoiceOver (71.5٪) و Android TalkBack (29.1٪). (تضيف هذه الأرقام أكثر من 100٪ لأن بعض الأشخاص يستخدمون كليهما.)
المفقود من هذا المسح هو مسح “الوقت على الجوال مقابل الوقت على سطح المكتب”، ولكن، حسب تجربتي، فإن الغالبية العظمى من تقارير الأخطاء التي أسمعها من مستخدمي قارئات الشاشة تأتي من مستخدمي iOS ومستخدمي NVDA.
لذلك، أوصي بالاختبار بهذا الترتيب حسب الأولوية:
iOS Safari VoiceOver. أوصي بالجوال على سطح المكتب (لأنني أدعي، بدون بيانات، أن الجوال أكثر شيوعًا بشكل كبير بين المستخدمين المكفوفين) و iOS على Android، لأن iOS أكثر شيوعًا بشكل ساحق من Android بين المستخدمين المكفوفين.
Windows NVDA على Chrome. NVDA ليس شائعًا مثل JAWS، ولكنه به أخطاء أكثر. أي شيء يعمل في NVDA سيعمل أيضًا على JAWS، ولكن ليس بالضرورة العكس.
Windows JAWS على Chrome.
Android TalkBack على Chrome.
macOS VoiceOver على Safari.
لكنني أعتقد أنك ستجد أن مجرد الاختبار في iOS Safari VoiceOver يحقق عائدًا ممتازًا على استثمارك. عادةً ما أقوم باختبار iOS Safari فقط، ثم Windows NVDA على Chrome عندما أرغب في أن أكون شاملاً للغاية، ثم أتوقف عادةً.
لقد مرت خمس سنوات على الأقل منذ أن رأيت مستخدمًا يبلغ عن خطأ يحدث في Windows JAWS ولكنه لا يحدث في Windows NVDA. أعتقد أنني لم أر قط مستخدمًا يبلغ عن خطأ في Android TalkBack على الإطلاق.
aria-live غير مخصص للتبديل. يجب عليك تعيينه على polite في البداية وتركه. مع التنفيذ الحالي، لا يتم التعرف على حدوث تغيير أبدًا لأنه لا تحدث تغييرات أثناء تشغيله.
المشكلة بالنسبة لي (NVDA/Windows) تبدو في أن لديك عنصر div خارجي مع aria-label. أعتقد أنه في معظم قارئات الشاشة، هذه ليست ملاحظة للمحتوى، بل هي بديل للمحتوى غير المتاح. على الأقل، aria-label هو الشيء الوحيد الذي يتم قراءته بالنسبة لي.
إليك تسجيل للعرض المخفي في هذا الموضوع: قراءة شريط الوقت في أسفل الفيديو، ثم مساحة فارغة (لا أعرف ما هذا)، ثم المحتوى المخفي المرئي (“زر موسع إخفاء المحتوى”) ثم قائمة “2 ردود”.
لاحظ أنه إذا استخدمت ميزة تصحيح الأخطاء في NVDA وحركت مؤشر الفأرة فوق النص الموسع لقراءته، فإنه يتم قراءته. لكنني لم أجد أي طريقة لجعله يقرأ النص دون استخدام الفأرة. لذلك، لا يبدو أن هذه طريقة صالحة لاختبار ما إذا كان متاحًا بالفعل…
