Menentukan apakah situs web atau aplikasi Anda dapat diakses bisa tampak seperti tugas yang berat. Jika Anda sedang mendekati aksesibilitas untuk pertama kalinya, topik yang luas dapat membuat Anda bertanya-tanya dari mana harus memulai. Lagi pula, bekerja untuk mengakomodasi beragam kemampuan berarti ada berbagai berbagai masalah yang berbeda untuk dipertimbangkan.
Posting ini menguraikan masalah itu menjadi sebuah proses langkah demi langkah yang logis untuk meninjau situs yang ada untuk aksesibilitas.
Memulai dengan keyboard
Untuk pengguna yang tidak dapat atau memilih untuk tidak menggunakan {i>mouse<i}, navigasi {i>keyboard<i} sarana utama untuk menjangkau semua yang ada di layar. Audiens ini mencakup pengguna dengan gangguan motorik, seperti cedera stres berulang (RSI) atau kelumpuhan, serta pengguna pembaca layar (screen reader).
Untuk pengalaman {i>keyboard<i} yang baik, upayakan untuk memiliki urutan tab yang logis dan jelas gaya fokus yang jelas.
Mulai dengan menelusuri situs Anda menggunakan tombol tab. Urutan elemen yang difokuskan harus mengikuti urutan DOM. Jika Anda tidak yakin elemen mana yang harus menerima baca modul dalam kursus Mempelajari Aksesibilitas tentang fokus. Terbaik dalam praktiknya adalah kontrol apa pun yang dapat berinteraksi dengan pengguna atau memberikan input harus dapat difokuskan dan menampilkan indikator fokus (seperti cincin fokus).
Kontrol interaktif kustom harus dapat difokuskan. Jika Anda menggunakan JavaScript untuk mengubah
<div>ke dalam drop-down yang menarik, nilai ini tidak akan otomatis dimasukkan ke dalam urutan tab. Untuk membuat kontrol kustom dapat difokuskan, berikantabindex="0". Nilaitabindexyang lebih besar dari 0 mengubah urutan tab dan dapat membingungkan pengguna pembaca layar.Jadikan konten interaktif saja dapat difokuskan. Menambahkan
tabindexke non- elemen interaktif seperti {i>heading<i} memperlambat pengguna {i>keyboard<i} yang dapat melihat layar, dan tidak membantu pengguna pembaca layar karena pembaca layar yang sudah tahu untuk mengumumkannya.Jika Anda menambahkan konten baru ke halaman, arahkan fokus pengguna ke konten tersebut terlebih dahulu sehingga mereka dapat mengambil tindakan. Lihat Mengelola Fokus di Tingkat Halaman untuk contoh.
Desain situs Anda agar pengguna selalu dapat memfokuskan elemen berikutnya ketika mereka mereka inginkan. Waspadai widget pelengkapan otomatis dan konteks lain yang dapat menjebak fokus keyboard. Anda dapat menjebak fokus untuk sementara bila Anda ingin pengguna berinteraksi dengan modal dan bukan bagian lain dari laman, tetapi Anda harus selalu menyediakan cara yang dapat diakses {i>keyboard<i} untuk keluar dari modal. Lihat Modal dan Jebakan Keyboard sebagai contoh.
Jadikan kontrol fokus Anda dapat digunakan
Jika Anda sudah membuat kontrol kustom, biarkan pengguna menjangkau semua fiturnya hanya dengan menggunakan {i>keyboard<i}. {i>Read<i} Mengelola Fokus dalam Komponen teknik untuk meningkatkan akses {i>keyboard<i}.
Kelola konten di balik layar
Banyak situs memiliki konten di balik layar yang ada di DOM tetapi tidak terlihat, seperti tautan di dalam menu panel samping responsif atau tombol di dalam jendela modal yang belum ditampilkan. Membiarkan elemen ini dalam DOM dapat membuat pengalaman {i>keyboard<i} yang membingungkan, terutama bagi pembaca layar, yang mengumumkan konten di balik layar seolah-olah itu merupakan bagian dari laman.
Lihat Menangani konten di balik layar untuk mendapatkan tip untuk menangani elemen-elemen ini.
Menguji dengan pembaca layar
Meningkatkan dukungan {i>keyboard<i} umum memberikan beberapa dasar untuk langkah berikutnya, yang adalah memeriksa halaman untuk pelabelan dan semantik yang tepat serta gangguan navigasi pembaca layar.
Jika Anda tidak memahami cara markup semantik diinterpretasikan oleh teknologi, baca Struktur konten.
- Periksa semua gambar untuk teks
altyang benar. Pengecualian untuk praktik ini adalah ketika gambar pada dasarnya untuk tujuan presentasi dan bukan bagian penting dari saat ini. Untuk menunjukkan bahwa pembaca layar harus melewati gambar, setel atribut menjadi string kosong:alt="". - Centang semua kontrol untuk label. Untuk kontrol kustom, proses ini mungkin memerlukan
penggunaan
aria-labelatauaria-labelledby. Lihat Label dan Hubungan ARIA untuk contoh. - Periksa semua kontrol kustom untuk
roleyang sesuai dan ARIA yang diperlukan atribut yang mengomunikasikan status mereka. Misalnya, kotak centang kustom memerlukanrole="checkbox"danaria-checked="true|false"untuk menyampaikan status. Lihat Pengantar ARIA untuk informasi umum ringkasan tentang cara ARIA dapat memberikan semantik yang tidak ada untuk kontrol kustom. - Buat alur informasi di seluruh halaman Anda masuk akal. Karena layar pembaca menavigasi halaman dalam urutan DOM, mereka akan mengumumkan elemen apa pun yang Anda secara visual diposisikan ulang secara visual menggunakan CSS dalam urutan yang tidak masuk akal. Jika Anda memerlukan sesuatu yang muncul di awal, pindahkan secara fisik lebih awal di DOM.
- Bertujuan mendukung navigasi pembaca layar untuk semua konten di halaman. Pastikan
tidak ada bagian situs yang disembunyikan atau diblokir secara permanen dari layar
akses pembaca.
- Jika konten harus disembunyikan dari pembaca layar, misalnya, jika konten
di balik layar atau hanya presentasi, setel konten tersebut ke
aria-hidden="true". Untuk penjelasan yang lebih mendalam, lihat Menyembunyikan konten.
- Jika konten harus disembunyikan dari pembaca layar, misalnya, jika konten
di balik layar atau hanya presentasi, setel konten tersebut ke
Membiasakan diri dengan pembaca layar
Meskipun mungkin tampak sulit untuk mempelajari {i>screen reader<i}, sebenarnya mereka cukup mudah digunakan. Secara umum, sebagian besar pengembang dapat mengelolanya hanya dengan beberapa perintah-perintah tombol lainnya.
Jika Anda menggunakan Mac, lihat video tentang VoiceOver, pembaca layar yang dilengkapi dengan Mac OS. Jika Anda menggunakan PC, lihat video tentang NVDA, pembaca layar {i>open-source<i} yang mendukung donasi untuk Windows.
aria-hidden tidak mencegah fokus keyboard
Perlu dipahami bahwa ARIA hanya dapat memengaruhi semantik
element; hal ini tidak berpengaruh pada perilaku elemen. Anda dapat membuat
elemen yang disembunyikan dari pembaca layar dengan aria-hidden="true", tetapi tidak
mengubah perilaku fokus elemen tersebut. Untuk konten interaktif di luar layar,
Untuk konten interaktif di luar layar, gunakan atribut inert
untuk memastikan itu benar-benar
dihilangkan dari alur {i>keyboard<i}. Untuk {i>browser<i} lama,
menggabungkan aria-hidden="true" dengan tabindex="-1".
Elemen interaktif harus menunjukkan tujuan dan statusnya
Memberikan petunjuk visual, atau kemampuan, tentang apa yang akan dilakukan sebuah kontrol akan membantu banyak orang di berbagai perangkat beroperasi dan menavigasi situs Anda.
- Elemen interaktif, seperti tautan dan tombol, harus dapat dibedakan dari elemen non-interaktif. Sulit bagi pengguna untuk menavigasi situs atau aplikasi ketika mereka tidak dapat mengetahui apakah suatu elemen dapat diklik. Ada banyak cara yang valid untuk menunjukkan elemen-elemen interaktif. Salah satu praktik yang umum adalah menggarisbawahi tautan ke membedakannya dari teks di sekitarnya.
- Mirip dengan persyaratan fokus, elemen interaktif seperti tautan dan tombol
memerlukan status
hoveruntuk memberi tahu pengguna mouse saat pointer mereka berada di atas sesuatu dapat diklik. Namun, untuk membuat elemen-elemen ini dapat diakses oleh metode {i>input<i} lainnya, tetapi dapat dibedakan tanpa statushover.
Memanfaatkan {i>heading<i} dan {i>landmark<i}
{i>Heading<i} dan elemen {i>landmark<i} memberikan struktur semantik pada laman Anda, dan sangat meningkatkan efisiensi navigasi pengguna teknologi bantuan. Banyak pengguna pembaca layar melaporkan bahwa, ketika mereka pertama kali tiba di laman yang tidak dikenal, mereka biasanya mencoba untuk membuka judul.
Demikian pula, pembaca layar juga menawarkan kemampuan untuk melompat ke {i>landmark<i} yang penting
seperti <main> dan <nav>. Oleh karena itu, penting
untuk mempertimbangkan bagaimana
struktur laman dapat digunakan untuk
memandu pengalaman pengguna.
- Gunakan hierarki
h1-h6. Anggaplah {i>heading<i} sebagai alat untuk membuat garis besar untuk halaman Anda. Jangan mengandalkan gaya visual judul bawaan. Sebaliknya, perlakukan mereka seolah-olah semuanya memiliki ukuran yang sama dan menggunakan tingkat untuk konten primer, sekunder, dan tersier. Kemudian gunakan CSS untuk membuat sesuai dengan desain Anda. - Gunakan elemen dan peran tempat terkenal agar pengguna dapat mengabaikan konten yang berulang. Banyak
teknologi pendukung menyediakan jalan pintas
untuk melompat ke bagian tertentu pada laman,
seperti yang ditentukan oleh elemen
<main>atau<nav>. Elemen-elemen ini memiliki peran penanda implisit. Anda juga dapat menggunakan atributroleARIA untuk secara eksplisit menentukan region pada halaman, seperti dalam<div role="search">. Lihat Semantik dan navigasi konten untuk informasi lainnya contoh. - Hindari
role="application", kecuali jika Anda memiliki pengalaman menggunakannya. Peran penandaapplicationmemberi tahu teknologi pendukung untuk menonaktifkan pintasan dan melewati semua penekanan tombol ke halaman. Ini berarti kunci pembaca layar yang biasanya digunakan pengguna untuk berpindah-pindah halaman yang tidak lagi berfungsi, dan Anda harus menerapkan semua penanganan keyboard sendiri.
Meninjau judul dan penanda dengan pembaca layar
Pembaca layar, seperti VoiceOver dan NVDA, menyediakan menu konteks untuk melewati ke wilayah penting pada halaman. Saat menguji aksesibilitas, Anda dapat menggunakan menu-menu ini untuk mendapatkan gambaran umum halaman dan menentukan apakah judul telah sesuai dan {i>landmark<i} mana yang digunakan.
Untuk mempelajari lebih lanjut, lihat video pengajaran ini tentang dasar-dasar VoiceOver dan NVDA.
Mengotomatiskan proses
Menguji aksesibilitas situs secara manual bisa jadi menjemukan dan rentan kesalahan. Ada baiknya mengotomatiskan pengujian sebagai sebanyak mungkin. Anda dapat menggunakan ekstensi browser dan aksesibilitas command line rangkaian pengujian.
- Apakah halaman lulus semua pengujian dari
aXe
atau WAVE
ekstensi browser? Ada opsi lain yang tersedia, tetapi ekstensi ini
dapat menjadi tambahan yang berguna untuk
proses pengujian manual karena mereka dapat
menangani masalah halus seperti rasio kontras yang gagal dan tidak ada ARIA
.
- Jika Anda lebih suka bekerja dengan baris perintah, axis-cli menyediakan fitur yang sama sebagai ekstensi browser aXe, tetapi dapat dijalankan dari terminal Anda.
- Untuk menghindari regresi, terutama di lingkungan continuous integration, menggabungkan library seperti axis-core ke rangkaian pengujian otomatis Anda. axis-core adalah mesin yang sama dengan aXe Chrome, tetapi dalam utilitas baris perintah.
- Jika Anda menggunakan framework atau library, apakah ia menyediakan aksesibilitasnya sendiri alat? Misalnya, protractor-accessibility-plugin untuk Angular. Manfaatkan alat yang tersedia jika memungkinkan.
Menggunakan Lighthouse untuk menguji PWA
Lighthouse adalah alat yang mengukur performa progressive web app (PWA) Anda. Selain itu, skrip ini menggunakan library axis-core untuk mendukung pengujian aksesibilitasnya.
Jika Anda sudah menggunakan Lighthouse, cari aksesibilitas yang gagal pengujian dalam laporan Anda. Perbaiki kesalahan untuk meningkatkan pengalaman pengguna secara keseluruhan di situs Anda.