قارئ الشاشة: ما هو، أنواعه ومبدأ عمله

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

قارئ الشاشة (Screen Reader) هو تقنية مساعدة (Assistive Technology, AT) تفسر واجهة المستخدم الرسومية وتعرضها بشكل غير بصري: عبر كلام مركب أو شاشة برايل لمسية. قارئات الشاشة هي الوسيلة الرئيسية للوصول إلى أجهزة الكمبيوتر والأجهزة المحمولة للأشخاص الذين يعانون من فقدان البصر الكلي أو الجزئي.

ظهرت أول قارئات الشاشة في أواخر الثمانينيات لنظام MS-DOS (مثل Vocal-Eyes) ولاحقًا لنظام Windows (JAWS, NVDA). على المنصات المحمولة، أصبحت قارئات الشاشة مدمجة على مستوى النظام: أدمجت Apple VoiceOver في iPhone 3GS في عام 2009، وأدمجت Google TalkBack في Android 1.6 في نفس العام. بحلول عام 2025، تمتلك جميع الهواتف الذكية الحديثة تقريبًا قارئ شاشة مدمجًا لا يتطلب تثبيت برامج إضافية.

قارئ الشاشة لا يقرأ النص من الشاشة فقط — بل يحلل تسلسل الواجهة، ويحدد أنواع العناصر (زر، رابط، عنوان، حقل إدخال)، وحالاتها (مفعل/معطل، محدد/غير محدد) والعلاقات (أصل-فرع، مجموعة). تنتقل هذه المعلومات إلى المستخدم عبر تلميحات صوتية أو أحاسيس لمسية من شاشة برايل، التي تحدث الخلايا في الوقت الفعلي وفقًا لموضع البؤرة.

كيف يعمل قارئ الشاشة؟

يعمل قارئ الشاشة بشكل وثيق مع نظام التشغيل، ليحصل على تمثيله الداخلي للواجهة — شجرة إمكانية الوصول (Accessibility Tree). هذه الآلية نفسها على iOS وAndroid، على الرغم من اختلاف أسماء API.

تحويل النص إلى كلام (TTS)

القناة الرئيسية لإخراج قارئ الشاشة هي مركب الكلام (Text-To-Speech, TTS). عندما تقع بؤرة إمكانية الوصول على عنصر، يستخرج قارئ الشاشة محتواه النصي (أو الوصف الذي قدمه المطور) ويرسله إلى محرك TTS. تستخدم محركات TTS الحديثة، مثل Apple Speech Synthesis وGoogle Text-to-Speech، الشبكات العصبية لتوليد كلام طبيعي مع نبرة صحيحة وتوقفات وتشديد وفقًا لعلامات الترقيم ونوع المحتوى.

يمكن للمستخدم ضبط سرعة الكلام (عادة 60–80% من الحد الأقصى للإدراك المريح)، ودرجة الصوت ومستوى الصوت. تدعم بعض قارئات الشاشة أصواتًا متعددة والتبديل بينها حسب نوع المحتوى — على سبيل المثال، صوت أبطأ لقراءة النص وصوت أسرع للتنقل في الواجهة. شاشات برايل تتصل عبر Bluetooth وتعرض حتى 40–80 حرفًا في المرة الواحدة، مع تحديث السطر مع كل تغيير في البؤرة.

إدارة البؤرة والتنقل

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

يدعم قارئ الشاشة أيضًا أوضاع تنقل مختلفة يبدلها المستخدم عبر العجلة (VoiceOver) أو القائمة (TalkBack): حسب العناوين، الروابط، الأحرف، الكلمات، النماذج. في وضع العناوين، يتحرك قارئ الشاشة فقط بين H1–H6 — وهذا أمر بالغ الأهمية للتنقل الفعال عبر الصفحات والمستندات الطويلة. وضع الأحرف يساعد عند إدخال رموز التأكيد أو كلمات المرور المعقدة، بنطق كل حرف على حدة.

قارئات الشاشة الرئيسية للمنصات المحمولة

تهيمن قارئتا شاشة على المنصات المحمولة: VoiceOver على iOS وTalkBack على Android. لديهما API وإيماءات وإمكانيات مختلفة، لكن المبدأ المشترك هو قراءة شجرة إمكانية الوصول والتحكم بالإيماءات.

VoiceOver (iOS)

VoiceOver هو قارئ شاشة من Apple، مدمج في iOS وiPadOS وmacOS. يستخدم API UIAccessibility للحصول على معلومات حول العناصر ويدعم العجلة لتبديل أوضاع التنقل. VoiceOver متكامل مع iCloud (تتزامن الإعدادات عبر الأجهزة)، وApple Pay (تأكيد الدفع عبر Touch ID أو Face ID)، والنص الديناميكي (يتكيف الخط مع إعدادات المستخدم).

تختلف إيماءات VoiceOver عن TalkBack: يستخدم الدوران بإصبعين (العجلة)، والنقر الثلاثي لشاشة Screen Curtain والنقر المزدوج بإصبعين لإلغاء إجراء. يدعم VoiceOver عجلات مخصصة يضيفها المطور عبر UIAccessibilityCustomRotor — على سبيل المثال، للتنقل السريع بين أقسام التطبيق متجاوزًا الترتيب القياسي.

TalkBack (Android)

TalkBack هو قارئ شاشة من Google، جزء من Android Accessibility Suite. يستخدم AccessibilityService وAccessibilityNodeInfo للوصول إلى الواجهة. يدعم TalkBack قائمة عامة عبر تمرير على شكل L، وإجراءات مخصصة للعناصر وLiveRegion للتحديثات الديناميكية. بدءًا من Android 14، حصل TalkBack على دعم إيماءات بيد واحدة وتحسين التكامل مع Google Assistant.

يمتلك TalkBack نظام إيماءات أكثر مرونة من VoiceOver: يمكن للمستخدم تعيين أي إيماءة تقريبًا لأي إجراء. يدعم TalkBack أيضًا إدخال برايل على الشاشة (BrailleBack) — يدخل المستخدم النص بأحرف برايل مباشرة على الشاشة اللمسية في تخطيط خاص 3×2 لكل إصبع، مما يسرع إدخال النص بشكل كبير مقارنة بلوحة المفاتيح على الشاشة.

إلى جانب VoiceOver وTalkBack، توجد قارئات شاشة محمولة أقل شيوعًا: Select to Speak (Android، ينطق المنطقة المحددة)، وSamsung Voice Assistant (يستبدل TalkBack على أجهزة Samsung مع One UI) وحلول طرف ثالث لقطاعات محددة — على سبيل المثال، لمستخدمي الهواتف الذكية الصينية بدون خدمات Google.

كيف يتفاعل قارئ الشاشة مع التطبيق

قارئ الشاشة لا يملك وصولًا مباشرًا إلى مكونات واجهة التطبيق. بدلاً من ذلك، يعمل عبر طبقة — API إمكانية الوصول لنظام التشغيل. يبني نظام التشغيل شجرة إمكانية الوصول (Accessibility Tree) التي يجتازها قارئ الشاشة ويحللها.

شجرة إمكانية الوصول على iOS وAndroid

على iOS، تُبنى شجرة إمكانية الوصول من كائنات UIAccessibilityElement المقابلة لكل View على الشاشة. يحتوي كل عنصر على label (النص الرئيسي)، وtraits (نوع العنصر: زر، عنوان، رابط)، وhint (تلميح)، وvalue (القيمة الحالية للمنزلقات والمؤشرات)، وframe (منطقة اللمس). ينشئ النظام تلقائيًا عناصر للمكونات القياسية للواجهة، لكن يمكن للمطور إضافتها وتخصيصها.

على Android، تُبنى شجرة إمكانية الوصول من كائنات AccessibilityNodeInfo. تحتوي كل عقدة على: text (نص أو contentDescription)، وclassName (نوع العنصر)، وcontentDescription (وصف)، وstateDescription (حالة)، وisEnabled، وisChecked، وisClickable وعلامات أخرى. يدعم Android أيضًا AccessibilityAction — قائمة إجراءات يمكن لقارئ الشاشة تنفيذها نيابة عن المستخدم: نقر، ضغط مطول، تمرير، تعيين بؤرة، تعيين نص.

أحداث إمكانية الوصول

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

// الاستماع إلى أحداث إمكانية الوصول على Android
class CustomAccessibilityService : AccessibilityService() {
    override fun onAccessibilityEvent(event: AccessibilityEvent?) {
        event ?: return
        when (event.eventType) {
            TYPE_VIEW_CLICKED ->
                handleClick(event)
            TYPE_WINDOW_STATE_CHANGED ->
                handleWindowChange(event)
            TYPE_VIEW_TEXT_CHANGED ->
                handleTextChange(event)
        }
    }
}

على iOS، تُعالج الأحداث المماثلة عبر UIAccessibility.Notification: layoutChanged (تغير التخطيط)، screenChanged (شاشة جديدة كليًا)، announcement (إعلان مخصص)، pageScrolled (تمرير الصفحة). يرسل المطور هذه الأحداث عبر UIAccessibility.post لكي يستجيب قارئ الشاشة بشكل صحيح للتغييرات. على سبيل المثال، عند فتح نافذة مشروطة، يجب إرسال screenChanged مع العنوان الجديد — وإلا سيبقى VoiceOver على العنصر السابق أسفل النافذة.

تطوير التطبيقات لقارئ الشاشة

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

القواعد الأساسية لإمكانية الوصول

يجب أن تحتوي جميع العناصر التفاعلية على وصف ذي معنى: يجب وصف زر “إرسال” كـ “إرسال رسالة”، وليس فقط “زر”. يجب إخفاء العناصر الزخرفية (الفواصل، صور الخلفية، الأيقونات غير الوظيفية) عن قارئ الشاشة. ترتيب التنقل يجب أن يتبع التدفق المنطقي للشاشة، وليس التخطيط البصري. يجب أن يكون تباين النص 4.5:1 على الأقل للنص العادي و3:1 للنص الكبير (WCAG AA).

// iOS: التكوين الصحيح لعنصر معقد
let customControl = UIControl()
customControl.isAccessibilityElement = true
customControl.accessibilityLabel = "مستوى الصوت"
customControl.accessibilityValue = "75 بالمئة"
customControl.accessibilityTraits = [
    .adjustable,
    .button
]
customControl.accessibilityHint =
    "يزيد أو يخفض مستوى الصوت"

// تحديث عند تغيير القيمة
func didChangeVolume(newValue: Float) {
    customControl.accessibilityValue =
        "\(Int(newValue)) بالمئة"
    UIAccessibility.post(
        notification: .layoutChanged,
        argument: customControl
    )
}

على iOS، العلامة isAccessibilityElement تُفعّل دعم VoiceOver للعناصر المخصصة. مجموعة traits (.adjustable + .button) تخبر VoiceOver أن العنصر يمكن ضبطه بالتمرير لأعلى/لأسفل وتفعيله بنقر مزدوج. بعد تغيير القيمة، يجب إرسال إشعار layoutChanged — وإلا سيستمر VoiceOver في الإعلان عن القيمة القديمة.

توصيات خاصة بكل منصة

لنظام iOS: استخدم accessibilityElements لتجاوز ترتيب القراءة، وaccessibilityCustomActions لإجراءات إضافية في القائمة السياقية، وshouldGroupAccessibilityChildren لتجميع العناصر في مجموعات منطقية. لـ SwiftUI، استخدم المعدّلات .accessibilityLabel() و.accessibilityAddTraits() و.accessibilityRespondsToUserInteraction(). تجنب تعيين isAccessibilityElement = false على الحاويات التي تحتوي على عناصر فرعية تفاعلية — فهذا سيخفيها عن VoiceOver.

لنظام Android: استخدم accessibilityTraversalBefore وaccessibilityTraversalAfter لترتيب التنقل، وAccessibilityDelegate للعناصر المخصصة وLiveRegion (polite/assertive) للتحديثات الديناميكية. في Compose، استخدم المُعدِّل .semantics {} مع contentDescription وstateDescription وcustomActions. تجنب تعيين focusable = true على العناصر غير التفاعلية — فهذا ينشئ نقاط بؤرة زائفة لـ TalkBack ويُربك المستخدم.

أدوات الاختبار

يجب إجراء الاختبار مع قارئ الشاشة على جهاز فعلي. يوفر المحاكي فهمًا أساسيًا، لكن الإيماءات وسرعة الاستجابة تختلف. استخدم Accessibility Inspector (Xcode) لنظام iOS وAccessibility Scanner (Android) للكشف التلقائي عن المشكلات.

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