Lompat ke Konten Utama
Pengujian & Audit07 Juli 2026

Kombinasi AT Stack: Mengapa Auditor Harus Menguji di Lebih dari Satu Screen Reader

Penulis

Redaksi Disabilitas.com

4 Menit Baca2 Kali Dibaca

Ada sebuah rahasia yang sering membingungkan developer: sebuah bug aksesibilitas bisa hanya muncul di kombinasi teknologi tertentu dan tidak muncul di yang lain. Seorang developer yang menguji dengan NVDA+Chrome bisa berpikir "ini sudah beres", sementara jutaan pengguna JAWS+Edge masih terjebak dalam hambatan yang sama sekali berbeda.

Inilah mengapa seorang auditor aksesibilitas profesional tidak cukup hanya menguasai satu screen reader. Mereka harus memahami lanskap AT Stack — yaitu, kombinasi-kombinasi spesifik antara Assistive Technology (AT) dengan browser atau platform yang digunakan pengguna nyata di dunia — dan mengetahui kapan setiap kombinasi harus digunakan dalam audit.


Mengapa Kombinasi AT+Browser Penting?

Screen reader bekerja dengan cara "membaca" struktur aksesibilitas yang diekspos oleh browser melalui sebuah lapisan bernama Accessibility API (antarmuka pemrograman aksesibilitas). Masalahnya, setiap browser mengekspos informasi ini sedikit berbeda, dan setiap screen reader menginterpretasikan API tersebut dengan caranya sendiri.

Hasilnya: perilaku yang berbeda untuk kode yang sama.

Sebagai contoh nyata, sebuah komponen dialog modal yang dibuat dengan role="dialog" dan aria-modal="true" bisa:

  • Berfungsi sempurna di NVDA + Chrome (pengguna terkurung di dalam modal sebagaimana diharapkan).
  • Gagal di JAWS + Edge (pengguna dapat keluar dari modal menggunakan Virtual Cursor dan membaca konten latar belakang).
  • Berfungsi sebagian di VoiceOver + Safari (modal terdeteksi, namun fokus tidak secara otomatis berpindah ke dalamnya).

Laporan audit yang baik harus mencatat kombinasi mana yang berhasil dan mana yang gagal.


Peta AT Stack yang Wajib Diketahui Auditor

Desktop

Kombinasi Pangsa Pasar Sistem Operasi Catatan Penting
JAWS + Chrome ~33% Windows Kombinasi paling populer di kalangan profesional; sering digunakan di lingkungan korporat dan pemerintahan
JAWS + Edge ~10% Windows Relevan untuk pengguna di ekosistem Microsoft 365
NVDA + Chrome ~26% Windows Paling populer di kalangan pengguna rumahan; open source dan gratis
NVDA + Firefox ~8% Windows Komunitas open source; tes ini penting untuk memastikan standar web terbuka terpenuhi
VoiceOver + Safari ~9% macOS Wajib untuk auditor yang menargetkan pengguna ekosistem Apple
Narrator + Edge ~3% Windows Screen reader bawaan Windows; penting untuk pengujian dasar kepatuhan pemerintah

Mobile (Aplikasi Native & Mobile Web)

Kombinasi Platform Catatan Penting
VoiceOver + Safari iOS/iPadOS Standar utama untuk pengujian mobile Apple; wajib untuk semua aplikasi iOS
TalkBack + Chrome Android Standar utama untuk pengujian Android; perilaku gestur berbeda antar versi Android
TalkBack + Firefox Android Relevan untuk pengguna Android yang mengutamakan privasi

Data Referensi: WebAIM Screen Reader Survey (2024) adalah survei tahunan yang paling komprehensif untuk memahami tren penggunaan screen reader nyata di seluruh dunia. Auditor disarankan mengikuti survei ini setiap tahun karena pangsa pasar berubah seiring waktu.


Strategi Pengujian: Tidak Harus Menguji Semua Kombinasi

Menguji setiap permutasi kombinasi AT+browser untuk setiap halaman akan memakan waktu yang tidak realistis. Seorang auditor profesional menggunakan strategi yang pragmatis:

Pendekatan Tier (Bertingkat)

Tier 1 (Wajib): Selalu uji minimal dua kombinasi desktop dan satu kombinasi mobile:

  • NVDA + Chrome
  • JAWS + Chrome (atau Edge)
  • VoiceOver + Safari (iOS)

Ini sudah mencakup lebih dari 70% pengguna screen reader nyata.

Tier 2 (Direkomendasikan untuk Proyek Enterprise):

  • Tambahkan TalkBack + Chrome (Android)
  • Tambahkan VoiceOver + Safari (macOS)

Tier 3 (Untuk Proyek Pemerintah atau Aksesibilitas Tinggi):

  • Tambahkan Narrator + Edge
  • Tambahkan NVDA + Firefox

Cara Memilih Tier yang Tepat

Saat mendiskusikan ruang lingkup dengan klien, tanyakan:

  1. Siapa pengguna sasaran? Platform Apple atau Windows yang lebih dominan?
  2. Apakah ini produk enterprise/pemerintah? Jika ya, JAWS wajib masuk.
  3. Apakah ada aplikasi mobile? Jika ya, VoiceOver + TalkBack wajib masuk.
  4. Apa anggaran audit? Lebih banyak kombinasi = lebih banyak jam kerja.

Cara Mendokumentasikan AT Stack dalam Laporan Bug

Setiap entri bug dalam laporan harus mencantumkan AT Stack secara eksplisit:

Isu #12: Komponen Dropdown Navigasi Tidak Dapat Ditutup via Keyboard
AT Stack yang Terpengaruh: JAWS 2024 + Chrome 126 / Windows 11
AT Stack yang TIDAK Terpengaruh: NVDA 2024.1 + Chrome 126 / Windows 11
Langkah Reproduksi: ...

Informasi ini sangat krusial karena memungkinkan developer memprioritaskan perbaikan berdasarkan seberapa luas populasi pengguna yang terpengaruh.


Quirks (Keanehan) yang Wajib Diketahui Per Kombinasi

Setiap kombinasi AT+browser memiliki "keanehan" historis yang bukan bug, melainkan perbedaan implementasi yang perlu dipahami auditor:

JAWS: Memiliki mode Virtual Cursor (membaca halaman seperti dokumen teks) vs Forms/Application Mode (berinteraksi dengan elemen formulir). Transisi antar mode ini kadang tidak otomatis, menyebabkan pengguna terjebak di mode yang salah.

NVDA: Menggunakan mode Browse Mode dan Focus Mode. Memiliki fitur "Speech Viewer" yang sangat berguna untuk audit — menampilkan semua teks yang diucapkan screen reader dalam sebuah jendela teks real-time yang bisa dibaca tim sighted.

VoiceOver (iOS): Gestur usap kiri/kanan untuk navigasi elemen berbeda secara fundamental dengan cara NVDA/JAWS menavigasi halaman web. Auditor harus benar-benar fasih dengan Rotor VoiceOver sebagai alat penting.

TalkBack (Android): Perilaku notifikasi dan gestur navigasi berubah cukup signifikan antara Android 12, 13, dan 14. Selalu catat versi Android dan TalkBack dalam laporan.


Kesimpulan

Menguasai beragam AT Stack bukan berarti harus memiliki semua perangkat tersebut sekaligus — banyak auditor mulai dengan yang paling populer (NVDA + Chrome), kemudian secara bertahap memperluas kemampuan mereka. Yang terpenting adalah memahami prinsipnya: bahwa pengalaman pengguna bisa sangat berbeda tergantung alat yang mereka gunakan, dan tugas auditor adalah memastikan tidak ada populasi pengguna yang tertinggal.

Referensi

- Firth, A. Practical Web Accessibility: A Book Apart. - Lazar, J. dkk. Ensuring Digital Accessibility Through Process and Policy. - WebAIM. Screen Reader User Survey. https://webaim.org/projects/screenreadersurvey/

Bagaimana menurut Anda?

Berikan reaksi Anda pada artikel ini