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"danlink "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:
- kata-kata dan urutan yang diucapkan tiap screen reader, dan seberapa panjang;
- cara mengucapkan "Rp 700.000" atau "12 Des";
- kapan live region dibacakan, atau apakah terpotong suara lain;
- perpindahan browse mode dan focus mode di NVDA, dan gerakan jari di HP;
- apakah sebuah teks masuk akal saat didengar sendirian.
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
- Berhenti di pohon aksesibilitas atau alat otomatis. Mereka menangkap nama yang hilang, bukan nama yang gak bermakna.
- Memakai mouse saat screen reader menyala. Pengguna sungguhan berpindah dengan keyboard atau gerakan jari; ikuti cara mereka.
- Cuma membaca dari atas ke bawah. 71,6% responden WebAIM melompat lewat heading. Tes daftar heading, link, dan landmark.
- Mengharap kata yang sama dari semua screen reader. NVDA, VoiceOver, dan TalkBack mengucapkan role dengan cara berbeda. Cek maknanya.
- Temuan tanpa versi dan pasangan. Orang lain gak bisa mengulanginya, dan perbaikannya gak bisa dibuktikan.
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.