Screen Reader: какво е това, видове екранни четци и принцип на работа

Какво е Screen Reader?

Screen Reader (екранен четец) — е асистивна технология (Assistive Technology, AT), която интерпретира графичния потребителски интерфейс и го представя в невизуална форма: чрез синтезирана реч или тактилен брайлов дисплей. Екранните четци са основното средство за достъп до компютри и мобилни устройства за хора с пълна или частична загуба на зрение.

Първите екранни четци се появяват в края на 80-те години за MS-DOS (напр. Vocal-Eyes) и по-късно за Windows (JAWS, NVDA). На мобилни платформи екранните четци започват да се вграждат на системно ниво: Apple интегрира VoiceOver в iPhone 3GS през 2009 г., Google интегрира TalkBack в Android 1.6 през същата година. До 2025 г. почти всички съвременни смартфони имат вграден екранен четец, който не изисква инсталиране на допълнителен софтуер.

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 използват невронни мрежи за генериране на естествена реч с правилна интонация, паузи и акценти в зависимост от пунктуацията и типа съдържание.

Потребителят може да настрои скоростта на речта (обикновено 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.

Как 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, за да може екранният четец да реагира правилно на промените. Например при отваряне на модален прозорец трябва да се изпрати screenChanged с новото заглавие — в противен случай VoiceOver ще остане върху предишния елемент под прозореца.

Разработка на приложения с оглед на Screen Reader

Създаването на достъпно приложение не е просто добавяне на 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%), — приложението изисква подобрение на достъпността.