اسکرین ریڈر: یہ کیا ہے، اسکرین ریڈر کی اقسام اور کام کا اصول

اسکرین ریڈر کیا ہے؟

اسکرین ریڈر (Screen Reader) ایک معاون ٹیکنالوجی (Assistive Technology, AT) ہے جو گرافیکل یوزر انٹرفیس کی تشریح کرتی ہے اور اسے غیر بصری شکل میں پیش کرتی ہے: مصنوعی تقریر یا سپرش بریل ڈسپلے کے ذریعے۔ اسکرین ریڈرز مکمل یا جزوی بینائی کھو دینے والوں کے لیے کمپیوٹر اور موبائل ڈیوائسز تک رسائی کا بنیادی ذریعہ ہیں۔

پہلے اسکرین ریڈرز 1980 کی دہائی کے آخر میں MS-DOS کے لیے (مثلاً Vocal-Eyes) اور بعد میں Windows کے لیے (JAWS, NVDA) ظاہر ہوئے۔ موبائل پلیٹ فارمز پر، اسکرین ریڈرز سسٹم کی سطح پر ضم ہو گئے: Apple نے 2009 میں iPhone 3GS میں VoiceOver کو ضم کیا، Google نے اسی سال Android 1.6 میں TalkBack کو ضم کیا۔ 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 کے درمیان چلتا ہے — لمبی صفحات اور دستاویزات پر موثر نیویگیشن کے لیے یہ ضروری ہے۔ حرف موڈ تصدیقی کوڈز یا پیچیدہ پاس ورڈز داخل کرتے وقت مدد کرتا ہے، ہر حرف کو الگ الگ تلفظ کرتا ہے۔

موبائل پلیٹ فارمز کے لیے اہم اسکرین ریڈرز

دو اسکرین ریڈرز موبائل پلیٹ فارمز پر حاوی ہیں: iOS پر VoiceOver اور Android پر TalkBack۔ ان کے مختلف API، اشارے اور صلاحیتیں ہیں، لیکن مشترکہ اصول رسائی کے درخت کو پڑھنا اور اشاروں کا کنٹرول ہے۔

VoiceOver (iOS)

VoiceOver Apple کا اسکرین ریڈر ہے، جو iOS، iPadOS اور macOS میں بلٹ ہے۔ یہ عناصر کے بارے میں معلومات حاصل کرنے کے لیے UIAccessibility API استعمال کرتا ہے اور نیویگیشن موڈز تبدیل کرنے کے لیے روٹر کو سپورٹ کرتا ہے۔ 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-shaped سوائپ کے ذریعے گلوبل مینو، عناصر کے لیے کسٹم ایکشنز اور ڈائنامک اپ ڈیٹس کے لیے LiveRegion کو سپورٹ کرتا ہے۔ Android 14 سے شروع کرتے ہوئے، TalkBack نے ایک ہاتھ کے اشاروں کی سپورٹ اور Google Assistant کے ساتھ بہتر انضمام حاصل کیا۔

TalkBack کا VoiceOver سے زیادہ لچکدار اشاروں کا نظام ہے: صارف تقریباً کسی بھی اشارے کو کسی بھی عمل کے لیے تفویض کر سکتا ہے۔ TalkBack آن اسکرین بریل ان پٹ (BrailleBack) کو بھی سپورٹ کرتا ہے — صارف فی انگلی خاص 3×2 لے آؤٹ میں ٹچ اسکرین پر براہ راست بریل حروف کے ساتھ ٹیکسٹ داخل کرتا ہے، جو آن اسکرین کی بورڈ کے مقابلے میں ٹیکسٹ انٹری کو نمایاں طور پر تیز کرتا ہے۔

VoiceOver اور TalkBack کے علاوہ، کم عام موبائل اسکرین ریڈرز بھی ہیں: Select to Speak (Android، منتخب کردہ علاقہ بولتا ہے)، Samsung Voice Assistant (One UI کے ساتھ Samsung آلات پر TalkBack کو تبدیل کرتا ہے) اور مخصوص شعبوں کے لیے تھرڈ پارٹی حل — مثال کے طور پر، Google خدمات کے بغیر چینی اسمارٹ فون صارفین کے لیے۔

اسکرین ریڈر ایپ کے ساتھ کیسے تعامل کرتا ہے

اسکرین ریڈر کی ایپ کے UI اجزاء تک براہ راست رسائی نہیں ہے۔ اس کے بجائے، یہ ایک پرت — آپریٹنگ سسٹم کی رسائی API — کے ذریعے کام کرتا ہے۔ آپریٹنگ سسٹم ایک رسائی کا درخت (Accessibility Tree) بناتا ہے جسے اسکرین ریڈر ٹراورس اور تجزیہ کرتا ہے۔

iOS اور Android پر رسائی کا درخت

iOS پر، رسائی کا درخت اسکرین پر موجود ہر View کے مطابق UIAccessibilityElement اشیاء سے بنایا جاتا ہے۔ ہر عنصر میں label (بنیادی ٹیکسٹ)، traits (عنصر کی قسم: بٹن، عنوان، لنک)، hint (ٹول ٹپ)، value (سلائیڈرز اور اشارے کی موجودہ قیمت) اور frame (ٹچ ایریا) ہوتا ہے۔ سسٹم معیاری UI اجزاء کے لیے خود بخود عناصر بناتا ہے، لیکن ڈیولپر انہیں شامل اور کسٹمائز کر سکتا ہے۔

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 میں، contentDescription، stateDescription اور customActions کے ساتھ .semantics {} موڈیفائر استعمال کریں۔ غیر انٹرایکٹو عناصر پر focusable = true سیٹ کرنے سے گریز کریں — یہ TalkBack کے لیے جھوٹے فوکس پوائنٹس بناتا ہے اور صارف کو الجھاتا ہے۔

ٹیسٹنگ ٹولز

اسکرین ریڈر کے ساتھ ٹیسٹنگ فزیکل ڈیوائس پر کی جانی چاہیے۔ ایک ایمولیٹر/سیمولیٹر بنیادی سمجھ فراہم کرتا ہے، لیکن اشارے اور ردعمل کی رفتار مختلف ہوتی ہے۔ iOS کے لیے Accessibility Inspector (Xcode) اور خودکار مسئلہ کا پتہ لگانے کے لیے Android میں Accessibility Scanner استعمال کریں۔

اہم ٹیسٹنگ منظرنامے: رجسٹریشن (فارم بھرنا، توثیق، جمع کروانا)، تلاش اور کیٹلاگ نیویگیشن، چیک آؤٹ، پاس ورڈ کی بازیابی۔ ہر منظرنامہ بصری کنٹرول کے بغیر — صرف اسکرین ریڈر کے صوتی اشاروں کے ذریعے — مکمل ہونے کے قابل ہونا چاہیے۔ اگر اسکرین ریڈر صارف کسی منظرنامے کو عام صارف کے برابر وقت (±50%) میں مکمل نہیں کر سکتا، تو ایپ کو رسائی میں بہتری کی ضرورت ہے۔