Modul ini berfokus pada penggunaan teknologi pendukung (AT) untuk pengujian aksesibilitas. Penyandang disabilitas dapat menggunakan AT untuk membantu meningkatkan, mempertahankan, atau meningkatkan kemampuan melakukan tugas.
Di ruang digital, AT dapat berupa:
- Tidak/Teknologi rendah: stik kepala/mulut, pembesar genggam, perangkat dengan tombol besar
- Teknologi tinggi: perangkat yang diaktifkan dengan suara, perangkat pelacak mata, keyboard/tikus adaptif
- Hardware: tombol tombol, keyboard ergonomis, perangkat Braille yang diperbarui secara otomatis
- Software: program text-to-speech, teks otomatis, pembaca layar
Kami mendorong Anda untuk menggunakan beberapa jenis AT dalam alur kerja pengujian Anda secara keseluruhan.
Dasar-dasar pengujian pembaca layar
Dalam modul ini, kita berfokus pada salah satu AT digital paling populer, yaitu pembaca layar (screen reader). Pembaca layar adalah perangkat lunak yang membaca kode yang mendasari situs atau aplikasi. Kemudian, alat ini mengonversi informasi tersebut menjadi output Braille atau ucapan bagi pengguna.
Pembaca layar sangat penting bagi pengguna tunanetra dan tunanetra, tetapi juga dapat bermanfaat bagi pengguna dengan gangguan penglihatan, gangguan membaca, atau gangguan kognitif.
Kompatibilitas browser
Ada beberapa opsi pembaca layar yang tersedia. Pembaca layar yang 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 tampil sebagai opsi terbaik. Sebagian besar pembaca layar dibuat dengan mempertimbangkan hardware dan browser web tertentu. Saat Anda menggunakan pembaca layar dengan browser yang tidak dikalibrasi, Anda mungkin menemukan lebih banyak "bug" yang tidak diinginkan atau tidak terduga. Pembaca layar berfungsi paling baik ketika digunakan dalam kombinasi berikut.
Perintah pembaca layar
Setelah menyiapkan software pembaca layar yang tepat untuk perangkat desktop atau 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 baru.
Saat menggunakan pembaca layar untuk pengujian aksesibilitas, tujuan Anda adalah mendeteksi masalah dalam kode yang mengganggu penggunaan situs atau aplikasi Anda, bukan untuk meniru pengalaman pengguna pembaca layar. Dengan demikian, ada banyak hal yang dapat Anda lakukan dengan pengetahuan dasar, beberapa perintah pembaca layar, dan sedikit—atau banyak—praktik.
Jika perlu lebih memahami pengalaman pengguna dari pengguna 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 seperangkat aturan dan bertanya kepada pengguna tentang pengalaman mereka sering kali memberikan hasil yang berbeda. Keduanya merupakan aspek penting untuk menciptakan produk yang sepenuhnya inklusif.
Perintah utama untuk pembaca layar desktop
Perintah tombol 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 Anda menemukan beberapa error mungkin berbeda dengan cara yang dijelaskan dalam modul ini.
Langkah 1
Kunjungi CodePen yang telah diupdate, yang menerapkan semua pembaruan aksesibilitas otomatis dan manual.
Lihat dalam mode debug untuk melanjutkan proses
pengujian berikutnya. Hal ini penting, karena menghapus <iframe> yang mengelilingi
halaman web demo, yang dapat mengganggu beberapa alat pengujian. Pelajari selengkapnya tentang
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 sesudah perbaikan diterapkan pada demo. Sebaiknya jalankan demo dengan pembaca layar Anda sendiri.
Masalah 1: Struktur konten
{i>Heading<i} dan {i>landmark<i} adalah salah satu cara utama navigasi orang menggunakan pembaca layar. Jika elemen ini tidak ada, pengguna pembaca layar harus membaca seluruh halaman untuk memahami konteksnya. Ini bisa memakan banyak waktu dan bisa menyebabkan frustrasi. Jika Anda mencoba bernavigasi menurut salah satu elemen dalam demo, Anda akan segera mengetahui bahwa elemen itu 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 Anda akan meningkat secara signifikan.
Mari kita perbaiki.
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 sebenarnya konten tersebut digabungkan dalam <div> bergaya.
Untuk memperbaiki masalah terkait judul dan penanda, Anda harus terlebih dahulu mengidentifikasi setiap elemen yang harus di-markup, dan memperbarui HTML terkait. Pastikan juga untuk memperbarui CSS terkait.
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 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 memanfaatkan konteks tambahan—terutama karena penyakit 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 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 opsi praktis dalam situasi ini. Anda mungkin melihat bahwa label ARIA menggantikan 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 kami, Lighthouse tidak dapat menangkap SVG inline yang bertindak sebagai gambar pembuka utama di halaman demo kami—tetapi 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, pertama-tama kami 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 tersebut 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 butir
Anda mungkin telah memperhatikan bahwa pembaca layar membaca gambar butir CSS di bawah bagian penyakit langka. Meskipun bukan jenis gambar tradisional yang kita yang dibahas dalam modul Gambar, gambar diam harus dimodifikasi 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 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 telah mempelajari bahwa semua bentuk kolom juga harus memiliki label visual dan terprogram. Label ini harus tetap terlihat setiap saat.
Dalam demo ini, kami tidak memiliki label visual dan terprogram di kolom email pendaftaran newsletter. Ada elemen placeholder teks, tetapi 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 mirip. Elemen label tersebut terhubung secara terprogram ke kolom formulir dan gerakan ditambahkan dengan JavaScript agar label tetap terlihat bahkan saat 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 terbaru untuk demo ini.
Sekarang, Anda dapat menggunakan apa yang telah Anda pelajari untuk meninjau aksesibilitas situs web dan aplikasi.
Tujuan dari semua pengujian aksesibilitas ini adalah untuk mengatasi sebanyak mungkin masalah yang mungkin mungkin dihadapi pengguna. Namun, ini tidak berarti bahwa situs atau aplikasi Anda akan dapat diakses dengan sempurna setelah selesai. Anda akan meraih kesuksesan dengan mendesain {i>website<i} atau aplikasi Anda dengan aksesibilitas sepanjang proses, dan menggabungkan pengujian ini dengan pengujian pra-peluncuran lainnya.
Menguji pemahaman Anda
Uji pengetahuan Anda tentang pengujian aksesibilitas otomatis
Pembaca layar apa yang terbaik yang digunakan untuk menguji aksesibilitas?
Apa tujuan pengujian dengan teknologi pendukung?