Cara melakukan audit aksesibilitas untuk kepatuhan WCAG
Diterbitkan: 2022-06-28WCAG (pedoman aksesibilitas konten web) dibuat oleh world wide web consortium (W3C) dan merupakan standar yang paling dikenal secara global untuk aksesibilitas.
Dalam artikel ini kami menguraikan tugas yang diperlukan untuk melakukan audit untuk memverifikasi kepatuhan dengan standar WCAG 2.1.
Aksesibilitas adalah tentang memastikan konten dan fungsionalitas situs web Anda dapat diakses oleh audiens yang lebih luas.
Sebagai contoh:
- Penghalang aksesibilitas sementara – Seseorang kehilangan kacamatanya!
- Masalah perangkat – Mereka ada di perangkat yang membatasi, misalnya ponsel
- Situasional - Sinar matahari cerah, ruangan gelap, dll
- Cacat permanen - Tidak ada penglihatan, tidak ada pendengaran, masalah kognitif, dll.
- Masalah bandwidth – Koneksi yang sangat lambat
Seperti yang Anda lihat, ada banyak bentuk disabilitas yang perlu Anda pertimbangkan.

Pedoman WCAG dipecah menjadi berikut:

Sebelum melalui setiap bagian, inilah daftar apa yang Anda perlukan untuk melakukan pengujian:
1. Dapat dipahami
- Pilihan browser termasuk teks saja (misalnya Lynx)
- Alat untuk memeriksa tag alt, heading, dll (mis. ScreamingFrog)
- Pembaca layar seperti NVDA
- Alat uji aksesibilitas situs web
- Alat pengembangan Chrome
- Akses ke pilihan perangkat
Ini tentang memastikan bahwa konten dapat diakses dalam berbagai bentuk. Misalnya, seseorang dapat melihat konten, mendengarkannya, menggunakan sentuhan untuk memahami konten, dll. Ini juga mencakup item antarmuka pengguna seperti menu dan tombol.
Alat aksesibilitas WAVE adalah salah satu dari banyak alat yang dapat digunakan untuk menemukan masalah di area ini:

Dalam contoh di atas halaman tidak cukup baik. Ini hanya memiliki 1 kesalahan dan 5 kesalahan dengan masalah kontras warna.
Satu kesalahan adalah bahwa halaman ini tidak menunjukkan bahasa.
Tetapi ada banyak hal baik di halaman itu. Misalnya, pada gambar di sebelah kanan tempat Anda melihat 2 elemen disorot dengan warna hijau, keduanya menggunakan label 'ARIA' untuk membantu pembaca layar memahami konten ini. Nanti kami akan menjelaskan lebih lanjut tentang ini.
Mari kita lihat panduan dan kriteria keberhasilannya.
Pedoman 1.1 -Menyediakan alternatif teks untuk konten non teks
Apakah ada alternatif teks untuk konten non teks?
Saat Anda memiliki konten non teks di layar, Anda perlu memverifikasi bahwa ada deskripsi untuk masing-masing elemen tersebut.
Sebelum kita memberikan contoh, saya ingin membahas ARIA yang merupakan cara memberikan deskripsi tambahan ke elemen dan hanya boleh digunakan ketika HTML standar tidak memungkinkan.
Saat Anda menggunakan HTML, Anda secara otomatis mendapatkan kontrol keybord, fokus, dll. Dan itu adalah preferensi tetapi ARIA dapat digunakan sebagai cadangan.
Apa itu ARIA?
ARIA (aplikasi internet kaya yang dapat diakses) adalah cara untuk menggambarkan konten yang tidak dapat dijelaskan secara memadai menggunakan HTML standar. Tujuan utamanya adalah untuk pembaca layar. Jika Anda dapat menggunakan HTML standar maka itu adalah pendekatan terbaik karena secara otomatis akan memberikan fokus pada elemen dan kontrol keyboard. Jika ini tidak memungkinkan, ARIA adalah alternatifnya.
Gambar Deskriptif
Citra deskriptif adalah sesuatu yang menggambarkan sesuatu yang bermakna. Misalnya gambar mobil Toyota Prius.
Jika Anda tidak dapat melihat gambarnya, maka perlu ada cara untuk menggambarkan apa yang diwakili oleh gambar ini di mana tag Alt masuk.
Di platform seperti WordPress, Anda dapat menambahkan tag alt saat mengunggah gambar:

Cukup sering kami memperbarui tag alt ini untuk memastikan kata kunci yang relevan disertakan untuk tujuan SEO, tetapi kami harus melampaui ini.
Screaming frog akan menganalisis semua gambar di situs web Anda dan menampilkan gambar mana yang tidak memiliki tag alt, tag alt duplikat, tag alt yang terlalu panjang atau tag alt yang terlalu pendek!
Anda dapat melihat gambar di samping detail gambar juga:

Gambar dekoratif
Gambar dekoratif adalah gambar yang ada untuk menyempurnakan desain tetapi tidak ada gambar yang layak untuk dijelaskan!
Gambar dekoratif harus menggunakan properti latar belakang CSS kecuali ada alasan bagus untuk menggunakan tag 'img'. Jika pembaca layar melihat properti latar belakang CSS, ia tahu untuk mengabaikan gambar.
Berikut adalah contoh gambar yang digambarkan sebagai gambar latar di situs web Dokter Darurat Saya di Australia:
Berikut kode di balik ini:


Karena gambar ini tidak terdaftar sebagai <img>, ia menggunakan role=img untuk memberi tahu pembaca layar bahwa ini adalah gambar. Ini menggunakan 'Aria-label' untuk memberikan deskripsi gambar yang akurat. Ini juga mendefinisikan gambar sebagai 'gambar latar'.
Catatan: Jika Anda menggunakan tag 'img' untuk gambar latar belakang, Anda perlu menentukan tag alt null misalnya alt=" "
Kapan sebaiknya Anda menggunakan <img> alih-alih warna latar?
Ketika gambar merupakan bagian penting dari konten, gunakan <img>. Misalnya, jika Anda memiliki gambar produk maka ini adalah <img> . Anda juga dapat memiliki gambar yang hanya gambar latar belakang yang digunakan untuk tujuan dekorasi dan tidak masuk akal untuk menggambarkannya sebagai gambar (yang akan diindeks oleh Google).
Dalam contoh di atas Anda dapat mempertanyakan apakah gambar yang ditampilkan harus didefinisikan sebagai img tetapi itu adalah foto stok dan mereka memutuskan untuk mendefinisikannya sebagai gambar latar belakang yang tidak apa-apa.
Catatan: <img> adalah tag HTML tetapi gambar latar adalah gaya CSS yang Anda gunakan.
Kontrol UI
Ada berbagai kontrol UI yang memerlukan beberapa teks untuk menjelaskan apa itu.
Misalnya, tombol atau kontrol formulir.
Tombol digunakan untuk membantu menyelesaikan suatu fungsi. Bisa berupa tombol yang hanya memiliki ikon dan tombol yang memiliki teks di dalam tombol. Keduanya bisa ditangani secara berbeda.
Menggunakan ARIA Anda dapat menentukan 'role=button' tetapi dengan HTML standar Anda dapat menggunakan tag <button>. Yang mana yang harus Anda gunakan?
Berikut adalah contoh tombol yang hanya memiliki X di dalamnya yang mengharuskan kita membuat 'aria-label' untuk menjelaskan fungsi tombol tersebut.
<button aria-label=”Tutup” onclick=”myDialog.close()”>X</button>
Berikut daftar kontrol UI umum yang perlu Anda uji:
Kategori | Contoh |
---|---|
Kontrol masukan | Kotak centang, tombol radio, daftar, tombol, bidang teks, bidang tanggal. |
Komponen navigasi | Menu, tab, remah roti, penggeser, ikon, pagination, tag, ikon, bidang pencarian, korsel |
Komponen informasi | Bilah kemajuan, tooltips, pemberitahuan, kotak pesan, jendela modal (popup), |
Wadah | Akordeon |
Jika Anda menggunakan formulir, Anda perlu memastikan bahwa setiap bidang diberi label dengan benar. Berikut adalah contoh pelabelan yang baik:
<label for="fname">Nama depan:</label><br>
<input type=”text” id=”fname” name=”fname”><br>
<label for="lname">Nama belakang:</label><br>
<input type="text" id="lname" name="lname">
</form>
Catatan: untuk formulir Anda juga harus memastikan:
- Tandai bidang wajib dengan jelas. Jika suatu bidang wajib, maka bidang itu juga perlu diberi label dengan benar di html.
- Ada instruksi untuk pengguna (biasanya di bagian atas formulir)
- Pengguna mendapatkan bantuan ketika mereka membuat kesalahan dalam mengisi bidang formulir (misalnya format tanggal yang salah, ini yang harus Anda masukkan).
captcha
Ini bisa sangat bermasalah tergantung bagaimana penerapannya. Misalnya, ketika gambar ditampilkan dan Anda diminta untuk mengidentifikasi gambar mana yang berisi lampu lalu lintas!
Kami akan meninjau implementasi dan membuat saran yang relevan.
Konten multimedia
Video/Audio membutuhkan setidaknya deskripsi untuk mengidentifikasi tentang apa video/audio tersebut.
Tautan
Anda ingin memastikan bahwa tautan terlihat jelas di halaman (misalnya warna berbeda) dan tautan tersebut menggunakan teks jangkar dan deskripsi tautan yang relevan.
Pedoman 1.2 – Media berbasis waktu
Area ini adalah tentang melayani konten video dan audio yang perlu dibuat lebih mudah diakses.
Apakah transkripsi tersedia hanya untuk audio atau video yang telah direkam sebelumnya ?
Transkripsi video adalah terjemahan audio video Anda menjadi teks. Transkripsi tidak menyertakan informasi audio yang menjelaskan hal-hal seperti visual yang ditampilkan dalam video. Ini ditangani secara terpisah.
Tip transkripsi!
Rev.com adalah layanan hebat untuk membuat teks/transkripsi untuk audio/video Anda. Mereka bahkan menyediakan layanan teks langsung untuk video Zoom.
Apakah ada teks yang tersedia untuk audio yang direkam sebelumnya?
Caption adalah teks yang muncul di dalam video untuk memberi tahu pengguna tentang apa yang dikatakan orang tersebut.

Apakah ada deskripsi audio atau media alternatif (pre-recorded) ?
Saat Anda menonton video, teks mungkin tidak cukup untuk menggambarkan apa yang ditampilkan di dalam video. Di sinilah deskripsi audio juga diperlukan.
Misalnya, deskripsi audio dapat menjelaskan apa yang terjadi di latar belakang saat seseorang berbicara sehingga memberikan konteks kepada pengguna.
Berikut adalah contoh transkripsi yang menyertakan deskripsi audio.

Ini bagus untuk pengunjung situs web Anda tetapi juga bagus untuk SEO!
Kiat untuk memilih pemutar yang dapat diakses:
Anda ingin memastikan pemutar video yang Anda gunakan mendukung apa yang diperlukan untuk aksesibilitas:
- Mendukung teks tertutup
- Deskripsi audio dapat diaktifkan/dinonaktifkan
- Kontrol kata kunci dapat digunakan di pemutar media
- Pemutar media berfungsi di berbagai perangkat dan browser
- Semua kontrol dapat diakses.
Apakah ada teks untuk audio langsung ?
Anda biasanya tidak akan memiliki konten video atau audio langsung di situs web Anda, tetapi jika Anda melakukannya, Anda harus memiliki pembuatan teks secara bersamaan sehingga pengguna dapat melihat teks yang ditampilkan saat orang tersebut berbicara.
Ada alat yang tersedia untuk membuat teks video dan audio langsung Anda secara otomatis.
Apakah ada deskripsi audio untuk media tersinkronisasi yang telah direkam sebelumnya?
Ini untuk media yang berisi video dan audio. Kami ingin informasi audio yang menyertai media.
Pedoman 1.3 – Adaptable – Menyajikan informasi dalam format yang dapat dipahami oleh perangkat lunak.
Anda perlu memastikan bahwa apa yang dapat Anda tafsirkan secara visual dengan melihat sesuatu dijelaskan secara terprogram sehingga dapat ditafsirkan dengan benar oleh perangkat lunak seperti pembaca layar.
Apakah ada struktur logis untuk konten dan apakah mudah untuk memahami hubungan dengan setiap bagian konten dalam struktur itu?
Saat Anda melihat halaman web, Anda biasanya melihat judul, paragraf, konten yang dicetak tebal, tabel, dll. Dan saat Anda melihat detail tabel, Anda melihat judul dan Anda melihat dengan jelas baris mana yang relevan dengan judul mana.
Inilah yang perlu Anda tinjau:
- Apakah konten dipecah menjadi sub judul?
- Apakah daftar, tabel dll digunakan bila sesuai?
- Apakah ada HTML yang benar yang digunakan untuk elemen struktural lain di seluruh konten?
- Apakah ada label dan teks alternatif yang digunakan sesuai kebutuhan (misalnya pada formulir?)
Tip
Titik awal yang baik adalah menguji situs web Anda menggunakan alat validator yang memeriksa html yang valid (misalnya validator html W3.org).
Berikut adalah contoh formulir yang menampilkan bidang wajib berwarna merah. Ini boleh untuk pengguna visual, tetapi bagaimana dengan seseorang yang menggunakan tampilan braille?
Untuk mengatasi masalah ini kata 'wajib' juga ditambahkan ke label untuk nama belakang yang merupakan bidang wajib.
<label for="lastname" class="required">Nama belakang (wajib): </label> <input type="text" size="25" value=""/> <style type="text/css"> .yg dibutuhkan { warna merah; } </ gaya>
Apakah ada urutan konten yang masuk akal?
- Saat Anda melihat halaman web, Anda akan melihat bilah navigasi, lalu beberapa konten, heading, sub heading, paragraf teks. Anda ingin memastikan ini disajikan dalam urutan yang masuk akal.
- Gunakan gaya heading untuk menunjukkan pentingnya bagian. Anda biasanya hanya memiliki satu gaya <h1> untuk mengidentifikasi halaman konten dan kemudian Anda mungkin memiliki beberapa H2, H3, dll.
- Pisahkan navigasi dari konten (mis., tentukan navigasi menggunakan <nav>)
- Gunakan html yang valid
Berikut adalah struktur khas heading yang masuk akal:

Dapatkah pengguna memahami konten ketika mereka tidak dapat melihat bentuk, ukuran, atau menggunakan informasi tentang bentuk atau ukuran spasial?
Cara termudah untuk menjelaskan ini adalah dengan sebuah contoh:
Katakanlah Anda memiliki tabel perbandingan fitur produk perangkat lunak dan ketika suatu produk memiliki fitur maka gambar berlian ditampilkan di kolom ini. Ini tidak cukup, Anda harus menambahkan teks untuk menunjukkan apa yang diwakili oleh berlian ini.
Apakah situs web berfungsi dengan baik dalam mode potret dan lanskap?
Situs web harus dapat beradaptasi dengan mode potret atau lanskap tanpa kehilangan makna.
Jika sebuah situs web telah menerapkan desain responsif dengan benar, maka ketika Anda mengubah orientasi, itu akan menyesuaikan dengan viewport yang berbeda (yaitu memilih tampilan yang lebih sesuai berdasarkan dimensi layar).
Apakah input ke formulir dijelaskan dengan benar?
Tujuannya adalah untuk memastikan bahwa secara terprogram ada informasi yang cukup tentang bidang apa pun yang perlu diisi dalam formulir.
Dan jika memungkinkan, aktifkan pengisian otomatis sehingga pengguna tidak harus menyelesaikan semuanya!
Bisakah tujuan elemen pada halaman diketahui secara terprogram?
Contohnya adalah menggunakan elemen 'peran' ARIA untuk bagian situs web.
Misalnya, spanduk yang berisi logo/nama perusahaan dll. dapat digambarkan sebagai 'peran=banner'.
atau menggunakan label input pada formulir untuk email, nama, alamat, dll.
Beginilah cara Anda melihatnya di HTML:
<jenis masukan=”email>
Apakah ada versi teks dari grafik apa pun?
Jika ada konten jenis grafik, Anda pasti ingin memiliki tabel yang merangkum konten ini.
Pedoman 1.4 – Lihat dan dengar konten
Ini untuk memudahkan orang melihat dan mendengar konten.
Apakah ada alternatif teks ketika warna digunakan untuk menyampaikan informasi?
Bayangkan Anda memiliki formulir dan bidang yang diperlukan ditampilkan dengan warna merah.
Ini tidak berarti banyak bagi pembaca layar!
Tapi Anda bisa menambahkan kata 'wajib' ke tabel seperti pada contoh di bawah ini:
<label for=”lastname” class=”required”>Nama belakang (wajib): </label> <input id=”lastname” type=”text” size=”25″ value="”/> <style type= ”teks/css”> .diperlukan { warna:merah; } </gaya>
Apakah ada mekanisme untuk menjeda atau menghentikan audio jika diputar lebih dari 3 detik?
Jika Anda menggunakan pembaca layar dan video diputar secara otomatis pada saat yang sama, Anda akan mendengar dua suara!
Idealnya, tidak akan ada pemutaran otomatis video yang memecahkan masalah ini.
Jika ada auto play maka pastikan kurang dari 3 detik dan jika tidak ada maka pastikan ada cara untuk mengontrol audio dari video yang diputar.
Apakah ada kontras yang baik antara teks dan gambar/warna di latar belakang?
Kita semua tahu betapa pentingnya warna dalam desain dan branding, tetapi bagi pengunjung dengan gangguan penglihatan ke situs Anda, warna tidak akan membuat banyak perbedaan pada pengalaman mereka.
Misalnya, orang buta warna tidak akan melihat perbedaan antara merah, jingga, kuning, dan hijau dan Anda juga harus memenuhinya.
Kuncinya di sini adalah memperhatikan rasio kontras yang merupakan salah satu masalah aksesibilitas paling umum yang ditemukan di situs web.
Apakah ada kontras yang cukup antara warna teks dan latar belakangnya? Alat seperti pemeriksa kontras warna dapat membantu Anda mengetahuinya!


Warna latar belakang ada di sebelah kiri dan kemudian warna teks di sebelah kanan. Skornya ada di tengah.
Rekomendasinya adalah kontras minimal 4,5:1 atau 3,1 jika teksnya besar (mis. 18 poin atau 14 poin tebal).
Selain itu, pastikan untuk menggunakan alat selain warna untuk mengomunikasikan konten dan informasi penting di situs Anda.
Misalnya, CTA utama Anda biasanya muncul di halaman karena warna yang membuat pengguna memperhatikannya. Untuk membuat CTA lebih mudah diakses, Anda dapat menggunakan ukuran, penempatan, ketebalan, kontras, untuk membuatnya terlihat oleh orang-orang dengan buta warna.
Bisakah teks dibuat lebih besar dan situs web Anda tetap berfungsi seperti biasa?
Yang jelas hanya memperbesar teks di layar untuk membantu seseorang dengan gangguan penglihatan.
Tetapi Anda ingin situs web berfungsi seperti biasa jika pengguna memperbesar ukuran teks.
Misalnya, ketika pengguna memperbesar teks hingga 400%, Anda perlu memastikan bahwa tidak ada informasi yang hilang.
Ini gambar dari W3.org. Saya yakin Anda tidak ingin situs web Anda terlihat seperti di sebelah kanan saat Anda memperbesar teks.

Persyaratan WCAG 2.1 adalah Anda harus dapat memperbesar hingga 200% tanpa masalah.
Apakah gambar teks dihindari kecuali diperlukan?
Anda mungkin memiliki logo yang berisi teks (misalnya nama perusahaan Anda) yang tidak masalah.
Tapi bagaimana dengan gambar teks?
Jika Anda memiliki gambar teks, Anda setidaknya harus memberikan label yang menjelaskannya.
Tetapi Anda lebih baik menghindari jenis gambar ini kecuali:
- Ini penting
- Ini dapat disesuaikan
Apakah situs web responsif?
Adalah normal untuk menggulir ke bawah untuk melihat halaman web penuh tetapi tidak menggulir ke kanan atau kiri.
Saat Anda berpindah dari desktop ke perangkat yang lebih kecil, layar akan secara otomatis menyesuaikan sehingga Anda tetap tidak perlu menggulir ke kanan atau kiri.
Apakah ada kontras yang cukup untuk konten non teks?
Warna yang berdekatan harus memiliki rasio kontras minimal 3:1
Persyaratan ini untuk orang dengan penglihatan yang relatif rendah.
Bisakah jarak/ketinggian garis disesuaikan tanpa kehilangan performa?
- Tinggi baris (line spacing) harus setidaknya 1,5 kali ukuran font;
- Spasi paragraf berikut harus minimal 2 kali ukuran font;
- Spasi huruf (pelacakan) harus setidaknya 0,12 kali ukuran font;
- Spasi kata harus setidaknya 0,16 kali ukuran font.
Apakah konten ditampilkan dengan benar saat mengarahkan kursor atau fokus?
Saat Anda fokus pada suatu elemen (misalnya tab ke sana) atau mengarahkan kursor ke atasnya, Anda akan melihat konten tambahan.
Misalnya, Anda mengarahkan kursor ke tombol dan munculan muncul.
…atau sub menu ditampilkan.
Konten ini harus:
Dismissable – Misalnya, jika Anda mengklik Escape, konten tidak ditampilkan lagi.
Hoverable – Saat Anda mengarahkan kursor ke konten, konten ditampilkan selama mouse berada di atas pemicu.
Persistent – Ini adalah kombinasi keduanya. Konten tetap terlihat sampai pengguna menutupnya, pengguna memindahkan mouse atau konten tidak lagi berisi informasi penting.
Catatan: Ini tidak berlaku ketika elemen HTML seperti judul ditampilkan saat Anda mengarahkan kursor ke sesuatu (misalnya gambar).
Apakah fontnya bisa dibaca?
Beberapa font/tipografi lebih mudah dibaca daripada yang lain. Ada preferensi terhadap serif atau sans serif tetapi itu tidak wajib. Mereka bagian kuncinya adalah bahwa itu dapat dibaca.
2. Dapat dioperasikan
Ini berarti pengguna harus dapat menggunakan navigasi dan antarmuka pengguna dengan berinteraksi dengannya. Misalnya, mereka dapat 'mengoperasikan' antarmuka pengguna menggunakan keyboard.
Pedoman 2.1 – Dapat diakses dengan keyboard
Banyak pengguna menggunakan keyboard alih-alih mouse atau trackpad, termasuk pengguna dengan hambatan aksesibilitas mobilitas atau mereka yang menggunakan pembaca layar.
Inilah sebabnya mengapa semua fungsi di situs web Anda harus dapat diakses melalui keyboard – tautan, tombol, formulir, dan kontrol lainnya.
Apakah semuanya dapat diakses melalui keyboard?
Sekarang saatnya untuk berhenti menggunakan mouse Anda dan hanya menggunakan keyboard Anda.
Anda sedang memeriksa:
Apakah semuanya mengikuti urutan logis maju atau mundur (menggunakan tab untuk maju dan menggeser tab untuk kembali).
Ketika Anda berada di tombol tertentu, bagian dll. Apakah Anda melihat bahwa elemen ini disorot? Dalam contoh berikut, jelas kita telah masuk ke tab 'artikel'.

Apakah semuanya dapat diakses menggunakan tombol tab dan ketika Anda menekan enter ketika Anda memiliki fokus, apakah itu mengaktifkan tindakan?
Catatan: Jika munculan muncul, Anda juga harus dapat menavigasi ini.
Bisakah Anda melewatkan header?
Saat Anda menggunakan pembaca layar, Anda tidak ingin pembaca itu membacakan header yang sama di setiap halaman. Itu akan membuatmu gila. Jadi Anda seharusnya dapat membuka tab 'Lewati ke tautan konten', tekan enter dan tab berikutnya akan melewati bagian itu.
Saat Anda mengklik tab saat pertama kali tiba di situs web di bawah ini, Anda berada di tautan 'Lewati ke konten'. Jika Anda menekan enter, Anda langsung menuju ke konten.
Jika Anda menekan tab kedua, Anda pindah ke tautan 'Lewati ke navigasi'. Jika Anda menekan enter, Anda akan dibawa ke navigasi.

Jika Anda menekan tab lagi, Anda pindah ke 'lompat ke navigasi'. Jika Anda memilih ini, Anda langsung melompat ke navigasi.
Jika ada karakter, tanda baca, angka, atau simbol yang digunakan sebagai pintasan, pasti ada cara untuk menonaktifkan atau mengubah pintasan ini menjadi satu atau lebih karakter yang tidak dapat dicetak. Satu-satunya pengecualian lainnya adalah ketika pintasan hanya tersedia ketika elemen memiliki fokus.
2.1.2 Apakah ada situasi di mana Anda menemui jalan buntu dengan keybord (perangkap keyboard) ?
Anda tab jalan ke suatu tempat di situs web dan Anda tidak dapat tab maju atau mundur.
Ini dikenal sebagai jebakan keyboard. Seperti lagunya…terperangkap dalam jebakan, tidak bisa melihat ke belakang….
Apakah ada alternatif untuk pintasan keyboard yang diterapkan menggunakan huruf?
Memiliki pintasan tombol karakter dengan seseorang yang mengandalkan keyboard untuk navigasi tidak baik karena mereka mungkin akhirnya menekannya secara tidak sengaja.
Jadi kita perlu memberikan alternatif.
a) Kemampuan untuk memetakan kembali karakter ini ke jalan pintas lain
b). Matikan
c). Ini hanya aktif ketika Anda memiliki fokus pada ini. Jadi itu berarti jika Anda menggunakan pintasan tidak ada yang terjadi kecuali Anda benar-benar menggunakannya!
Pedoman 2.2 – Waktu yang cukup
Bayangkan jika Anda menetapkan batas waktu untuk mengisi formulir tetapi hanya mempertimbangkan pengguna tanpa kebutuhan aksesibilitas. Batas waktu ini mungkin terlalu singkat.
Apakah waktunya dapat disesuaikan?
Mematikan waktu sangat ideal, tetapi dapat memperpanjangnya (yaitu ketika batas waktu hampir tercapai) atau menyesuaikannya dengan waktu baru tidak masalah.
Bisakah pengguna situs web menjeda, menghentikan, atau menyembunyikan konten yang bergerak, berkedip, atau memperbarui otomatis?
Jika bergerak/berkedip atau mengernyit dan:
sebuah). dimulai secara otomatis
b). berlangsung lebih dari 5 detik
c). disajikan secara paralel dengan konten lain
Lalu ada mekanisme untuk pause, stop atau delete.
Masalah yang sama dengan konten pembaruan otomatis.
Pedoman 2.3 – Kejang dan reaksi fisik
Pedoman ini untuk memastikan bahwa tidak ada yang dirancang yang dapat menyebabkan kejang atau reaksi fisik.
Apakah 'berkedip' di layar memenuhi pedoman?
Aturan nomor satu adalah menghindari objek yang berkedip tetapi jika itu tidak memungkinkan maka pastikan itu tidak berkedip lebih dari 3 kali dalam satu detik atau berkedip di bawah ambang batas flash umum atau merah.
Pedoman 2.4 – Dapat Dinavigasi
Ini tentang memudahkan navigasi melalui situs web.
Bisakah Anda melewati blok berulang?
Bayangkan menggunakan pembaca layar dan setiap kali membuka halaman baru, ia membacakan navigasi. Sekarang itu tidak akan menyenangkan. Jadi, Anda harus bisa melewati ini. Saya memberi contoh ini sebelumnya.
Apakah semua halaman diberi judul dengan benar?
Anda memerlukan judul deskriptif yang baik di semua halaman. Ini bagus untuk aksesibilitas tetapi juga bagus untuk SEO.
Anda dapat menggunakan Screaming Frog untuk melihat judul halaman di satu tempat:

Apakah urutan fokus mempertahankan makna?
Jika Anda menelusuri konten tetapi Anda melakukan tab dalam urutan yang tidak masuk akal, Anda harus memperbaikinya.
Bisakah Anda menentukan tujuan tautan dari teks tautan?
'Klik di sini' bukanlah teks jangkar yang sangat membantu. Anda harus memiliki kata-kata yang menggambarkan konten yang akan dituju oleh tautan tersebut.
Apa itu teks jangkar?
Saat Anda menautkan ke halaman lain di situs web Anda atau situs web eksternal, teks jangkar adalah teks yang terlihat yang Anda lihat yang terkait dengan halaman tempat Anda mengirim orang. Daripada hanya menampilkan tautan, lebih baik menampilkan teks yang sebenarnya.
Apakah ada lebih dari satu cara untuk menemukan halaman web?
Berikut beberapa contohnya:
- Peta Situs – Memiliki daftar semua halaman di peta situs
- Tautan cepat – Miliki tautan cepat untuk membuka halaman penting
- Cari – Cari untuk menemukan halaman yang relevan

Apakah fokus keyboard terlihat?
Pertanyaannya mengatakan itu semua! Ini juga tercakup dalam salah satu pedoman sebelumnya. Saat Anda membuka tab ke suatu tempat, Anda harus dapat melihat fokus secara visual di area itu.
Apakah header, body, dan footer didefinisikan dengan jelas?
Teknologi bantu harus dapat dengan jelas mengidentifikasi header, footer, dan body. Ada tag html yang mendefinisikan area ini.
Pedoman 2.5 Modalitas masukan
Pedoman ini adalah tentang antarmuka yang lebih baru di mana Anda tidak boleh menggunakan keyboard atau mouse untuk bernavigasi. Misalnya pada smartphone Anda dapat menggesek, mencubit dan memperbesar, ketuk dll.
Bisakah fungsionalitas menggunakan gerakan berbasis multipoint atau jalur dioperasikan oleh satu pointer tanpa menggunakan gerakan (kecuali penting)?
Gerakan berbasis jalur adalah tempat Anda perlu bergerak di jalur tertentu. Misalnya, Anda menggesek ke atas untuk mengakses fungsi tertentu atau ke bawah untuk mengakses yang lain. Gerakan multi-titik adalah di mana Anda menggunakan dua atau lebih titik kontak untuk mengakses fungsionalitas misalnya menggunakan 2 jari untuk mencubit dan memperbesar.
Apakah ada cara mudah untuk keluar dari tindakan yang telah dimulai oleh satu pointer?
Apa itu pointer tunggal?
Di sinilah Anda dapat mengakses fungsionalitas dengan satu titik interaksi dengan layar, misalnya ketuk, klik, tekan lama, dll.
Setidaknya salah satu dari berikut ini harus benar:
- Tidak ada acara turun – pemicu diterapkan saat Anda menekan tombol
- Abort or Undo – Anda menggunakan acara up (yaitu fungsi diaktifkan ketika pointer dilepaskan) dan ada cara untuk membatalkan. Misalnya, Anda menekan sesuatu dengan jari Anda dan alih-alih mengangkat jari Anda ke atas, Anda menggesernya ke bagian lain layar dan fungsionalitasnya dibatalkan.
- Pembalikan naik – Acara naik membalikkan acara turun
- Esensial – Menyelesaikan fungsi down event sangat penting.
Apakah label komponen yang terlihat cocok dengan nama program dari komponen itu?
Jika pengguna yang dapat melihat menggunakan teks ke ucapan, nama terprogram akan dibacakan dan akan menjadi pengalaman yang lebih baik jika ini cocok dengan label yang terlihat.
Bisakah fungsionalitas yang dioperasikan dengan gerakan atau isyarat juga dioperasikan oleh kontrol UI lainnya?
Jika Anda menggoyang atau memiringkan sesuatu untuk mengontrolnya, dapatkah Anda menggunakan kontrol UI lain untuk mengakses fungsi ini?
Dapat dimengerti
Ini tentang memastikan bahasa yang digunakan pada halaman dapat dimengerti.
3.1 Dapat dibaca
Kami mencakup hal-hal berikut:
Bisakah bahasa halaman atau bagian halaman ditentukan secara terprogram?
Anda akan melihat sesuatu seperti ini di awal halaman mana pun. 'Lang' menunjukkan bahasa halaman.
<html class="yaitu ie7″ lang="en-US">
Jika bahasa berubah pada halaman, Anda harus dapat mengidentifikasi ini juga.
3.2 Dapat diprediksi
Anda ingin UI Anda tampil dengan cara yang dapat diprediksi, tidak ada kejutan!
Apakah navigasi dalam urutan yang sama pada halaman?
Posisi navigasi pada satu halaman harus sama pada semua halaman lainnya kecuali pengguna melakukan perubahan pada navigasi.
Apakah komponen, gambar, dll. dinamai secara konsisten di seluruh halaman?
Jika Anda memiliki gambar di satu halaman dan memiliki gambar yang sama di halaman lain, maka Anda ingin gambar tersebut diberi nama yang sama.
Jika Anda memiliki beberapa halaman posting dan Anda memberi nama halaman 1, halaman 2, halaman 3 yang konsisten. Pelabelan tidak harus sama jika tidak masuk akal tetapi harus konsisten.
3.3 Bantuan Masukan
Ini tentang membantu pengguna menghindari atau memulihkan diri dari kesalahan:
Kesalahan input – Jika Anda mengetik sesuatu yang salah, Anda mungkin secara visual melihatnya salah, tetapi juga perlu ada teks yang mengidentifikasi masalah tersebut.
Label – Saat pengguna harus memasukkan teks, ada label terkait yang menjelaskan bidang tersebut.
Kesalahan input – Jika pengguna membuat kesalahan maka ada saran tentang cara memperbaikinya.
Pencegahan kesalahan – Anda harus dapat membalikkan, mendapatkan umpan balik tentang kesalahan, atau memiliki kemampuan untuk mengonfirmasi sebelum Anda mengirimkannya.
4. Kuat
Selain dapat diakses, konten Anda perlu mendukung berbagai browser, teknologi, dll.
Pedoman 4.1 Kompatibel
Ini melibatkan pengujian dengan berbagai agen pengguna dan teknologi bantu. Tes awal yang baik untuk ini adalah menggunakan alat validasi markup W3C untuk melihat apakah ada kesalahan (yaitu memvalidasi bahwa struktur/sintaks html, xhml dll sudah benar).
Berikut contoh outputnya:

Anda juga perlu menguji beberapa browser untuk memastikan konten dimuat dengan benar.
Dan juga layak memuat halaman di browser teks saja (seperti Lynx).
Bisakah semua data diurai dengan benar?
Apakah ada tag awal dan akhir yang tepat dalam bagian konten sehingga mudah untuk mengidentifikasi di mana bagian dimulai dan diakhiri?
Apakah elemen bersarang dengan benar?
Apakah ada atribut atau id duplikat yang menyulitkan untuk membedakan elemen?
Bisakah semua kontrol antarmuka pengguna dipahami oleh teknologi bantu?
Berikut adalah beberapa contoh kontrol dan apa yang perlu Anda ketahui:
- Kotak centang – apakah dicentang atau tidak?
- Fokus – Elemen apa yang memiliki fokus dan dapatkah ini dipahami secara terprogram (bukan hanya secara visual)?
Apakah pengguna disadarkan tentang pesan status yang tidak diberikan fokus dengan cara yang tidak selalu mengganggu pekerjaan?
Bayangkan jika Anda menjelajahi halaman dan saat berada di halaman itu, sebuah spanduk muncul di bagian atas situs web yang mengumumkan penjualan.
Apakah formulir dirancang dengan cara yang benar?
Untuk membuat formulir dapat diakses, Anda harus memastikan bahwa yang berikut ini diaktifkan:
- Kemampuan untuk menggunakan tab untuk menavigasi formulir
- Kemampuan untuk menggunakan tab untuk menavigasi formulir
<bentuk>
<label for="fname">Nama depan:</label><br>
<input type=”text” id=”fname” name=”fname”><br>
<label for="lname">Nama belakang:</label><br>
<input type="text" id="lname" name="lname">
</form>
- Bidang wajib yang ditandai dengan jelas. Jika suatu bidang wajib, maka bidang itu juga perlu diberi label dengan benar di html.
- Ada instruksi untuk pengguna (biasanya di bagian atas formulir)
- Pengguna mendapatkan bantuan ketika mereka membuat kesalahan dalam mengisi bidang formulir (misalnya format tanggal yang salah, ini yang harus Anda masukkan).
Ringkasan
Seperti yang Anda lihat, ada banyak hal yang harus dicakup saat menjalankan audit aksesibilitas yang komprehensif. Namun, semuanya terbayar dan manfaatnya banyak bagi bisnis Anda – mulai dari membangun citra merek yang positif hingga menjangkau audiens yang lebih luas dan meningkatkan SEO Anda.