Screen Reader: چیست، انواع صفحه‌خوان‌ها و اصول کار

Screen Reader چیست؟

Screen Reader (صفحه‌خوان) — یک فناوری کمکی (Assistive Technology, AT) است که رابط گرافیکی کاربر را تفسیر کرده و آن را به شکل غیربصری ارائه می‌دهد: از طریق گفتار مصنوعی یا نمایشگر بریل لمسی. صفحه‌خوان‌ها ابزار اصلی دسترسی به رایانه‌ها و دستگاه‌های موبایل برای افراد با از دست دادن کامل یا جزئی بینایی هستند.

اولین صفحه‌خوان‌ها در اواخر دهه ۱۹۸۰ برای MS-DOS (مثلاً Vocal-Eyes) و بعداً برای Windows (JAWS، NVDA) ظهور کردند. در پلتفرم‌های موبایل، صفحه‌خوان‌ها در سطح سیستم تعبیه شدند: Apple VoiceOver را در iPhone 3GS در سال ۲۰۰۹، Google TalkBack را در Android 1.6 در همان سال یکپارچه کرد. تا سال ۲۰۲۵، تقریباً همه گوشی‌های هوشمند مدرن دارای صفحه‌خوان داخلی هستند که نیاز به نصب نرم‌افزار اضافی ندارد.

Screen Reader نه تنها متن را از صفحه می‌خواند — بلکه سلسله‌مراتب رابط را تحلیل می‌کند، انواع عناصر (دکمه، پیوند، عنوان، فیلد ورودی)، وضعیت آنها (فعال/غیرفعال، انتخاب‌شده/انتخاب‌نشده) و روابط متقابل (والد-فرزند، گروه) را تعیین می‌کند. این اطلاعات از طریق راهنماهای صوتی یا حس‌های لمسی نمایشگر بریل که سلول‌ها را در زمان واقعی با توجه به موقعیت فوکوس به‌روزرسانی می‌کند به کاربر منتقل می‌شود.

Screen Reader چگونه کار می‌کند؟

Screen Reader در ارتباط نزدیک با سیستم عامل کار می‌کند و به نمایش داخلی رابط آن — درخت دسترسی (Accessibility Tree) — دسترسی پیدا می‌کند. این مکانیزم در iOS و Android یکسان است، اگرچه نام APIها متفاوت است.

تبدیل متن به گفتار (TTS)

کانال خروجی اصلی صفحه‌خوان، سنتزکننده گفتار (Text-To-Speech, TTS) است. وقتی فوکوس دسترسی به عنصری می‌رسد، صفحه‌خوان محتوای متنی آن (یا توضیح تعیین‌شده توسط توسعه‌دهنده) را استخراج کرده و به موتور TTS می‌فرستد. موتورهای TTS مدرن مانند Apple Speech Synthesis و Google Text-to-Speech از شبکه‌های عصبی برای تولید گفتار طبیعی با لحن، مکث و تأکید صحیح بسته به علائم نگارشی و نوع محتوا استفاده می‌کنند.

کاربر می‌تواند سرعت گفتار (معمولاً ۶۰–۸۰٪ حداکثر برای درک راحت)، زیروبمی صدا و بلندی صدا را تنظیم کند. برخی صفحه‌خوان‌ها چندین صدا و تغییر بین آنها را بسته به نوع محتوا پشتیبانی می‌کنند — مثلاً صدای آهسته‌تر برای خواندن متن و صدای سریع برای ناوبری در رابط. نمایشگرهای بریل از طریق Bluetooth متصل می‌شوند و همزمان ۴۰–۸۰ کاراکتر را نمایش می‌دهند و خط را با هر تغییر فوکوس به‌روزرسانی می‌کنند.

کنترل فوکوس و ناوبری

صفحه‌خوان از مفهوم فوکوس دسترسی (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-shaped، اقدامات سفارشی برای عناصر و LiveRegion برای به‌روزرسانی‌های پویا پشتیبانی می‌کند. از Android 14، TalkBack پشتیبانی از حرکات یک‌دستی و یکپارچگی بهبودیافته با Google Assistant را دریافت کرد.

TalkBack سیستم حرکتی انعطاف‌پذیرتری نسبت به VoiceOver دارد: کاربر می‌تواند تقریباً هر حرکتی را به هر عملی اختصاص دهد. TalkBack همچنین از ورود بریل روی صفحه (BrailleBack) پشتیبانی می‌کند — کاربر متن را با نویسه‌های بریل مستقیماً روی صفحه لمسی در چیدمان ویژه ۳×۲ برای هر انگشت وارد می‌کند که سرعت تایپ را در مقایسه با صفحه‌کلید لمسی به طور قابل توجهی افزایش می‌دهد.

علاوه بر VoiceOver و TalkBack، صفحه‌خوان‌های موبایل کمتر رایج دیگری نیز وجود دارند: Select to Speak (Android، اعلام ناحیه انتخاب‌شده)، Samsung Voice Assistant (جایگزین TalkBack در دستگاه‌های Samsung با One UI) و راه‌حل‌های شخص ثالث برای حوزه‌های خاص — مثلاً برای کاربران گوشی‌های چینی بدون سرویس‌های Google.

Screen Reader چگونه با برنامه تعامل دارد

Screen Reader دسترسی مستقیم به مؤلفه‌های UI برنامه ندارد. در عوض، از طریق یک لایه واسطه — API دسترسی سیستم عامل — کار می‌کند. سیستم عامل درخت دسترسی (Accessibility Tree) را می‌سازد که صفحه‌خوان آن را پیمایش و تحلیل می‌کند.

Accessibility Tree در iOS و Android

در iOS، درخت دسترسی از اشیاء UIAccessibilityElement ساخته می‌شود که با هر View روی صفحه مطابقت دارد. هر عنصر شامل label (متن اصلی)، traits (نوع عنصر: دکمه، عنوان، پیوند)، hint (راهنما)، value (مقدار فعلی برای لغزنده‌ها و نشانگرها) و frame (ناحیه لمس) است. سیستم به طور خودکار برای مؤلفه‌های استاندارد UI عناصر ایجاد می‌کند، اما توسعه‌دهنده می‌تواند آنها را اضافه و تنظیم کند.

در Android، درخت دسترسی از اشیاء AccessibilityNodeInfo ساخته می‌شود. هر گره شامل: text (متن یا contentDescription)، className (نوع عنصر)، contentDescription (توضیح)، stateDescription (وضعیت)، isEnabled، isChecked، isClickable و سایر پرچم‌ها است. Android همچنین از AccessibilityAction پشتیبانی می‌کند — لیست اقداماتی که صفحه‌خوان می‌تواند از طرف کاربر انجام دهد: کلیک، فشار طولانی، پیمایش، تنظیم فوکوس، تنظیم متن.

رویدادهای دسترسی (Accessibility Events)

وقتی تغییری در رابط رخ می‌دهد (عنصر جدیدی ظاهر شد، متن تغییر کرد، عنصر قابل مشاهده یا غیرقابل مشاهده شد)، سیستم عامل 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 ارسال می‌کند تا صفحه‌خوان به درستی به تغییرات واکنش نشان دهد. مثلاً هنگام باز شدن پنجره modal، باید screenChanged با عنوان جدید ارسال شود — در غیر این صورت VoiceOver روی عنصر قبلی زیر پنجره باقی می‌ماند.

توسعه برنامه‌ها با در نظر گرفتن Screen Reader

ایجاد یک برنامه قابل دسترس — این فقط اضافه کردن contentDescription به هر عنصر نیست، بلکه طراحی تجربه کاربری برای تعامل غیربصری است. قوانین پایه برای هر دو پلتفرم مشترک است، اگرچه پیاده‌سازی متفاوت است.

قوانین پایه دسترسی

همه عناصر تعاملی باید توضیح معنادار داشته باشند: دکمه «ارسال» باید به عنوان «ارسال پیام» توضیح داده شود، نه «دکمه». عناصر تزئینی (جداکننده‌ها، تصاویر پس‌زمینه، آیکون‌های بدون کارایی) باید از صفحه‌خوان پنهان شوند. ترتیب ناوبری باید با جریان منطقی صفحه مطابقت داشته باشد، نه چیدمان بصری. کنتراست متن باید حداقل ۴.۵:۱ برای متن اصلی و ۳:۱ برای متن بزرگ (WCAG AA) باشد.

// iOS: پیکربندی صحیح برای عنصر پیچیده
let customControl = UIControl()
customControl.isAccessibilityElement = true
customControl.accessibilityLabel = "بلندی صدا"
customControl.accessibilityValue = "۷۵ درصد"
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 برای جستجوی خودکار مشکلات استفاده کنید.

سناریوهای اصلی تست: ثبت‌نام (پر کردن فرم، اعتبارسنجی، ارسال)، جستجو و ناوبری در کاتالوگ، ثبت سفارش، بازیابی رمز عبور. هر سناریو باید بدون کنترل بصری — فقط از طریق راهنماهای صوتی صفحه‌خوان — قابل انجام باشد. اگر کاربر صفحه‌خوان نمی‌تواند سناریو را در همان زمان کاربر معمولی (±۵۰٪) کامل کند — برنامه نیاز به بهبود دسترسی دارد.