Screen Reader: apa itu, jenis pembaca layar dan prinsip kerja

Apa itu Screen Reader?

Screen Reader (pembaca layar) — adalah teknologi bantu (Assistive Technology, AT) yang menginterpretasikan antarmuka pengguna grafis dan menyajikannya dalam bentuk non-visual: melalui ucapan yang disintesis atau layar braille taktil. Pembaca layar adalah sarana utama akses ke komputer dan perangkat seluler bagi orang dengan kehilangan penglihatan total atau sebagian.

Pembaca layar pertama muncul pada akhir 1980-an untuk MS-DOS (misalnya, Vocal-Eyes) dan kemudian untuk Windows (JAWS, NVDA). Di platform seluler, pembaca layar mulai dibenamkan di tingkat sistem: Apple mengintegrasikan VoiceOver di iPhone 3GS pada tahun 2009, Google mengintegrasikan TalkBack di Android 1.6 pada tahun yang sama. Pada tahun 2025, hampir semua smartphone modern memiliki pembaca layar bawaan yang tidak memerlukan instalasi perangkat lunak tambahan.

Screen Reader tidak hanya membaca teks dari layar — ia menganalisis hierarki antarmuka, menentukan jenis elemen (tombol, tautan, judul, bidang input), statusnya (diaktifkan/dinonaktifkan, dipilih/tidak dipilih) dan hubungan timbal balik (induk-anak, grup). Informasi ini disampaikan kepada pengguna melalui petunjuk suara atau sensasi taktil dari layar braille, yang memperbarui sel secara real-time sesuai dengan posisi fokus.

Bagaimana cara kerja Screen Reader?

Screen Reader bekerja erat dengan sistem operasi, mendapatkan akses ke representasi internal antarmuka — pohon aksesibilitas (Accessibility Tree). Mekanisme ini sama di iOS dan Android, meskipun nama API berbeda.

Konversi teks ke ucapan (TTS)

Saluran keluaran utama pembaca layar adalah synthesizer ucapan (Text-To-Speech, TTS). Ketika fokus aksesibilitas mengenai suatu elemen, pembaca layar mengekstrak konten teksnya (atau deskripsi yang ditentukan oleh pengembang) dan mengirimkannya ke mesin TTS. Mesin TTS modern seperti Apple Speech Synthesis dan Google Text-to-Speech menggunakan jaringan saraf untuk menghasilkan ucapan alami dengan intonasi, jeda, dan aksen yang benar tergantung pada tanda baca dan jenis konten.

Pengguna dapat menyesuaikan kecepatan ucapan (biasanya 60-80% dari maksimum untuk persepsi yang nyaman), nada tinggi dan volume. Beberapa pembaca layar mendukung beberapa suara dan peralihan di antara mereka tergantung pada jenis konten — misalnya, suara yang lebih lambat untuk membaca teks dan suara cepat untuk navigasi antarmuka. Layar braille terhubung melalui Bluetooth dan menampilkan 40-80 karakter sekaligus, memperbarui baris setiap kali fokus berubah.

Kontrol fokus dan navigasi

Pembaca layar menggunakan konsep fokus aksesibilitas (Accessibility Focus), yang berbeda dari fokus input standar. Pengguna memindahkan fokus aksesibilitas dengan gestur (sentuhan, gesekan), dan pembaca layar menyuarakan elemen di bawah fokus. Urutan navigasi secara default mengikuti urutan visual: dari kiri ke kanan, dari atas ke bawah. Pengembang dapat menimpa urutan ini untuk tata letak yang kompleks.

Pembaca layar juga mendukung berbagai mode navigasi, yang pengguna alihkan melalui rotor (VoiceOver) atau menu (TalkBack): berdasarkan judul, tautan, karakter, kata, formulir. Dalam mode judul, pembaca layar hanya bergerak di antara H1-H6 — ini sangat penting untuk navigasi yang efisien melalui halaman dan dokumen yang panjang. Mode karakter membantu saat memasukkan kode konfirmasi atau kata sandi kompleks, mengucapkan setiap karakter secara terpisah.

Pembaca layar utama untuk platform seluler

Di platform seluler, dua pembaca layar mendominasi: VoiceOver di iOS dan TalkBack di Android. Mereka memiliki API, gestur, dan kemampuan yang berbeda, tetapi prinsip kerja yang sama — membaca pohon aksesibilitas dan kontrol dengan gestur.

VoiceOver (iOS)

VoiceOver — pembaca layar dari Apple, tertanam di iOS, iPadOS, dan macOS. Ia menggunakan API UIAccessibility untuk mendapatkan informasi tentang elemen dan mendukung rotor untuk mengganti mode navigasi. VoiceOver terintegrasi dengan iCloud (pengaturan disinkronkan antar perangkat), Apple Pay (konfirmasi pembayaran melalui Touch ID atau Face ID) dan teks dinamis (font menyesuaikan dengan pengaturan pengguna).

Gestur VoiceOver berbeda dari TalkBack: menggunakan rotasi dua jari (rotor), ketuk tiga kali untuk Screen Curtain dan ketuk dua kali dengan dua jari untuk membatalkan tindakan. VoiceOver mendukung rotor kustom, yang ditambahkan pengembang melalui UIAccessibilityCustomRotor — misalnya, untuk navigasi cepat melalui bagian aplikasi dengan melewati urutan standar.

TalkBack (Android)

TalkBack — pembaca layar dari Google, bagian dari Android Accessibility Suite. Ia menggunakan AccessibilityService dan AccessibilityNodeInfo untuk mengakses antarmuka. TalkBack mendukung menu global melalui gesekan berbentuk L, tindakan kustom untuk elemen dan LiveRegion untuk pembaruan dinamis. Mulai Android 14, TalkBack mendapatkan dukungan untuk gestur satu tangan dan integrasi yang lebih baik dengan Google Assistant.

TalkBack memiliki sistem gestur yang lebih fleksibel daripada VoiceOver: pengguna dapat mengonfigurasi hampir semua gestur untuk tindakan apa pun. TalkBack juga mendukung input braille di layar (BrailleBack) — pengguna memasukkan teks dengan karakter braille langsung di layar sentuh dalam tata letak khusus 3×2 untuk setiap jari, yang secara signifikan mempercepat pengetikan dibandingkan dengan keyboard layar.

Selain VoiceOver dan TalkBack, ada pembaca layar seluler yang kurang umum: Select to Speak (Android, menyuarakan area yang dipilih), Samsung Voice Assistant (pengganti TalkBack di perangkat Samsung dengan One UI) dan solusi pihak ketiga untuk niche tertentu — misalnya, untuk pengguna smartphone China tanpa layanan Google.

Bagaimana Screen Reader berinteraksi dengan aplikasi

Screen Reader tidak memiliki akses langsung ke komponen UI aplikasi. Sebaliknya, ia bekerja melalui lapisan perantara — API aksesibilitas sistem operasi. Sistem operasi membangun pohon aksesibilitas (Accessibility Tree), yang dilalui dan dianalisis oleh pembaca layar.

Accessibility Tree di iOS dan Android

Di iOS, pohon aksesibilitas dibangun dari objek UIAccessibilityElement, yang sesuai dengan setiap View di layar. Setiap elemen berisi label (teks utama), traits (jenis elemen: tombol, judul, tautan), hint (petunjuk), value (nilai saat ini untuk penggeser dan indikator) dan frame (area sentuhan). Sistem secara otomatis membuat elemen untuk komponen UI standar, tetapi pengembang dapat menambah dan mengonfigurasinya.

Di Android, pohon aksesibilitas dibangun dari objek AccessibilityNodeInfo. Setiap simpul berisi: text (teks atau contentDescription), className (jenis elemen), contentDescription (deskripsi), stateDescription (status), isEnabled, isChecked, isClickable dan flag lainnya. Android juga mendukung AccessibilityAction — daftar tindakan yang dapat dilakukan pembaca layar atas nama pengguna: klik, tekan lama, gulir, atur fokus, atur teks.

Peristiwa aksesibilitas (Accessibility Events)

Ketika terjadi perubahan dalam antarmuka (elemen baru muncul, teks berubah, elemen menjadi terlihat atau tidak terlihat), sistem operasi mengirimkan AccessibilityEvent. Pembaca layar berlangganan peristiwa ini dan bereaksi terhadapnya: misalnya, ketika kotak dialog muncul, pembaca layar secara otomatis memindahkan fokus ke judulnya dan menyuarakan konten.

// Mendengarkan peristiwa aksesibilitas di 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)
        }
    }
}

Di iOS, peristiwa serupa ditangani melalui UIAccessibility.Notification: layoutChanged (tata letak berubah), screenChanged (layar baru sepenuhnya), announcement (pengumuman sembarang), pageScrolled (gulir halaman). Pengembang mengirim peristiwa ini melalui UIAccessibility.post agar pembaca layar bereaksi dengan benar terhadap perubahan. Misalnya, saat membuka jendela modal, screenChanged harus dikirim dengan judul baru — jika tidak, VoiceOver akan tetap berada di elemen sebelumnya di bawah jendela.

Pengembangan aplikasi dengan mempertimbangkan Screen Reader

Membuat aplikasi yang aksesibel bukan hanya tentang menambahkan contentDescription ke setiap elemen, tetapi memikirkan pengalaman pengguna untuk interaksi non-visual. Aturan dasarnya sama untuk kedua platform, meskipun implementasinya berbeda.

Aturan dasar aksesibilitas

Semua elemen interaktif harus memiliki deskripsi yang bermakna: tombol "Kirim" harus dideskripsikan sebagai "Kirim pesan", bukan "Tombol". Elemen dekoratif (pemisah, gambar latar, ikon tanpa fungsionalitas) harus disembunyikan dari pembaca layar. Urutan navigasi harus sesuai dengan alur logis layar, bukan tata letak visual. Kontras teks harus setidaknya 4.5:1 untuk teks utama dan 3:1 untuk teks besar (WCAG AA).

// iOS: konfigurasi yang benar untuk elemen kompleks
let customControl = UIControl()
customControl.isAccessibilityElement = true
customControl.accessibilityLabel = "Volume suara"
customControl.accessibilityValue = "75 persen"
customControl.accessibilityTraits = [
    .adjustable,
    .button
]
customControl.accessibilityHint =
    "Meningkatkan atau mengurangi volume"

// Memperbarui saat nilai berubah
func didChangeVolume(newValue: Float) {
    customControl.accessibilityValue =
        "\(Int(newValue)) persen"
    UIAccessibility.post(
        notification: .layoutChanged,
        argument: customControl
    )
}

Di iOS, flag isAccessibilityElement mengaktifkan dukungan VoiceOver untuk elemen kustom. Kombinasi traits (.adjustable + .button) memberi tahu VoiceOver bahwa elemen dapat disesuaikan dengan menggesek ke atas/bawah dan diaktifkan dengan ketuk dua kali. Setelah nilai berubah, notifikasi layoutChanged wajib dikirim — jika tidak, VoiceOver akan terus menyuarakan nilai lama.

Rekomendasi khusus untuk kedua platform

Untuk iOS: gunakan accessibilityElements untuk menimpa urutan pembacaan, accessibilityCustomActions untuk tindakan tambahan di menu konteks dan shouldGroupAccessibilityChildren untuk mengelompokkan elemen ke dalam grup logis. Untuk SwiftUI, terapkan pengubah .accessibilityLabel(), .accessibilityAddTraits() dan .accessibilityRespondsToUserInteraction(). Hindari penggunaan isAccessibilityElement = false pada wadah yang berisi elemen anak interaktif — ini akan menyembunyikannya dari VoiceOver.

Untuk Android: gunakan accessibilityTraversalBefore dan accessibilityTraversalAfter untuk urutan navigasi, AccessibilityDelegate untuk elemen kustom dan LiveRegion (polite/assertive) untuk pembaruan dinamis. Di Compose, terapkan pengubah .semantics {} dengan contentDescription, stateDescription dan customActions. Hindari penggunaan focusable = true pada elemen non-interaktif — ini akan menciptakan titik fokus palsu untuk TalkBack dan membingungkan pengguna.

Alat pengujian

Pengujian dengan pembaca layar wajib dilakukan pada perangkat fisik. Emulator/simulator memberikan gambaran dasar, tetapi gestur dan kecepatan respons berbeda. Gunakan Accessibility Inspector (Xcode) untuk iOS dan Accessibility Scanner untuk Android untuk mencari masalah secara otomatis.

Skenario pengujian utama: pendaftaran (mengisi formulir, validasi, pengiriman), pencarian dan navigasi melalui katalog, pemesanan, pemulihan kata sandi. Setiap skenario harus dapat dilakukan tanpa kontrol visual — hanya melalui petunjuk suara pembaca layar. Jika pengguna pembaca layar tidak dapat menyelesaikan skenario dalam waktu yang sama dengan pengguna biasa (±50%), — aplikasi memerlukan perbaikan aksesibilitas.