هل ينبغي أن يقرأ تطبيق الويب التعليمات بصوت مسموع؟ احسم التحكم قبل اختيار الصوت
قد يساعد زر القراءة بصوت مسموع شخصا على سماع تعليمات قصيرة وهو ينظر إلى العمل أمامه. اطلبه كوسيلة اختيارية لسماع نص محدد، مع إيقاف موثوق وبقاء المعلومات المكتوبة متاحة. نجاح تجربة صوت واحد لا يثبت أن كل جهاز ولغة وحالة مقاطعة ستعمل كما تريد.
المقصود هنا إخراج صوتي داخل تطبيق المتصفح، وليس الإملاء أو إنتاج ملف تعليق صوتي للتنزيل. كما أنه لا يغني عن جعل التطبيق قابلا للاستخدام مع التقنيات المساعدة.
ما النص الذي ستقرؤه الميزة تحديدا؟
تخيل فريقا لتأجير المعدات يراجع ملاحظة قصيرة عن تجهيز جهاز. هذا مثال مختلق للتوضيح، وليس نتيجة مشروع لعميل. قد تكون الوظيفة المفيدة «قراءة خطوات التجهيز»، لا «قراءة كل ما في الصفحة». لا ينبغي أن تدخل أسماء العملاء والتعليقات الداخلية وروابط التنقل في الصوت لمجرد وجودها بجانب التعليمات.
حدد حدود المحتوى قبل التطوير. هل يقرأ الزر خطوة واحدة أم التعليمات كلها أم فقرة مختارة؟ هل يأتي التحذير في موضعه الصحيح؟ إذا احتوى جدول على كميات، فاكتب ترتيب قراءته وراجعه بدلا من افتراض أن التخطيط البصري سيصبح كلاما مفهوما تلقائيا.
يبقى النص المعروض هو المرجع. لا ينبغي للصوت اختراع تعليمات أقصر أو حذف شرط بصمت. وإذا احتفظت بنسخة منفصلة للقراءة، فعيّن مسؤولا عن تطابق النسختين عند التحديث.
اختيار اللغة لا يضمن صوتا بعينه
تصف وثائق MDN لواجهة SpeechSynthesis التحكم بأصوات النطق المتاحة وأوامر الكلام. تعيد الدالة getVoices الأصوات المتاحة على الجهاز الحالي، وتصف الوثائق حدث voiceschanged عند تغير تلك القائمة.
لذلك اطلب فحص الأصوات الفعلية بدلا من الوعد بالصوت المسمى نفسه على جميع الأجهزة. اتفق على ما يحدث إذا لم يتوفر صوت مناسب للغة المطلوبة: يبقى النص مقروءا وتوضح الواجهة أن القراءة غير متاحة، بدلا من اختيار لغة غير مناسبة دون تنبيه.
اختبر عبارات حقيقية من كل لغة مدعومة مع أشخاص قادرين على تقييم نطقها. انتبه إلى الأسماء والاختصارات والكميات العشرية والنصوص المختلطة اللغات. صدور صوت بنجاح تقني لا يثبت أن التعليمات مفهومة. ولا تعد بالعمل دون اتصال أو بمعالجة محلية بالكامل قبل التحقق المستقل من الصوت والمنصة المختارين.
تكرار الضغط يجب ألا يراكم تعليمات قديمة
توضح MDN أن أمر speak يضيف مقطعا إلى قائمة انتظار، وأن المقاطع السابقة تقرأ أولا. هذه نقطة مهمة في طلب المشروع: الضغط المتكرر على «قراءة» يجب ألا يترك مجموعة تعليمات قديمة تنتظر دورها دون قصد.
اختر قاعدة واضحة. قد يتحول التحكم أثناء القراءة إلى إيقاف مؤقت ثم استئناف، أو قد يؤدي اختيار نص جديد إلى إنهاء القراءة القديمة وبدء النص المختار. سمِّ الأفعال بوضوح. تفرق الوثائق بين pause وresume وبين cancel الذي يزيل المقاطع من قائمة الانتظار. هذه سلوكيات مختلفة، وليست أسماء متبادلة لزر واحد.
حدد معنى الإيقاف عندما ينتظر نص آخر بالفعل. اطلب عرض الضغط السريع المتكرر والتنقل بين تعليمتين. ينبغي أن يعرف المستخدم ما الذي يسمعه الآن وما إذا كان شيء آخر سيُقرأ بعده.
ماذا يحدث عندما تتغير المهمة؟
إذا فتح المستخدم طلب عمل آخر أو عدل التعليمات أو سجل الخروج، فهل يستمر النص القديم؟ التوصية المبدئية المعقولة هي إنهاء المحتوى الذي لم يعد صالحا، واشتراط إجراء صريح جديد لقراءة النص الجديد. سجل السلوك المقصود بدلا من تركه لصدفة التنفيذ الأول.
فكر أيضا في المكان المحيط. قد يسمع الآخرون تفاصيل العميل المنطوقة. اجعل التشغيل بطلب المستخدم، ووضح ما سيُقرأ، وتجنب الإعلان التلقائي عن معلومات خاصة. هذه توصيات تصميم عملية، وليست ادعاء بأن واجهة النطق توفر ضوابط سرية.
إذا تعذر الاستماع، تبقى التعليمات متاحة كنص. قدم حالة مفهومة لعدم الإتاحة أو المقاطعة؛ لا تكفي أيقونة مكبر صوت متحركة لتفسير الفشل.
اختبر سير الاستخدام لا جمال الصوت فقط
استخدم تعليمات تجريبية غير حساسة. على كل جهاز ومتصفح متفق عليهما، اختبر بدء القراءة وإيقافها مؤقتا واستئنافها وإنهاءها وفقا للتحكم المختار. كرر الضغط وانتقل إلى عنصر ثان، وتأكد من عدم ظهور قراءة قديمة مفاجئة. عدل المحتوى أو غادر المهمة وافحص قاعدة المقاطعة المتفق عليها.
كرر ذلك لكل لغة مدعومة، بما في ذلك غياب صوت مناسب حيث يمكن إعادة إنتاج هذه الحالة. افحص تشغيل لوحة المفاتيح ووضوح أسماء الأزرار والتوافق مع إعداد التقنيات المساعدة المشمول بالمشروع. هذه اختبارات استلام محددة، وليست شهادة شاملة بإمكانية الوصول.
أحضر أنواع النصوص والأجهزة واللغات وقواعد المقاطعة إلى مناقشة مشروع تطبيق الويب. الناتج المفيد مسار استماع اختياري ومفهوم بحدود مختبرة، لا مجرد زر يصدر صوتا.