قارئات الشاشة وبرايل والوصول غير البصري
البنية الدلالية قبل الصوت
برايل الإلكتروني والعربية
العربية واللغات المختلطة
لوحة المفاتيح والتركيز
المسار الكامل دون فأرة
الأسماء والأدوار والحالات
اسم يمكن فهمه خارج السياق البصري
ARIA والبنية الدلالية
الصور والجداول والنماذج
PDF والوثائق والكتب
العربية وRTL عمليًا
قائمة فحص قابلة للطباعة
قياس نجاح الوصول
الأسئلة الشائعة
أسئلة شائعة
ما قارئ الشاشة؟
برنامج يحول البنية والمحتوى الرقمي إلى كلام أو برايل ويتيح التنقل بالأوامر.
هل قارئ الشاشة يقرأ أي موقع؟
قد يستخرج النص، لكن إنجاز المهمة يعتمد على البنية الدلالية والتركيز ولوحة المفاتيح.
هل برايل الإلكتروني بديل عن الصوت؟
ليس بالضرورة؛ يمكن الجمع بينهما وفق المهمة والتفضيل.
هل ARIA تجعل الموقع متاحًا؟
لا بمفردها؛ تستخدم عند الحاجة ولا تستبدل HTML الدلالي الجيد.
هل PDF القابل للبحث متاح؟
ليس دائمًا؛ يحتاج أيضًا ترتيب قراءة وبنية وعناوين وجداول ونصوص بديلة.
كيف أختبر العربية؟
اختبر RTL والنص المختلط والأرقام والنطق وترتيب التركيز والجداول والنماذج.
هل الفحص الآلي يكفي؟
لا؛ يلزم اختبار لوحة المفاتيح وقارئ الشاشة والمهام الفعلية.
متى أحتاج اختبار مستخدم؟
في المسارات عالية الأثر والمكونات المعقدة وعند قياس قابلية الاستخدام الفعلية.
قارئات الشاشة تحول الواجهة الرقمية إلى معلومات يمكن استكشافها بالصوت أو ببرايل القابل للتحديث. لكنها لا تقرأ الشاشة كما يراها المستخدم المبصر حرفيًا؛ بل تعتمد أساسًا على البنية الدلالية التي يعرضها المتصفح أو نظام التشغيل. لذلك فإن نجاح الوصول يبدأ من عناوين صحيحة وروابط وأزرار وعناصر نموذج تحمل أسماء وأدوارًا وحالات قابلة للبرمجة، ثم من ترتيب منطقي للتركيز وتشغيل كامل بلوحة المفاتيح. عندما تكون هذه الطبقة سليمة يستطيع المستخدم التنقل بالعناوين أو الروابط أو حقول النموذج بدل المرور على كل حرف في الصفحة. الوصول غير البصري ليس مرادفًا لاستخدام قارئ الشاشة فقط. بعض المستخدمين يعتمدون على الكلام، وبعضهم على برايل الإلكتروني، وبعضهم يمزج بين الاثنين وفق المهمة واللغة والبيئة. وقد يستخدم الشخص التكبير مع قارئ الشاشة أو لوحة مفاتيح بديلة. لهذا السبب يجب أن تختبر الخدمة مع أكثر من طريقة وصول عندما تكون الفئة المستهدفة متنوعة، وأن تقيس إنجاز المهمة لا مجرد إعلان البرنامج أن العنصر موجود. ## كيف يعمل قارئ الشاشة؟ ### البنية الدلالية قبل الصوت يبني قارئ الشاشة تمثيلًا يعتمد على شجرة الوصول التي ينشئها النظام من HTML والعناصر الأصلية وخصائص الوصول. الزر الحقيقي يقدم عادة اسمه ودوره وحالته بصورة أوضح من عنصر مرئي صمم ليشبه الزر من دون دلالة. العنوان الحقيقي يسمح بالقفز بين الأقسام، والقائمة الحقيقية تعطي معلومات عن بنيتها، وحقل النموذج المرتبط بتسمية واضحة يمكن فهمه دون رؤية مكان النص على الشاشة. لذلك يكون HTML الدلالي نقطة البداية قبل إضافة ARIA. لا تختبر الصفحة بقراءة خطية فقط. استخدم قائمة العناوين، ثم الروابط، ثم المعالم الرئيسة، ثم حقول النموذج. إذا كان المستخدم لا يستطيع تكوين خريطة سريعة للصفحة، فقد تكون البنية ضعيفة حتى لو أمكن سماع جميع الكلمات في النهاية. الهدف هو الوصول الكفء للمعلومة، لا مجرد إمكانية استخراج النص بعد وقت طويل. ### الكلام وبرايل مساران متكاملان الإخراج الصوتي سريع ومناسب للتصفح، بينما يوفر برايل القابل للتحديث تمثيلًا لمسيًا للنص والتهجئة وعلامات الترقيم والبنية الدقيقة. قد يكون برايل مهمًا في تعلم القراءة والكتابة، مراجعة الشفرة البرمجية، تحرير النصوص، دراسة اللغات أو الرياضيات، أو في البيئات التي لا يناسب فيها الصوت. لا تفترض أن المستخدم يختار أحد المسارين بصورة دائمة؛ يمكن أن تتغير الطريقة حسب المهمة. ## برايل الإلكتروني والقابل للتحديث ### ما الذي تعرضه خلية برايل؟ تعرض أسطر برايل الإلكترونية عددًا محدودًا من الخلايا في كل مرة، ويتحرك المستخدم خلال النص بواسطة مفاتيح الجهاز أو أوامر قارئ الشاشة. لهذا السبب تؤثر جودة البنية في كفاءة القراءة: العنوان المعلن والجدول المنظم والحقل المسمى يوفر معلومات لا يمكن استنتاجها من موضع بصري. ويجب اختبار الجداول والرموز والاختصارات بالعربية والإنجليزية لأن طريقة الترجمة إلى برايل قد تختلف وفق جدول اللغة والإعدادات. عند شراء شاشة برايل افحص عدد الخلايا، طرق الاتصال، دعم أنظمة التشغيل والأجهزة المستخدمة، إدخال برايل، عمر البطارية، سهولة النقل، وتوفر الدعم الفني. لا تجعل عدد الخلايا وحده معيارًا؛ الاستخدام المدرسي المتنقل يختلف عن التحرير المكتبي الطويل، كما أن مهارة المستخدم وتفضيله عاملان أساسيان. ### العربية واللغات المختلطة المحتوى العربي يضيف تحديات عملية مثل اتجاه RTL، مزج الأرقام والإنجليزية بالعربية، علامات الترقيم، الاختصارات، والانتقال بين جداول برايل أو أصوات النطق. يجب اختبار النص كما يستخدم فعلًا لا عبر جمل عربية معزولة. افحص عناوين الصفحات والقوائم والجداول وحقول الإدخال ورسائل الخطأ، ثم جرّب نصًا يمزج العربية والإنجليزية والأرقام لأن كثيرًا من البيئات التعليمية والتقنية تستخدم هذا المزج. ## لوحة المفاتيح والتركيز ### المسار الكامل دون فأرة ابدأ من أعلى الصفحة واستخدم Tab وShift+Tab والمفاتيح القياسية للمكونات. يجب أن يصل التركيز إلى كل عنصر تفاعلي بالترتيب المتوقع وأن يكون العنصر الذي يملك التركيز واضحًا للمستخدمين المبصرين أيضًا. لا ينبغي أن يدخل التركيز في منطقة لا يمكن الخروج منها، ولا أن يقفز إلى عناصر مخفية، ولا أن يتغير السياق بصورة مفاجئة لمجرد انتقال التركيز. اختبر المهمة كاملة: تسجيل الدخول، البحث، اختيار نتيجة، فتح مستند، تشغيل وسائط، تعبئة نموذج، رفع ملف، إرسال المهمة وقراءة رسالة النجاح أو الخطأ. كثير من المنتجات تبدو متاحة في الصفحة الأولى ثم تفشل في نافذة منبثقة أو منتقي تاريخ أو رفع ملف. لذلك لا تعتمد على فحص الصفحة الرئيسية بوصفه دليلًا على الوصول للخدمة. ### ترتيب التركيز وإدارة النوافذ عند فتح مربع حوار ينبغي أن ينتقل التركيز إلى مكان منطقي داخله، وأن يبقى التنقل ضمن المربع ما دام مفتوحًا عندما يتطلب النمط ذلك، ثم يعود إلى العنصر الذي فتحه بعد الإغلاق. إذا ظهر إشعار مهم أو خطأ دون تغيير التركيز، فيجب أن تصل المعلومة إلى التقنية المساعدة بطريقة مناسبة. إدارة التركيز ليست تجميلًا؛ هي جزء من فهم مكان المستخدم داخل التطبيق. ## الأسماء والأدوار والحالات ### اسم يمكن فهمه خارج السياق البصري الأزرار ذات الأيقونة فقط تحتاج اسمًا برمجيًا يصف الوظيفة. عبارة اضغط هنا ضعيفة عندما تظهر في قائمة روابط طويلة، بينما اسم مثل تنزيل تقرير الوصول يوضح الوجهة. حقول النموذج تحتاج تسمية مرتبطة برمجيًا، والتعليمات الإضافية ينبغي أن تكون قابلة للوصول عند الحاجة. لا تستخدم placeholder بديلًا دائمًا عن label لأنه قد يختفي أثناء الإدخال ولا يوفر دائمًا العلاقة المطلوبة. الحالة مهمة أيضًا: هل القائمة موسعة أم مطوية؟ هل مربع الاختيار محدد؟ هل الزر غير متاح؟ هل التبويب الحالي محدد؟ يجب أن تصل هذه المعلومات إلى قارئ الشاشة بدل الاعتماد على اللون أو الشكل وحده. استخدم العناصر الأصلية متى أمكن، ثم ARIA عندما توجد فجوة دلالية حقيقية. ## ARIA: متى تساعد ومتى تضر؟ ### القاعدة الأولى: لا تستبدل HTML الجيد بلا حاجة ARIA قوية لكنها لا تضيف تلقائيًا سلوك لوحة المفاتيح. إعطاء div دور button لا يجعله يتصرف كزر أصلي ما لم يبرمج التركيز والمفاتيح والحالات. وقد يؤدي اسم ARIA غير صحيح إلى إخفاء نص مرئي مهم أو إعلان عنصر بطريقة مربكة. لذلك افحص المكون وفق نمط معروف واختبره فعليًا بدل قياس عدد خصائص ARIA في الشفرة. في المكونات المعقدة مثل التبويبات والقوائم المنبثقة والشجرات والشبكات، اتبع نمط تفاعل متوقع وثابت. إذا اخترعت مفاتيح خاصة لكل مكون، يصبح التعلم عبئًا على المستخدم حتى لو كانت جميع العناصر قابلة للتركيز تقنيًا. ## الصور والرسوم والمحتوى المرئي ### النص البديل يشرح الغرض لا كل بكسل الصورة الزخرفية التي لا تضيف معنى يمكن تجاهلها برمجيًا، بينما الصورة الوظيفية تحتاج بديلًا يشرح وظيفتها أو معناها في السياق. الرسم التعليمي المعقد قد يحتاج وصفًا أطول أو جدول بيانات أو شرحًا في النص المحيط. لا تجعل alt مستودعًا لكل التفاصيل؛ اسأل ما المعلومة التي يحتاجها القارئ لتحقيق الهدف نفسه الذي يحصل عليه القارئ المبصر. إذا كانت الصورة تحتوي نصًا أساسيًا، الأفضل عادة تقديم النص كنص حقيقي متى أمكن. وعند استخدام رسوم بيانية، وفر الخلاصة والاتجاهات والبيانات المهمة بطريقة يمكن قراءتها غير بصريًا. الاختبار هنا وظيفي: هل يستطيع المستخدم الإجابة عن السؤال أو اتخاذ القرار المطلوب من الرسم؟ ## الجداول ### الرؤوس والعلاقات الجداول البسيطة تحتاج رؤوس صفوف أو أعمدة معرفة بطريقة صحيحة حتى يستطيع قارئ الشاشة إعلان العلاقة أثناء الانتقال بين الخلايا. الجداول المعقدة جدًا قد تصبح مرهقة، وقد يكون من الأفضل تبسيط البنية أو تقسيمها أو توفير عرض بديل. لا تستخدم الجدول لمجرد ترتيب الصفحة بصريًا. اختبر التنقل خلية خلية واسأل هل يعرف المستخدم العمود والصف الذي تنتمي إليه القيمة دون العودة يدويًا إلى البداية. في جداول الدرجات أو الجداول الزمنية أو المقارنات، قد يكون اسم العمود وحده غير كاف إذا كانت هناك مجموعات متعددة؛ صمم البنية بحيث تبقى العلاقات مفهومة. ## النماذج ورسائل الخطأ ### التعليمات قبل الخطأ وبعده كل حقل يحتاج اسمًا واضحًا، والحقول المطلوبة يجب أن تعلن بطريقة مفهومة. إذا كان الإدخال يتطلب تنسيقًا محددًا، قدم التعليمات قبل أن يقع الخطأ. وعند الخطأ، لا تكتف بتلوين الحقل؛ قدم رسالة نصية تحدد المشكلة وطريقة التصحيح، واربطها بالحقل برمجيًا عندما يكون ذلك مناسبًا. بعد إرسال نموذج طويل مع أخطاء، ينبغي أن يعرف المستخدم أن الإرسال لم ينجح وأن يستطيع الوصول بسرعة إلى مواضع الخطأ. اختبر أيضًا التحقق أثناء الكتابة، لأن الرسائل الديناميكية قد تظهر بصريًا دون أن تعلن للتقنية المساعدة أو قد تقاطع المستخدم بكثرة إذا كانت مناطق الإعلان مصممة بصورة مزعجة. ## ملفات PDF والوثائق ### ملف قابل للبحث ليس بالضرورة متاحًا وجود طبقة نص في PDF لا يكفي. يحتاج المستند إلى ترتيب قراءة منطقي، عناوين، قوائم، جداول معرفة، لغة مستند، نصوص بديلة للصور ذات المعنى، وروابط ذات أسماء مفهومة. الملفات الممسوحة ضوئيًا تحتاج تحويلًا إلى نص ومراجعة الأخطاء، لكن OCR وحده لا ينشئ بنية دلالية جيدة. اختبر الوثيقة بقارئ شاشة وبالتنقل عبر العناوين والروابط، وليس فقط بالبحث عن كلمة. في النماذج القابلة للتعبئة افحص أسماء الحقول وترتيب الانتقال ورسائل الخطأ. وإذا كان إصلاح PDF معقدًا جدًا وكان المحتوى مناسبًا للويب، فقد يكون توفير نسخة HTML متاحة أكثر فاعلية مع الاحتفاظ بالوثيقة عند الحاجة. ## الكتب والمواد التعليمية ### بنية قابلة للتنقل الكتاب الرقمي الجيد يسمح بالانتقال بين الفصول والعناوين والصفحات والملاحظات، ويوفر بدائل للصور والأنشطة. يجب ألا تعتمد الأسئلة على وصف بصري فقط مثل اختر الشكل الموجود إلى اليمين إذا كان موضع الشكل لا يحمل معنى غير بصري. أعد صياغة التعليمات بحيث تشير إلى اسم أو رقم أو مفهوم يمكن للجميع تحديده. في التعليم، لا تقيس سرعة التعامل مع واجهة غير متاحة بدل المعرفة المستهدفة. إذا كان الطالب يحتاج وقتًا إضافيًا بسبب التنقل التسلسلي أو استخدام برايل، افصل هذا العبء عن هدف الاختبار. التقنية المساعدة وطريقة العرض ينبغي أن تكونا جزءًا من تخطيط التقييم لا استثناءً في اللحظة الأخيرة. ## الرياضيات والعلوم والشفرة ### البنية أهم من صورة المعادلة المعادلة التي تقدم كصورة دون بديل منظم قد تكون غير قابلة للاستكشاف. استخدم تمثيلًا دلاليًا تدعمه البيئة التعليمية واختبر القراءة مع التقنية المساعدة المستخدمة فعليًا. في الشفرة البرمجية حافظ على المسافات البادئة والنص الحقيقي وإمكانية النسخ، وتجنب لقطات الشاشة عندما يكون الكود نفسه هو المحتوى المطلوب. المخططات العلمية تحتاج وصف العلاقات لا أسماء العناصر فقط. إذا كان الهدف فهم دورة أو مسار، قدم ترتيب الخطوات والعلاقات في نص منظم أو جدول مناسب. هذا لا يعني حذف الرسم؛ بل إضافة قناة مكافئة للمعلومة الأساسية. ## التطبيقات أحادية الصفحة والمحتوى الديناميكي ### التغير يجب أن يكون قابلًا للإدراك عندما تتغير النتائج دون إعادة تحميل الصفحة، يحتاج المستخدم إلى معرفة أن شيئًا تغير. لا تعلن كل حركة صغيرة، لكن أعلن النتائج المهمة مثل اكتمال الحفظ أو ظهور خطأ أو تغير عدد نتائج البحث. إذا أضاف التطبيق محتوى أعلى موضع المستخدم دون إدارة مناسبة، قد يضيع السياق. اختبر زر الرجوع، الروابط العميقة، العناوين التي تتغير، وحفظ موضع التركيز. التطبيقات السريعة بصريًا قد تكون مربكة غير بصريًا إذا لم تعكس التغيرات في بنية الوصول. ## الهاتف المحمول ### الإيماءات لا تلغي الحاجة إلى الدلالات قارئات الشاشة على الهاتف تستخدم إيماءات خاصة للتنقل، لكن جودة الأسماء والأدوار والحالات تبقى أساسية. اختبر تدوير الجهاز، لوحة المفاتيح الافتراضية، الأزرار القريبة من حواف الشاشة، والإجراءات التي تعتمد على السحب فقط. وفر بديلًا لعملية معقدة إذا كانت الإيماءة الدقيقة هي الطريقة الوحيدة. في التطبيقات الهجينة أو المكونات المخصصة قد تختلف النتائج بين iOS وAndroid. لا تفترض أن نجاح الاختبار على منصة واحدة يضمن الأخرى، خصوصًا في المكونات الأصلية المخصصة أو المحتوى المضمن داخل WebView. ## العربية وRTL عمليًا ### اختبار مسار ثنائي اللغة ابدأ بواجهة عربية كاملة، ثم اختبر اسم المستخدم أو البريد الإلكتروني بالإنجليزية، أرقامًا وتواريخ، عنوانًا يمزج اللغتين، وجدولًا يحتوي رموزًا. استمع إلى ترتيب القراءة وتحقق من أن الانتقال البصري RTL لا يغير ترتيب التركيز بطريقة غير منطقية. راقب نطق الاختصارات والأسماء الأجنبية ولا تفترض أن تبديل اللغة البرمجي يحدث تلقائيًا بصورة صحيحة. حدد لغة الصفحة والمقاطع التي تتغير لغتها عندما يكون ذلك ممكنًا. يساعد ذلك محركات النطق على اختيار الصوت أو قواعد النطق المناسبة. لكن الاختبار البشري يظل مهمًا لأن أسماء المنتجات والمصطلحات المختلطة قد تحتاج صياغة أو ضبطًا أوضح. ## الخصوصية والأمان ### الصوت قد يكشف المعلومات قارئ الشاشة قد ينطق بيانات حساسة بصوت مسموع في مكان عام. وفر للمستخدم تحكمًا في ما يعرض، ولا تكشف كلمات المرور أو الرموز الحساسة في رسائل غير ضرورية. عند تصميم التحقق بخطوتين، اختبر نسخ الرمز والتنقل بين الحقول وعدم انتهاء المهلة قبل أن يتمكن المستخدم من إكمال المهمة. اختبارات CAPTCHA التي تعتمد على صورة أو صوت صعب قد تنشئ حاجزًا إضافيًا. استخدم وسائل تحقق أكثر شمولًا عندما تتوفر، واختبر تدفق استعادة الحساب لأن الوصول إلى الخدمة لا يكتمل إذا كان المستخدم يستطيع تسجيل الدخول فقط عندما لا تحدث مشكلة. ## كيف تختبر موقعًا بقارئ شاشة؟ ### اختبار سريع ثم اختبار مستخدم ابدأ بفحص آلي لاكتشاف أخطاء قابلة للرصد مثل غياب أسماء أو تباين، لكنه لا يثبت قابلية الاستخدام. بعد ذلك نفذ اختبار لوحة مفاتيح، ثم قارئ شاشة: عنوان الصفحة، العناوين، المعالم، الروابط، الأزرار، النماذج، الأخطاء والمحتوى الديناميكي. سجل المشكلة مع خطوة إعادة الإنتاج والنتيجة المتوقعة والأثر على المهمة. الاختبار الأفضل يشمل مستخدمين يعتمدون على التقنية في حياتهم الفعلية. قد يجتاز مكون قاعدة تقنية ويظل بطيئًا أو مربكًا بسبب كثرة الخطوات أو الأسماء المتشابهة. اجمع مؤشرات مثل إكمال المهمة، الزمن، الأخطاء، التراجع، الحاجة إلى المساعدة، ورضا المستخدم. ## قائمة فحص عملية قابلة للطباعة ### قبل اعتماد صفحة أو خدمة 1. عنوان الصفحة يصف الغرض ويتغير عند تغير السياق. 2. يوجد H1 واضح وتسلسل عناوين يعكس بنية المحتوى. 3. يمكن تنفيذ كل وظيفة أساسية بلوحة المفاتيح. 4. ترتيب التركيز منطقي ولا توجد مصائد تركيز. 5. لكل زر ورابط وحقل اسم برمجي مفهوم. 6. الحالات مثل موسع ومحدد وغير متاح تعلن للتقنية المساعدة. 7. الصور ذات المعنى لها بدائل مناسبة، والزخرفية لا تضيف ضوضاء. 8. الجداول تستخدم رؤوسًا وعلاقات مفهومة. 9. النماذج تقدم تعليمات ورسائل خطأ نصية مرتبطة بالمشكلة. 10. التغيرات الديناميكية المهمة تصل للمستخدم دون إغراقه بالإعلانات. 11. العربية وRTL والمحتوى ثنائي اللغة اختبرت فعليًا. 12. PDF والملفات المرفقة اختبرت كبنية، لا كنص قابل للبحث فقط. 13. المهمة الكاملة اختبرت من الدخول حتى النتيجة النهائية. 14. توجد طريقة لتسجيل العائق وأثره وأولوية إصلاحه. 15. أُجري اختبار مستخدم عندما تكون الخدمة عالية الأثر أو واسعة الاستخدام. هذه القائمة أداة ضمان جودة وليست اختبارًا تشخيصيًا للشخص. نجاحها يعني أن الفريق فحص مجموعة من متطلبات الوصول؛ ولا يعني وحده أن كل مستخدم سيتمكن من كل مهمة. احتفظ بسجل للمتصفح ونظام التشغيل وقارئ الشاشة وإصداراتها لأن النتائج قد تختلف بين البيئات. ## قياس نجاح الوصول ### من الامتثال إلى النتيجة لا تجعل نسبة اجتياز القواعد الآلية المؤشر الوحيد. قس نسبة إكمال المهام الأساسية، الوقت مقارنة بخط أساس معقول، عدد الأخطاء، نقاط التوقف، وعدد المرات التي يحتاج فيها المستخدم إلى مساعدة خارجية. راقب أيضًا ما إذا كان تحديث جديد أعاد عائقًا سبق إصلاحه. حدد مجموعة مسارات حرجة وأعد اختبارها بعد التغييرات الكبيرة. في منصة تعليمية قد تكون: تسجيل الدخول، الوصول للمقرر، قراءة مادة، حل نشاط، رفع واجب، قراءة التغذية الراجعة. في متجر قد تكون البحث، تفاصيل المنتج، السلة والدفع. بهذه الطريقة يصبح الوصول جزءًا من ضمان الجودة المستمر. ## اختيار قارئ شاشة أو شاشة برايل ### الاختيار حسب البيئة والمهمة لا توجد أداة واحدة مثالية للجميع. افحص الأجهزة وأنظمة التشغيل التي يستخدمها الشخص، اللغة، التطبيقات الأساسية، الحاجة إلى برايل، التنقل، التدريب والدعم. جرّب الأداة في المهام الحقيقية قبل اعتماد تغيير كبير، خصوصًا إذا كان الانتقال من منظومة مألوفة إلى أخرى يحتاج إعادة تعلم اختصارات وسير عمل. في المؤسسة، تجنب فرض قارئ شاشة واحد إذا كان المنتج يجب أن يعمل مع مجموعة معقولة من التقنيات الشائعة. الهدف هو بناء خدمة متوافقة مع المعايير ثم اختبار توليفات ممثلة للمستخدمين، لا برمجة الموقع خصيصًا لأداة واحدة بطريقة تكسر الأدوات الأخرى. ## العلاقة بصفحات روافد الأخرى هذه الصفحة هي Canonical للوصول الرقمي غير البصري بقارئات الشاشة وبرايل. لفهم ضعف البصر واستخدام الرؤية المتبقية راجع صفحة ضعف البصر. ولخصائص الرؤية الدماغية راجع صفحة CVI. وللدورة العامة لاختيار الأجهزة والخدمات راجع دليل التقنيات المساعدة. هذا الفصل يمنع Cannibalization: الصفحة الحالية تركز على تفاعل التقنية مع المحتوى الرقمي، بينما الصفحات الأم تشرح الوظيفة البصرية أو عملية اختيار التقنية بصورة أوسع. ## الأسئلة الشائعة ما قارئ الشاشة؟ هو برنامج يحول البنية والمحتوى الرقمي إلى كلام أو برايل ويمكن المستخدم من التنقل بالأوامر ولوحة المفاتيح أو الإيماءات. هل قارئ الشاشة يقرأ أي موقع؟ قد يستخرج نصًا من مواقع كثيرة، لكن إنجاز المهمة يعتمد على البنية الدلالية والأسماء والتركيز ولوحة المفاتيح والمكونات المتوافقة. هل برايل الإلكتروني بديل عن الصوت؟ ليس بالضرورة. كثير من المستخدمين يجمعون بينهما، ويكون الاختيار مرتبطًا بالمهمة والتفضيل واللغة والبيئة. هل ARIA تجعل الموقع متاحًا؟ لا بمفردها. تستخدم لسد فجوات دلالية عند الحاجة، وقد تسبب مشكلات إذا استبدلت عناصر HTML أصلية جيدة أو استخدمت بصورة خاطئة. هل PDF القابل للبحث متاح؟ ليس دائمًا. يحتاج أيضًا ترتيب قراءة وبنية عناوين وقوائم وجداول ولغة ونصوص بديلة وروابط ونماذج قابلة للوصول بحسب المحتوى. كيف أختبر العربية؟ اختبر واجهة RTL كاملة مع نص مختلط بالعربية والإنجليزية والأرقام، وراجع ترتيب التركيز والنطق واللغة البرمجية والجداول والنماذج. هل الفحص الآلي يكفي؟ لا. يساعد في كشف فئات من الأخطاء، لكنه لا يقيس كفاءة إنجاز المهمة أو جميع مشكلات قارئ الشاشة. متى أحتاج اختبار مستخدم؟ عند الخدمات عالية الأثر، والمسارات الأساسية، والمكونات الجديدة أو المعقدة، وعندما تريد قياس قابلية الاستخدام الفعلية لا الامتثال التقني فقط.