Modul ini berfokus pada penggunaan teknologi bantu (AT) untuk pengujian aksesibilitas. Penyandang disabilitas dapat menggunakan AT untuk membantu meningkatkan, mempertahankan, atau meningkatkan kemampuan dalam melakukan tugas.
Di ranah digital, AT dapat berupa:
- Tidak/Berteknologi rendah: tongkat kepala/mulut, kaca pembesar genggam, perangkat dengan tombol besar
- Teknologi tinggi: perangkat yang diaktifkan dengan suara, perangkat pelacak mata, keyboard/mouse adaptif
- Hardware: tombol akses, keyboard ergonomis, perangkat Braille yang dimuat ulang secara otomatis
- Software: program text-to-speech, teks otomatis, pembaca layar
Kami mendorong Anda untuk menggunakan beberapa jenis AT dalam keseluruhan alur kerja pengujian Anda.
Dasar-dasar pengujian pembaca layar
Dalam modul ini, kita fokus pada salah satu AT digital paling populer, yaitu pembaca layar. Pembaca layar adalah software yang membaca kode dasar situs atau aplikasi, lalu mengonversi informasi tersebut menjadi output ucapan atau Braille bagi pengguna.
Pembaca layar sangat penting bagi penyandang tunanetra dan tunanetra, tetapi juga bermanfaat bagi pengguna dengan gangguan penglihatan, gangguan membaca, atau gangguan kognitif.
Kompatibilitas browser
Ada beberapa opsi pembaca layar yang tersedia. Pembaca layar paling populer saat ini adalah JAWS, NVDA, dan VoiceOver untuk komputer desktop serta VoiceOver dan Talkback untuk perangkat seluler.
Bergantung pada sistem operasi (OS), browser favorit, dan perangkat yang Anda gunakan, satu pembaca layar mungkin merupakan opsi terbaik. Sebagian besar {i>screen reader<i} dibuat dengan mempertimbangkan perangkat keras dan {i>browser<i} web tertentu. Jika Anda menggunakan pembaca layar dengan browser yang tidak dikalibrasi, Anda mungkin menemukan lebih banyak "bug" atau perilaku tidak terduga. Pembaca layar berfungsi paling baik jika digunakan dalam kombinasi berikut.
Perintah pembaca layar
Setelah menyiapkan software pembaca layar dengan benar untuk desktop atau perangkat seluler, Anda harus melihat dokumentasi pembaca layar (ditautkan dalam tabel sebelumnya) dan menjalankan beberapa perintah pembaca layar penting untuk memahami teknologi ini. Jika Anda pernah menggunakan pembaca layar sebelumnya, pertimbangkan untuk mencoba pembaca layar yang baru.
Saat menggunakan pembaca layar untuk pengujian aksesibilitas, tujuan Anda adalah mendeteksi masalah dalam kode yang mengganggu penggunaan situs atau aplikasi Anda, bukan untuk mengemulasikan pengalaman pengguna pembaca layar. Dengan demikian, ada banyak hal yang dapat Anda lakukan dengan pengetahuan dasar, beberapa perintah pembaca layar, dan sedikit—atau banyak—latihan.
Jika Anda perlu lebih memahami pengalaman pengguna dari orang-orang yang menggunakan pembaca layar dan AT lainnya, Anda dapat terlibat dengan banyak organisasi dan individu untuk mendapatkan wawasan berharga ini. Ingatlah bahwa menggunakan AT untuk menguji kode terhadap seperangkat aturan dan menanyakan kepada pengguna tentang pengalaman mereka sering kali memberikan hasil yang berbeda. Keduanya merupakan aspek penting untuk menciptakan produk yang sepenuhnya inklusif.
Perintah tombol untuk pembaca layar desktop
Perintah kunci untuk pembaca layar seluler
Demo pengujian pembaca layar
Untuk menguji demo, kami menggunakan Safari di laptop yang menjalankan MacOS dan merekam suara. Anda dapat mengikuti langkah-langkah ini menggunakan pembaca layar apa pun, tetapi cara menemukan error mungkin berbeda dengan cara yang dijelaskan dalam modul ini.
Langkah 1
Buka CodePen yang telah diupdate, yang menerapkan semua update aksesibilitas otomatis dan manual.
Tampilkan dalam mode debug untuk melanjutkan
pengujian berikutnya. Hal ini penting karena tindakan ini akan menghapus <iframe> yang mengelilingi
halaman web demo, yang dapat mengganggu beberapa alat pengujian. Pelajari lebih lanjut mode debug CodePen.
Langkah 2
Aktifkan pembaca layar pilihan Anda dan buka halaman demo. Anda dapat mempertimbangkan untuk menjelajahi seluruh halaman dari atas ke bawah sebelum berfokus pada masalah tertentu.
Kami telah merekam pembaca layar untuk setiap masalah, sebelum dan setelah perbaikan diterapkan ke demo. Sebaiknya jalankan demo dengan pembaca layar Anda sendiri.
Masalah 1: Struktur konten
Judul dan {i>landmark<i} adalah salah satu cara utama orang bernavigasi menggunakan pembaca layar. Jika tidak ada, pengguna pembaca layar harus membaca seluruh halaman untuk memahami konteksnya. Ini bisa memakan banyak waktu dan menyebabkan frustrasi. Jika Anda mencoba menavigasi menurut salah satu elemen dalam demo, Anda akan segera menemukan bahwa elemen-elemen tersebut tidak ada.
- Contoh tempat terkenal:
<div class="main">...</div> - Contoh judul:
<p class="h1">Join the Club</p>
Jika Anda telah memperbarui semuanya dengan benar, seharusnya tidak ada perubahan visual apa pun, tetapi pengalaman pembaca layar akan meningkat secara signifikan.
Mari kita perbaiki.
Beberapa elemen yang tidak dapat diakses tidak dapat diamati hanya dengan melihat situs. Anda mungkin dapat mengingat pentingnya tingkat judul dan HTML semantik dari modul Struktur konten. Konten mungkin terlihat seperti judul, tetapi konten sebenarnya digabungkan dalam <div> bergaya.
Untuk memperbaiki masalah pada {i>heading<i} dan {i>landmark<i}, Anda harus terlebih dahulu mengidentifikasi setiap elemen yang harus di-markup seperti itu dan memperbarui HTML terkait. Pastikan untuk memperbarui CSS yang terkait juga.
Contoh tempat terkenal: <main>...</main>
Contoh judul: <h1>Join the Club</h1>
Jika Anda telah memperbarui semuanya dengan benar, seharusnya tidak ada perubahan visual apa pun, tetapi pengalaman pembaca layar akan meningkat secara signifikan.
Masalah 2: Konteks link
Penting untuk memberikan konten kepada pengguna pembaca layar terkait tujuan link dan jika link tersebut mengalihkan mereka ke lokasi baru di luar situs atau aplikasi.
Dalam demo, kami memperbaiki sebagian besar link saat memperbarui teks alternatif gambar aktif. Namun, ada beberapa link tambahan tentang berbagai penyakit langka yang dapat memanfaatkan konteks tambahan—terutama karena link tersebut dialihkan ke lokasi baru.
<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease">
Maple syrup urine disease (MSUD)
</a>
Untuk memperbaiki masalah bagi pengguna pembaca layar ini, kami memperbarui kode untuk menambahkan lebih banyak informasi, tanpa memengaruhi elemen visual. Atau, untuk membantu lebih banyak orang seperti mereka yang memiliki gangguan membaca dan kognitif, kami dapat memilih untuk menambahkan teks visual tambahan.
Ada banyak pola berbeda yang dapat kami pertimbangkan untuk menambahkan informasi link tambahan. Berdasarkan lingkungan sederhana kami yang hanya mendukung satu bahasa, label ARIA adalah pilihan yang mudah dalam situasi ini. Anda mungkin melihat bahwa label ARIA mengganti teks tautan asli, jadi pastikan untuk menyertakan informasi itu dalam pembaruan Anda.
<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease"
aria-label="Learn more about Maple syrup urine disease on the Rare Diseases website.">
Maple syrup urine disease (MSUD)
</a>
Masalah 3: Gambar dekoratif
Dalam modul pengujian otomatis kami, Lighthouse tidak dapat memilih SVG inline yang bertindak sebagai gambar pembuka utama pada halaman demo kami—tetapi pembaca layar menemukannya dan mengumumkannya sebagai "gambar" tanpa informasi tambahan. Hal ini berlaku, meskipun tanpa menambahkan atribut role="img" secara eksplisit ke SVG.
<div class="section-right">
<svg>...</svg>
</div>
Untuk memperbaiki masalah ini, pertama-tama kita harus memutuskan apakah gambar tersebut informatif atau dekoratif. Berdasarkan keputusan tersebut, kita perlu menambahkan teks alternatif gambar yang sesuai (gambar informatif) atau menyembunyikan gambar dari pengguna pembaca layar (dekoratif).
Kami mempertimbangkan pro dan kontra mengenai cara terbaik untuk mengategorikan gambar dan memutuskan bahwa gambar itu bersifat dekoratif, yang berarti kami ingin menambahkan atau mengubah kode untuk menyembunyikan gambar. Metode cepat adalah menambahkan role="presentation" ke gambar SVG secara langsung. Tindakan ini akan mengirimkan sinyal ke pembaca layar untuk melewati gambar ini dan tidak mencantumkannya dalam grup gambar.
<div class="section-right">
<svg role="presentation">...</svg>
</div>
Masalah 4: Dekorasi peluru
Anda mungkin telah melihat bahwa pembaca layar membaca gambar butir CSS di bagian penyakit langka. Meskipun bukan jenis gambar tradisional yang kami bahas dalam modul Gambar, gambar tetap harus dimodifikasi karena mengganggu alur konten dan dapat mengalihkan perhatian atau membingungkan pengguna pembaca layar.
<p class="bullet">...</p>
Sama seperti contoh gambar dekoratif yang dibahas sebelumnya, Anda dapat menambahkan role="presentation" ke HTML dengan class butir untuk menyembunyikannya dari pembaca layar. Demikian pula, role="none" akan berfungsi. Pastikan Anda tidak menggunakan aria-hidden: true atau Anda akan menyembunyikan semua informasi paragraf dari pengguna pembaca layar.
<p class="bullet" role="none">...</p>
Masalah 5: Kolom formulir
Dalam modul Formulir, kita mempelajari bahwa semua kolom formulir juga harus memiliki label visual dan terprogram. Label ini harus tetap terlihat setiap saat.
Dalam demo kami, label visual dan terprogram tidak ada pada kolom email pendaftaran newsletter. Ada elemen placeholder teks, tetapi ini tidak menggantikan label karena secara visual tidak persisten dan tidak sepenuhnya kompatibel dengan semua pembaca layar.
<form>
<div class="form-group">
<input type="email" placeholder="Enter your e-mail address" required>
<button type="submit">Subscribe</button>
</div>
</form>
Untuk memperbaiki masalah ini, ganti placeholder teks dengan elemen label yang mirip. Elemen label tersebut terhubung secara terprogram ke kolom formulir dan gerakan ditambahkan dengan JavaScript agar label tetap terlihat meskipun konten ditambahkan ke kolom tersebut.
<form>
<div class="form-group">
<input type="email" required id="youremail" name="youremail" type="text">
<label for="youremail">Enter your e-mail address</label>
<button type="submit" aria-label="Subscribe to our newsletter">Subscribe</button>
</div>
</form>
Rangkuman
Selamat! Anda telah menyelesaikan semua pengujian untuk demo ini. Anda dapat melihat semua perubahan ini di Codepen yang diperbarui untuk demo ini.
Sekarang, Anda dapat menggunakan apa yang telah Anda pelajari untuk meninjau aksesibilitas situs dan aplikasi Anda sendiri.
Pengujian aksesibilitas ini bertujuan untuk mengatasi sebanyak mungkin masalah yang mungkin dihadapi pengguna. Namun, ini tidak berarti bahwa situs atau aplikasi Anda akan dapat diakses dengan sempurna setelah Anda selesai. Anda akan meraih kesuksesan terbesar dengan mendesain situs atau aplikasi dengan aksesibilitas selama prosesnya, dan menggabungkan pengujian ini dengan pengujian pra-peluncuran lainnya.
Menguji pemahaman Anda
Uji pengetahuan Anda tentang pengujian aksesibilitas otomatis
Apa pembaca layar terbaik yang digunakan untuk menguji aksesibilitas?
Apa tujuan pengujian dengan teknologi pendukung?