Screen Reader: ano ito, mga uri ng screen reader at prinsipyo ng paggana

Ano ang Screen Reader?

Screen Reader (tagabasa ng screen) — ay isang asistibong teknolohiya (Assistive Technology, AT) na nag-iinterpret ng graphical user interface at nagpapakita nito sa hindi-visual na anyo: sa pamamagitan ng synthesized na pagsasalita o tactile braille display. Ang mga screen reader ay ang pangunahing paraan ng pag-access sa mga computer at mobile device para sa mga taong may kumpleto o bahagyang pagkawala ng paningin.

Ang mga unang screen reader ay lumitaw noong huling bahagi ng 1980s para sa MS-DOS (halimbawa, Vocal-Eyes) at kalaunan para sa Windows (JAWS, NVDA). Sa mga mobile platform, ang mga screen reader ay nagsimulang i-embed sa antas ng system: Isinama ng Apple ang VoiceOver sa iPhone 3GS noong 2009, isinama ng Google ang TalkBack sa Android 1.6 sa parehong taon. Pagsapit ng 2025, halos lahat ng modernong smartphone ay may naka-embed na screen reader na hindi nangangailangan ng pag-install ng karagdagang software.

Ang Screen Reader ay hindi lamang nagbabasa ng teksto mula sa screen — sinusuri nito ang hierarchy ng interface, tinutukoy ang mga uri ng elemento (button, link, heading, input field), ang kanilang estado (naka-enable/naka-disable, napili/hindi napili) at mga ugnayan (magulang-anak, grupo). Ang impormasyong ito ay ipinapadala sa gumagamit sa pamamagitan ng mga voice prompt o tactile sensations ng braille display, na nag-a-update ng mga cell sa real-time ayon sa posisyon ng pokus.

Paano gumagana ang Screen Reader?

Ang Screen Reader ay gumagana nang malapit sa operating system, na may access sa panloob na representasyon nito ng interface — ang puno ng aksesibilidad (Accessibility Tree). Ang mekanismong ito ay pareho sa iOS at Android, kahit na magkaiba ang mga pangalan ng API.

Pag-convert ng teksto sa pagsasalita (TTS)

Ang pangunahing channel ng output ng screen reader ay ang speech synthesizer (Text-To-Speech, TTS). Kapag ang pokus ng aksesibilidad ay dumating sa isang elemento, kinukuha ng screen reader ang tekstuwal na nilalaman nito (o paglalarawan na itinakda ng developer) at ipinapadala ito sa TTS engine. Ang mga modernong TTS engine tulad ng Apple Speech Synthesis at Google Text-to-Speech ay gumagamit ng neural network upang makabuo ng natural na pagsasalita na may tamang intonasyon, paghinto at accent depende sa bantas at uri ng nilalaman.

Maaaring ayusin ng gumagamit ang bilis ng pagsasalita (karaniwang 60-80% ng maximum para sa komportableng pandinig), taas ng tono at volume. Ang ilang screen reader ay sumusuporta sa maraming boses at paglipat sa pagitan ng mga ito depende sa uri ng nilalaman — halimbawa, mas mabagal na boses para sa pagbabasa ng teksto at mabilis na boses para sa nabigasyon sa interface. Ang mga braille display ay kumokonekta sa pamamagitan ng Bluetooth at nagpapakita ng 40-80 character nang sabay-sabay, ina-update ang linya sa bawat pagbabago ng pokus.

Kontrol ng pokus at nabigasyon

Gumagamit ang screen reader ng konsepto ng pokus ng aksesibilidad (Accessibility Focus), na naiiba mula sa standard na pokus ng input. Inililipat ng gumagamit ang pokus ng aksesibilidad gamit ang mga kilos (touch, swipe), at binibigkas ng screen reader ang elemento sa ilalim ng pokus. Ang pagkakasunod-sunod ng nabigasyon ay sumusunod sa visual na pagkakasunod-sunod: mula kaliwa pakanan, mula itaas pababa. Maaaring i-override ng developer ang pagkakasunod-sunod na ito para sa mga kumplikadong layout.

Sinusuportahan din ng screen reader ang iba't ibang mga mode ng nabigasyon, na pinapalitan ng gumagamit sa pamamagitan ng rotor (VoiceOver) o menu (TalkBack): ayon sa mga heading, link, character, salita, form. Sa mode ng heading, gumagalaw lamang ang screen reader sa pagitan ng H1-H6 — ito ay kritikal para sa mahusay na nabigasyon sa mahabang pahina at dokumento. Ang mode ng character ay tumutulong sa pagpasok ng mga confirmation code o kumplikadong password, binibigkas ang bawat character nang hiwalay.

Mga pangunahing screen reader para sa mobile platform

Sa mga mobile platform, dalawang screen reader ang nangingibabaw: VoiceOver sa iOS at TalkBack sa Android. Mayroon silang iba't ibang API, kilos at kakayahan, ngunit parehong prinsipyo ng paggana — pagbabasa ng puno ng aksesibilidad at kontrol sa pamamagitan ng mga kilos.

VoiceOver (iOS)

VoiceOver — screen reader mula sa Apple, naka-embed sa iOS, iPadOS at macOS. Ginagamit nito ang UIAccessibility API upang makakuha ng impormasyon tungkol sa mga elemento at sinusuportahan ang rotor para sa pagpapalit ng mga mode ng nabigasyon. Ang VoiceOver ay isinama sa iCloud (nagsi-sync ang mga setting sa pagitan ng mga device), Apple Pay (kumpirmasyon ng pagbabayad sa pamamagitan ng Touch ID o Face ID) at dynamic na teksto (angkop ang font sa mga setting ng gumagamit).

Ang mga kilos ng VoiceOver ay naiiba mula sa TalkBack: gumagamit ng pag-ikot ng dalawang daliri (rotor), triple touch para sa Screen Curtain at double touch gamit ang dalawang daliri para kanselahin ang aksyon. Sinusuportahan ng VoiceOver ang mga custom na rotor, na idinaragdag ng developer sa pamamagitan ng UIAccessibilityCustomRotor — halimbawa, para sa mabilis na nabigasyon sa mga seksyon ng app na lumalampas sa standard na pagkakasunod-sunod.

TalkBack (Android)

TalkBack — screen reader mula sa Google, bahagi ng Android Accessibility Suite. Ginagamit nito ang AccessibilityService at AccessibilityNodeInfo upang ma-access ang interface. Sinusuportahan ng TalkBack ang global na menu sa pamamagitan ng L-shaped swipe, custom na aksyon para sa mga elemento at LiveRegion para sa dynamic na pag-update. Simula sa Android 14, nakatanggap ang TalkBack ng suporta para sa isang kamay na kilos at pinahusay na integrasyon sa Google Assistant.

Ang TalkBack ay may mas nababaluktot na sistema ng kilos kaysa VoiceOver: maaaring i-configure ng gumagamit ang halos anumang kilos para sa anumang aksyon. Sinusuportahan din ng TalkBack ang braille input sa screen (BrailleBack) — naglalagay ang gumagamit ng teksto gamit ang braille character nang direkta sa touch screen sa isang espesyal na 3×2 layout para sa bawat daliri, na makabuluhang nagpapabilis ng pag-type kumpara sa screen keyboard.

Bukod sa VoiceOver at TalkBack, mayroong hindi gaanong karaniwang mobile screen reader: Select to Speak (Android, pagbigkas ng napiling lugar), Samsung Voice Assistant (kapalit ng TalkBack sa Samsung device na may One UI) at third-party na solusyon para sa mga tiyak na niche — halimbawa, para sa mga gumagamit ng Chinese smartphone na walang serbisyo ng Google.

Paano nakikipag-ugnayan ang Screen Reader sa app

Ang Screen Reader ay walang direktang access sa UI components ng app. Sa halip, gumagana ito sa pamamagitan ng isang intermediate layer — ang accessibility API ng operating system. Binubuo ng operating system ang puno ng aksesibilidad (Accessibility Tree), na tinatahak at sinusuri ng screen reader.

Accessibility Tree sa iOS at Android

Sa iOS, ang puno ng aksesibilidad ay binuo mula sa mga bagay na UIAccessibilityElement, na tumutugma sa bawat View sa screen. Ang bawat elemento ay naglalaman ng label (pangunahing teksto), traits (uri ng elemento: button, heading, link), hint (pahiwatig), value (kasalukuyang halaga para sa mga slider at indicator) at frame (lugar ng pagpindot). Awtomatikong lumilikha ang system ng mga elemento para sa standard na UI components, ngunit maaaring magdagdag at mag-configure ang developer ng mga ito.

Sa Android, ang puno ng aksesibilidad ay binuo mula sa mga bagay na AccessibilityNodeInfo. Ang bawat node ay naglalaman ng: text (teksto o contentDescription), className (uri ng elemento), contentDescription (paglalarawan), stateDescription (estado), isEnabled, isChecked, isClickable at iba pang mga flag. Sinusuportahan din ng Android ang AccessibilityAction — listahan ng mga aksyon na maaaring gawin ng screen reader sa ngalan ng gumagamit: click, long press, scroll, itakda ang pokus, itakda ang teksto.

Mga kaganapan sa aksesibilidad (Accessibility Events)

Kapag may pagbabago sa interface (lumitaw ang bagong elemento, nagbago ang teksto, naging nakikita o hindi nakikita ang elemento), nagpapadala ang operating system ng AccessibilityEvent. Ang screen reader ay naka-subscribe sa mga kaganapang ito at tumutugon sa mga ito: halimbawa, kapag lumitaw ang isang dialog box, awtomatikong inililipat ng screen reader ang pokus sa heading nito at binibigkas ang nilalaman.

// Pakikinig sa mga kaganapan ng aksesibilidad sa 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)
        }
    }
}

Sa iOS, ang mga katulad na kaganapan ay pinoproseso sa pamamagitan ng UIAccessibility.Notification: layoutChanged (nagbago ang layout), screenChanged (ganap na bagong screen), announcement (anumang anunsyo), pageScrolled (pag-scroll ng pahina). Ipinapadala ng developer ang mga kaganapang ito sa pamamagitan ng UIAccessibility.post upang ang screen reader ay tumugon nang tama sa mga pagbabago. Halimbawa, kapag nagbubukas ng modal window, dapat ipadala ang screenChanged na may bagong heading — kung hindi, mananatili ang VoiceOver sa nakaraang elemento sa ilalim ng window.

Pag-develop ng app na isinasaalang-alang ang Screen Reader

Ang paglikha ng isang naa-access na app ay hindi lamang tungkol sa pagdaragdag ng contentDescription sa bawat elemento, kundi pag-iisip ng karanasan ng gumagamit para sa hindi-visual na interaksyon. Ang mga pangunahing patakaran ay pareho para sa parehong platform, kahit na magkaiba ang implementasyon.

Mga pangunahing patakaran ng aksesibilidad

Ang lahat ng interaktibong elemento ay dapat magkaroon ng makabuluhang paglalarawan: ang button na "Ipadala" ay dapat ilarawan bilang "Ipadala ang mensahe", hindi "Button". Ang mga dekoratibong elemento (mga separator, background na imahe, icon na walang functionality) ay dapat itago mula sa screen reader. Ang pagkakasunod-sunod ng nabigasyon ay dapat tumugma sa lohikal na daloy ng screen, hindi sa visual na layout. Ang contrast ng teksto ay dapat na hindi bababa sa 4.5:1 para sa pangunahing teksto at 3:1 para sa malaking teksto (WCAG AA).

// iOS: tamang configuration para sa kumplikadong elemento
let customControl = UIControl()
customControl.isAccessibilityElement = true
customControl.accessibilityLabel = "Volume ng tunog"
customControl.accessibilityValue = "75 porsyento"
customControl.accessibilityTraits = [
    .adjustable,
    .button
]
customControl.accessibilityHint =
    "Nagpapataas o nagpapababa ng volume"

// Pag-update kapag nagbago ang halaga
func didChangeVolume(newValue: Float) {
    customControl.accessibilityValue =
        "\(Int(newValue)) porsyento"
    UIAccessibility.post(
        notification: .layoutChanged,
        argument: customControl
    )
}

Sa iOS, ang flag na isAccessibilityElement ay nag-a-activate ng suporta ng VoiceOver para sa custom na elemento. Ang kombinasyon ng traits (.adjustable + .button) ay nagpapaalam sa VoiceOver na ang elemento ay maaaring ayusin sa pamamagitan ng pag-swipe pataas/pababa at i-activate sa pamamagitan ng double touch. Pagkatapos ng pagbabago ng halaga, ipinapadala ang notisyong layoutChanged — kung hindi, patuloy na bibigkasin ng VoiceOver ang lumang halaga.

Mga tiyak na rekomendasyon para sa parehong platform

Para sa iOS: gamitin ang accessibilityElements upang i-override ang pagkakasunod-sunod ng pagbasa, accessibilityCustomActions para sa karagdagang aksyon sa context menu at shouldGroupAccessibilityChildren para sa pag-grupo ng mga elemento sa lohikal na grupo. Para sa SwiftUI, ilapat ang mga modifier na .accessibilityLabel(), .accessibilityAddTraits() at .accessibilityRespondsToUserInteraction(). Iwasan ang paggamit ng isAccessibilityElement = false sa mga container na naglalaman ng interaktibong child element — itatago nito ang mga ito mula sa VoiceOver.

Para sa Android: gamitin ang accessibilityTraversalBefore at accessibilityTraversalAfter para sa pagkakasunod-sunod ng nabigasyon, AccessibilityDelegate para sa custom na elemento at LiveRegion (polite/assertive) para sa dynamic na pag-update. Sa Compose, ilapat ang modifier na .semantics {} na may contentDescription, stateDescription at customActions. Iwasan ang paggamit ng focusable = true sa hindi interaktibong elemento — lilikha ito ng maling focus point para sa TalkBack at malilito ang gumagamit.

Mga tool sa pagsubok

Ang pagsubok gamit ang screen reader ay sapilitan sa isang pisikal na device. Ang emulator/simulator ay nagbibigay ng pangunahing ideya, ngunit ang mga kilos at bilis ng pagtugon ay magkaiba. Gamitin ang Accessibility Inspector (Xcode) para sa iOS at Accessibility Scanner para sa Android para sa awtomatikong paghahanap ng mga problema.

Mga pangunahing senaryo ng pagsubok: pagpaparehistro (pagpuno ng form, validation, pagpapadala), paghahanap at nabigasyon sa catalog, pag-order, pag-recover ng password. Bawat senaryo ay dapat magawa nang walang visual na kontrol — sa pamamagitan lamang ng voice prompt ng screen reader. Kung hindi makumpleto ng gumagamit ng screen reader ang senaryo sa parehong oras ng ordinaryong gumagamit (±50%), — ang app ay nangangailangan ng pagpapabuti ng aksesibilidad.