Screen Reader Testing — UI/UX

Testing dengan Screen Reader Screen reader membaca konten halaman secara linear. Apa yang terlihat bagus secara visual belum tentu masuk akal saat…

Screen reader testing artinya memakai halaman seperti pengguna tunanetra memakainya: dengan screen reader sungguhan, mengikuti skrip tes yang ditulis lebih dulu, sambil mencatat apa yang terdengar. Di pelajaran aksesibilitas dasar, screen reader adalah Bu Sri yang membacakan halaman lewat telepon. Sekarang kamu pemeriksanya: kamu menelepon dengan daftar pertanyaan ("bacakan judulnya", "apa tombol berikutnya?", "tekan tombol itu, apa yang terjadi?"), lalu menulis setiap jawabannya, kata per kata.

🧪 Tebakan cepat: Tab Accessibility di Chrome DevTools menunjukkan button "Pesan kamar, bayar di tempat" dan link "Klik di sini". Dua-duanya punya role dan nama. Cukup untuk bilang halaman ini beres untuk pengguna screen reader? Jawabannya ada di bagian "Yang bisa dan gak bisa dicek tanpa screen reader".

Screen reader dan pasangannya

Screen reader bekerja berpasangan dengan browser, karena dia membaca pohon aksesibilitas yang dibangun browser.

Screen reader Sistem Biaya Pasangan yang umum
NVDA Windows gratis (NV Access) Chrome, Firefox
JAWS Windows berbayar Chrome, Edge
VoiceOver macOS, iOS bawaan Safari
TalkBack Android bawaan Chrome

WebAIM Screen Reader User Survey #10 (Desember 2023 sampai Januari 2024, 1.539 responden): screen reader utama di desktop JAWS 40,5%, NVDA 37,7%, VoiceOver 9,7%. Pasangan terbanyak JAWS dengan Chrome (24,7%) dan NVDA dengan Chrome (21,3%). 91,3% juga memakai screen reader di HP; di sana VoiceOver dipakai 70,6% responden dan TalkBack 34,7% (boleh lebih dari satu). Dan 71,6% mencari informasi di halaman panjang dengan melompat dari heading ke heading.

Paling sedikit, tes dengan satu pasangan desktop (NVDA dengan Chrome gratis) dan satu pasangan HP (VoiceOver dengan Safari di iPhone, atau TalkBack dengan Chrome di Android).

Perintah yang kamu butuhkan

Tugas NVDA (tombol NVDA = Insert) VoiceOver macOS (VO = Control+Option) TalkBack
Nyalakan Ctrl+Alt+N Command+F5 tahan kedua tombol volume 3 detik (kalau pintasannya aktif)
Item berikutnya panah bawah VO+panah kanan geser kanan
Tekan Enter VO+Spasi ketuk dua kali
Heading berikutnya H (1 sampai 6 untuk level) VO+Command+H pilih reading control Headings, lalu geser bawah
Daftar heading, link, landmark NVDA+F7 VO+U (rotor; panah kiri dan kanan ganti daftar) gak ada daftar; lompat dengan reading control
Link, landmark berikutnya K, D lewat rotor reading control Links
Berhenti bicara Ctrl Control ketuk dua jari (jeda, TalkBack 9.1 ke atas)

Di NVDA, NVDA+Q mematikan; NVDA+Spasi berpindah antara browse mode (membaca halaman dengan tombol huruf) dan focus mode (mengetik di kolom isian). Di TalkBack, reading control dipilih dengan geser atas lalu bawah (atau tiga jari geser bawah), dan menu TalkBack dibuka dengan geser bawah lalu kanan (atau ketuk tiga jari). Perintah ini dari dokumentasi resmi NV Access, Apple, dan Google.

Untuk mengecek urutan heading dengan VoiceOver tanpa mendengar seluruh halaman, tekan VO+U lalu buka daftar Headings di rotor. Di NVDA, NVDA+F7 membuka daftar yang sama.

Skrip tes untuk halaman pesan

Tulis skripnya dulu, lalu jalankan sama persis di tiap pasangan. Kolom "harus terdengar" diambil dari pohon aksesibilitas: role, nama, dan state. Kata persisnya berbeda di tiap screen reader, jadi yang dicek maknanya.

No Langkah Harus terdengar
1 Buka halaman judul "Kamar Teras · Homestay Kabut", dibaca dengan logat Indonesia (lang="id")
2 Daftar heading h1 "Kamar Teras", h2 "Aturan menginap", h2 "Lokasi", tanpa level yang terloncati
3 Daftar landmark banner, navigasi "Navigasi utama", main, contentinfo
4 Item berikutnya sampai foto dan peta "Kamar Teras: ranjang ganda...", gambar; peta rute dengan isinya; garis kabut hiasan gak terdengar
5 Tab ke pilihan malam grup "Lama menginap", "2 malam", radio, terpilih
6 Tab ke tombol Pesan, tekan "Pesan kamar, bayar di tempat", tombol; lalu kabar "Pesanan terkirim..." tanpa fokus berpindah
7 Daftar link tiap link bermakna sendiri, misalnya "Baca aturan menginap lengkap"

Yang didengarkan di tiap langkah: role (tombol, link, heading), nama (apa yang tertulis), state (terpilih, terbuka), urutan (sesuai urutan tampilan), diam di hiasan, dan perubahan yang dibacakan.

Catat temuan

Catat tiap temuan dengan cara yang bisa diulang orang lain. NVDA punya Speech Viewer (menu NVDA, Tools) yang menampilkan teks yang diucapkan; VoiceOver punya caption panel. Salin teks dari sana. Contoh format untuk tiga masalah di halaman Bu Sri (contoh catatan, bukan rekaman tes kami):

No Langkah Yang terdengar Masalah WCAG Pasangan
1 7, daftar link "Klik di sini", link gak menyebut tujuan; tanpa kalimat sebelumnya artinya hilang 2.4.4 Link Purpose (In Context), A NVDA + Chrome, tulis versinya
2 4, peta rute gambar tanpa nama (sebagian screen reader membacakan nama file) <img> tanpa alt 1.1.1 Non-text Content, A VoiceOver + Safari, tulis versinya
3 6, setelah Pesan gak ada yang dibacakan toast tanpa live region 4.1.3 Status Messages, AA TalkBack + Chrome, tulis versinya

Perbaikannya: link "Baca aturan menginap lengkap"; alt yang menyebut isi peta, misalnya "Peta rute: dari terminal Dieng jalan kaki 400 meter ke utara"; toast di dalam role="status". Untuk grafik, alt menyebut kesimpulannya, bukan jenis gambarnya; nama file seperti "chart.png" gak membantu siapa pun.

Kolom pasangan wajib diisi dengan versi: temuan yang muncul di satu pasangan belum tentu muncul di pasangan lain.

Yang bisa dan gak bisa dicek tanpa screen reader

Pohon aksesibilitas Chromium (DevTools, tab Accessibility; atau Accessibility.getFullAXTree lewat Chrome DevTools Protocol di tes otomatis) memperlihatkan apa yang browser serahkan: role, nama, state, apakah tersembunyi, apakah bisa difokus, dan sifat live region. Itu yang kami cek untuk pelajaran ini dan Lab-nya.

Yang gak terlihat di pohon:

Kami gak menjalankan NVDA, VoiceOver, atau TalkBack untuk pelajaran ini; pohon Chromium adalah perkiraan, bukan screen reader.

Jadi jawaban tebakannya: belum. Pohonnya benar secara teknis: tombol punya role dan nama, link juga. Tapi link "Klik di sini" gak berarti apa-apa saat didengar di daftar link, tanpa kalimat di depannya. Masalah seperti itu cuma ketahuan saat kamu benar-benar mendengarkan halamannya. Itu jawaban tebakannya.

⚠️ Jebakan yang sering ketemu

TL;DR: Screen reader testing = memakai halaman dengan screen reader sungguhan, mengikuti skrip, mencatat yang terdengar. Pasangan umum: NVDA (gratis) atau JAWS dengan Chrome di Windows, VoiceOver dengan Safari di Mac dan iPhone, TalkBack dengan Chrome di Android; WebAIM #10: JAWS 40,5%, NVDA 37,7%, VoiceOver 9,7% di desktop, 91,3% juga di HP, 71,6% melompat lewat heading. Perintah inti: item berikutnya (panah bawah, VO+panah kanan, geser kanan), tekan (Enter, VO+Spasi, ketuk dua kali), daftar heading (NVDA+F7, VO+U untuk rotor). Skrip tes menulis langkah dan yang harus terdengar (role, nama, state, urutan, diam di hiasan, perubahan dibacakan). Temuan dicatat dengan langkah, teks yang terdengar (Speech Viewer, caption panel), kriteria WCAG (link "Klik di sini" gagal 2.4.4, gambar tanpa alt 1.1.1, toast tanpa live region 4.1.3), dan pasangan beserta versinya. Pohon aksesibilitas Chromium memperlihatkan apa yang diserahkan browser, bukan apa yang terdengar: dia perkiraan, bukan screen reader.

Yang akan kamu pelajari