Modul ini berfokus pada penggunaan teknologi pendukung (AT) untuk pengujian aksesibilitas. Penyandang disabilitas dapat menggunakan AT untuk membantu meningkatkan, mempertahankan, atau meningkatkan kemampuan dalam melakukan tugas.
Di ruang digital, AT dapat berupa:
- Teknologi rendah atau tanpa teknologi: tongkat kepala dan mulut, kaca pembesar genggam, perangkat dengan tombol besar
- Teknologi tinggi: perangkat yang diaktifkan dengan suara, perangkat pelacak mata, keyboard dan mouse adaptif
- Hardware: tombol akses, keyboard ergonomis, perangkat Braille yang diperbarui otomatis
- Software: program text-to-speech, teks terjemahan langsung, pembaca layar
Sebaiknya gunakan beberapa jenis AT dalam alur kerja pengujian Anda secara keseluruhan.
Dasar-dasar pengujian pembaca layar
Dalam modul ini, kita akan berfokus pada salah satu AT digital paling populer, yaitu pembaca layar. Pembaca layar adalah software yang membaca kode dasar situs atau aplikasi. Kemudian, software tersebut akan mengonversi informasi tersebut menjadi output ucapan atau Braille untuk pengguna.
Pembaca layar sangat penting bagi orang yang tunanetra dan tunarungu, tetapi juga dapat bermanfaat bagi orang yang mengalami gangguan penglihatan, gangguan membaca, dan disabilitas kognitif.
Kompatibilitas browser
Ada beberapa opsi pembaca layar yang tersedia. Pembaca layar paling populer 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 menjadi opsi terbaik. Sebagian besar pembaca layar dibuat dengan mempertimbangkan hardware dan browser web tertentu. Jika Anda menggunakan pembaca layar dengan browser yang tidak dikalibrasi untuknya, Anda mungkin akan menemukan lebih banyak "bug" atau perilaku yang tidak terduga. Pembaca layar berfungsi paling baik jika digunakan dalam kombinasi berikut.
| Pembaca layar | OS | Kompatibilitas browser |
|---|---|---|
| Job Access With Speech (JAWS) | Windows | Chrome, Firefox, Edge |
| Non-Visual Desktop Access (NVDA) | Windows | Chrome dan Firefox |
| Narrator | Windows | Edge |
| VoiceOver | macOS | Safari |
| Orca | Linux | Firefox |
| TalkBack | Android | Chrome dan Firefox |
| VoiceOver (untuk seluler) | iOS | Safari |
| ChromeVox | ChromeOS | Chrome |
Perintah pembaca layar
Setelah menyiapkan software pembaca layar dengan benar untuk perangkat desktop atau seluler, Anda harus melihat dokumentasi pembaca layar (ditautkan dalam tabel sebelumnya) dan menjalankan beberapa perintah pembaca layar penting untuk membiasakan diri dengan teknologi tersebut. Jika pernah menggunakan pembaca layar sebelumnya, pertimbangkan untuk mencoba pembaca layar baru.
Saat menggunakan pembaca layar untuk pengujian aksesibilitas, tujuan Anda adalah mendeteksi masalah dalam kode yang mengganggu penggunaan situs atau aplikasi, bukan untuk meniru pengalaman pengguna pembaca layar. Oleh karena itu, ada banyak hal yang dapat Anda lakukan dengan beberapa pengetahuan dasar, beberapa perintah pembaca layar, dan sedikit (atau banyak) latihan.
Jika perlu memahami lebih lanjut pengalaman pengguna yang menggunakan pembaca layar dan AT lainnya, Anda dapat berinteraksi dengan banyak organisasi dan individu untuk mendapatkan insight berharga ini. Ingatlah bahwa menggunakan AT untuk menguji kode terhadap sekumpulan aturan dan bertanya kepada pengguna tentang pengalaman mereka sering kali menghasilkan hasil yang berbeda. Keduanya merupakan aspek penting untuk membuat produk yang sepenuhnya inklusif.
Perintah tombol untuk pembaca layar desktop
| Elemen | NVDA (Windows) | VoiceOver (macOS) |
|---|---|---|
| Tombol perintah umum | Insert | Control+Option |
| Hentikan audio | Control | Control |
| Baca berikutnya/sebelumnya | ↓ atau ↑ | Control+Option+→ atau ← |
| Mulai membaca | Insert↓ | Control+Option+A |
| Daftar Elemen/Rotor | NVDA + F7 | Control+Option+U |
| Tempat terkenal | D | Control+Option+U |
| Judul | H | Control+Option+Command+H |
| Link | K | Control+Option+Command+L |
| Kontrol formulir | F | Control+Option+Command+J |
| Tabel | T | Control+OptionCommand+T |
| Dalam Tabel | Insert Alt + ↓ ↑ ← → | Control+Option+↓ ↑ ← → |
Perintah tombol untuk pembaca layar seluler
| Elemen | TalkBack (Android) | VoiceOver (iOS) |
|---|---|---|
| Jelajahi | Tarik satu jari di sekitar layar | Tarik satu jari di sekitar layar |
| Pilih atau aktifkan | Ketuk dua kali | Ketuk dua kali |
| Pindahkan ke atas atau ke bawah | Geser ke atas atau ke bawah dengan dua jari | Geser ke atas atau ke bawah dengan tiga jari |
| Ubah halaman | Geser ke kiri atau kanan dengan dua jari | Geser ke kiri atau kanan dengan tiga jari |
| Berikutnya/sebelumnya | Geser ke kiri atau kanan dengan satu jari | Geser ke kiri atau kanan dengan satu jari |
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 Anda menemukan beberapa error mungkin berbeda dengan cara yang dijelaskan dalam modul ini.
Langkah 1
Buka CodePen yang telah diperbarui, yang memiliki semua update aksesibilitas otomatis dan manual yang diterapkan.
Lihat dalam mode debug untuk melanjutkan
pengujian berikutnya. Hal ini penting karena akan menghapus <iframe> yang mengelilingi
halaman web demo, yang dapat mengganggu beberapa alat pengujian. Pelajari lebih lanjut tentang
mode debug CodePen.
Langkah 2
Aktifkan pembaca layar pilihan Anda dan buka halaman demo. Anda dapat mempertimbangkan untuk menavigasi 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 tempat terkenal adalah salah satu cara utama orang menavigasi menggunakan pembaca layar. Jika tidak ada, pengguna pembaca layar harus membaca seluruh halaman untuk memahami konteksnya. Hal ini dapat memerlukan banyak waktu dan menyebabkan frustrasi.
Jika mencoba menavigasi berdasarkan salah satu elemen dalam demo, Anda akan segera menemukan bahwa 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, tidak akan ada perubahan visual, tetapi pengalaman pembaca layar Anda akan meningkat secara signifikan.
Beberapa elemen yang tidak dapat diakses tidak dapat diamati hanya dengan melihat situs. Anda
mungkin ingat pentingnya tingkat judul dan HTML semantik dari
modul Struktur konten. Konten
mungkin terlihat seperti judul, tetapi konten tersebut sebenarnya dibungkus dalam <div> bergaya.
Untuk memperbaiki masalah dengan judul dan tempat terkenal, Anda harus mengidentifikasi setiap elemen yang harus ditandai sebagai judul dan tempat terkenal terlebih dahulu, lalu memperbarui HTML terkait. Pastikan untuk memperbarui CSS terkait juga.
- Contoh tempat terkenal:
<main>...</main> - Contoh judul:
<h1>Join the Club</h1>
Jika Anda telah memperbarui semuanya dengan benar, tidak akan ada perubahan visual, tetapi pengalaman pembaca layar Anda akan meningkat secara signifikan.
Masalah 2: Konteks link
Penting untuk memberikan konten kepada pengguna pembaca layar tentang tujuan link dan apakah link tersebut mengalihkan mereka ke lokasi baru di luar situs atau aplikasi.
Dalam demo kami, kami memperbaiki sebagian besar link saat memperbarui teks alternatif gambar aktif, tetapi ada beberapa link tambahan tentang berbagai penyakit langka yang dapat memperoleh manfaat dari konteks tambahan—terutama karena link tersebut mengalihkan ke lokasi baru.
<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease">
Maple syrup urine disease (MSUD)
</a>
Untuk memperbaiki masalah ini bagi pengguna pembaca layar, kami memperbarui kode untuk menambahkan informasi lebih lanjut, tanpa memengaruhi elemen visual. Atau, untuk membantu lebih banyak orang seperti mereka yang mengalami 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 kami yang hanya mendukung satu bahasa, label ARIA adalah opsi yang mudah dalam situasi ini. Anda mungkin memperhatikan bahwa label ARIA mengganti teks link asli, jadi pastikan untuk menyertakan informasi tersebut 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, Lighthouse tidak dapat mengambil SVG inline yang berfungsi sebagai gambar pembuka utama di halaman demo kami. Namun, pembaca layar menemukannya dan mengumumkannya sebagai "gambar" tanpa informasi tambahan.
Hal ini benar, bahkan tanpa menambahkan atribut role="img" secara eksplisit ke
SVG.
<div class="section-right">
<svg>...</svg>
</div>
Untuk memperbaiki masalah ini, kita harus memutuskan terlebih dahulu 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 kelebihan dan kekurangan cara terbaik untuk mengategorikan gambar dan memutuskan bahwa gambar tersebut bersifat dekoratif, yang berarti kami ingin menambahkan atau mengubah kode untuk menyembunyikan gambar. Metode cepatnya adalah menambahkan role="presentation" langsung ke gambar SVG. 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 poin
Anda mungkin memperhatikan bahwa pembaca layar membaca gambar poin CSS di bagian penyakit langka. Meskipun gambar ini tidak sama dengan yang kita bahas di modul Gambar, gambar tersebut tetap harus diubah karena mengganggu alur konten dan dapat mengganggu 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 poin untuk menyembunyikannya dari the
pembaca layar. Demikian pula, a role="none" akan berfungsi. Pastikan untuk 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, kami tidak memiliki label visual dan terprogram di kolom email pendaftaran newsletter. Ada elemen placeholder teks, tetapi elemen ini tidak menggantikan label karena tidak persisten secara visual 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 terlihat sama. Elemen label tersebut terhubung secara terprogram ke kolom formulir dan gerakan ditambahkan dengan JavaScript agar label tetap terlihat meskipun konten ditambahkan ke kolom.
<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 telah diperbarui untuk demo ini.
Sekarang, Anda dapat menggunakan pengetahuan yang telah dipelajari untuk meninjau aksesibilitas situs dan aplikasi Anda sendiri.
Tujuan dari semua pengujian aksesibilitas ini adalah untuk mengatasi sebanyak mungkin masalah yang mungkin dihadapi pengguna. Namun, hal ini tidak berarti bahwa situs atau aplikasi Anda dapat diakses sepenuhnya setelah Anda selesai. Anda akan menemukan kesuksesan terbesar dengan mendesain situs atau aplikasi dengan aksesibilitas di seluruh proses, dan menggabungkan pengujian ini dengan pengujian pra-peluncuran lainnya.