لقد استخدمت الويب لمدة يوم باستخدام قارئ الشاشة

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

ما هو قارئ الشاشة؟

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

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

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

هناك بدائل أخرى ، بما في ذلك Microsoft Narrator و System Access و Window-Eyes و ZoomText (ليس قارئًا بملء الشاشة ، ولكن مكبر شاشة لديه قدرات قراءة) ؛ المجموع المجمع لهما يعادل حوالي 6٪ من استخدام قارئ الشاشة. في نظام Linux ، يتم تجميع Orca افتراضيًا في عدد من التوزيعات.

قارئ الشاشة المجمّع في macOS و iOS و tvOS هو VoiceOver . يشكل VoiceOver 11.7٪ من مستخدمي قارئ شاشة سطح المكتب وترتفع إلى 69٪ من مستخدمي قارئ الشاشة على الهاتف المحمول. برامج قراءة الشاشة الرئيسية الأخرى في مساحة الهاتف المحمول هي Talkback على Android (29.5٪) والمساعد الصوتي على Samsung (5.2٪) ، والتي تعتمد في حد ذاتها على Talkback ، ولكن مع إيماءات إضافية.

لدي جهاز MacBook و iPhone ، لذا سأستخدم VoiceOver و Safari لهذه المقالة. Safari هو المتصفح الموصى باستخدامه مع VoiceOver ، حيث يتم صيانة كلاهما بواسطة Apple ويجب أن يعمل بشكل جيد معًا. قد يؤدي استخدام VoiceOver مع متصفح مختلف إلى سلوكيات غير متوقعة.

كيفية تمكين واستخدام قارئ الشاشة

إرشاداتي خاصة بـ VoiceOver ، ولكن يجب أن تكون هناك أوامر مكافئة لقارئ الشاشة الذي تختاره.

VoiceOver على سطح المكتب

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

الاختصار الخاص بإيقاف تشغيل VoiceOver هو نفس الاختصار لتشغيله: ⌘ + F5 (تُعرف ⌘ أيضًا بمفتاح Cmd ). في أجهزة Mac الأحدث المزودة بشريط اللمس ، يكون الاختصار هو الاستمرار في الضغط على مفتاح الأوامر والضغط ثلاث مرات على زر Touch ID. هل يتحدث VoiceOver سريعًا جدًا؟ افتح أداة VoiceOver ، واضغط على علامة التبويب "الكلام" ، واضبط المعدل وفقًا لذلك.

بمجرد إتقان تشغيله وإيقاف تشغيله ، ستحتاج إلى تعلم كيفية استخدام "مفتاح VoiceOver" (وهو في الواقع مفتاحان يتم الضغط عليهما في نفس الوقت): Ctrl و ⌥ (يُعرف المفتاح الأخير أيضًا باسم "الخيار" "أو مفتاح Alt ). باستخدام مفتاح VO مع مفاتيح أخرى ، يمكنك التنقل في الويب.

على سبيل المثال ، يمكنك استخدام VO + A لقراءة صفحة الويب من الموقع الحالي ؛ في الممارسة العملية ، هذا يعني الضغط على Ctrl + ⌥ + A. إن تذكر ما يتوافق مع VO أمر محير في البداية ، ولكن تدوين VO هو للإيجاز والاتساق. من الممكن تكوين مفتاح VO ليكون شيئًا آخر ، لذلك من المنطقي أن يكون لديك تدوين قياسي يمكن للجميع اتباعه.

يمكنك استخدام VO ومفاتيح الأسهم ( VO + → و VO + ← ) لتصفح كل عنصر في DOM بالتسلسل. عندما تصادف رابطًا ، يمكنك استخدام VO + Space للنقر عليه - ستستخدم هذه المفاتيح للتفاعل مع عناصر النموذج أيضًا.

حوزة! أنت تعرف الآن ما يكفي عن VoiceOver للتنقل عبر الويب.

VoiceOver على الهاتف المحمول

يختلف اختصار الهاتف / الجهاز اللوحي لتشغيل VoiceOver وفقًا للجهاز ، ولكنه عمومًا عبارة عن "نقرة ثلاثية" لزر الصفحة الرئيسية (بعد تمكين الاختصار في الإعدادات).

يمكنك قراءة كل شيء من الموضع الحالي باستخدام أمر Two-Finger Swipe Down ، ويمكنك تحديد كل عنصر في DOM بالتسلسل باستخدام Swipe Right or Left .

أنت الآن تعرف الكثير عن iOS VoiceOver كما تعرف سطح المكتب!

التنقل حسب نوع المحتوى

فكر في كيفية استخدامك للويب كمستخدم مبصر. هل تقرأ كل كلمة بعناية ، بالتسلسل ، من أعلى إلى أسفل؟ لا ، فالبشر كسالى حسب التصميم وقد تعلموا "مسح" الصفحات للحصول على معلومات شيقة بأسرع ما يمكن.

يحتاج مستخدمو قارئ الشاشة إلى نفس هذه الحاجة إلى الكفاءة ، لذلك سيتنقل معظمهم في الصفحة حسب نوع المحتوى ، مثل العناوين أو الروابط أو عناصر التحكم في النموذج. تتمثل إحدى طرق القيام بذلك في فتح قائمة الاختصارات باستخدام VO + U ، والانتقال إلى نوع المحتوى الذي تريده باستخدام مفتاحي الأسهم ← و → ، ثم التنقل عبر هذه العناصر باستخدام مفاتيح ↑ ↓ .

هناك طريقة أخرى للقيام بذلك وهي تمكين ميزة "التنقل السريع" (بالضغط على ← مع ← في نفس الوقت). مع تمكين Quick Nav ، يمكنك تحديد نوع المحتوى بالضغط على السهم ↑ بجانب ← أو ← . على نظام iOS ، يمكنك القيام بذلك باستخدام إيماءة Two-Finger Rotate بإصبعين.

بمجرد تحديد نوع المحتوى الخاص بك ، يمكنك تخطي كل عنصر دوار باستخدام مفاتيح ↑ ↓ (أو Swipe Up or Down على نظام iOS). إذا كان هذا يبدو كثيرًا لنتذكره ، فمن الجدير وضع إشارة مرجعية على ورقة غش VoiceOver سهلة الاستخدام هذه للرجوع إليها.

الطريقة الثالثة للتنقل عبر أنواع المحتوى هي استخدام إيماءات لوحة التتبع. هذا يجعل التجربة أقرب إلى كيفية استخدام VoiceOver على iOS على iPad / iPhone ، مما يعني ضرورة تذكر مجموعة واحدة فقط من أوامر قارئ الشاشة!

يمكنك التدرب على التنقل القائم على الإيماءات والعديد من تقنيات VoiceOver الأخرى في برنامج التدريب المدمج على OSX. يمكنك الوصول إليه من خلال تفضيلات النظام → إمكانية الوصول → VoiceOver → فتح تدريب VoiceOver.

بعد الانتهاء من البرنامج التعليمي ، كنت متشوقًا للذهاب!

دراسة حالة 1: يوتيوب

البحث على موقع يوتيوب

لقد انتقلت إلى صفحة YouTube الرئيسية في شريط أدوات Safari ، حيث أخبرني VoiceOver أن "أدخل" إلى محتوى الويب باستخدام Ctrl + ⌥ + Shift + ↓ . سأعتد قريبًا على الدخول إلى محتوى الويب ، حيث تنطبق نفس الآلية على المحتوى المضمن وبعض عناصر التحكم في النموذج.

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

لقد بحثت عن بعض المحتويات عالية الجودة:

وانتقلت إلى زر البحث:

ومع ذلك ، عندما قمت بتنشيط الزر باستخدام VO + Space ، لم يتم الإعلان عن أي شيء.

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

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

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

هناك مقالات كاملة مخصصة لإمكانية الوصول للتطبيقات المقدمة من العميل ؛ في هذه الحالة ، أوصي YouTube بتنفيذ منطقة aria-live التي ستعلن عند نجاح إرسال البحث.

النصيحة رقم 1: استخدم مناطق aria-live للإعلان عن تغييرات جانب العميل في DOM.

 <div role="region" aria-live="polite" class="off-screen"></div> <form> <label> <span class="off-screen">Search for a video</span> <input type="text" /> </label> <input type="submit" value="Search" /> </form> <script> document.getElementById('search-form').addEventListener('submit', function (e) { e.preventDefault(); ajaxSearchResults(); // not defined here, for brevity document.getElementById('search-status').textContent = 'Search submitted. Navigate to results below.'; // announce to screen reader }); </script>

الآن بعد أن خدعت وعرفت أن هناك نتائج بحث يجب النظر إليها ، أغمضت عيني وانتقلت إلى الفيديو الأول للنتائج ، بالتبديل إلى وضع "العناوين" في Quick Nav ثم التنقل خلال النتائج من هناك.

تشغيل الفيديو على موقع يوتيوب

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

نصيحة رقم 2: قم دائمًا بتوفير طريقة لمنع التشغيل التلقائي ، وتذكر اختيار المستخدم.

يتم التعامل مع الفيديو نفسه على أنه "مجموعة" يجب عليك التدخل فيها للتفاعل معها. كان بإمكاني التنقل في كل خيار من الخيارات في مشغل الفيديو ، الأمر الذي فوجئت به بسرور - أشك في أن هذا كان الحال في أيام Flash!

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

نصيحة رقم 3: قم دائمًا بتسمية عناصر التحكم في النموذج.

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

لم يتم سرد هذه النصائح بالترتيب من حيث الأهمية ، ولكن إذا كانت كذلك ، فستكون هذه هي الأولى بالنسبة لي:

نصيحة رقم 4: يجب أن يكون لدى مستخدمي قارئ الشاشة تكافؤ وظيفي مع المستخدمين المبصرين.

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

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

نصيحة رقم 5: استخدم aria-hidden لإخفاء المحتوى الذي لا ينطبق على مستخدمي قارئ الشاشة.

لقد استغرق الأمر وقتًا طويلاً لمعرفة كيفية ضبط موضع التشغيل حتى أتمكن من إرجاع بعض المحتويات. بمجرد أن "تدخل" إلى شريط التمرير ( VO + Shift + ↓ ) ، اضغط مع الاستمرار على ⌥ + ↑ ↓ للضبط. يبدو الأمر غير بديهي بالنسبة لي ، ولكن مرة أخرى ليست المرة الأولى التي تتخذ فيها Apple بعض قرارات اختصارات لوحة المفاتيح المثيرة للجدل.

التشغيل التلقائي في نهاية فيديو يوتيوب

في نهاية الفيديو ، تمت إعادة توجيهي تلقائيًا إلى مقطع فيديو جديد ، وهو أمر محير - لم يحدث أي إعلان.

تعلمت قريبًا الانتقال إلى عناصر التحكم في التشغيل التلقائي وتعطيلها:

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

دراسة حالة 2: بي بي سي

نظرًا لأن الأخبار هي شيء يتم استهلاكه بشكل سلبي بدلاً من البحث عن شيء محدد ، فقد قررت التنقل في بي بي سي نيوز حسب العناوين. تجدر الإشارة إلى أنك لست بحاجة إلى استخدام Quick Nav لهذا الغرض: يوفر VoiceOver أوامر البحث عن العناصر التي يمكن أن توفر الوقت للمستخدم المتميز. في هذه الحالة ، يمكنني التنقل بين العناوين باستخدام مفاتيح VO + ⌘ + H.

كان العنوان الأول هو إشعار ملفات تعريف الارتباط ، وكان العنوان الثاني <h2> بعنوان "روابط إمكانية الوصول". تحت هذا العنوان الثاني ، كان الرابط الأول عبارة عن رابط "تخطي إلى المحتوى" والذي مكنني من تخطي كل التنقلات الأخرى.

تعتبر روابط "التخطي إلى المحتوى" مفيدة جدًا ، وليست فقط لمستخدمي قارئ الشاشة ؛ راجع مقالتي السابقة "لقد استخدمت الويب لمدة يوم باستخدام لوحة مفاتيح فقط".

النصيحة رقم 6: قم بتوفير روابط "تخطي إلى المحتوى" لمستخدمي لوحة المفاتيح وقارئ الشاشة.

كان التنقل حسب العناوين طريقة جيدة: فلكل خبر عنوانه الخاص ، لذلك يمكنني سماع العنوان قبل أن أقرر ما إذا كنت سأقرأ المزيد عن قصة معينة. وبما أن العنوان نفسه كان ملفوفًا داخل علامة ربط ، لم أضطر حتى إلى تبديل أوضاع التنقل عندما أردت النقر ؛ يمكنني فقط VO + Space لتحميل خياري الحالي من المقالات.

في حين أن اختصار تخطي الصفحة الرئيسية إلى المحتوى مرتبط بشكل جيد بـ #skip-to-content-link-target anchor (والذي يقرأ بعد ذلك عنوان الخبر الرئيسي) ، تم كسر رابط تخطي صفحة المقالة. لقد تم ربطه بمعرف مختلف ( #page ) والذي أخذني إلى group المحيطة بمحتوى المقالة ، بدلاً من قراءة العنوان الرئيسي.

في هذه المرحلة ، قمت بالضغط على VO + A لجعل VoiceOver يقرأ لي المقال بالكامل.

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

يبدو أن هذا يرجع إلى بعض العلامات المراوغة قليلاً في جزء تضمين الفيديو من التغريدة:

يبدو أن VoiceOver لا يقرأ سمة النص alt للصورة المتداخلة ، ولا يوجد نص آخر داخل نقطة الارتساء ، لذلك يقوم VoiceOver بفعل الشيء الأكثر فائدة الذي يعرف كيفية القيام به: قراءة جزء من عنوان URL نفسه.

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

لم تكن مشاكل الارتباط موجودة:

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

1. لا أعرف ما تعنيه كلمة "1،887".
2. لا أعلم أنه من خلال النقر على الرابط ، سأعجب بالتغريدة.

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

 <style> .off-screen { clip: rect(0 0 0 0); clip-path: inset(100%); height: 1px; overflow: hidden; position: absolute; white-space: nowrap; width: 1px; } </style> <a href="/tweets/123/like"> <span class="off-screen">1,887 users like this tweet. Click to like</span> <span aria-hidden="true">1,887</span> </a>

النصيحة رقم 7: تأكد من أن كل رابط منطقي عند قراءته بشكل منفصل.

قرأت بعض المقالات الأخرى على البي بي سي ، بما في ذلك مقال "طويل".

قراءة المقالات الأطول

انظر إلى لقطة الشاشة التالية من مقال طويل آخر في BBC - كم عدد الصور المختلفة التي يمكنك رؤيتها ، وماذا يجب أن تكون سماتها alt ؟

أولاً ، لنلقِ نظرة على الصورة الأمامية لبحيرة هافاسو في وسط الصورة. يوجد أدناه عنوان: "بحيرة هافاسو تم إنشاؤها بعد الانتهاء من سد باركر في عام 1938 ، مما أدى إلى تراجع نهر كولورادو".

من أفضل الممارسات تقديم سمة النص alt حتى إذا تم توفير التسمية التوضيحية. يجب أن يصف النص alt الصورة ، بينما يجب أن توفر التسمية التوضيحية السياق. في هذه الحالة ، قد تكون سمة النص alt مثل "منظر جوي لبحيرة هافاسو في يوم مشمس".

لاحظ أنه لا ينبغي أن نبدأ النص alt بـ "صورة:" أو "صورة" أو أي شيء من هذا القبيل. توفر برامج قراءة الشاشة هذا السياق بالفعل من خلال الإعلان عن كلمة "صورة" قبل النص alt الخاص بنا. أيضًا ، اجعل النص alt قصيرًا (أقل من 16 كلمة). إذا كانت هناك حاجة إلى نص alt أطول ، على سبيل المثال ، تحتوي الصورة على الكثير من النص الذي يحتاج إلى نسخ ، فابحث في سمة longdesc .

النصيحة رقم 8: اكتب نصوصًا alt وصفية وفعالة.

من الناحية الدلالية ، يجب ترميز مثال لقطة الشاشة بعنصري < <figure> و <figcaption> :

 <figure> <img src="/havasu.jpg" alt="Aerial view of Lake Havasu on a sunny day" /> <figcaption>Lake Havasu was created after the completion of the Parker Dam in 1938, which held back the Colorado River</figcaption> </figure>

الآن دعونا نلقي نظرة على صورة الخلفية في لقطة الشاشة تلك (تلك التي تنقل أكواب ومعدات الشرب المختلفة). كقاعدة عامة ، يجب أن تحتوي صور الخلفية أو الصور التقديمية مثل هذه على سمة alt فارغة ( alt="" ) ، بحيث يتم إخبار VoiceOver صراحة أنه لا يوجد نص بديل ولا يحاول قراءته.

لاحظ أن alt="" لا يماثل عدم احتوائه على سمة alt ، وهو أمر لا يُعد محظورًا. إذا كانت سمة alt مفقودة ، فستقرأ برامج قراءة الشاشة أسماء ملفات الصور بدلاً من ذلك ، والتي غالبًا ما تكون غير مفيدة جدًا!

النصيحة رقم 9: لا تخف من استخدام سمات النص alt الفارغة للمحتوى التقديمي.

دراسة حالة 3: فيسبوك

توجه إلى Facebook الآن ، وكنت أعاني من أعراض الانسحاب من وقت سابق ، لذلك ذهبت للبحث عن المزيد من الجوكر غير العمليين .

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

يعرّف Facebook أيضًا عددًا من المفاتيح على أنها مفاتيح اختصار يمكن استخدامها من أي مكان في الصفحة:

لقد لعبت معهم ، وهم يعملون جيدًا مع VoiceOver - بمجرد أن تعرف أنهم هناك. المشكلة الوحيدة التي أراها هي أنها ملكية (لا يمكنني أن أتوقع أن تعمل هذه الاختصارات نفسها خارج Facebook) ، لكن من الجيد أن Facebook يحاول بجد هنا.

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

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

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

يمكن تصور ذلك باستخدام المكون الإضافي Web Developer لمتصفح Chrome / Firefox.

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

النصيحة رقم 10: تحقق من صحة هيكل العنوان الخاص بك.

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

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

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

لقد تأثرت بشكل لا يصدق بدقة بعض الأوصاف. ظهرت صورة أخرى قمت بتجربتها كـ "ربما تحتوي الصورة على: 3 أشخاص ، من بينهم John Smith و Jane Doe و Chris Ashton ، أشخاص يبتسمون ، صورة مقربة وداخل المنزل" - وصفية للغاية ، وصحيح تمامًا!

لكن ما يزعجني هو أن الميمات والنكات التي تنتشر على وسائل التواصل الاجتماعي لا يمكن الوصول إليها بطبيعتها ؛ يتعامل موقع Facebook مع ما يلي على أنه "قد تحتوي الصورة على: طائر ونص" ، والتي بالرغم من صحتها ، إلا أنها بعيدة كل البعد عن التصوير الحقيقي!

لحسن الحظ ، يمكن للمستخدمين كتابة نص alt خاص بهم إذا رغبوا في ذلك.

دراسة حالة 4: أمازون

شيء ما لاحظته على Facebook ، يحدث على Amazon أيضًا. يظهر زر البحث قبل حقل إدخال البحث في DOM. هذا على الرغم من حقيقة أن الزر يظهر بعد حقل الإدخال بصريًا.

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

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

النصيحة رقم 11: اجعل ترتيب DOM يطابق الترتيب المرئي.

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

عناوين على أمازون

مرة أخرى ، مثل Facebook ، لدى Amazon ترتيب غريب للعناوين. لقد بحثت عن طريق العناوين وكان أكثر شيء في حيرة من أمري هو أن العنوان الأول في الصفحة كان مستوى عنوان 5 في قسم "البائعون الآخرون على أمازون":

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

يظهر h1 من الصفحة ما يقرب من 10000 سطر لأسفل في التعليمات البرمجية المصدر.

ليس هذا فقط ضعيفًا من الناحية اللغوية وضعيفًا لإمكانية الوصول ، ولكن هذا أيضًا ضعيف بالنسبة إلى مُحسنات محركات البحث. ضعف تحسين محركات البحث يعني عددًا أقل من التحويلات (المبيعات) - وهو أمر أتوقع أن يكون موقع أمازون على رأسه!

نصيحة رقم 12: إمكانية الوصول وتحسين محركات البحث وجهان لعملة واحدة.

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

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

متنوع

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

ستلاحظ المواقع البطيئة

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

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

هل أوافق على ماذا؟

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

كنت سأعرف ما كنت أوافق عليه إذا كان إخلاء المسؤولية جزءًا من الملصق:

 <label> Important: We can only hold details of one trip at a time. <input type="checkbox" /> Tick to confirm you have read this. * </label>

اتباع الكود هو كابوس

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

انظر إلى مدى سهولة قراءة نموذج التعليمات البرمجية هذا من المقالة:

ولكن ها هو إصدار قارئ الشاشة:

شرطة مائلة أولاً نحصل على ارتفاع منفذ العرض ونضربه بواحد [إيقاف مؤقت] في المائة للحصول على قيمة لوحدة vh ، دع vh يساوي ارتفاع النافذة الداخلي نجمة [إيقاف مؤقت] صفر صفر شرطة مائلة واحدة ثم نضبط القيمة في [إيقاف مؤقت ] الخاصية المخصصة vh إلى جذر المستند المستند إلى مجموعة نمط عنصر نمط الخاصية [إيقاف مؤقت] vh dollar brace vh right brace px

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

يتم ترميز الكود باستخدام عناصر HTML القياسية <pre> و <code> ، لذلك لا أعرف كيف يمكن تحسين هذا لمستخدمي قارئ الشاشة. أي شخص يثابر على البرمجة يحظى بإعجابي الكامل.

بخلاف ذلك ، كان الخطأ الوحيد الذي وجدته هو أن شعار الموقع يحتوي على رابط إلى الصفحة الرئيسية ، ولكن لا يوجد نص alt ، لذلك كل ما سمعته هو "link: slash". أنا فقط بصفتي مطور ويب أعرف ما إذا كان لديك رابط href="/" ثم يأخذك إلى الصفحة الرئيسية لموقع الويب ، لذلك اكتشفت الغرض من الارتباط - ولكن "link: CSS Tricks الصفحة الرئيسية "سيكون أفضل!

VoiceOver على iOS أصعب من OSX

كان استخدام VoiceOver على هاتفي تجربة!

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

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

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

ملخص

كانت هذه تجربة ممتعة وصعبة ، وكان أصعب مقال في السلسلة للكتابة حتى الآن.

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

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

لكن لا ينبغي أن نتجنب فعل ذلك لمجرد أنه صعب. كما قالت تشارلي أوين في حديثها ، عزيزي المطور ، الويب ليس عنك : هذا. يكون. لك. الوظيفة . Whilst it's fun to build beautiful, responsive web applications with all the latest cutting-edge technologies, we can't just pick and choose what we want to do and neglect other areas. We are the ones at the coal face. We are the only people in the organization capable of providing a good experience for these users. What we choose to prioritize working on today might mean the difference between a person being able to use our site, and them not being able to.

Let us do our jobs responsibly, and let's make life a little easier for ourselves, with my last tip of the article:

Tip #13: Test on a screen reader, little and often.

I've tested on screen readers before, yet I was very ropey trying to remember my way around, which made the day more difficult than it needed to be. I'd have been much more comfortable using a screen reader for the day if I had been regularly using one beforehand, even for just a few minutes per week.

Test a little, test often, and ideally, test on more than one screen reader. Every screen reader is different and will read content out in different ways. Not every screen reader will read “23/10/18” as a date; some will read out “two three slash one zero slash one eight.” Get to know the difference between application bugs and screen reader quirks, by exposing yourself to both.

Did you enjoy this article? This was the third one in a series; read how I Used The Web For A Day With JavaScript Turned Off and how I Used The Web For A Day With Just A Keyboard.