Pembaca Layar Pratinjau

Tempel HTML untuk melihat bagaimana pembaca layar akan melinearisasi dan mengumumkannya. Verifikasi teks alt, heading, dan atribut ARIA Anda.

Keluaran pembaca layar

Tempel HTML dan klik Analisis.
📚 Dasar ilmiah dan sumber

Untuk siapa alat ini dirancang

Pembaca layar adalah teknologi bantu yang penting untuk orang yang buta atau memiliki gangguan penglihatan signifikan. Menurut World Report on Vision WHO (2019), setidaknya 2,2 miliar orang di seluruh dunia mengalami gangguan penglihatan, di antaranya sekitar 43 juta buta. Survei Pembaca Layar WebAIM (2024) secara konsisten menemukan bahwa sebagian besar pengguna pembaca layar adalah penyandang disabilitas, dengan kebutaan sebagai alasan paling umum. Developer, desainer, dan pencipta konten menggunakan alat ini untuk mempratinjau bagaimana HTML mereka akan ditafsirkan oleh teknologi bantu, yang membantu menemukan teks alternatif yang hilang, struktur heading yang salah, tombol dan kolom tanpa nama yang dapat diakses, dan penggunaan ARIA yang salah, sebelum pengguna akhir menemukannya.

Cara kerja alat ini

Alat ini menganalisis HTML Anda melalui DOMParser native browser (tidak ada data yang meninggalkan perangkat Anda), kemudian melintasi pohon aksesibilitas untuk membangun urutan baca yang dilinearisasi. Memeriksa keberadaan teks alternatif pada gambar, konsistensi tingkat heading, tautan dan tombol tanpa nama yang dapat diakses, peran dan label ARIA, serta kolom formulir tanpa label terkait.

Referensi ilmiah

  • WebAIM (2024). "Screen Reader User Survey #10 Results." webaim.org · Survei berkelanjutan terbesar tentang mode penggunaan pembaca layar, kombinasi browser, dan hambatan aksesibilitas. Secara konsisten menemukan bahwa heading dan landmark adalah strategi navigasi utama pengguna.
  • Organisasi Kesehatan Dunia (2019). World Report on Vision. · Melaporkan bahwa setidaknya 2,2 miliar orang di seluruh dunia mengalami gangguan penglihatan jarak dekat atau jauh, di antaranya sekitar 43 juta buta.
  • Power, C., Freire, A., Petrie, H. & Swallow, D. (2012). "Guidelines are only half of the story: Accessibility problems encountered by blind users on the web." Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI '12). · Menemukan bahwa sebagian besar masalah aksesibilitas yang ditemui oleh pengguna buta tidak tercakup oleh WCAG saja, menyoroti perlunya tinjauan manual dan pengujian pembaca layar.
  • Lazar, J., Allen, A., Kleinman, J. & Malarkey, C. (2007). "What frustrates screen reader users on the web: A study of 100 blind users." International Journal of Human-Computer Interaction, 22(3), 247–269. · Mengidentifikasi teks alternatif yang hilang, kolom formulir yang tidak berlabel, dan label tautan yang menyesatkan sebagai frustrasi utama yang dilaporkan oleh pengguna buta.
  • W3C WAI (2023). "WAI-ARIA Authoring Practices 1.2." · Menentukan bagaimana peran, status, dan properti harus digunakan untuk membuat konten dinamis dapat diakses oleh teknologi bantu.

Penafian

Alat ini memberikan pendekatan sederhana dari keluaran pembaca layar berdasarkan pohon aksesibilitas HTML. Pembaca layar nyata (NVDA, JAWS, VoiceOver, TalkBack) berbeda dalam cara mereka mengumumkan konten, menangani atribut ARIA, dan berinteraksi dengan widget dinamis. Pratinjau ini tidak menggantikan pengujian dengan pembaca layar dan pengguna nyata. Dimaksudkan untuk mendeteksi masalah umum di awal proses penulisan.

Sejarah singkat standar aksesibilitas web

Aksesibilitas di web diatur oleh tumpukan kecil standar dari W3C Web Accessibility Initiative (WAI), ditambah undang-undang nasional yang merujuknya. WCAG 1.0 diterbitkan pada Mei 1999, panduan formal pertama tentang membuat konten web dapat diakses. Itu sebagian besar berpusat pada HTML dan cepat menjadi usang. WCAG 2.0 (Desember 2008) adalah penulisan ulang besar yang diorganisir di sekitar empat prinsip (Dapat Dirasakan, Dapat Dioperasikan, Dapat Dipahami, Tangguh) dan tiga tingkat kepatuhan (A, AA, AAA). Ini menjadi standar ISO (ISO/IEC 40500) pada 2012 dan merupakan target kepatuhan yang masih dirujuk sebagian besar undang-undang. WCAG 2.1 (Juni 2018) menambahkan 17 kriteria keberhasilan baru yang mencakup mobile, penglihatan rendah, dan disabilitas kognitif. WCAG 2.2 (Oktober 2023) menambahkan 9 lagi, terutama 2.4.11 Fokus Tidak Tertutup dan 3.3.8 Autentikasi yang Dapat Diakses. WAI-ARIA 1.0 diselesaikan pada Maret 2014; 1.2 pada Juni 2023 adalah Rekomendasi saat ini. Di sisi hukum, Penyegaran Bagian 508 AS (Januari 2018) memasukkan WCAG 2.0 AA ke dalam pengadaan federal AS. Undang-Undang Aksesibilitas Eropa (Directive 2019/882) berlaku pada 28 Juni 2025, mengharuskan sebagian besar produk digital yang menghadap konsumen di UE memenuhi standar aksesibilitas. Sebagian besar negara merujuk WCAG, jadi membangun ke WCAG 2.2 AA adalah target praktis untuk produk global apa pun hari ini.

Lanskap pembaca layar saat ini

WebAIM Screen Reader User Survey #10 (2024) adalah sumber kanonis tentang pembaca layar mana yang sebenarnya digunakan orang. Lima produk mendominasi desktop, mobile, dan ChromeOS.

  • JAWS (Freedom Scientific, dirilis pertama 1989) adalah pemimpin komersial yang lama berdiri di Windows. Biaya ~$1000+. WebAIM 2024 menemukannya sebagai pembaca layar utama untuk sekitar 40% responden survei, sedikit di bawah NVDA.
  • NVDA (NV Access, dirilis pertama 2006, ditulis dalam Python) adalah alternatif open-source untuk Windows. Gratis. WebAIM 2024 melaporkannya sebagai pembaca layar utama yang paling banyak digunakan, sekitar 47% responden. Pertumbuhan NVDA dari alat khusus menjadi pemimpin pasar dalam 15 tahun adalah salah satu kisah sukses open-source hebat dalam teknologi bantu.
  • VoiceOver (Apple, 2005 di macOS, 2009 di iOS) dikirim bawaan di setiap Mac, iPhone, iPad, Apple Watch, Apple TV. Ini adalah pembaca layar mobile yang paling banyak digunakan. Terintegrasi erat dengan Safari dan rotor iOS untuk navigasi.
  • TalkBack (Google, 2009 di Android) adalah rekan Android. Open-source sejak Android 4. Menggunakan gerakan dan menu navigasi.
  • ChromeVox (Google, 2012) dan Narrator (Microsoft, 2000, dimodernisasi di Windows 10) melengkapi gambaran. Masing-masing memiliki basis pengguna kecil tetapi setia.

Satu halaman dapat diumumkan secara berbeda oleh setiap produk. Halaman yang tangguh diuji dengan bersih di setidaknya dua: biasanya NVDA + Firefox atau Chrome, dan VoiceOver + Safari.

Kapan menggunakan alat ini

  • Audit pra-peluncuran. Tempel halaman kunci (beranda, formulir pendaftaran, checkout) dan baca output yang dilinearisasi dengan keras. Jika tidak masuk akal bagi Anda, tidak akan masuk akal bagi pengguna pembaca layar.
  • Review kode. Sebelum menggabungkan PR dengan perubahan markup signifikan, tempel HTML yang dirender dan konfirmasi bahwa heading, landmark, dan alt text tetap utuh.
  • Verifikasi serah terima desain. Desainer dapat menempelkan HTML akhir mereka untuk mengonfirmasi bahwa hierarki visual cocok dengan hierarki semantik. Halaman yang terlihat seperti heading juga harus menjadi satu di DOM.
  • Mengajar aksesibilitas. Tunjukkan kepada kelas atau tim apa yang sebenarnya diterima pembaca layar. Kesenjangan antara tata letak visual dan output yang dilinearisasi sering kali adalah pertama kali pengembang non-disabilitas memahami mengapa HTML semantik penting.
  • Pemeriksaan kepatuhan terhadap WCAG. Pemeriksaan spot cepat untuk empat kriteria yang paling dilanggar: 1.1.1 Konten non-teks (alt text), 1.3.1 Informasi dan Hubungan (struktur semantik), 2.4.4 Tujuan tautan, 4.1.2 Nama, Peran, Nilai.
  • Pemeriksaan situs CMS / tanpa kode. Editor visual sering menghasilkan div alih-alih heading atau tautan tanpa teks. Tempel HTML yang dipublikasikan, lihat apa yang lolos.
  • Aksesibilitas template email. Email HTML terkenal sulit untuk dibuat dapat diakses. Gunakan pratinjau untuk memverifikasi alt text pada setiap gambar, urutan heading yang tepat, dan alur baca yang dapat dibaca.

Kesalahan umum yang dipaparkan pembaca layar

  • Alt text yang hilang atau tidak berguna. alt="image", alt="photo", alt="logo" hanya sedikit lebih baik daripada tidak ada. Lazar et al. (2007) mengidentifikasi alt text yang hilang sebagai frustrasi utama pengguna web tunanetra. Tulis alt text yang menyampaikan tujuan gambar dalam konteks sekitarnya, atau gunakan alt="" untuk gambar dekoratif murni sehingga pembaca layar melewatkannya.
  • Level heading yang melompat atau memulai ulang. Beralih dari h1 ke h3 melompati h2 membingungkan navigasi. Menggunakan beberapa elemen h1 pada halaman yang sama (pola yang cukup umum dalam desain berbasis komponen) merusak garis besar dokumen yang digunakan pengguna pembaca layar untuk navigasi. WebAIM 2024 menemukan bahwa heading adalah strategi navigasi paling umum untuk pengguna pembaca layar.
  • Divitis. Membungkus teks yang dapat diklik di <div> dengan handler klik alih-alih menggunakan <button> atau <a> berarti tidak ada dukungan keyboard, tidak ada cincin fokus, tidak ada pengumuman peran. Selalu mulai dari HTML semantik dan tambahkan ARIA hanya jika tidak ada elemen native yang cocok.
  • ARIA digunakan di tempat HTML akan cukup. Aturan pertama ARIA (menurut W3C WAI-ARIA Authoring Practices): «jika Anda dapat menggunakan elemen HTML native... lakukan itu». <button role="button"> berlebihan; <div role="button"> adalah tanda bahwa Anda harus menggunakan tombol asli.
  • ARIA digunakan secara tidak benar. aria-hidden="true" pada elemen yang dapat difokuskan membuatnya tidak terlihat oleh pembaca layar tetapi masih dapat difokuskan keyboard, resep untuk urutan tab yang membingungkan. role="button" tanpa tabindex="0" dan handler keyboard tidak melakukan hal yang berguna.
  • Input formulir tanpa label. Sebuah <input> tanpa <label>, aria-label, atau aria-labelledby yang terkait diumumkan sebagai «edit, blank» tanpa konteks. Teks placeholder bukan pengganti, itu menghilang pada fokus dan sering gagal kontras.
  • Tautan «klik di sini» dan «baca lebih banyak». Pengguna pembaca layar sering menavigasi dengan menarik daftar semua tautan di halaman. «Klik di sini» saja tidak memberi tahu mereka apa-apa. Buat teks tautan mendeskripsikan tujuan: «Baca survei WebAIM 2024» mengalahkan «Baca lebih banyak di sini».
  • Menghapus gaya fokus. outline: none tanpa indikator fokus pengganti adalah salah satu kriteria WCAG yang paling dilanggar (2.4.7 Fokus Terlihat). Pengguna keyboard, termasuk banyak pengguna pembaca layar, perlu melihat di mana fokus berada.

ARIA sekilas: apa yang dilakukan setiap jenis peran

  • Peran landmark (banner, navigation, main, complementary, contentinfo, search) membagi halaman menjadi wilayah di mana pengguna pembaca layar dapat melompat. Sebagian besar memiliki padanan HTML native (<header>, <nav>, <main>, <aside>, <footer>). Gunakan elemen native terlebih dahulu.
  • Peran widget (button, checkbox, combobox, menu, tabpanel, dll.) menggambarkan kontrol interaktif. Peran widget menyiratkan pola interaksi keyboard yang didokumentasikan secara rinci oleh W3C ARIA Authoring Practices Guide (APG). Jika Anda tidak dapat mencocokkan spesifikasi APG dengan tepat, lebih suka HTML native.
  • Peran struktur dokumen (article, list, listitem, row, cell, dll.) menggambarkan konten non-interaktif. Sebagian besar juga memiliki padanan HTML native. Gunakan hanya ketika elemen native tidak tersedia (misalnya, membangun grid data kustom di mana <table> tidak cocok).
  • Wilayah live (aria-live="polite", aria-live="assertive", role="status", role="alert") memberi tahu pembaca layar untuk mengumumkan pembaruan dinamis tanpa memindahkan fokus. Digunakan untuk pesan obrolan, kesalahan formulir, status pemuatan. Penggunaan berlebihan menyebabkan kelelahan pemberitahuan; cadangkan assertive untuk keadaan darurat asli seperti status kesalahan.

Pertanyaan yang lebih sering diajukan

Apakah pratinjau ini cocok dengan apa yang sebenarnya akan dikatakan NVDA / JAWS / VoiceOver?

Ini mendekati. Alat ini membaca pohon aksesibilitas browser (struktur yang sama yang digunakan pembaca layar) dan menghasilkan versi yang dilinearisasi dari apa yang akan diumumkan. Pembaca layar nyata menambahkan perilaku khusus produk: pengumuman perubahan fokus, navigasi tabel, header tabel, hitungan item daftar, penanganan kesopanan ARIA-live, pengaturan verbositas kustom. Perlakukan pratinjau sebagai pemeriksaan kewarasan pertama; untuk peluncuran produksi, uji dengan setidaknya satu pembaca layar nyata pada sistem operasi yang digunakan audiens Anda.

Apa perbedaan antara WCAG dan ARIA?

WCAG (Web Content Accessibility Guidelines) adalah daftar persyaratan: «setiap konten non-teks harus memiliki alternatif teks». Ini memberi tahu Anda apa yang harus dicapai tetapi tidak selalu bagaimana. ARIA (Accessible Rich Internet Applications) adalah salah satu alat untuk memenuhi WCAG: satu set atribut HTML (peran, status, properti) yang mengekspos semantik ke teknologi bantu ketika HTML native tidak cukup. Anda dapat memenuhi WCAG tanpa ARIA sama sekali jika HTML Anda cukup semantik. ARIA untuk kasus-kasus ketika tidak.

Bagaimana saya menulis alt text yang baik?

Tiga aturan dari An alt Decision Tree W3C: (1) Jika gambar murni dekoratif, gunakan alt="" sehingga pembaca layar melewatkannya sepenuhnya. (2) Jika gambar menyampaikan informasi yang belum ada di teks sekitarnya, deskripsikan informasi itu dengan ringkas (biasanya di bawah 125 karakter). (3) Jika gambar fungsional (misalnya logo yang menautkan ke beranda, atau tombol ikon), deskripsikan tindakan daripada penampilan. «Cari» mengalahkan «ikon kaca pembesar». Hindari «gambar dari...», «foto dari...», pembaca layar sudah mengumumkan bahwa elemen adalah gambar.

Situs saya menggunakan div di mana-mana. Mulai dari mana?

Mulai dengan menambahkan lima elemen landmark: <header>, <nav>, <main>, <aside>, <footer>. Kemudian ganti div yang dapat diklik dengan <button> (untuk tindakan) atau <a> (untuk navigasi). Kemudian audit heading: setiap halaman harus memiliki satu <h1> dan sisanya dalam urutan bersarang. Ketiga langkah ini memperbaiki mungkin 70% masalah aksesibilitas pada situs tipikal yang penuh div. ARIA dan manajemen fokus JavaScript datang setelahnya, setelah fondasi semantik tersedia.

Apakah HTML yang saya tempel di sini dikirim ke mana pun?

Tidak. Parsing menggunakan DOMParser bawaan browser dan analisis berjalan sepenuhnya di sisi klien. Buka tab Jaringan di DevTools dan klik Analisis, Anda akan melihat nol permintaan keluar selama linearisasi. Aman untuk template internal, halaman yang belum dirilis, atau HTML yang berisi data pelanggan.

Alat terkait

WCAG Heading Pemeriksa Aksesibilitas Resources Pembuat Palet Warna yang Dapat Diakses Pemeriksa Kontras Warna